@alexdora
Топ-менеджер

Какую базу выбрать для bigdata?

Добрый день всем

Столкнулись с дилеммой при разработке. Есть входящие данные 100-150к rps (Читать как более 100 000 отдельных инсертов в секунду). Сейчас все это работает так:
В базе разделено все на более чем 800 таблиц (сама таблица это некий указатель на пул данных, как индекс), внутри таблиц используются индексы на время (поделили по год/день)
И все это в mysql...
Еще тогда на первых версиях реализовали некий буфер, который 100 инсертов объединяет в 1 большой и отправляет в базу, потому что mysql просто мягко говоря не вывозила если начинаешь лить инсерты по одному. Но тогда запросов было меньше. Сейчас настало время обновления и решили что-то придумывать другое.
Разделение таблиц – было первое обновление чтобы избавится от одного индекса и складывать все не в одну большую таблицу, а несколько. Это и добавило удобства, уменьшило место и ускорило систему (меньше индексов - быстрее инсерт).
Итого: приняли решение уходить с mysql, по нашему скромному мнению – она не подходит для задачи.
Основные хотелки:
1. Уменьшить размер занимаемых данных
2. Избавится от самописного буфера и просто инсертить
3. Кластеризация (у нас это сейчас в "ручном" режиме 3 базы mysql разных на 12ТБ, в конфигах ручками прописаны сервера где хранится тот или иной пул данных)
4. Выборка по базе это единичные большие запросы. Например: дай мне данные с такого-то пула за такой-то период времени. Скорость запроса не должна выходить за предел абсурда == до секунды это окей. Селекты делаются большие, но их единицы. В основном ночью на пересчет отправляются куски данных.

Поспрашивали ребят знакомых, сказали что такие задачи решаются: Cassandra или Postgre.

На тему Касандры почитал, все нравится (некий авто-кластер), но так и не понял что там с индексами, а именно 128 битный ключ. Если я правильно все понял, то это сразу перечеркивает пункт 1. И непонятно что со скростью инсертов. На вид оно сделано для того чтобы было условно 1000 разных клиентов которые читают и пишут. У нас таких клиентов нет, у. нас есть сервис который пишет эти данные. Есть приложение которые делает конкретные запросы на чтение.

Postgre я никогда не работал, но знаю что это. Мб кто с ней работает просто прокомментирует как сиё чудо ведет себя при входящих условиях. А именно как переваривает отдельные инсерты в большом количестве

Вообще, если какие мысли будут под такую задачу, буду рад любому комментарию. А то уже идеи появляются сделать все в файловой системе, а в mysql указатели хранить :) Что будет самым экономным и возможно самым быстрым. Но писать отдельный драйвер. ой как не хочется

Отписался в отдельном посте. Всем спасибо
  • Вопрос задан
  • 4586 просмотров
Решения вопроса 7
alexfilus
@alexfilus
Senior backend developer
Звучит как задача для ClickHouse, Вроде как они недавно пофиксили производительность при отдельных инсертах без буфера. Даже если нет, есть схема с записью всех событий в Kafka и вычитыванием оттуда с помощью Materialized view в таблицу КликХауса. Эта схема точно рабочая и указанные нагрузки выдержит. Плюс отличное сжатие данных.
Чистый PostgreSQL по производительности не сильно отличается от MySQL, а вот с дополнением TimescaleDB вставка становится очень быстрой, возможно вам его хватит. Там полноценный SQL и возможность редактировать данные без проблем. Неплохо сжимает.
Про ScyllaDB уже написали.
Ответ написан
@vitaly_il1
DevOps Consulting
Хороший вопрос.
Во-первых, чтобы думать о платформе, нужно больше узнать о вашей базе и данных, и data lifecycle. Советы вроде Clickhouse и Postgres Timescale вполне релевантны если ваши данные это time series, и не очень, если нет.
Я бы на вашем месте:
1) заказал сессию с архитекторами Percona, CockroachDB или другого NewSQL, и т.п.
2) включил бы наличие надежного DBaaS как условие для выбора платформы
Ответ написан
Комментировать
@KoreanGuy
CockroachDB. Это как постгрес, но шардированный из коробки. Ничего вручную настраивать не нужно, только правильный первичный ключ подобрать. Насколько быстрыми будут большие инсерты зависит от ключа. Если будет хорошо шардированный, то будет быстро.

