powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / NoSQL, Big Data [игнор отключен] [закрыт для гостей] / Выбор СУБД для больших данных
25 сообщений из 34, страница 1 из 2
Выбор СУБД для больших данных
    #38379158
Neerrar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый день, коллеги.

Хочу обратиться к вам за помощью в выборе новой СУБД для своего проекта. Стоит отметить, что проект работает и приносит прибыль.
Одна из основных проблем - это медленный поиск и агрегация данных (особенно если записей в выборке много).

Теперь немного цифр. Основную нагрузку составляют 2 таблицы.
1. Таблица с 1,5 млрд записей. Каждая запись занимает около 850 байт. В табличку ежедневно добавляется ~3 млн записей и удаляется ~2,7 млн устаревших. Таким образом ежедневный прирост составляет 300 тысяч записей.
По этой таблице в 99% запросов на выборку по ID/primary-key (примерно около 5 млн чтений). И еще 1% запросов это различные агрегации (в основном по дате) с фильтрами (абсолютно различными).
Скорость выборки по ID критически важна, а вот скоростью агрегации можно пожертвовать в разумных пределах конечно.
2. Таблица со 200 млн записей. Каждый день в таблицу добавляется по 150 тысяч записей. Каждая запись занимает около 1500 байт.
По этой таблице наоборот важнее запросы на поиск по различным полям и агрегация данных, т.к. большая часть запросов носит именно такой характер.
К этой таблице в сутки происходит приблизительно 600 тысяч запросов.

Итак, что посоветуете? Поскольку проект работает и приносит прибыль, то платные решения тоже имеет смысл учитывать.

Большое спасибо за помощь!
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38379311
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если исходных данных при общем хранении не перевалит более 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 потому что плотно именно с ней работаю на больших проектах.
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38379313
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Извиняюсь, зашпарился и не правильно написал. Перечислял как раз по мере нарастания сложности :) То есть Вертика самый легкий в освоении и стартапе продукт, Hadoop получается самый тяжелый.
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38380565
Фотография Vovaka
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну 1Тб тут явно не хватит, да и удалений многовато. Вертика бесплатная явно не подойдет. А сейчас что используется?
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38381577
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
VovakaНу 1Тб тут явно не хватит, да и удалений многовато. Вертика бесплатная явно не подойдет. А сейчас что используется?
а апдейтов нету чтоли?
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38381885
Фотография Vovaka
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan Durak,

Есть, но применять надо аккуратно, не любит она этого.
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38382020
Neerrar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ASCRUS, большое спасибо за развёрнутый ответ. Обязательно ознакомлюсь с предложенными вами решениями.

VovakaНу 1Тб тут явно не хватит, да и удалений многовато. Вертика бесплатная явно не подойдет. А сейчас что используется?
Я, конечно, не знаю их цен, но и платные решения я тоже рассматриваю.

И да, сейчас используем MongoDB. К сожалению, у на таких объемах показываются всё её страшные низкоуровневые косяки.
Хотя, отмечу, что при работе как с key-value она просто превосходна.
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38382612
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну вот Кассандра на самом деле тоже key-value, только это сверху обернуто в аналог таблиц и SQL :) Почитайте на Хабре статьи компании LifeStreet Media, там Кассандра в очень высоконагруженном проекте используется для сбора больших объемов данных, очень подробно все описано. Но кстати они же и Вертику используют, но уже для аналитической работы.
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38382642
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
VovakaIvan Durak,

Есть, но применять надо аккуратно, не любит она этого.
это я вообще у автора хотел узнать. Что у него с апдейтами
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38384323
Andrey Sribnyak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Neerrar,

я бы для подобной задачи взял любую БД, поддерживающую патицирование
Пусть это будет PostgreSQL или MSSQL или Oracle или...

Что бы это дало?
это позволило бы разные периоды разные дисковые системы.
Позволило бы держать актуальные данные на быстрых дисках, а архивные на медленных.
Облегчило бы удаление архивных данных (путем удаления патиций) и не блокировало бы всю таблицу, при добавлении актуальных данных.
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38386124
Neerrar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Andrey SribnyakNeerrar,

я бы для подобной задачи взял любую БД, поддерживающую патицирование
Пусть это будет PostgreSQL или MSSQL или Oracle или...

Что бы это дало?
это позволило бы разные периоды разные дисковые системы.
Позволило бы держать актуальные данные на быстрых дисках, а архивные на медленных.
Облегчило бы удаление архивных данных (путем удаления патиций) и не блокировало бы всю таблицу, при добавлении актуальных данных.
Andrey Sribnyak, у меня был вариант реализации на PostgreSQL. Партицировать данные я могу по дате, с этим проблем нет. Проблемы появляются тогда, когда я хочу агрегировать какую-то большую выборку. Обработка 50 млн записей занимает неадекватно большое время.
Поэтому пока отложил PostgreSQL в поисках решения "из коробки".
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38386349
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NeerrarAndrey SribnyakNeerrar,

я бы для подобной задачи взял любую БД, поддерживающую патицирование
Пусть это будет PostgreSQL или MSSQL или Oracle или...

