Comments 29
Коннект через сокет или TCP?
Но правда в том, что какая бы БД не была в вашей системе, вы всё равно прикрутите её дополнительно как key-value к части бизнес логики. Так что, сравнение допустимо. Redis работает в режиме одного потока, поэтому я запускал по 4 инстанса - один на ядро. Остальные же базы активно используют все 4 ядра. Mongo по определенным причинам запускал в докере, остальные базы просто устанавливал в систему. Настройки дефолтные, т.к. нас не интересуют размеры кэшей и индексов в данном тесте.
Вот этот абзац точно написан через ChatGPT, потому что каждое предложение очень нелогично.
То есть вы сравниваете in-memory KV-хранилище с транзакционной базой данных? И удивляетесь что почему-то на диск пишет?
Настройки дефолтные, т.к. нас не интересуют размеры кэшей и индексов в данном тесте.
В смысле не интересуют? Из-коробки любая база сконфигурирована так, чтобы просто запуститься на минимальном железе, но производительность никто не обещал.
Redis работает в режиме одного потока, поэтому я запускал по 4 инстанса - один на ядро.
То есть в кластере? Или по отдельности? А тесты шли на каждый отдельно или только на один? Что за ерунда тут происходит? В linux можно прилепить процесс к одному ядру процессора и он только его и будет использовать, если вы этого хотели добиться. Зачем 4 инстанса-то?
Почему бы и не сравнить в режиме чтения? В данном случае это всё лежит в памяти. И где вы увидели, что я удивлялся записи на диск? Redis тоже может записывать, если уж на то пошло. Они все записывают, и у всех можно тюнить wal лог и fsync. Но исследование записи меня не интересовало, там вообще всё будет сильно по разному, что и получилось.
Когда у вас записей на 100 мегабайт в памяти, все дефолтные настройки как раз годятся. Можете почитать официальные доки, как запускать бенч на Scylla и той же Postgres. Они интересуют, когда у вас режим работы базы совсем другой. В данном случае влияние настроек будет ничтожно.
Redis работает в одном процессе (и потоке), так он спроектирован. Можно запустить несколько шардов на одной системе прибив их каждый к своему cpu, что я и сделал.
Конечно же, если вместо 1го инстанса запустить 4 шарда, перфоманс не вырастет в 4 раза, потому что сеть у вас разгребает всё тот же один поток ядра.
Выигрышь получается процентов 20-30. Я не стал выкладывать результаты с 1м процессом Redis, так как мог использовать 4. И написал об этом. С точки зрения максимального использования ресурсов системы это выглядит логичным.
PS: поправил в статье про Redis. Мне показалось, что и так будет понятно про несколько шардов, но, увы, нет.
Почему бы и не сравнить в режиме чтения? В данном случае это всё лежит в памяти.
Или не в памяти. Postgres по-умолчанию: shared_buffers=128MB , work_mem=4MB Ну ещё max_connections=100, но вы могли в них и не упереться. Если вы рандомно читаете из таблицы, то будете с диска грузить постоянно новые страницы. Кстати, версия 15 немного старовата - уже 18я вышла.
С остальными базами не могу нормально прокомментировать, но опираться на дефолт и мерять скорость - не очень объективно.
Опять же - Redis тут вообще ни к месту сравнивать. У него доступ O(1), а постгрес сначала посчитает номер закоммиченной транзакции чтобы вам строку отдать.
То, что оно было в памяти, это 100%. Я еще раз повторюсь, что датасет ничтожный. К тому же, я проверял сериализацию даже когда у меня каждый запрос брал запись в одним и тем же ключом. А уж момент чтения пустой таблицы какие настройки могут затронуть кроме количества соединения? Шифрование, сжатие? Сжатия нет, шифрование отключеною. Количество коннектов бы вылезло во время теста однозначно, если бы их не хватало. Но замечание засчитано, спасибо. Я посмотрю, какие дефолтные параметры выставились у Postgres, попробую их поднять, если вызовут подозрения и перепроверю. Про то, как Postgres ищет запись, я представляю. Конечно там не O(1), как у Redis. Я дополнил вступление к статье и написал, что Redis я использовал для референса. Уверен, мало кто представляет себе, какова реальная разница в скорости получения данных из памяти для Redis и Postgres. Тут я это подсветил, в том числе. Меня больше удивило то, как быстра Postgres.
То, что оно было в памяти, это 100%.
чёйт? давайте вы добавите хотя бы в составной индекс все поля, тогда хоть какая-то уверенность будет что всё в памяти, и то не факт.
Монга туда же, там снаппи запаковано всё, кроме индексов, которые частично или полностью в памяти будут. Соответственно чтение - это поиск по индексу и чтение с диска. Хорошо если данные в дисковый кэш попадут, а то и не факт. Очень опрометчивое заявление про 100%. Если бы это было правдой, то вы бы получили сравнимые результаты доступа к данным, не так ли? ;)
это рассуждение уходит от темы статьи. я уже сказал, что все данные в памяти, верить - не верить - ваше дело. я долго возился с этими измерениями и снимал гораздо больше разных метрик и с разным набором данных начиная от 1го row в таблице. здесь приведена лишь небольшая часть. это не бенчмарк доступа к данным, о чем он я написал в начале статьи. тут не то что в памяти, тут данные в кэше процессора в каком то смысле )
больше интересно, почему для пустой таблицы такие результаты. а насчет замечания по поводу сравнимых результатов, которые я должен был получить - вот как раз в этом и суть бенчмарка. даже имея данные в памяти, получать вы их будете с разной скоростью. я сам удивлен такой разнице цифр.
опять же, если говорить про методологию и настройки, что может влиять
количество соединений? их достаточно
настройки памяти, индексов, кэшей, page cache и тп и тд? данные в памяти как и индекс
утилизация cpu? они все были настроены чтобы утилизировать все ресурсы системы
настройки сети, очередей? система была одинаково настроена для всех тестов, мониторинг никаких затыков ни по каким параметрам не показывал
сжатие данных и шифрование? не включено
каких то еще идей, что донастроить, у меня не возникло. возможно, где то и есть волшебные настройки, жду помощи в коментах
никто вот не спросил про драйвера, которые разные у каждой БД. как раз это может сильно влиять на latency. я проверял не только с rust драйвером, но и с java - результаты схожи.
Драйвера как раз в меньшей степени влияют на latency в ваших тестах, потому что измерялась именно скорость доступа к данным, как бы вы не уверяли в обратном. Хотите сделать более-менее честный тест? Вынесите дата файлы баз в tmpfs, тогда можно будет более предметно разговаривать (нет).
Хранит ли Редис у Вас данные на диске или всё в памяти?
Раз уж тут сравнения теплого с мягким, то попробуйте провести тест с insert миллиона строк в каждую из баз, а потом их удалением - удивитесь тому как редиска просядет.
Какой диск вообще, там миллион записей всего. Естественно, там всё в памяти. Меня не интересовал инсерт в данном случае. Только как база читает из памяти. Инсерт миллиона строк в базу происходит за 10-20 секунд, как и удаляется. Что там может просесть, я не понимаю. Наверное, вы имели ввиду миллиард строк?
Вывод общий, в боевых условиях скорее упрёшься в сеть, логику приложения или диски, чем в саму базу
In memory базы данных всегда будет быстрее тех что работают с диском (ssd, hdd...). Тут изначально это надо принять. Специализированная БД, всегда быстрее БД общего назначения.
Также есть понятие "тюнинг" БД, когда их можно настроить с учётом доступной оперативной памяти.
В целом по статье, неясно цель всех тестов. В реальных проектах, используют комбинации БД, кеширования.
Попробуйте все это же самое сделать на другом микрокомпьтере, например. Тогда будет смысл всех этих тестов, понять где лучше железо для каждой из БД (а смысл, т. е. опять вопрос "а зачем?"). Кстати как я понял это тест без настройки БД, т. е. по умолчанию из коробки.
Какое-то хрен с пальцем сравнение.
Кассандра заточена под распределенную запись, дайте кластеру миллион записей (не чтений) в секунду и найдите кто это сделает эффективнее.
Редис распределенный будет эффективнее, да, но что будет если записей на порядок больше, чтоб влезет в память? Редис отвалился. А в тысячу раз больше чем память?
Постгрес, ну тут понятно, реляционная база, можно придумать миллиард сценариев, где остальные из рассматриваемых сдохнут.
Про монго, если честно, ничего сказать не могу, так и не было практических задач, что она была бы сильно лучше других вариантов.
Для монги тоже можно поискать нишу, если какие-то специальные сравнения делать.
Например, загонять документы в JSON-формате и потом по ним искать по вложенным полям. Из конкурентов PostgreSQL что-то может сравнимое показать, да ещё у Redis было расширение для такого, кажется.
Ну или просто пихать рандомные JSON в монгу, без схемы. Все остальные базы с ума сойдут от такого. Разве что какие-нибудь колоночные базы вытащат.
ну они все нишевые, конечно. поэтому оптимизированные сценарии для конкретной субд меня не интересовали. я взял самый простой кейс. а если по хорошему проводить бенчмарк с полным набором данных, это только схему и набор данных будешь продумывать и готовить неделю ) потом еще месяц тюнить каждую СУБД
всё верно, но статья то не об этом. я же написал, что я проверил лишь протокол и сериализацию данных. и в этом смысле от каждой СУБД это требуется в одинаковом виде. даже nginx с блобами payload по id файла подошел бы для схожего сравнения, на самом деле.
что делали и зачем - вообще нет ясности.
Кликхаус забыли
И если говорить о key-value хранилище, то надо было что-то типа etcd добавить. Зукипер ещё можно.
Почему Cassandra так сливает Scylla?
Это две очень разных базы, по сути сцилла это работа над ошибками кассандры)
Меня одного смущает сравнение реляционных бд с нереляционными? Я бы поделил эту статью и сравнил реляционные с аналогами реляционных и отдельно key-value бд
Даже не знаю кому такое экзотическое окружение может быть интересно. Postgres как KV на малинке с картой памяти.
Пгшечку берут для транзакций. Чтобы не попадать в ситуцию "Ваш заказ оплачен, но не создан, платите ещё раз". Возник кейс кей валуэ - читаем что такое вообще КЭШ. И сначала храним его в своей голове. А уже если этого не хватает берём куй валуя в виде редис. Сравнить это всё в одном месте ток нейронка могла. Ей да наплевать на здравый смысл. А почему кликхауса тут нет кстати? В него тоже можно кей велью сохранить. Ну или кафки?
Самая быстрая БД на Диком Западе