@dyasny извиняюсь, но опять маркетинговый булшит
"мы не знаем ваш ворклоад, но давайте вы попробуете наше решение,
а вдруг прокатит?"
на практике это зачастую прокатывает на PoC в 10GB данных, а когда оказывается 10+TB уже в проде, то
добро пожаловать в наш слак чат разрабов и вот эту платную подписку купите на саппорт, может что-то придумаем но не обещаемтеперь более предметно как инженеры про seastar:есть знакомые c/c++ девелоперы которые пытались seastar использовать
да, они подтвердили что он написан хорошо и предоставляет много отличных абстракций,
но конкретно они его у себя выпилили, так как он принуждает использовать его подход к обработке, что для них не совсем подходит
в частности: за ядром закрепляется обработчик и sharing nothing, с одной стороны линейный скейл и cpu друг другу в кеш не лезут, не нужны синхронизации, с другой это всё хорошо работает пока у вас не cpu bound задачи
перейдём теперь на scylladb и как она его использует:каждая партиция закреплена за ядром
запросы на одну партицию обрабатываются в пределях одного потока, что даёт нам преимущества в виде отсутствия синхронизаций и перекидывания данных между ядрами
до тех пор пока это IO bound задачи:
1) вставить данные потоком
2) вернуть данные прочитав с диска
то их async на диск и внутренний асинхронный процессинг и reactor себя показывает очень хорошо
так как решает многие вопросы которые были у кассандры (мы не ждем данных с диска, а можем процессить другие запросы)
но если мы нарываемся на другие задачи которые больше CPU bound, то начинаются проблемы:
1) compaction - scylladb пытается динамически предугадать размер сколько мы должны прочитать следующий блок, чтобы потом его быстро отпроцессить, причем соблюсти баланс
а) захватим меньше - сделаем быстро - нужно ждать пока следующий квант времени дадут, скорость компакшена может просесть
б) захватим много - процессим долго - весь процессинг запросов на этой партиции останавливается (get/put/etc выстраиваются в очередь, latency растет, все же помнят что одна партиция - один поток)
проблема что один и тот же блок по размеру может занять совершенно разное время в зависимости это были просто потоком таймсерии (можно просто sorted merge делать, можно сказать что упираемся в io) или вагон updates (тут еще нужно уже считать и находить кто последний был, объединять разные колонки и тд, намного больше cpu понадобится, и подход кассандры с отдельными потоками на compaction уже не кажется таким уж плохим)
2) record updates - уже существующих записей, опять же если запись существует, то merge её больше упирается в cpu при расчётах, плюс лок на memtable
то есть
2578 и
4405 это не совсем баги, их можно назвать
издержками принятых архитектурных решений
и так быстро их не исправить
именно поэтому они висят уже годами и их пытаются решить лишь подставляя очередные костыли
ещё раз: я не против scylladb или любой другой технологии пока дискусия идёт в рамках "опишите ваш ворклоад - у нас есть продукт с такими плюсами/минусами - в вашем случае он походит/не подходит потому что..."
но когда всем пытаются впарить что-то даже не выясняя как это будут использовать, очередную серебрянную пулю которая решит все ваши проблемы, то это совсем не инженерный подход, а напоминает классику продажников
такое было с хадупом и общим подходом nosql, потом монгой, потом с кликхаусом, сейчас вот со сциллой
