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

Question

[egorov_a]

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

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

Хотелось бы узнать какие используются подходы для реализации данной задачи?
Услышать хороший совет по организации и структуре данных.

Comments

[Иван Шумов]

В каких операциях деградация?

[egorov_a]

Иван Шумов, долго выполняется группировка по определенным полям.
Например, запрос агрегации - фильтрация выдает ~ 17млн записей(30сек) + операция агрегации, по сути подсчет count для агрегационной группы(40сек).
А то может и дольше.

[Иван Шумов]

egorov_a, ну так это же аналитика (OLAP) на которую такие базы данных не подходят. Тут лучше применить колоночную базу

[egorov_a]

Иван Шумов, да уже есть некоторые наработки с комбинацией двух баз OLAP+OLTP.
Хотелось бы услышать какие решения вы использовали в своей практики?

[Иван Шумов]

egorov_a, разные, в зависимости от задачи. Я в основном по AWS, но если нужен on prem то всегда есть Clickhouse, Cassandra, Snowflake

[egorov_a]

Иван Шумов, да знаем про такое, пробовали. Для OLTP что используете?

[Иван Шумов]

egorov_a, в основном пресловутый MySQL, в клауде Aurora. Если не нужна реляционка то DynamoDB

[egorov_a]

Иван Шумов, понятно, спасибо :)

[Илья]

egorov_a, было бы проще если бы описали сами данные (в терминах реального мира) и типовые запросы к ним. Потому что в большинстве случаев оптимизация идет под конкретный запрос.

[egorov_a]

Илья, вся проблема состоит в том что нет конкретных запросов. Сейчас один пользователь хочет фильтровать по атрибуту А1, второй хочет узнать сколько было данных в определенный диапазон(например за последний месяц), другой делает выборку по комбинации полей + дата.
Для других задач нужно агрегировать по определенным правилам, порядка 30 типов различных агрегаций, со всевозможной фильтрацией.

[Илья]

egorov_a, нет конкретных запросов — нет конкретных решений. Поэтому я и просил описать предметную область. Нужно делать партиции, причем функцию партицирования выбирать с умом. А если не хватает, то шардировать. Для запросов которые не вписываются можно дублировать данные в другую БД. Либо все-таки разделить данные на 2 хранилища: OLTP и OLAP, например держать в Mongo последний месяц, а за все время держать ClickHouse или еще чего. В любом случае нужно сначала отойти от постановки задачи "НАМ ВАЖНО ВСЕ И СРАЗУ" к "У НАС ЕСТЬ ИЕРАРХИЯ ЗАПРОСОВ ПО ВАЖНОСТИ"

Answer 1

[Олег Фролов]

Говорят, именно в таких случаях реляционные БД показывают своё преимущество.

Comments

[egorov_a]

Денормализованная SQL таблица на 80 столбцов покажет хорошую производительность?
Вериться с трудом. Думаю будет производительность близкая к MongoDB.

[Олег Фролов]

Не все же 80 столбцов нужны для поиска. Оставите свои 30 поисковых столбцов столбцами, проиндексировав их вдоль и поперёк, а остальное сверите в JSON и храните в одном мета-поле.

[Олег Фролов]

Не подумайте, что я фанат реляционной модели данных, я наоборот поклонник постреляционных многомерных СУБД. Просто данное заявление сделал в силу того, что некоторое время назад общался с программером из большой компании, который и сказал, что Mongo у них не показала должной призводительности на реалтайме, поэтому они используют реляционных подход. Запросов у них десятки тысяч в секунду...

Answer 2

[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 полям и их возможным комбинациям

Индексы по полям и комбинациям.
См. план запроса чтобы понять какие именно индексы нужны.

Comments

[egorov_a]

Для современного железа и современного СУБД - это ерунда.

Пожалуйста конкретизируете что вы понимаете под современном железом. Задача стоит с минимальными ресурсами добиться максимально производительности.

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

Конечно, это все давно используется.

Это троллинг?

Нет это не тролинг, речь идет о тяжелых агрегационных запросов для сотем милионов записей. Для обычной операции поиска желаемое время до 5сек

Индексы по полям и комбинациям.

Как говорил раньше индексы есть, как single так и сompound.

[zavodp]

egorov_a,

Пожалуйста конкретизируете что вы понимаете под современном железом. Задача стоит с минимальными ресурсами добиться максимально производительности.

Не думаю. Тут скорее или исполнитель или заказчик не правильно поняли/сформулировали.
Дело в том, что можно заставить летать хоть и на RapsberryPi, но стоимость разработки будет столь велика, что никакое дешёвое железо не окупится.
проверил тут https://ruweb.net/vds на тарифе KVMz-MINI том, что за 480 рублей в месяц.
У меня прямо сейчас тянет до 5000 запросов к СУБД PostgreSQL в секунду.
Размер СУБД - 50 Г

[zavodp]

egorov_a,

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

Конечно, это все давно используется.

1) Индексы должны быть не от балды, а соответствовать запросам. См. план запроса - а используются ли вооще индексы.
2) Не верю.

