Проектирования СУБД для хранения больших объемов?

Столкнулся с проблемой проектирования БД для большого массива данных, речь про миллиарды записей(на данный момент 200млн). Стандартные решения на таких объемах начинают деградировать по скорости вставки/чтения(очень важно).
Приемлемое время отклика до 20 сек, конечно чем быстрее - тем лучше.
Данные хранятся в одном ЦОДе. Сейчас 10-50 запросов/сек. В ближайщем будующем около 100запр/сек.

В данный момент используется MongoDB. Стурктура данных выглядит след образом(буду писать в терминах монги) - документе порядка 80 полей, с типом string, datetime, int, float, null, boolean. У записи есть уникальный ключ, с типом string(длиной в 30 символов). Поиск осуществляется по 30 полям и их возможным комбинациям. Необходимо читать в режиме реалтайм и делать всевозможные агрегационные операции с данными. На таких данных очень долго выполняется операция count.

Хотелось бы узнать какие используются подходы для реализации данной задачи?
Услышать хороший совет по организации и структуре данных.
  • Вопрос задан
  • 733 просмотра
Пригласить эксперта
Ответы на вопрос 6
Digiport
@Digiport
WebBasic CMS
Говорят, именно в таких случаях реляционные БД показывают своё преимущество.
Ответ написан
@zavodp
для большого массива данных, речь про миллиарды записей(на данный момент 200млн).

Это никакие не "большие данные".
Для современного железа и современного СУБД - это ерунда.

Стандартные решения на таких объемах начинают деградировать по скорости вставки/чтения(очень важно).

Для чтения - индексы.
Для вставки - bulk loading

Приемлемое время отклика до 20 сек, конечно чем быстрее - тем лучше.

Это троллинг?
Или вы нам пишете из 1960 годов?

Данные хранятся в одном ЦОДе. Сейчас 10-50 запросов/сек. В ближайщем будующем около 100запр/сек.

Это не нагрузка вообще. Смешно.

В данный момент используется MongoDB. Стурктура данных выглядит след образом(буду писать в терминах монги) - документе порядка 80 полей, с типом string, datetime, int, float, null, boolean. У записи есть уникальный ключ, с типом string(длиной в 30 символов). Поиск осуществляется по 30 полям и их возможным комбинациям. Необходимо читать в режиме реалтайм и делать всевозможные агрегационные операции с данными. На таких данных очень долго выполняется операция count.

Индексы.
А для агрегаций - подготовленные данные использовать. Count - всегда медленно, поскольку это полный перебор. Считать заранее, сохранять во вспомогательных данных.
Смысла нет использовать MongoDB, если только вы не собираетесь это по огромному кластеру размазывать. Там и будет преимущество Монги.
На 1-2-3 серверах классические реляционные СУБД типа PostgreSQL имеют преимущество перед Mongo.

Поиск осуществляется по 30 полям и их возможным комбинациям

Индексы по полям и комбинациям.
См. план запроса чтобы понять какие именно индексы нужны.
Ответ написан
begemot_sun
@begemot_sun
Программист в душе.
ClickHouse рассмотрите
Ответ написан
@frozen_coder
Java-developer
Можно вынести поиск в elasticSearch, который будет возвращать идентификаторы документов, а уже по ним быстро доставать документы из монги.

Ну и про OLAP вам уже написали
Ответ написан
@tester12
За MongoDB не скажу. Но общее направление очевидно:
- планы запросов (используются ли индексы? или перебирается вся таблица?)
- дисковые операции (возможно, имеет смысл купить SSD с лучшим показателем IOPS).
- масштабирование (организовать несколько slave-реплик и распределять "поисковую" нагрузку между ними)
- денормализация (создать поля и таблицы со "вторичными" данными; например, с количеством товаров; тогда, возможно, удастся обойтись без операций count или сократить кол-во этих операций)
- логика приложения (возможно, без каких-то операций можно обойтись)
Ответ написан
@v_m_smith
лучше бы я пил и курил
Я бы тоже смотрел в сторону Clickhouse или другой column-store СУБД (вместо того, чтобы делать классическую DWH-снежинку).
Ради прикола еще я бы попробовал записать эту таблицу "порядка 80 полей" в партиционированный Parquet и вычитывал бы столбцы в таблицы Apache Arrow по мере необходимости (с языком обвязки по вкусу, там кажется все языки есть). Думаю производительность будет сравнима с Clickhouse, ну или уж точно лучше MongoDB. Вот бенчмарки двухлетней давности. Если кластера не надо, то и Spark там не нужен.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы