Да, проходил, и как ни странно больше пришлось подкручивать у 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 умели так же скейлиться, был бы результат в несколько раз выше, чем у баз.
TCP/IP, локальный redis-benchmark чтобы не тестить ничего кроме самих продуктов. Сокет даст побольше, но со скейлингом по ядрам это не будет связано, там уже чисто ядро.
По-моему, вы перебарщиваете, он особенно никого не поливает, но в его словах безусловно есть нотки обиды. Послушайте, я не знаю, что он делал для nginx последние 2 года, но для многих core-чуваков в open source их проект - это ребенок, особенно когда они над ним работают 10+ лет, нужно делать на это скидку, менеджмент должен был это понимать и постараться договориться.
Про ядро - @ximaeraкоторый уже каментил выше, тут подметил крайне точно один факт, и это произошло именно 14-го февраля, в тот же день: "коллективный Торвальдс", который как раз плакал, получил таки возможность управлять процессом создания CVE:
к докладам от лидеров open sourсe проектов такого уровня могло бы быть другое отношение :) вот энжи докладывался на хайлоаде - и ничего. будет что рассказать - думаю примем с большим удовольствием.
Слово "омерзительный" всё же too much. Всё что вы пишете, справедливо в нормальной ситуации, когда есть компания, есть коллектив разработчиков, который в ней работает, все работают заодно. В данной ситуации были явные трения, возможно продиктованные by design ситуацией, когда один из главных людей в проекте - волонтер, фактически не имеющий к компании уже никакого отношения, но судя по всему продолжающий выполнять очень важные функции. Неизвестно, какие были договоренности - Максим пишет, что договоренности были о полном невмешательстве.
По поводу CVE - по мне стоило сделать исключение, я не понимаю, если честно, почему в обсуждении разработчики решили не делать релиз. По-моему вообще стоило относиться к HTTP/3 иначе, чем к остальным экспериментам. С другой стороны, когда заведение CVE у части ИБ-шников превратился в вид спорта, открыть ящик Пандоры - дать возможность писать CVE ещё и на эксперимент - вот это прям шаг скользкий.
А зачем вообще вы мигрировали на постгрес? помимо модной строчки (что конечно большой плюс) вы упомянули "плюшки", но citext сам по себе кажется сомнительной причиной для переезда.
Да, проходил, и как ни странно больше пришлось подкручивать у 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 умели так же скейлиться, был бы результат в несколько раз выше, чем у баз.
TCP/IP, локальный redis-benchmark чтобы не тестить ничего кроме самих продуктов. Сокет даст побольше, но со скейлингом по ядрам это не будет связано, там уже чисто ядро.
Серьезно или сарказм? Если вдруг серьезно, то нужно изучать лицензионную политику Хабра, я не изучал. Ваш КО
ну в этой истории копаться довольно опасно, скорее всего всем был предложен переезд (другое дело, куда, помогали ли и тд).
По-моему, вы перебарщиваете, он особенно никого не поливает, но в его словах безусловно есть нотки обиды. Послушайте, я не знаю, что он делал для nginx последние 2 года, но для многих core-чуваков в open source их проект - это ребенок, особенно когда они над ним работают 10+ лет, нужно делать на это скидку, менеджмент должен был это понимать и постараться договориться.
Про ядро -
@ximaeraкоторый уже каментил выше, тут подметил крайне точно один факт, и это произошло именно 14-го февраля, в тот же день: "коллективный Торвальдс", который как раз плакал, получил таки возможность управлять процессом создания CVE:
https://openssf.org/blog/2024/02/14/linux-kernel-achieves-cve-numbering-authority-status/
к докладам от лидеров open sourсe проектов такого уровня могло бы быть другое отношение :) вот энжи докладывался на хайлоаде - и ничего. будет что рассказать - думаю примем с большим удовольствием.
Слово "омерзительный" всё же too much. Всё что вы пишете, справедливо в нормальной ситуации, когда есть компания, есть коллектив разработчиков, который в ней работает, все работают заодно. В данной ситуации были явные трения, возможно продиктованные by design ситуацией, когда один из главных людей в проекте - волонтер, фактически не имеющий к компании уже никакого отношения, но судя по всему продолжающий выполнять очень важные функции. Неизвестно, какие были договоренности - Максим пишет, что договоренности были о полном невмешательстве.
По поводу CVE - по мне стоило сделать исключение, я не понимаю, если честно, почему в обсуждении разработчики решили не делать релиз. По-моему вообще стоило относиться к HTTP/3 иначе, чем к остальным экспериментам. С другой стороны, когда заведение CVE у части ИБ-шников превратился в вид спорта, открыть ящик Пандоры - дать возможность писать CVE ещё и на эксперимент - вот это прям шаг скользкий.
А зачем вообще вы мигрировали на постгрес? помимо модной строчки (что конечно большой плюс) вы упомянули "плюшки", но citext сам по себе кажется сомнительной причиной для переезда.
спасибо! да, и про графану уже писали, и про ипотеку я понял, что не хватает такого разделения