Комментарии 17
более простого вертикального масштабирования.
Исключительно вертикального масштабирования. Горизонтальное не предусмотрено и не факт что будет в принципе.
Спасибо за комментарий, действительно на текущий момент вообще никакой работы над реальным горизонтальным масштабированием не ведется, но стоит добавить два момента:
Не отрицают, что может быть в будущем дойдут до этого руки (см. коммент на github)
Уже сейчас для миграции с Redis Cluster доступна эмуляция через
--cluster_mode=emulated(https://www.dragonflydb.io/docs/managing-dragonfly/clustermode). Больше похоже на "костыль", но хоть так
Честно говоря очень сильно заметно по этому проекту что самое важное это "Привлек $21 миллион в A-раунде инвестиций в марте этого года"
1) Манипулятивные комментарии к бенчмарку: про "demonstrated better latency in write workloads" они написали до того как привести результаты бенчмарка а про "exhibited lower latency for the read benchmark" ниже данных, скорее всего в надежде что никто не будет дальше читать. Забавный выбор слов better и lower и уж точно совершенно не случайный.
Ведь если просто написать что латенси на GET в три раза хуже чем в memcached то могут и не дать 21млн.
2) Отсутствие горизонтального масштабирования преподносится как плюс:
3) Бенчмаркая редис и df нужно обязательно привязаться к метрике количество запросов на инстанс. Ведь иначе не получить x25 перфоманс. Использовать редис кластер для сравнения видимо было лень.
Не так давно команда редиса запустила кластер на одной машине и оказалось что 40 инстансов редиса выдают результаты выше чем 64 ядерный dragonfly https://redis.com/blog/redis-architecture-13-years-later/. А казалось бы shared nothing архитектура.
Меня тоже эти $21 миллион как-то удивили для такого технологического проекта.
Под впечатлением пошел посмотреть, сколько привлекли KeyDB (тоже многопоточный убийца Redis из 2019 г.). Оказалось, что у них было $1.3 миллиона в Seed-раунде, а потом их поглотил Snapchat. Может и тут какая-то похожа история выйдет...
А мы с вами от конкуренции даже выиграем :)
Справедливости ради, стоит заметить, что то о чём вы говорите не что-то из ряда вон выходящее, а самый что ни на есть рядовой маркетинг и позиционирование. Непонятен ваш "срыв покровов".
Ведь если просто написать что латенси на GET в три раза хуже чем в memcached то могут и не дать 21млн.
Вы раскрыли секрет полишинеля.
Отсутствие горизонтального масштабирования преподносится как плюс.
А здесь уже вы манипулируете. Добро пожаловать в release notes и discussions.
Бенчмаркая редис и df нужно обязательно привязаться к метрике количество запросов на инстанс. Ведь иначе не получить x25 перфоманс.
да, именно так, именно потому что DF пока ограничен в возможностях горизонтального масштабирования.
40 инстансов редиса выдают результаты выше чем 64 ядерный dragonfly
omg, вы через строчку в школе научились читать? о том и речь что никто не хочет поднимать и сопровождать 40 (40, Карл!) инстансов Redis-а. Поэтому и появляются новые решения вроде DF.
Да вы просто хейтер, гражданин.
Вы раскрыли секрет полишинеля.
И? Это плохо?
А здесь уже вы манипулируете. Добро пожаловать в release notes и discussions.
Раскройте пожалуйста мысль как связаны ссылки и моя манипуляция скриншотом их рядового маркетинга.
да, именно так, именно потому что DF пока ограничен в возможностях горизонтального масштабирования.
Не ограничен а она отсутствует. Причем это преподносится как плюс.
о том и речь что никто не хочет поднимать и сопровождать 40 (40, Карл!) инстансов Redis-а. Поэтому и появляются новые решения вроде DF.
А я то думал что речь идет про перформанс.
Да вы просто хейтер, гражданин.
Все так, я хейтер манипулятивного маркетинга.
Не так давно команда редиса запустила кластер на одной машине и оказалось что 40 инстансов редиса выдают результаты выше чем 64 ядерный dragonfly
Я правильно понимаю, что редису понадобилось в 40 раз больше памяти, или они что-то с этим сделали?
Тестировал у себя, особо прям вау-результата не заметил, да и не все нужные команды поддерживает, но следить буду. Более того - не показал даже сильно лучше результатов, чем наша KVRocks, при том что мы на диск пишем все )
А KeyDB не тестировали? А то про него хайпа меньше, а толку может и больше)
Тестирую и смотрю на все редис-лайк штуки. Но мне надо персистент-хранилище, а не в памяти + мы активно используем STREAMS, которых в keyDB тогда не было, сейчас получше, но я все ждал их флеш-хранилище, пока непонятно. Пришлось стать комиттером в KVRocks )
Но мне надо персистент-хранилище
А в сторону aerospike и tarantool не смотрели? Там есть и персистанс и стримы.
аероспайк коммерческий, тарантул смотрел, но луа (ладно) но коннектор к nodejs официально не развиваеться и без поддержки + так и нет транзакций где оба движка (mem + vinyl)
в тарантуле нет нативно стримов, есть очередь написанная просто и тоже не развиваеться )
Кстати, очередь как будто немного ожила с середины 2022 года https://github.com/tarantool/queue/releases
Архитектура кеша DragonflyDB