Я в целом достаточно хорошо представляю, как ОС и она(субд) работает внутри, чтобы понимать несостоятельность этого совета в данном случае. Спорить о таких очевидных вещах бессмысленно.
давайте я вам помогу. представье, что вы разрабатываете субд и решили добавить поддержку io_uring или dpdk. как и какой бенчмарк вы будете проводить для оценки эффективности этого решения?
ну они все нишевые, конечно. поэтому оптимизированные сценарии для конкретной субд меня не интересовали. я взял самый простой кейс. а если по хорошему проводить бенчмарк с полным набором данных, это только схему и набор данных будешь продумывать и готовить неделю ) потом еще месяц тюнить каждую СУБД
всё верно, но статья то не об этом. я же написал, что я проверил лишь протокол и сериализацию данных. и в этом смысле от каждой СУБД это требуется в одинаковом виде. даже nginx с блобами payload по id файла подошел бы для схожего сравнения, на самом деле.
это рассуждение уходит от темы статьи. я уже сказал, что все данные в памяти, верить - не верить - ваше дело. я долго возился с этими измерениями и снимал гораздо больше разных метрик и с разным набором данных начиная от 1го row в таблице. здесь приведена лишь небольшая часть. это не бенчмарк доступа к данным, о чем он я написал в начале статьи. тут не то что в памяти, тут данные в кэше процессора в каком то смысле )
больше интересно, почему для пустой таблицы такие результаты. а насчет замечания по поводу сравнимых результатов, которые я должен был получить - вот как раз в этом и суть бенчмарка. даже имея данные в памяти, получать вы их будете с разной скоростью. я сам удивлен такой разнице цифр.
опять же, если говорить про методологию и настройки, что может влиять
количество соединений? их достаточно
настройки памяти, индексов, кэшей, page cache и тп и тд? данные в памяти как и индекс
утилизация cpu? они все были настроены чтобы утилизировать все ресурсы системы
настройки сети, очередей? система была одинаково настроена для всех тестов, мониторинг никаких затыков ни по каким параметрам не показывал
сжатие данных и шифрование? не включено
каких то еще идей, что донастроить, у меня не возникло. возможно, где то и есть волшебные настройки, жду помощи в коментах
никто вот не спросил про драйвера, которые разные у каждой БД. как раз это может сильно влиять на latency. я проверял не только с rust драйвером, но и с java - результаты схожи.
То, что оно было в памяти, это 100%. Я еще раз повторюсь, что датасет ничтожный. К тому же, я проверял сериализацию даже когда у меня каждый запрос брал запись в одним и тем же ключом. А уж момент чтения пустой таблицы какие настройки могут затронуть кроме количества соединения? Шифрование, сжатие? Сжатия нет, шифрование отключеною. Количество коннектов бы вылезло во время теста однозначно, если бы их не хватало. Но замечание засчитано, спасибо. Я посмотрю, какие дефолтные параметры выставились у Postgres, попробую их поднять, если вызовут подозрения и перепроверю. Про то, как Postgres ищет запись, я представляю. Конечно там не O(1), как у Redis. Я дополнил вступление к статье и написал, что Redis я использовал для референса. Уверен, мало кто представляет себе, какова реальная разница в скорости получения данных из памяти для Redis и Postgres. Тут я это подсветил, в том числе. Меня больше удивило то, как быстра Postgres.
Почему бы и не сравнить в режиме чтения? В данном случае это всё лежит в памяти. И где вы увидели, что я удивлялся записи на диск? Redis тоже может записывать, если уж на то пошло. Они все записывают, и у всех можно тюнить wal лог и fsync. Но исследование записи меня не интересовало, там вообще всё будет сильно по разному, что и получилось.
Когда у вас записей на 100 мегабайт в памяти, все дефолтные настройки как раз годятся. Можете почитать официальные доки, как запускать бенч на Scylla и той же Postgres. Они интересуют, когда у вас режим работы базы совсем другой. В данном случае влияние настроек будет ничтожно.
Redis работает в одном процессе (и потоке), так он спроектирован. Можно запустить несколько шардов на одной системе прибив их каждый к своему cpu, что я и сделал. Конечно же, если вместо 1го инстанса запустить 4 шарда, перфоманс не вырастет в 4 раза, потому что сеть у вас разгребает всё тот же один поток ядра. Выигрышь получается процентов 20-30. Я не стал выкладывать результаты с 1м процессом Redis, так как мог использовать 4. И написал об этом. С точки зрения максимального использования ресурсов системы это выглядит логичным.
PS: поправил в статье про Redis. Мне показалось, что и так будет понятно про несколько шардов, но, увы, нет.
Какой диск вообще, там миллион записей всего. Естественно, там всё в памяти. Меня не интересовал инсерт в данном случае. Только как база читает из памяти. Инсерт миллиона строк в базу происходит за 10-20 секунд, как и удаляется. Что там может просесть, я не понимаю. Наверное, вы имели ввиду миллиард строк?
Я имел ввиду Java. А там подразумевается то, что другой поток увидит нормальное значение даже несмотря на то, что запись через 2 инструкции производится. просто порядки поменяет чтения/записи и барьер вставит (вероятно).
Спасибо за отзыв! Моя первая статья. Грамотно излагать мысли оказалось не так просто, как я ожидал (. Буду учиться. И я совсем не эксперт по архитектурам CPU, разбирался с нуля. А про более интересный и детальный разбор различных интерконнектов и прокотолов я бы и сам почитал с удовольствием.
Я в целом достаточно хорошо представляю, как ОС и она(субд) работает внутри, чтобы понимать несостоятельность этого совета в данном случае. Спорить о таких очевидных вещах бессмысленно.
Я не совсем понимаю, о каких данных вы говорите, когда их нет.
давайте я вам помогу. представье, что вы разрабатываете субд и решили добавить поддержку io_uring или dpdk. как и какой бенчмарк вы будете проводить для оценки эффективности этого решения?
ну они все нишевые, конечно. поэтому оптимизированные сценарии для конкретной субд меня не интересовали. я взял самый простой кейс. а если по хорошему проводить бенчмарк с полным набором данных, это только схему и набор данных будешь продумывать и готовить неделю ) потом еще месяц тюнить каждую СУБД
всё верно, но статья то не об этом. я же написал, что я проверил лишь протокол и сериализацию данных. и в этом смысле от каждой СУБД это требуется в одинаковом виде. даже nginx с блобами payload по id файла подошел бы для схожего сравнения, на самом деле.
это рассуждение уходит от темы статьи. я уже сказал, что все данные в памяти, верить - не верить - ваше дело. я долго возился с этими измерениями и снимал гораздо больше разных метрик и с разным набором данных начиная от 1го row в таблице. здесь приведена лишь небольшая часть. это не бенчмарк доступа к данным, о чем он я написал в начале статьи. тут не то что в памяти, тут данные в кэше процессора в каком то смысле )
больше интересно, почему для пустой таблицы такие результаты. а насчет замечания по поводу сравнимых результатов, которые я должен был получить - вот как раз в этом и суть бенчмарка. даже имея данные в памяти, получать вы их будете с разной скоростью. я сам удивлен такой разнице цифр.
опять же, если говорить про методологию и настройки, что может влиять
количество соединений? их достаточно
настройки памяти, индексов, кэшей, page cache и тп и тд? данные в памяти как и индекс
утилизация cpu? они все были настроены чтобы утилизировать все ресурсы системы
настройки сети, очередей? система была одинаково настроена для всех тестов, мониторинг никаких затыков ни по каким параметрам не показывал
сжатие данных и шифрование? не включено
каких то еще идей, что донастроить, у меня не возникло. возможно, где то и есть волшебные настройки, жду помощи в коментах
никто вот не спросил про драйвера, которые разные у каждой БД. как раз это может сильно влиять на latency. я проверял не только с rust драйвером, но и с java - результаты схожи.
Всё, понял вопрос. TCP.
То, что оно было в памяти, это 100%. Я еще раз повторюсь, что датасет ничтожный. К тому же, я проверял сериализацию даже когда у меня каждый запрос брал запись в одним и тем же ключом. А уж момент чтения пустой таблицы какие настройки могут затронуть кроме количества соединения? Шифрование, сжатие? Сжатия нет, шифрование отключеною. Количество коннектов бы вылезло во время теста однозначно, если бы их не хватало. Но замечание засчитано, спасибо. Я посмотрю, какие дефолтные параметры выставились у Postgres, попробую их поднять, если вызовут подозрения и перепроверю. Про то, как Postgres ищет запись, я представляю. Конечно там не O(1), как у Redis. Я дополнил вступление к статье и написал, что Redis я использовал для референса. Уверен, мало кто представляет себе, какова реальная разница в скорости получения данных из памяти для Redis и Postgres. Тут я это подсветил, в том числе. Меня больше удивило то, как быстра Postgres.
Почему бы и не сравнить в режиме чтения? В данном случае это всё лежит в памяти. И где вы увидели, что я удивлялся записи на диск? Redis тоже может записывать, если уж на то пошло. Они все записывают, и у всех можно тюнить wal лог и fsync. Но исследование записи меня не интересовало, там вообще всё будет сильно по разному, что и получилось.
Когда у вас записей на 100 мегабайт в памяти, все дефолтные настройки как раз годятся. Можете почитать официальные доки, как запускать бенч на Scylla и той же Postgres. Они интересуют, когда у вас режим работы базы совсем другой. В данном случае влияние настроек будет ничтожно.
Redis работает в одном процессе (и потоке), так он спроектирован. Можно запустить несколько шардов на одной системе прибив их каждый к своему cpu, что я и сделал.
Конечно же, если вместо 1го инстанса запустить 4 шарда, перфоманс не вырастет в 4 раза, потому что сеть у вас разгребает всё тот же один поток ядра.
Выигрышь получается процентов 20-30. Я не стал выкладывать результаты с 1м процессом Redis, так как мог использовать 4. И написал об этом. С точки зрения максимального использования ресурсов системы это выглядит логичным.
PS: поправил в статье про Redis. Мне показалось, что и так будет понятно про несколько шардов, но, увы, нет.
Какой диск вообще, там миллион записей всего. Естественно, там всё в памяти. Меня не интересовал инсерт в данном случае. Только как база читает из памяти. Инсерт миллиона строк в базу происходит за 10-20 секунд, как и удаляется. Что там может просесть, я не понимаю. Наверное, вы имели ввиду миллиард строк?
В каком смысле?
Я имел ввиду Java. А там подразумевается то, что другой поток увидит нормальное значение даже несмотря на то, что запись через 2 инструкции производится. просто порядки поменяет чтения/записи и барьер вставит (вероятно).
Спасибо за отзыв! Моя первая статья. Грамотно излагать мысли оказалось не так просто, как я ожидал (. Буду учиться. И я совсем не эксперт по архитектурам CPU, разбирался с нуля. А про более интересный и детальный разбор различных интерконнектов и прокотолов я бы и сам почитал с удовольствием.