[zavodp]

egorov_a,

Нет это не тролинг, речь идет о тяжелых агрегационных запросов для сотем милионов записей. Для обычной операции поиска желаемое время до 5сек

Агрегацию еще могу поверить.
Но если у вас время простого поиска исчисляется в секундах - что-то вы не так делаете.

См. план запроса.

[zavodp]

egorov_a,

Как говорил раньше индексы есть, как single так и сompound.

А вот теперь проверяйте - используются ли индексы.
См. план запроса: https://docs.mongodb.com/manual/core/query-plans/

[egorov_a]

zavodp, план запроса я смотрел - при чтение индексы используются. Оптимизировал некотрые запросы, путем добавления составного индекса.
Дело в том что на каждый запрос фильтрации , по мимо самих данных, необходимо отдавать общий count для всей выборки.

2) Не верю.

ваше право ;)

[zavodp]

egorov_a,

необходимо отдавать общий count для всей выборки.

А это только кэшировать.
Или заранее расчитывать.
С count все СУБД долго работают.

[egorov_a]

zavodp, count кешируется в redis с ttl. Первый запрос все равно выполняется долго.

Или заранее расчитывать.

Как я понимаю это расчет для целевых запросов? Весь массив всевозможных комбинаций входных параметров невозможно покрыть(и это неправильно).

[zavodp]

egorov_a,

Как я понимаю это расчет для целевых запросов? Весь массив всевозможных комбинаций входных параметров невозможно покрыть(и это неправильно).

Правильно или не правильно зависит от ваших потребностей.
Если нужно чтобы было очень быстро - то это нормально.

Не обязательно рассчитывать сразу итоговые числа.
Можно рассчитать по частичным срезам, чтобы потом эти данные использовать для итоговых окончательных расчетов.

Answer 3

[Сергей]

ClickHouse рассмотрите

Comments

[egorov_a]

Да смотрели, работает бысто, но есть свои нюансы при работе с этой БД.
Клик это про аналитику, поэтому нужно хорошее OLTP решение. Думал над тем чтобы использовать MongoDB, с прехешем для униикальных ключей, на уровне приложения.

[Дима]

"и делать всевозможные агрегационные операции с данными. На таких данных очень долго выполняется операция count." - column store базы как раз и придумали для таких операций - агрегации и group by

Answer 4

[Frozen Coder]

Можно вынести поиск в elasticSearch, который будет возвращать идентификаторы документов, а уже по ним быстро доставать документы из монги.

Ну и про OLAP вам уже написали

Comments

[egorov_a]

Делали подобное, но со связкой clickhouse + hbase. Работало быстро, но и ресурсов сжирало немерено. Думаю над тем что бы использовать MongoDB как key-value.

[zavodp]

egorov_a,

Думаю над тем что бы использовать MongoDB как key-value.

Если у вас по множеству полей выборка, да еще и с агрегацией - то движки key-value плохо с этим работают.

[egorov_a]

zavodp, агрегацию и поиск выполнять на OLAP БД, потом лезть в key-value. Это я имел ввиду.

[zavodp]

egorov_a,

агрегацию и поиск выполнять на OLAP БД, потом лезть в key-value. Это я имел ввиду.

А с поиском - OLAP плохо работает.
При этом key-value по индексированным ключам отлично ищет.

[Дима]

zavodp, по индексированным ключам все отлично ищут

Answer 5

[tester12]

За MongoDB не скажу. Но общее направление очевидно:
- планы запросов (используются ли индексы? или перебирается вся таблица?)
- дисковые операции (возможно, имеет смысл купить SSD с лучшим показателем IOPS).
- масштабирование (организовать несколько slave-реплик и распределять "поисковую" нагрузку между ними)
- денормализация (создать поля и таблицы со "вторичными" данными; например, с количеством товаров; тогда, возможно, удастся обойтись без операций count или сократить кол-во этих операций)
- логика приложения (возможно, без каких-то операций можно обойтись)

Answer 6

[Дима]

Я бы тоже смотрел в сторону Clickhouse или другой column-store СУБД (вместо того, чтобы делать классическую DWH-снежинку).
Ради прикола еще я бы попробовал записать эту таблицу "порядка 80 полей" в партиционированный Parquet и вычитывал бы столбцы в таблицы Apache Arrow по мере необходимости (с языком обвязки по вкусу, там кажется все языки есть). Думаю производительность будет сравнима с Clickhouse, ну или уж точно лучше MongoDB. Вот бенчмарки двухлетней давности. Если кластера не надо, то и Spark там не нужен.