Кассанда тоже подойдет, но ее сложно готовить. Это только кажется что там все просто, на самом деле у Кассандры куча нюансов буквально во всем. Вторичные индексы там локальные. Если в двух словах, то селекты только по вторичному индексу сканируют всю базу, то есть очень медленно. В идеале нужно использовать селекты которые делают фильтр и по первичному, и по вторичному, тогда будет быстро. Там таких gotcha очень много. Все кто работает с Кассандрой должны понимать что они делают, потратить время на изучение.

Есть еще ScyllaDB – это C++ версия Кассандры. Там некоторые проблемы Кассандры пофикшены. Ну и сцилла быстрее и эффективнее, спасибо крестам.
Ответ написан
@alexdora Автор вопроса
Топ-менеджер
Я прошу прощения что не-про-лайкал, но за темой следил. Утонули в работе. Хочу ответить к чему все пришло, кому будет интересно

Еще как тема создалась, мы сразу пробовали различные варианты которые тут советовали.

Clickhouse – не зашел, кажется что он слишком простой, но он требует инженерить. Это все не так просто оказалось как 1,2,3.
Да, быстро читает
Да, чуть сэкономил место на тестовом стенде (2%)
Но: кучу геморроя с настройкой и потребуется вложить время в переделку всего (ч.к деньги). А у нас никто им не владеет

Kafka Немного не под эту задачу, но взяли её в оборот на будущие доработки внутри микросервисов

Далее отвлеклись, а когда вернулись к вопросу с холодной головой оказалось что купить Б/У сервера с новыми NVME дисками (нет перезаписи - нет проблем с ресурсом) выгоднее, чем тратить время на оптимизацию. Провели работу над соединениями, основному софту mysql теперь нужно только чтоб сделать старт. Далее база не нужна, а данные читают как читались большими выборками
Поработали над буфером, добавили mysql серверов и вот нагрузка уже не такая печальная.
Ответ написан
Комментировать
@rPman
Так как автор молчит про особенность своей задачи, значит можно предположить что угодно? например write once read many базы данных? с запросом только данных по временному интервалу?

Пили самописное что-нибудь на основе файлов.

Современная файловая система, если это не какой-нибудь fat, - это отличная key-value база данных, причем самая быстрая из возможных, но без инструментов индексирования (кроме поиска по имени, если дробить его по подкаталогам то не будет лишних накладных расходов, например на обслуживание), а так как у автора временные ряды, раскидать по файлам-каталогам соответственно временным интервалам (дни или часы), разбив данные по еще какому либо признаку, если нужна фильтрация по нему, можно получить искомый результат фактически забесплатно (нечего там кодить). Например, если тебе нужны редкие транзакции (атомарно менять большой объем данных не ломая чтение) то какой-нибудь btrfs представит этот функционал за бесплатно на основе снапшотов.

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

Некоторые сложности может создать задача частых запросов на чтение, в этом случае нужно физически разнести голову массива данных и основное хранилище (например голова на ssd все остальное на hdd), а перенос проводить в момент наименьшей нагрузки, ну само собой можно и все на ssd если денег хватает, просто когда такой поток данных, сразу терабайты мерещатся
Ответ написан
Комментировать
@zo0Mx
Строжайше рекомендую ScyllaDB - решит все ваши вопросы.
Ответ написан
dimonchik2013
@dimonchik2013
non progredi est regredi
Кликхаус или Аэроспайк
https://habr.com/ru/post/551508/

зависит много от чего, надо ли сохранять исходные данные и т.п.

чудесов нет: вставляется хорошо пока ХОПА - не кончается память / быстрые диски, потом лаги, потери, очереди, очко админа и пересмотр зарплат

кстати о зарплатах - если слышали о Кассандре, но не слышали об Аэроспайке - можете начинать пересматривать
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
@lonely_guy
Tidb. Mysql совместима, шардирование их коробки,
отлично работает в htap сценариях
Ответ написан
Комментировать
@Ustas4
Не бросайтесь тапками. Оракул вам поможет. Вместо индекса используйте партиции. Для вставки есть bulk insert
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Похожие вопросы