Порекомендуйте подходящую базу данных?

День добрый.

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

Дано
Имеется некая аналитическая система которая работает на нескольких сайтах. Она для каждой страницы, для каждого элемента сохраняет некую статистику (к примеру, сколько раз элемент был виден, сколько раз на него кликнули и т.д., но в целом это не так важно). Все данные аггрегируются в памяти, а затем раз в сутки скидываются в табличку в БД. Затем аналитики могут генерировать отчет за определенный период для определенного сайта + определенной страницы + определенного сегмента. Либо за определенный период для определенного сайта + определенной страницы + отдельного элемента.

Структура таблицы примерно такая:
1. ID сайта
2. ID страницы
3. ID елемента
4. Дата (день)
5. ID сегмента пользователя (все пользователи поделены на некое количество разных сегментов)
6+. Все остальные поля с данными

На данный момент мы используем Amazon Aurora (MySQL 5.7) с движком InnoDB
Поля с 1-5 это первичный ключ.
Ежедневно в таблицу записывается порядка 80М строчек (но это не конечная цель, в будущем возможна запись и намного большего количества)
Запись оптимизированна и происходит блоками по 1000 строчек в каждом INSERT запросе.

Проблемы текущего подхода
1. Когда таблица пустая, то запись такого количества данных занимает несколько часов, но уже через месяц, из-за увеличения индекса, скорость падает до примерно 12 часов. Т.е. если данных будет в 2 раза больше, то уже не получится вложиться в 24 часовое окно, когда еще не закончилась запись предыдущего дня, а надо уже писать следующий.
2. Скорость генерации отчет оставляет желать лучшего. Для страницы с большим количеством элементов, генерация репорта за месяц может занимать 2-3 минуты, это слишком долго.
3. Иногда нужно удалить данные для определенного сайта, изза огромного количества данных такая процедура блокирует не только саму таблицу, но и всю БД, в которой еще много других таблиц к которым постоянно идет обращение чтение/запись. Пытались решить данную проблему партицированием, но это не особо помогло.

Какие будут предложения?
  • Вопрос задан
  • 617 просмотров
Пригласить эксперта
Ответы на вопрос 8
@rPman
которые при генерации отчета как либо аггрегируются.
это чуть ли не наисложнейшая задача для баз данных, 80м записей тем более

Партицируйте прямо по суткам.

Убирайте транзакции, нафиг вам тут innodb когда хватит myisam, оно на запись быстрее, у вас база write once read ... тоже once.

У вас там база данных упирается случайно не в работу с диском? в облаке можно взять несколько дисков, они будут независимыми, раскидай по ним таблицы (myisam штатно поддерживает симлинки), что может дать прирост в скорости в разы только за счет этого, даже если они ssd, например отделить хранение индексов от данных или отделить старые данные от сегодняшних.

На время обработки аналитики можно потюнить файловую систему и отключить flush для файлов таблиц (например ext4 data writeback и можно отключить журнал) - сильно ускоряет именно запись, особенно если много ram, это включает большой риск потери/порчи данных при сбросе ос но с другой стороны вероятность этого очень мала и как я понимаю, данные в базу и так пишутся из какого то другого хранилища, т.е. при проблеме с сервером просто перезапускается обработка за текущие сутки.

Уберите индексы на запись, все, сначала пусть идет вставка данных без их индексации, затем создаете индекс (это на порядок быстрее) и уже потом строите аналитику.

Общая аналитика должна не работать с самими данными, а с их посуточной выжимкой (возможно в результате и хранить их не придется) считай это самодельные индексы. Грубо говоря если в запросе на аналитику стоит count,max,min,.. то достаточно сложить посуточные значения и для глобальных считать уже по ним... само собой если запросы с условиями и сложными группировками, то надо думать но все решаемо.. грубый пример нужно считать агрегацию по часам, вот в индексы и пиши суточные значения по часам, а если надо постранично то для каждой страницы для каждых суток считаешь, потом агрегируешь уже по этим результатам.
Ответ написан
@AndromedaStar
.Net - monkey
У вас задача, которая решается с помощью OLAP.
Поэтому копать нужно в эту сторону, решений достаточно много.
Ответ написан
Комментировать
sgjurano
@sgjurano
Разработчик
Для OLAP нагрузки в последнее время активно используют Clickhouse — у него довольно высокий порог вхождения, зато бесплатный и производительность того стоит.
Ответ написан
Комментировать
AlexNest
@AlexNest
Работаю с Python/Django
Может, вам лучше посмотреть в сторону noSQL (mongoDB, firebase и т.д.)?
https://habr.com/ru/sandbox/113232/
Ответ написан
Вам не нужна бд в принципе.
При собеседование почему-то у программистов в 100% случаев возникает тупик в вопросе для чего нужна mysql
и когда спрашиваешь почему именно его используют до вопроса с транзакциями не доходит практически никогда.
А ведь именно из-за них ее используют.
Так вот тут у вас транзакции не нужны. Тупо 1 инсерт
Как следствие вам хватит и обычного лог файла который можно удобно парсить, дабы для этого вообще не требуется никакого ПО. да и того в достатке.
Ротация логов и тд и тп, в общем это до вас придумали.
Так же для ваших целей и яндекса и гугла есть соответствующие инструменты ( особенно у гугла с отчётами и подобной хренью, не понимаю зачем вам вообще держать эти данные локально)
Ответ написан
Adamos
@Adamos
Если по полям 6+ на самом деле не производится выборка, а только пишутся-читаются данные, можно попробовать собрать поля 3 и 6+ в один блоб (JSON, например). Уменьшится нагрузка на запись, в отчетах будет больше возни, но меньше обращений к базе...
Ответ написан
Jeer
@Jeer
уверенный пользователь
Для бигдаты часто используется hive, например, озеро данных в налоговой, поковыряйте в эту сторону.
Но вообще, под ваши требования нужно выбирать не базы, а OLAP решения
Ответ написан
Комментировать
@mayton2019
Bigdata Engineer
Бигдата и индексы - обычно не дружат друг с другом. Антагонизмы по сути. Поэтому от индексов надо уходить и двигаться в сторону партишенинга, сложного и полностью ориентированного на аналитические выборки.

В идеале - реплицировать все данные в другую БД с другой геометрией таблиц или вообще в систему другого типа.

Любая современная биг-дата будет дешевле по стоимости владения по сравнению с DBMS.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

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