Там ключевой косяк теста: "Issue #1 is that in Kafka’s server.properties file has the line log.flush.interval.messages=1 which forces Kafka to fsync on each message batch... So I removed that from the server.properties file...", автор убрал этот параметр, и весь его тест превратился в фуфло. Т.к. по default log.flush.interval.messages=10000 (было раньше, а сейчас вообще лимита нет по сути), т.е. kafka сбрасывает на накопитель каждые 10000 msg (в старых версиях, в новых версиях применяются default'ы checkpoint интервалов - 1 минута), если так подходить, то логично было-бы для redpanda выставить --unsafe-bypass-fsync и тогда сравнивать. А в своих тестах команда redpanda делает акцент на надёжности - демонстрируя потерю данных в kafka: https://github.com/redpanda-data/kafka-fsync.
Чем выше радиационный фон, тем выше вероятность инвертирования значений в ячейках памяти. ZFS всё протаскивает через ARC, который большой и постоянно в ОЗУ. Дальше сами считайте вероятность возникновения ошибок в данных прошедших через ОЗУ без ECC и решайте насколько важны ваши данные. У меня дома ZFS на ПК без ECC - пока не заметил искажений данных. Но это не отменяет факта: ОЗУ без ECC - недоразумение.
А, например, нам не хватает. И multi-master кластер в keydb поднимает лапки под реальной нагрузкой, к сожалению. Да и подход - копировать в/из ОЗУ файл дампа при рестартах с большими объёмами - это неприличный даунтайм.
Есть ещё интересные фокусы с zvol, видел как iostat кажет на группе nvme накопителей загрузку около 1%, а на /dev/zd0 (raidz на эти самые nvme накопители, сам volume выставлен FC target'ом на другой хост) - 100% и скорость записи втрое ниже чем на Solaris с HDD (ZStorage). Но насколько актуальны эти фокусы, относительно версии драйвера и ядра linux, не уточню - не я производил сетап хоста и не я эксплуатирую.
Про "плаформонезависимость" - непонял о чём вы, но я имел ввиду, "способность" програм для jvm работать на любой ОС где работает jvm без изменений под конкретнуюю ОС, на практие оно только на десктопах и годится. Про эффективность, я вам уже привёл пример: ScyllaDB. Про "есть/нет программисты" - неверно. Есть бюджет, что-бы: а) нанять программистов б) оплатить эффективное решение. Бюджетом можно распорядиться рационально, а можно разбазарить. 300 разрабов собравшихся вокруг биллинга - разбазаривание бюджета. 40 инстансов субд на java (в облаке-ли, on-premise-ли), там где справятся 3-5 инстансов субд на cpp - разбазаривание бюджета И вопрос только в том, разберёт "заказчик музыки", что ему впарили "какофонию" или нет. Увы, но часто, выбор эффективного языка, вообще не стоит в начале, пишут не оценивая будущее TCO, в результате имеем кучу легаси с тремя сотнями разрабов плящущими вокруг и доказывающими что "хуяк-хуяк и в продакшин" это time-to-market.
Не спасёт. Например, мне надо что-бы было вот так и за мало денег, и с обращением к одному серверу:
redis не работает быстро, и его однопоточность это беда, а не достоинство.
"Кажется, что C# не для того, чтобы большую часть проекта писать с использованием unsafe и с собственным менеджером памяти."
А ультимативная производительность говорит о том, что подход выбран правильный.
Там ключевой косяк теста: "Issue #1 is that in Kafka’s server.properties file has the line log.flush.interval.messages=1 which forces Kafka to fsync on each message batch... So I removed that from the server.properties file...", автор убрал этот параметр, и весь его тест превратился в фуфло. Т.к. по default log.flush.interval.messages=10000 (было раньше, а сейчас вообще лимита нет по сути), т.е. kafka сбрасывает на накопитель каждые 10000 msg (в старых версиях, в новых версиях применяются default'ы checkpoint интервалов - 1 минута), если так подходить, то логично было-бы для redpanda выставить --unsafe-bypass-fsync и тогда сравнивать. А в своих тестах команда redpanda делает акцент на надёжности - демонстрируя потерю данных в kafka: https://github.com/redpanda-data/kafka-fsync.
Повторите тесты для zfs с:
По этому поводу мной был оставлен первый комментарий - https://habr.com/ru/companies/vk/articles/770300/comments/#comment_26109430. Рекурсия ;)
Эм... а что не так? Есть smart инфа на одном и есть сбой на другом. Зеркало из nvme на pci и nvme на usb переходнике видимо было сделано для проверки.
Чел интересовался за ZFS. А так это вообще относится ко всем данным находящимся в ОЗУ.
Чем выше радиационный фон, тем выше вероятность инвертирования значений в ячейках памяти. ZFS всё протаскивает через ARC, который большой и постоянно в ОЗУ. Дальше сами считайте вероятность возникновения ошибок в данных прошедших через ОЗУ без ECC и решайте насколько важны ваши данные. У меня дома ZFS на ПК без ECC - пока не заметил искажений данных. Но это не отменяет факта: ОЗУ без ECC - недоразумение.
А, например, нам не хватает. И multi-master кластер в keydb поднимает лапки под реальной нагрузкой, к сожалению. Да и подход - копировать в/из ОЗУ файл дампа при рестартах с большими объёмами - это неприличный даунтайм.
Распространение ОЗУ без ECC и является недоразумением. В ОЗУ должен быть ECC.
Есть ещё интересные фокусы с zvol, видел как iostat кажет на группе nvme накопителей загрузку около 1%, а на /dev/zd0 (raidz на эти самые nvme накопители, сам volume выставлен FC target'ом на другой хост) - 100% и скорость записи втрое ниже чем на Solaris с HDD (ZStorage). Но насколько актуальны эти фокусы, относительно версии драйвера и ядра linux, не уточню - не я производил сетап хоста и не я эксплуатирую.
https://habr.com/ru/companies/vk/articles/770300/#comment_26108856
https://habr.com/ru/companies/vk/articles/770300/#comment_26108856
Насчёт производительности, если вот эти проблемы решены:
https://github.com/openzfs/zfs/issues/14346
https://coda.io/@ff0/zvol-performance-issues
https://github.com/openzfs/zfs/issues/11933
, то гуд, если нет, то ждёмс...
https://github.com/openzfs/zfs/issues/9172 - и эта проблема и похожие - закрыты автоматически за неактивностью, а не по исправлению. Это как сказал один из пользователей github:
it's like sweeping dirt under the carpet(https://github.com/openzfs/zfs/issues/9693#issuecomment-882027592)Чётка FS, но с ZVOL проблемы (под Linux) и давно...
redis-benchmark посредственно тестирует, проверяйте с помощью memtier, особенно если накинете тредов на keydb.
статья подустарела, в redis появилась многопототочность, по крайней мере для io. И Redis все, есть KeyDB.
Про "плаформонезависимость" - непонял о чём вы, но я имел ввиду, "способность" програм для jvm работать на любой ОС где работает jvm без изменений под конкретнуюю ОС, на практие оно только на десктопах и годится.
Про эффективность, я вам уже привёл пример: ScyllaDB.
Про "есть/нет программисты" - неверно.
Есть бюджет, что-бы:
а) нанять программистов
б) оплатить эффективное решение.
Бюджетом можно распорядиться рационально, а можно разбазарить.
300 разрабов собравшихся вокруг биллинга - разбазаривание бюджета.
40 инстансов субд на java (в облаке-ли, on-premise-ли), там где справятся 3-5 инстансов субд на cpp - разбазаривание бюджета
И вопрос только в том, разберёт "заказчик музыки", что ему впарили "какофонию" или нет. Увы, но часто, выбор эффективного языка, вообще не стоит в начале, пишут не оценивая будущее TCO, в результате имеем кучу легаси с тремя сотнями разрабов плящущими вокруг и доказывающими что "хуяк-хуяк и в продакшин" это time-to-market.