Что бы это дало?
это позволило бы разные периоды разные дисковые системы.
Позволило бы держать актуальные данные на быстрых дисках, а архивные на медленных.
Облегчило бы удаление архивных данных (путем удаления патиций) и не блокировало бы всю таблицу, при добавлении актуальных данных.
Andrey Sribnyak, у меня был вариант реализации на PostgreSQL. Партицировать данные я могу по дате, с этим проблем нет. Проблемы появляются тогда, когда я хочу агрегировать какую-то большую выборку. Обработка 50 млн записей занимает неадекватно большое время.
Поэтому пока отложил PostgreSQL в поисках решения "из коробки".
попробуйте Greenplum. Это MPP на Постгресовском движке как раз. Перейти будет легко. А агрегировать большие выборки на нем - одно удовольствие.
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38386398
Andrey Sribnyak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Neerrar,

Для агрегации, давно придумали OLAP
Натравите на эту базу тот же SSAS
и расчеты всех этих агрегатов будут занимать доли секунды
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38399453
mesier
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Поддержу Andrey Sribnyak по всем пункткам! Партиционирование и элементы BI на реляционных БД вполне работают!
Переход на NoSQL это ж не просто так, это вам вообще всю модель данных перетрясать.
Повыкидывать констрэйнты, транзакционность, продумывать вопросы конкурентного доступа к модифицируемым данным..
Вы уверены, что переход будет лёгким?
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38401325
Neerrar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ASCRUS, Andrey Sribnyak,
на данный момент для аналитики решил попробовать Vertica. Сейчас она очень радует производительностью.

mesier,
у меня и сейчас данные лежат в нереляционной субд - MongoDB. Но, к сожалению, есть ряд вещей, которые в монго меня категорически не устраивают.
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38401368
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Neerrarу меня и сейчас данные лежат в нереляционной субд - MongoDB. Но, к сожалению, есть ряд вещей, которые в монго меня категорически не устраивают.
Какие же. Поделитесь опытом!
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38401589
Neerrar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ivan Durak, перечитайте пожалуйста первый пост.
Там всё описано достаточно подробно. Разве, что коллекции по привычке называю таблицами :)
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38401812
mesier
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Neerrar Ivan Durak, перечитайте пожалуйста первый пост.
Там всё описано достаточно подробно. Разве, что коллекции по привычке называю таблицами :)
Как оказалось не всё..
Например ни слова про Монго. (было дальше в каментах, но я ответы по диагонали прочитал, не заметил)
Точно так же и про "не устраивает" - в первом сообщении ни слова про это, только где-то среди каментов про некие "низкоуровневые косяки" упомянуто.
Только и всего, что подходы к работе, как к настоящей реляционной БД, описаны в стартовом сообщении достаточно подробно, да..

Вы, любезнейший, в будущем поточнее формулируйте вопросы, а то на недосказанностях конечно не удивительно грубо ушибиться в ответе. Вынуждаете собеседников почувствовать себя дураками. Не красиво как-то..
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38405118
Neerrar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mesier, Ivan Durak, прошу простить великодушно, не думал ничего дурного, и уж тем более не хотел никого обидеть.

В любом случае всем большое спасибо за помощь.
Для статистики пока взял Vertica (и пока она очень радует), а вот с хранением пока вопрос не решил.
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38405289
Andrey Sribnyak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На том же хабре статья почти по сабжу

http://habrahabr.ru/post/194434/
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38405326
mesier
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andrey SribnyakНа том же хабре статья почти по сабжу
http://habrahabr.ru/post/194434/
Тоже на выходных попалась, прочитал с нескрываемым удовольствием! )
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38406794
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
используем MS SQL (EE) + SSAS, более 5 млрд записей в самой большой таблице,
система вполне неплохо работает
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38409036
Фотография Vovaka
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andrey SribnyakНа том же хабре статья почти по сабжу

http://habrahabr.ru/post/194434/

Интересно почему автор прошел мимо МРР СУБД? ТС вот говорит про Вертику и я его полностью тут поддержу, это Вещь. А Hadoop ... ну если заняться нечем, то можно и на нем конечно ехать.

А у меня данных больше 5 ТБ !
Ну могу только посочувствовать — вот вам без Hadoop не обойтись. Других разумных вариантов мало (хотя может хватить больших серверов со множеством жёстких дисков)
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38409037
Фотография Vovaka
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Критикиспользуем MS SQL (EE) + SSAS, более 5 млрд записей в самой большой таблице,
система вполне неплохо работает

А если будет 50 - какие прогнозы? Ничего не имею против данного решения, просто когда у меня было 3 лярда, я знал, что будет 30 и ничего не изменится, сейчас у меня за 30 местами и я знаю, что будет 300 и опять ничего не изменится в плане производительности. Только лицензии и серваки докупать в кластер :)
...
Рейтинг: 0 / 0
Выбор СУБД для больших данных
    #38409134
lookat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
NeerrarASCRUS, большое спасибо за развёрнутый ответ. Обязательно ознакомлюсь с предложенными вами решениями.

VovakaНу 1Тб тут явно не хватит, да и удалений многовато. Вертика бесплатная явно не подойдет. А сейчас что используется?
Я, конечно, не знаю их цен, но и платные решения я тоже рассматриваю.

И да, сейчас используем MongoDB. К сожалению, у на таких объемах показываются всё её страшные низкоуровневые косяки.
Хотя, отмечу, что при работе как с key-value она просто превосходна.

Рискну предложить попробовать
эволюционное решение,
а именно TokuMX.

Удачи
...
Рейтинг: 0 / 0
25 сообщений из 34, страница 1 из 2
Форумы / NoSQL, Big Data [игнор отключен] [закрыт для гостей] / Выбор СУБД для больших данных
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]