|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
Добрый день, коллеги. Хочу обратиться к вам за помощью в выборе новой СУБД для своего проекта. Стоит отметить, что проект работает и приносит прибыль. Одна из основных проблем - это медленный поиск и агрегация данных (особенно если записей в выборке много). Теперь немного цифр. Основную нагрузку составляют 2 таблицы. 1. Таблица с 1,5 млрд записей. Каждая запись занимает около 850 байт. В табличку ежедневно добавляется ~3 млн записей и удаляется ~2,7 млн устаревших. Таким образом ежедневный прирост составляет 300 тысяч записей. По этой таблице в 99% запросов на выборку по ID/primary-key (примерно около 5 млн чтений). И еще 1% запросов это различные агрегации (в основном по дате) с фильтрами (абсолютно различными). Скорость выборки по ID критически важна, а вот скоростью агрегации можно пожертвовать в разумных пределах конечно. 2. Таблица со 200 млн записей. Каждый день в таблицу добавляется по 150 тысяч записей. Каждая запись занимает около 1500 байт. По этой таблице наоборот важнее запросы на поиск по различным полям и агрегация данных, т.к. большая часть запросов носит именно такой характер. К этой таблице в сутки происходит приблизительно 600 тысяч запросов. Итак, что посоветуете? Поскольку проект работает и приносит прибыль, то платные решения тоже имеет смысл учитывать. Большое спасибо за помощь! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2013, 18:45 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
Если исходных данных при общем хранении не перевалит более 1 тб, если их посчитать как будто они хранятся в формате CSV, то имеет смысл посмотреть бесплатную Vertica Community, которая ориентирована на добавление в реалтайм большого количества информации и поиску/агрегации по ней. Масс удаление и изменение поддерживаются, но с оговорками и считаются для аналитической БД признаком дурного тона. Если же данных может перевалить за 1 тб, то смотреть не надо, цены там начинаются для крупных компаний, в своем проекте явно не выгодно. Из достоинств: полный настоящий ANSI SQL + OLAP + ACID, бесплатную можно развернуть как на одиночный сервак, так и 3 сервера в кластере, молотить будет только в путь и на запись и на поиск и на любой вид агрегации, плюс отказоустойчивость (обеспечение 24x7 с горячей заменой выбывшего сервера). Еще можно посмотреть Apache Cassandra. Отлично молотит и на запись и на поиск, ориентация собирать и изменять в реальном времени большие массивы данных, обеспечивая быстрый поиск по ним. Как и Vertica может разворачиваться в кластер, причем даже круче - можно несколько территориально удаленных датацентров сделать и сцепить их. Есть CQL синтаксисом смахивающий на примитивный SQL с поддержкой фильтров и сортировки, может сжимать данные, так же как у Вертики реализована отказоустойчивость с горячей заменой. Но бесплатная версия не поддерживает агрегацию, для этого есть платная DataStax Enterprise версия Кассандры, поддерживающая полнотекстовый поиск и агрегацию, сколько стоит пока не знаю. Однако агрегация и поиск у этой версии не собственные, а реализованы посредством интеграции Кассандры c Solr и Hadoop, насколько это удобно, безбажно и быстро мне не известно. Еще можно посмотреть прочие MongoDB, HBase, CouchDB. Идеи по идее те же, аля BigTable, реализация разная. Ну и конечно сам Hadoop, но мне кажется для такой задачи это вообще перебор. P.S. Перечислял по убыванию сложности исходя из собственных взглядов. Могу запросто и ошибаться, 100% отвечаю за Vertica потому что плотно именно с ней работаю на больших проектах. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2013, 22:27 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
Извиняюсь, зашпарился и не правильно написал. Перечислял как раз по мере нарастания сложности :) То есть Вертика самый легкий в освоении и стартапе продукт, Hadoop получается самый тяжелый. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2013, 22:31 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
Ну 1Тб тут явно не хватит, да и удалений многовато. Вертика бесплатная явно не подойдет. А сейчас что используется? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.08.2013, 07:17 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
VovakaНу 1Тб тут явно не хватит, да и удалений многовато. Вертика бесплатная явно не подойдет. А сейчас что используется? а апдейтов нету чтоли? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.08.2013, 18:24 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
Ivan Durak, Есть, но применять надо аккуратно, не любит она этого. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2013, 07:40 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
ASCRUS, большое спасибо за развёрнутый ответ. Обязательно ознакомлюсь с предложенными вами решениями. VovakaНу 1Тб тут явно не хватит, да и удалений многовато. Вертика бесплатная явно не подойдет. А сейчас что используется? Я, конечно, не знаю их цен, но и платные решения я тоже рассматриваю. И да, сейчас используем MongoDB. К сожалению, у на таких объемах показываются всё её страшные низкоуровневые косяки. Хотя, отмечу, что при работе как с key-value она просто превосходна. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2013, 10:36 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
Ну вот Кассандра на самом деле тоже key-value, только это сверху обернуто в аналог таблиц и SQL :) Почитайте на Хабре статьи компании LifeStreet Media, там Кассандра в очень высоконагруженном проекте используется для сбора больших объемов данных, очень подробно все описано. Но кстати они же и Вертику используют, но уже для аналитической работы. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2013, 16:38 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
VovakaIvan Durak, Есть, но применять надо аккуратно, не любит она этого. это я вообще у автора хотел узнать. Что у него с апдейтами ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2013, 16:58 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
Neerrar, я бы для подобной задачи взял любую БД, поддерживающую патицирование Пусть это будет PostgreSQL или MSSQL или Oracle или... Что бы это дало? это позволило бы разные периоды разные дисковые системы. Позволило бы держать актуальные данные на быстрых дисках, а архивные на медленных. Облегчило бы удаление архивных данных (путем удаления патиций) и не блокировало бы всю таблицу, при добавлении актуальных данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2013, 16:13 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
Andrey SribnyakNeerrar, я бы для подобной задачи взял любую БД, поддерживающую патицирование Пусть это будет PostgreSQL или MSSQL или Oracle или... Что бы это дало? это позволило бы разные периоды разные дисковые системы. Позволило бы держать актуальные данные на быстрых дисках, а архивные на медленных. Облегчило бы удаление архивных данных (путем удаления патиций) и не блокировало бы всю таблицу, при добавлении актуальных данных. Andrey Sribnyak, у меня был вариант реализации на PostgreSQL. Партицировать данные я могу по дате, с этим проблем нет. Проблемы появляются тогда, когда я хочу агрегировать какую-то большую выборку. Обработка 50 млн записей занимает неадекватно большое время. Поэтому пока отложил PostgreSQL в поисках решения "из коробки". ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 08:29 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
NeerrarAndrey SribnyakNeerrar, я бы для подобной задачи взял любую БД, поддерживающую патицирование Пусть это будет PostgreSQL или MSSQL или Oracle или... Что бы это дало? это позволило бы разные периоды разные дисковые системы. Позволило бы держать актуальные данные на быстрых дисках, а архивные на медленных. Облегчило бы удаление архивных данных (путем удаления патиций) и не блокировало бы всю таблицу, при добавлении актуальных данных. Andrey Sribnyak, у меня был вариант реализации на PostgreSQL. Партицировать данные я могу по дате, с этим проблем нет. Проблемы появляются тогда, когда я хочу агрегировать какую-то большую выборку. Обработка 50 млн записей занимает неадекватно большое время. Поэтому пока отложил PostgreSQL в поисках решения "из коробки". попробуйте Greenplum. Это MPP на Постгресовском движке как раз. Перейти будет легко. А агрегировать большие выборки на нем - одно удовольствие. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 11:48 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
Neerrar, Для агрегации, давно придумали OLAP Натравите на эту базу тот же SSAS и расчеты всех этих агрегатов будут занимать доли секунды ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2013, 12:09 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
Поддержу Andrey Sribnyak по всем пункткам! Партиционирование и элементы BI на реляционных БД вполне работают! Переход на NoSQL это ж не просто так, это вам вообще всю модель данных перетрясать. Повыкидывать констрэйнты, транзакционность, продумывать вопросы конкурентного доступа к модифицируемым данным.. Вы уверены, что переход будет лёгким? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2013, 23:19 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
ASCRUS, Andrey Sribnyak, на данный момент для аналитики решил попробовать Vertica. Сейчас она очень радует производительностью. mesier, у меня и сейчас данные лежат в нереляционной субд - MongoDB. Но, к сожалению, есть ряд вещей, которые в монго меня категорически не устраивают. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2013, 12:47 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
Neerrarу меня и сейчас данные лежат в нереляционной субд - MongoDB. Но, к сожалению, есть ряд вещей, которые в монго меня категорически не устраивают. Какие же. Поделитесь опытом! ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2013, 13:06 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
Ivan Durak, перечитайте пожалуйста первый пост. Там всё описано достаточно подробно. Разве, что коллекции по привычке называю таблицами :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2013, 15:01 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
Neerrar Ivan Durak, перечитайте пожалуйста первый пост. Там всё описано достаточно подробно. Разве, что коллекции по привычке называю таблицами :) Как оказалось не всё.. Например ни слова про Монго. (было дальше в каментах, но я ответы по диагонали прочитал, не заметил) Точно так же и про "не устраивает" - в первом сообщении ни слова про это, только где-то среди каментов про некие "низкоуровневые косяки" упомянуто. Только и всего, что подходы к работе, как к настоящей реляционной БД, описаны в стартовом сообщении достаточно подробно, да.. Вы, любезнейший, в будущем поточнее формулируйте вопросы, а то на недосказанностях конечно не удивительно грубо ушибиться в ответе. Вынуждаете собеседников почувствовать себя дураками. Не красиво как-то.. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2013, 16:53 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
mesier, Ivan Durak, прошу простить великодушно, не думал ничего дурного, и уж тем более не хотел никого обидеть. В любом случае всем большое спасибо за помощь. Для статистики пока взял Vertica (и пока она очень радует), а вот с хранением пока вопрос не решил. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2013, 19:13 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
Andrey SribnyakНа том же хабре статья почти по сабжу http://habrahabr.ru/post/194434/ Тоже на выходных попалась, прочитал с нескрываемым удовольствием! ) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2013, 22:32 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
используем MS SQL (EE) + SSAS, более 5 млрд записей в самой большой таблице, система вполне неплохо работает ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2013, 09:26 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
Andrey SribnyakНа том же хабре статья почти по сабжу http://habrahabr.ru/post/194434/ Интересно почему автор прошел мимо МРР СУБД? ТС вот говорит про Вертику и я его полностью тут поддержу, это Вещь. А Hadoop ... ну если заняться нечем, то можно и на нем конечно ехать. А у меня данных больше 5 ТБ ! Ну могу только посочувствовать — вот вам без Hadoop не обойтись. Других разумных вариантов мало (хотя может хватить больших серверов со множеством жёстких дисков) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2013, 21:54 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
Критикиспользуем MS SQL (EE) + SSAS, более 5 млрд записей в самой большой таблице, система вполне неплохо работает А если будет 50 - какие прогнозы? Ничего не имею против данного решения, просто когда у меня было 3 лярда, я знал, что будет 30 и ничего не изменится, сейчас у меня за 30 местами и я знаю, что будет 300 и опять ничего не изменится в плане производительности. Только лицензии и серваки докупать в кластер :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2013, 21:57 |
|
Выбор СУБД для больших данных
|
|||
---|---|---|---|
#18+
NeerrarASCRUS, большое спасибо за развёрнутый ответ. Обязательно ознакомлюсь с предложенными вами решениями. VovakaНу 1Тб тут явно не хватит, да и удалений многовато. Вертика бесплатная явно не подойдет. А сейчас что используется? Я, конечно, не знаю их цен, но и платные решения я тоже рассматриваю. И да, сейчас используем MongoDB. К сожалению, у на таких объемах показываются всё её страшные низкоуровневые косяки. Хотя, отмечу, что при работе как с key-value она просто превосходна. Рискну предложить попробовать эволюционное решение, а именно TokuMX. Удачи ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2013, 00:52 |
|
|
start [/forum/topic.php?fid=48&fpage=11&tid=1856924]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
others: | 245ms |
total: | 391ms |
0 / 0 |