Сообщение Re[6]: каталогизация баз данных, вопрос по терминологии от 16.09.2014 10:57
Изменено 16.09.2014 11:55 Miroff
опечатался, извиняюсь что насмешил
Здравствуйте, gandjustas, Вы писали:
G>Как физически хранятся данные — детали конкретной субд. MS SQL имеет тип filetable — по сути файлы и папки для пользователя выглядит как таблица и можно работать как через SQL, так и через WinAPI.
Можно и так, особенно если вам плевать как будет развиваться приложение после того как вы его сдадите.
G>Так что для каждого типа свое хранилище — скорее вынужденная мера, чтобы обойти ограничения хранилища, чем признак ума. А иногда стремление "для каждого типа данных свое хранилище" приводит к неоправданному увеличению затрат на разработку.
Ну боль-то в основном у тех кто использует хранилище общего назначения для всего. Внезапно оказывается что картинки нужно выносить в CDN, файлы бэкапить отдельно от базы, а кэша вообще не бэкапить.
G>Потому что это замена более слабой системы на более сильную А вот заменить оракл на mysql это боль. А замена MS SQL на key-value хранилище — аццкая боль.
Зачем кому-то в здравом уме менять весь MS SQL на KV хранилище? О_о Это все равно что пытаться заменить колесо ниткой.
G>Шутишь?
Что-то такое я и предполагал
G>2-3 тыщи инсертов в секудну выдержит на быстром диске, масштабируется добавлением дисков и партиций.
Решение на KV хранилище выдает 10-30 инсертов в секунду и упирается в CPU, а не в диски. Масштабируется горизонтально шардингом по user_id. Надо будет сравнить разные хранилища на этой задаче и написать статью на хабр
M>>NoSQL на эту тему предлагает забить на P и использовать KV хранилище, а список всех возможных баннеров джойнить со списком всех просмотренных баннеров в памяти прямо из приложения.
G>если durability и масштабирование не нужно вообще, то хорошее решение. Но обычно нужно и то и другое.
В данном конкретном случае отказом партиции можно пренебречь. Оттого что ограничение частоты показа для некоторых пользователей сломается, никто не умрет.
G>Как физически хранятся данные — детали конкретной субд. MS SQL имеет тип filetable — по сути файлы и папки для пользователя выглядит как таблица и можно работать как через SQL, так и через WinAPI.
Можно и так, особенно если вам плевать как будет развиваться приложение после того как вы его сдадите.
G>Так что для каждого типа свое хранилище — скорее вынужденная мера, чтобы обойти ограничения хранилища, чем признак ума. А иногда стремление "для каждого типа данных свое хранилище" приводит к неоправданному увеличению затрат на разработку.
Ну боль-то в основном у тех кто использует хранилище общего назначения для всего. Внезапно оказывается что картинки нужно выносить в CDN, файлы бэкапить отдельно от базы, а кэша вообще не бэкапить.
G>Потому что это замена более слабой системы на более сильную А вот заменить оракл на mysql это боль. А замена MS SQL на key-value хранилище — аццкая боль.
Зачем кому-то в здравом уме менять весь MS SQL на KV хранилище? О_о Это все равно что пытаться заменить колесо ниткой.
G>Шутишь?
Что-то такое я и предполагал
G>2-3 тыщи инсертов в секудну выдержит на быстром диске, масштабируется добавлением дисков и партиций.
Решение на KV хранилище выдает 10-30 инсертов в секунду и упирается в CPU, а не в диски. Масштабируется горизонтально шардингом по user_id. Надо будет сравнить разные хранилища на этой задаче и написать статью на хабр
M>>NoSQL на эту тему предлагает забить на P и использовать KV хранилище, а список всех возможных баннеров джойнить со списком всех просмотренных баннеров в памяти прямо из приложения.
G>если durability и масштабирование не нужно вообще, то хорошее решение. Но обычно нужно и то и другое.
В данном конкретном случае отказом партиции можно пренебречь. Оттого что ограничение частоты показа для некоторых пользователей сломается, никто не умрет.
Re[6]: каталогизация баз данных, вопрос по терминологии
Здравствуйте, gandjustas, Вы писали:
G>Как физически хранятся данные — детали конкретной субд. MS SQL имеет тип filetable — по сути файлы и папки для пользователя выглядит как таблица и можно работать как через SQL, так и через WinAPI.
Можно и так, особенно если вам плевать как будет развиваться приложение после того как вы его сдадите.
G>Так что для каждого типа свое хранилище — скорее вынужденная мера, чтобы обойти ограничения хранилища, чем признак ума. А иногда стремление "для каждого типа данных свое хранилище" приводит к неоправданному увеличению затрат на разработку.
Ну боль-то в основном у тех кто использует хранилище общего назначения для всего. Внезапно оказывается что картинки нужно выносить в CDN, файлы бэкапить отдельно от базы, а кэша вообще не бэкапить.
G>Потому что это замена более слабой системы на более сильную А вот заменить оракл на mysql это боль. А замена MS SQL на key-value хранилище — аццкая боль.
Зачем кому-то в здравом уме менять весь MS SQL на KV хранилище? О_о Это все равно что пытаться заменить колесо ниткой.
G>Шутишь?
Что-то такое я и предполагал
G>2-3 тыщи инсертов в секудну выдержит на быстром диске, масштабируется добавлением дисков и партиций.
Решение на KV хранилище выдает 10-30к инсертов в секунду и упирается в CPU, а не в диски. Масштабируется горизонтально шардингом по user_id. Надо будет сравнить разные хранилища на этой задаче и написать статью на хабр
M>>NoSQL на эту тему предлагает забить на P и использовать KV хранилище, а список всех возможных баннеров джойнить со списком всех просмотренных баннеров в памяти прямо из приложения.
G>если durability и масштабирование не нужно вообще, то хорошее решение. Но обычно нужно и то и другое.
В данном конкретном случае отказом партиции можно пренебречь. Оттого что ограничение частоты показа для некоторых пользователей сломается, никто не умрет.
G>Как физически хранятся данные — детали конкретной субд. MS SQL имеет тип filetable — по сути файлы и папки для пользователя выглядит как таблица и можно работать как через SQL, так и через WinAPI.
Можно и так, особенно если вам плевать как будет развиваться приложение после того как вы его сдадите.
G>Так что для каждого типа свое хранилище — скорее вынужденная мера, чтобы обойти ограничения хранилища, чем признак ума. А иногда стремление "для каждого типа данных свое хранилище" приводит к неоправданному увеличению затрат на разработку.
Ну боль-то в основном у тех кто использует хранилище общего назначения для всего. Внезапно оказывается что картинки нужно выносить в CDN, файлы бэкапить отдельно от базы, а кэша вообще не бэкапить.
G>Потому что это замена более слабой системы на более сильную А вот заменить оракл на mysql это боль. А замена MS SQL на key-value хранилище — аццкая боль.
Зачем кому-то в здравом уме менять весь MS SQL на KV хранилище? О_о Это все равно что пытаться заменить колесо ниткой.
G>Шутишь?
Что-то такое я и предполагал
G>2-3 тыщи инсертов в секудну выдержит на быстром диске, масштабируется добавлением дисков и партиций.
Решение на KV хранилище выдает 10-30к инсертов в секунду и упирается в CPU, а не в диски. Масштабируется горизонтально шардингом по user_id. Надо будет сравнить разные хранилища на этой задаче и написать статью на хабр
M>>NoSQL на эту тему предлагает забить на P и использовать KV хранилище, а список всех возможных баннеров джойнить со списком всех просмотренных баннеров в памяти прямо из приложения.
G>если durability и масштабирование не нужно вообще, то хорошее решение. Но обычно нужно и то и другое.
В данном конкретном случае отказом партиции можно пренебречь. Оттого что ограничение частоты показа для некоторых пользователей сломается, никто не умрет.