Ну это не типовая проблема корпораций, это к сожалению одна из более-менее формальных, проверяемых и объективных оценок области ответственности менеджера: количество людей. За прибыль-то кстати тоже поощряют, но как критерий опыта/успеха в крупной компании это работает далеко не для всех.
Вот об этом отчасти писал Костя Осипов в своем комментарии: что trade-off небинарный и вообще говоря может зависеть от типа данных: что-то готовы терпеть как мусор (комментарии), а что-то нет (баланс, личные данные).
Ребят, это такой вид спорта теперь на хабре? Да, статья ретроспективная и поэтому длинная; статья не ставит целью "разжевать" базу тем, кто не в теме. Но обвинять в LLM-генерации -- имейте совесть, на крайняк не поленитесь и загоните текст в LLM чтобы оценить вероятность генерации.
Да, согласованность, или даже линеаризуемость, и консистентность из acid - это разные вещи. Но это вообще не меняет ни смысла статьи, ни ценности. И кстати нейронка-то как раз в курсе. И на всякий случай -- вместо того чтобы включать неуместный поучающий тон -- можно взять текст статьи, загнать его в LLM, и оценить вероятность написания текста нейронкой. Оставлю это упражнение в качестве домашнего задания (спойлер: будет очень низкая вероятность написания нейронкой, chatgpt 5.2 thinking даст ниже 10%).
Да, проходил, и как ни странно больше пришлось подкручивать у MySQL. У PostgreSQL подняли только воркеров и кеши. Если интересны какие-то специфические вопросы или примеры конфигов, напишите мне в ТГ на @alexeyrybak – вышлю.
Нет, не надо ничего придумывать. В статье показывается, что современные СУБД умеют справиться и с очень большой простой нагрузкой, выраженной в RPS, и с достаточно большим количеством одновременных соединений. И это основные причины, почему в хайлоад-проектах стали использовать кеши (но не все). Всё, больше никаких смыслов других в статье нет.
C latency всё нормально, не все графики вошли в статью. Пайплайнинг для редиса очевидно тут наоборот не нужен, поскольку это всегда искусственное "завышение" RPS в разы, а мы честно меряем отдельные запросы.
Даже сложные вещи умный человек может объяснить в двух словах. А если он объяснить этого не хочет, напускает тумана, использует заходы типа "у вас нет никакого понимания" и "уж я-то знаю", значит, либо он не очень умный, либо у него манипулятивная цель. Поверьте, ничего идти от основ организации не нужно. Неважно, чем отличаются принципы хранения данных, потому что вы не поняли ни исторический контекст создания кеш-слоя ни смысл этой статьи. И не знаете, что Redis (при всех его недостатках) используется в гигантском количестве огромных проектов.
параметры в-основном стандартные: везде менялся размер буферпула и параметры пула процессов/тредов. в mysql больше было изменений, если интересно напишите мне лс в ТГ @alexeyrybak и скину вам конфиг.
К сожалению, системно это не собиралось. Памяти конечно PPC модель потребляет заметно больше, и это и есть основная причина и ограничение для постгреса в ~5000 процессов на 128-гиговой машине.
Мы собрали достаточно большое количество предложений и вероятно будем делать регулярно работающий тестовый стенд. Он будет включать сбор метрик по потреблению CPU, памяти, и подробную статистику по latency запросов (кстати данные по latency как раз есть, однако к ним к самим много вопросов). Если есть какие-то еще предложения относительно того, какие метрики нужно собрать в отчеты - пишите!
Странный комментарий! Нет ни понимания статьи, ни единой аргументации, просто ноль, голый вася. Что характерно для современного ИТ, комментировал некий noname. Вот так :)
При больших нагрузках можно переходить на redis cluster, valkey, valkey cluster, а также на альтернативы типа dragonfly и др. Что такое перелицензированный Redis?
Предельное число запросов, что на чтение что на запись порядка 100К RPS на ядро на этих xeon gold при датасете в 10 млн 256-байтных ключей, и все эти параметры, кстати, важны. Если точно - около 160K RPS. Значит, если у вас valkey и 1M RPS, то вы "почуствуете" родовую травму редиса (main thread, не "однотредовость" - строго говоря, это неверно) только если R/W ratio > 10 (грубо). 1% или 3% - скорее всего, не почуствуете. Лучше, конечно, было бы это явно промерить - да, я согласен, про это написано в специальном разделе, в ближайшее время мы это проиллюстрируем.
Это общие слова, сори, и кажется, мы не спорим, либо я не понимаю, о чём. О чём?
Я не утверждаю, что "кеш не нужен", и это можно прочитать в выводах. кеш гарантирует низкий лэтенси, гарантирует хороший throuphput и база – по-прежнему риск. но риск уже меньше - традиционные базы сделали хороший шаг вперед.
Ну в целом да, но при 1.000.000 RPS сколько обычно операций на запись - больше 10%? упремся ли мы в одно ядро? Довольно важно, ~100К writes-PS main thread потянет на нормальном железе, там больше будет деградации при синках на диск (будет интересно посмотреть с aof на nvme например). Ну и кластер, write-нагрузку без кластера не смасштабировать.
Всё-таки это совсем в другой класс, и там конечно можно налопатить на порядок (или на порядки) больше RPS/thoughput.
Вопрос стоял именно в том, чтобы взять кеш-сервисы как обвязку базам, и посмотреть, как современные версии традиционных баз справляются с такой нагрузкой.
Какая-то точно будет, но в целом там ничего необычного нет: как раз RPS у СУБД и postgresql и mysql прекрасно масштабируются по ядрам, одно ядро может вытянуть десятки тысяч read-only RPS из кеша, поэтому на достаточно мощном сервере легко можно разогнаться до миллиона RPS - и так уже много лет. Думаю, что если бы Redis/Valkey умели так же скейлиться, был бы результат в несколько раз выше, чем у баз.
успехов! но я кстати поменял и название и подводку - этот мир мне абсолютно понятен
ну то есть по существу статьи комментариев нет, но очень нужно что-то сказать? понимаю :)
Ну это не типовая проблема корпораций, это к сожалению одна из более-менее формальных, проверяемых и объективных оценок области ответственности менеджера: количество людей. За прибыль-то кстати тоже поощряют, но как критерий опыта/успеха в крупной компании это работает далеко не для всех.
>> виртуалку 8 vCPU/16 RAM, грубо говоря за 700р в месяц и поднять там всю необходимую мне инфру
можно в лс где такое есть?
статья -- Кости Ратвина, но LLM тут нет
Вот об этом отчасти писал Костя Осипов в своем комментарии: что trade-off небинарный и вообще говоря может зависеть от типа данных: что-то готовы терпеть как мусор (комментарии), а что-то нет (баланс, личные данные).
Ребят, это такой вид спорта теперь на хабре? Да, статья ретроспективная и поэтому длинная; статья не ставит целью "разжевать" базу тем, кто не в теме. Но обвинять в LLM-генерации -- имейте совесть, на крайняк не поленитесь и загоните текст в LLM чтобы оценить вероятность генерации.
Да, согласованность, или даже линеаризуемость, и консистентность из acid - это разные вещи. Но это вообще не меняет ни смысла статьи, ни ценности. И кстати нейронка-то как раз в курсе. И на всякий случай -- вместо того чтобы включать неуместный поучающий тон -- можно взять текст статьи, загнать его в LLM, и оценить вероятность написания текста нейронкой. Оставлю это упражнение в качестве домашнего задания (спойлер: будет очень низкая вероятность написания нейронкой, chatgpt 5.2 thinking даст ниже 10%).
Да, проходил, и как ни странно больше пришлось подкручивать у MySQL. У PostgreSQL подняли только воркеров и кеши. Если интересны какие-то специфические вопросы или примеры конфигов, напишите мне в ТГ на @alexeyrybak – вышлю.
Нет, не надо ничего придумывать. В статье показывается, что современные СУБД умеют справиться и с очень большой простой нагрузкой, выраженной в RPS, и с достаточно большим количеством одновременных соединений. И это основные причины, почему в хайлоад-проектах стали использовать кеши (но не все). Всё, больше никаких смыслов других в статье нет.
C latency всё нормально, не все графики вошли в статью. Пайплайнинг для редиса очевидно тут наоборот не нужен, поскольку это всегда искусственное "завышение" RPS в разы, а мы честно меряем отдельные запросы.
Даже сложные вещи умный человек может объяснить в двух словах. А если он объяснить этого не хочет, напускает тумана, использует заходы типа "у вас нет никакого понимания" и "уж я-то знаю", значит, либо он не очень умный, либо у него манипулятивная цель. Поверьте, ничего идти от основ организации не нужно. Неважно, чем отличаются принципы хранения данных, потому что вы не поняли ни исторический контекст создания кеш-слоя ни смысл этой статьи. И не знаете, что Redis (при всех его недостатках) используется в гигантском количестве огромных проектов.
параметры в-основном стандартные: везде менялся размер буферпула и параметры пула процессов/тредов. в mysql больше было изменений, если интересно напишите мне лс в ТГ @alexeyrybak и скину вам конфиг.
К сожалению, системно это не собиралось. Памяти конечно PPC модель потребляет заметно больше, и это и есть основная причина и ограничение для постгреса в ~5000 процессов на 128-гиговой машине.
Мы собрали достаточно большое количество предложений и вероятно будем делать регулярно работающий тестовый стенд. Он будет включать сбор метрик по потреблению CPU, памяти, и подробную статистику по latency запросов (кстати данные по latency как раз есть, однако к ним к самим много вопросов). Если есть какие-то еще предложения относительно того, какие метрики нужно собрать в отчеты - пишите!
Странный комментарий! Нет ни понимания статьи, ни единой аргументации, просто ноль, голый вася. Что характерно для современного ИТ, комментировал некий noname. Вот так :)
При больших нагрузках можно переходить на redis cluster, valkey, valkey cluster, а также на альтернативы типа dragonfly и др. Что такое перелицензированный Redis?
Предельное число запросов, что на чтение что на запись порядка 100К RPS на ядро на этих xeon gold при датасете в 10 млн 256-байтных ключей, и все эти параметры, кстати, важны. Если точно - около 160K RPS. Значит, если у вас valkey и 1M RPS, то вы "почуствуете" родовую травму редиса (main thread, не "однотредовость" - строго говоря, это неверно) только если R/W ratio > 10 (грубо). 1% или 3% - скорее всего, не почуствуете. Лучше, конечно, было бы это явно промерить - да, я согласен, про это написано в специальном разделе, в ближайшее время мы это проиллюстрируем.
Это общие слова, сори, и кажется, мы не спорим, либо я не понимаю, о чём. О чём?
Я не утверждаю, что "кеш не нужен", и это можно прочитать в выводах. кеш гарантирует низкий лэтенси, гарантирует хороший throuphput и база – по-прежнему риск. но риск уже меньше - традиционные базы сделали хороший шаг вперед.
Ну в целом да, но при 1.000.000 RPS сколько обычно операций на запись - больше 10%? упремся ли мы в одно ядро? Довольно важно, ~100К writes-PS main thread потянет на нормальном железе, там больше будет деградации при синках на диск (будет интересно посмотреть с aof на nvme например). Ну и кластер, write-нагрузку без кластера не смасштабировать.
Всё-таки это совсем в другой класс, и там конечно можно налопатить на порядок (или на порядки) больше RPS/thoughput.
Вопрос стоял именно в том, чтобы взять кеш-сервисы как обвязку базам, и посмотреть, как современные версии традиционных баз справляются с такой нагрузкой.
Какая-то точно будет, но в целом там ничего необычного нет: как раз RPS у СУБД и postgresql и mysql прекрасно масштабируются по ядрам, одно ядро может вытянуть десятки тысяч read-only RPS из кеша, поэтому на достаточно мощном сервере легко можно разогнаться до миллиона RPS - и так уже много лет. Думаю, что если бы Redis/Valkey умели так же скейлиться, был бы результат в несколько раз выше, чем у баз.