Столкнулись с дилеммой при разработке. Есть входящие данные 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 указатели хранить :) Что будет самым экономным и возможно самым быстрым. Но писать отдельный драйвер. ой как не хочется
Нет, postgresql под такую задачу останется вам неудобен.
На сколько помню internals mysql, в postgresql row header даже на несколько байт больше, очень вряд ли получите уменьшение занимаемого места.
Буфер на таком потоке всё равно будет нужен. Тысяч 10-15 insert command/sec с сервера с хорошим DBA ещё выглядят возможными, дальше могут быть приключения из глубин internals.
Шардинг так же внешний останется.
Очень сильно зависит от задачи, от того, как устроены данные, как с ними работают. Поэтому вопрос "какую базу взять" без серьёзного предварительного анализа не имеет однозначного ответа.
что за данные? что дает поток временных данных в 150к rps
что нужно делать с данным после, достаточно ли выборки на дату/интервал?
нужно ли редактирование или это write once read many database?
нужны ли транзакции? возможно чтение недавно записанных данных?
нужно ли резервное копирование налету?
Я прошу прощения что не-про-лайкал, но за темой следил. Утонули в работе. Хочу ответить к чему все пришло, кому будет интересно
Еще как тема создалась, мы сразу пробовали различные варианты которые тут советовали.
Clickhouse – не зашел, кажется что он слишком простой, но он требует инженерить. Это все не так просто оказалось как 1,2,3.
Да, быстро читает
Да, чуть сэкономил место на тестовом стенде (2%)
Но: кучу геморроя с настройкой и потребуется вложить время в переделку всего (ч.к деньги). А у нас никто им не владеет
Kafka Немного не под эту задачу, но взяли её в оборот на будущие доработки внутри микросервисов
Далее отвлеклись, а когда вернулись к вопросу с холодной головой оказалось что купить Б/У сервера с новыми NVME дисками (нет перезаписи - нет проблем с ресурсом) выгоднее, чем тратить время на оптимизацию. Провели работу над соединениями, основному софту mysql теперь нужно только чтоб сделать старт. Далее база не нужна, а данные читают как читались большими выборками
Поработали над буфером, добавили mysql серверов и вот нагрузка уже не такая печальная.
