Стрім пише прямо з хеш таблиці на диск в побітовому форматі хеш таблиці? Як інакше він може її переформатувати без виділення буферу?

Як хеш таблиця суміщується з версіонуванням? Це в вал’ю замість одного ключа лежить список версій ключа?

А стрім — це що? Абстракція у вакумі? Звичайно, якщо вам не ліньки блокувати хеш на купу часу, поки буфера стріму дампляться на диск — тоді стрім може жити у маленькому буфері. А якщо хочете відпустити хеш швидко — то ваш стрім має вмістити дані з усієї хеш таблиці, відповідно — його розмір рівний розміру снепшота, і вам треба цю пам’ять виділити. Навіть якщо ви про це не здогадуєтесь, і працюєте з абстрактним об’єктом у вакумі.

Себто, під час реплікації ви копіюєте хеш таблицю в снепшот, під котрий окремо виділяєте пам’ять? А коли Редіс форкається, то проблема що в нього (на два процеси) один снепшот та дві таблиці, а у вас — один снепшот, одна таблиця і один журнал в оперативці?

Clustering, in the context of databases, refers to the ability of several servers or instances to connect to a single database. An instance is the collection of memory and processes that interacts with a database, which is the set of physical files that actually store data.

Clustering offers two major advantages, especially in high-volume database environments:

Fault tolerance: Because there is more than one server or instance for users to connect to, clustering offers an alternative, in the event of individual server failure.
Load balancing: The clustering feature is usually set up to allow users to be automatically allocated to the server with the least load.

Майстер з репліками та з менеджером, котрий перемикає клієнтів на репліки і створюють кластер за означенням.

Себто, у вас в оперативці є наступні сутності:
* снепшот
* журнал
* хеш таблиця
і кожен запис оновлює і хеш таблицю і журнал?
А для збереження на диск ви мержите журнал в снепшот?
Тоді в Редіса кількість зайвих витрат пам’яті з COW буде нульовою, бо він також спочатку вмержить журнал в снепшот, а потім форканеться з вже готовим снепшотом. І журнал буде рости лише в батька, а дитина деаллокує хеш таблицю, журнал та скине готовий снепшот без змін на диск.

O(1) для журналу

Це яким чином? Прочитати весь журнал — це O(N) по довжині журналу. І вам потрібно це робити на кожен запит на читання.
Якщо ваше збереження на диск робить наступні операції:
* Мерж журналу в старий снепшот в пам’яті
* Переключення на новий журнал
* Скидання оновленого снепшоту на диск
тоді я не бачу, чому Редіс мав би десь виїдати багато пам’яті з COW бо там під час скидання на диск буде лише наростати новий журнал — одна сторінка пам’яті.

Реплікація і є підвидом кластеру.

К тому же хлопцы, edis не имеет встроенной поддержки sharding, что может ограничить его масштабируемость.

Цитирую доку редиса: Redis Cluster provides a way to run a Redis installation where data is automatically sharded across multiple Redis nodes. redis.io/docs/management/scaling

1)

shared nothing означає що нам не потрібна синхронізація для доступу до даних, а не те що пам’ять не шариться між потоками (не шариться тільки хеш таблиця)

Цитую з Вікіпедії: Nodes do not share (independently access) the same memory or storage.
en.wikipedia.org/...​ared-nothing_architecture
Ось ще старе визначення: shared nothing (SN), i.e. neither memory nor peripheral storage is shared among processors www.scylladb.com/...​red-nothing-architecture
Якщо ви шарите пам’ять між потоками з можливістю запису до неї, то це не є shared nothing за означенням, і яким чином ви тоді позбулись синхронізації?
2) Ви знову не відповідаєте на питання. Сценарій в тому, що клієнт під час запису на диск надіслав команду, котра змінює дані. Ви кажете про журнал — у вас всі дані зберігаються в журналі, і для кожного запиту потрібно пройти максимум весь журнал? Складність читання O(N)? Себто, ви не тримаєте в пам’яті таблицю поточних значень змінних?

Нет, Редис деплоится на машину как кластер из нескольких процессов (по процессу на ядро процессора) — и при этом работает существенно быстрее, чем многопоточный Дрегонфлай, который занимает все ядра процессора. И шардинг там обещают автоматический, вроде redis.io/docs/management/scaling

С другой стороны, на Реддите пишут, что такую базу тянут туда, где критична стабильность системы. И как раз деплой на одну машину со стабильностью не стыкуется, в отличии от кластера.

Тут є порівняння, і воно показує що декілька пунктів (1, 2, 3) невірні www.reddit.com/...​s_hits_back_at_dragonfly

1) Багатопроцесний кластер та багатопоточна shared nothing — це одне й те ж, доки ви дотримуєтесь shared nothing парадигми. Хіба що вони можуть скейлитись на декілька комп’ютерів з комунікацією через мережу, а ви — ні. Бо shared nothing значить, що ви не можете шарити пам’ять між потоками. Так само, як ноди кластеру не можуть шарити пам’ять.
2) Ви використовуєте журнал, щоб знайти поточні значення для запиту клієнта? Тоді це повільніше, ніж робота з масивом, та ще й для створення снепшота вам потрібно виділити масив та пройти журналом — себто, у вас буде повільніше збереження даних, і для збереження доведеться виділяти пам’ять. Ви ж не журнал зберігаєте в снепшот?
Код бази читати — то дуже кепський варіант. Я колись намагався — так майже за два роки нічого й не зрозумів.
3) З вашої документації, ваш кластер потребує ручного налаштування: Dragonfly only provides a data plane (which is the Dragonfly server), but we do not provide a control plane to manage cluster deployments.
www.dragonflydb.io/...​ng-dragonfly/cluster-mode
на відміну від редіса: Moving hash slots from a node to another does not require stopping any operations; therefore, adding and removing nodes, or changing the percentage of hash slots held by a node, requires no downtime.
redis.io/docs/management/scaling
Себто масштабованість в них є, а у вас — під питанням. І при цьому в них кращий перформанс.

1) Тоді яким чином

завдяки багатопочтоності ми можемо зменшити максимальну затримку, запити можуть оброблятись паралельно (бо парсінг і початкова обробка запиту може бути проведена будь яким потоком і тільки працювання із хеш таблицює потребує конкретного потоку за я ким закріплений шард)

ваша багатопоточність швидша за shard-per-core в Редісу?
2)

У снапшоті будуть збережені ті дані які будуть у таблиці на момент.

На момент початку реплікації бази чи на момент початку реплікації блоку пам’яті? Якщо під час реплікації клієнти можуть робити записи, то ви вже маєте дуплікувати певні блоки пам’яті, щоб було куди записувати, і це — саме те, що редіс робить завдяки copy-on-write. Інакше вам нема куди записати зміни.
3) Ви писали в статті

Dragonfly зберігає швидкість, яка вам довподоби

але по факту Редіс надає близько +40% швидкості на −40% кількості ядер.
Ви писали

Зі зростанням навантаження один потік стає вузьким місцем, обмежуючи продуктивність і масштабування.

але по факту продуктивність Редісу вища і, на відміну від вашої бази, він довільно масштабується.
Ви писали

Це усуває вузьке місце однопотоковості, яке обмежує Redis, дозволяючи Dragonfly обробляти значно більші навантаження

але по факту Редіс підтримує вище навантаження ніж Дрегонфлай.
Ви писали

По суті, багатопотокова архітектура Dragonfly з підходом shared-nothing та акцентом на асинхронні операції відкриває значні переваги в продуктивності та масштабованості порівняно з Redis, роблячи його привабливим вибором для вимогливих робочих навантажень.

але це неправда www.reddit.com/...​s_hits_back_at_dragonfly

1) Тоді як ваші файбери в одному потоці дають перевагу в перформансі над однопоточним Редісом?
2) Нема відповідей, і ви не можете показати як працює система для конкретного прикладу.
3) Я думав, що бенчмарк був для порівняння швидкості, як ви написали

порівнювалось використання пам’яті і швидкість редіс і dragonfly

. Редіс наводить результати справжнього бенчмарка, де вони на 40 ядрах набагато швидші, ніж Дрегонфлай на 64:
The Dragonfly benchmark compares a standalone single process Redis instance (that can only utilize a single core) with a multithreaded Dragonfly instance (that can utilize all available cores on a VM/server). Unfortunately, this comparison does not represent how Redis is run in the real world. As technology builders, we strive to understand exactly how our technologies compare to others, so we did what we believe is a fair comparison and compared a 40-shard Redis 7.0 Cluster (that can utilize most of the instance cores) with Dragonfly, using a set of performance tests on the largest instance type used by the Dragonfly team in their benchmarks, AWS c6gn.16xlarge. In our trials, we saw Redis achieve 18% — 40% greater throughput than Dragonfly, even when utilizing only 40 out of the 64 vCores.
redis.com/...​hitecture-13-years-later

1) Тоді вам потрібен окремий потік на парсінг запитів. Наприклад, на 8-ядерному комп’ютері Редіс запустить 8 шардів, а ви — всього 6, щоб мати ще 2 службових потоки. Інакше, якщо ви запустите також 8 — то не матимете вільних ядер для парсингу. Де помилка в моєму тлумаченні?
2) Суть в тому, що ви не можете змінювати дані в той час, коли вони записуються на диск. І клієнт або має чекати, доки ви допишете, або ви маєте дуплікувати масив даних.
3) Ви наводите бенчмарк проти одного інстанса Редіса коли реальний бенчмарк має проводитись проти локального кластеру де кількість інстансів дорівнює кількості ядер процесора.

1) То чим тоді підхід Редісу, котрий надає оркестратор окремим модулем, гірший за ваш із вбудованим оркестратором між шардами?
2) Вона не пояснює юз кейс, котрий я запропонував. Або пояснення десь всередині проектно-специфічної термінології, котрою вона оперує.

1) Наскільки я зрозумів, вони експозять той самий інтерфейс пошуку, що й Редіс. А втрати швидкості на об’єднанні даних будуть у будь-якій shared-nothing системі, включно з вашою. Лише ви про них вголос не кажете.
2) У вас дані зберігаються блоками чи деревом?
— якщо блоками, то ви маєте скопіювати блок, щоб вносити в нього зміни під час його збереження на диск.
— якщо деревом, то у вас неефективна робота з кешом процесора.
Приклад що я маю на увазі:
* Є блоки даних А0, Б0, В0.
* Запускається копіювання на диск.
* Запустився ДМА для асинхронного збереження А0 на диск.
* Юзер пише в А, воно має змінитись на А1.
* Завершилося збереження А0 на диск.
* Запустилося збереження Б0 на диск.
* Юзер пише в В, воно має змінитись на В1.
* Завершилося збереження Б0 на диск.
* Юзер пише в Б, воно змінюється на Б1.
* Запустилось збереження В1 на диск.
* Завершилося збереження В1 на диск.
Питання: що маємо на диску? Якщо там А0, Б0, В0 — то ви десь маєте витрачати оперативку на версіонування блоків, або працювати не з блоками, а з деревом чи з патчами. Якщо ж на диску А0, Б0, В1 — то снепшот втратив причинно-наслідковий зв’язок записів (запис А1 випав з снепшоту, а він передує до В1).

1) Наскільки я розумію, ось це github.com/...​iSearch/tree/master/coord надає інтерфейс схожий на інтерфейс пошукового запиту. Точніше не скажу, бо з Редісом не працював. Можливо, ви можете навести приклад запиту, котрий не працює з RSCoordinator.
2) Себто, ви блокуєте (усі?) запити користувача на запис даних («оновлення»?) на весь час збереження бази на диск («серіалізація»?)?

1) Це не недолік архітектури, а вдала абстракція — власне, ідеальна імплементація shared-nothing. Такий кластер прозоро скейлиться з одної машини на датацентр. Приклади такої архітектури — Ерланг з Еліксиром, Акка, навіть та ж ScyllaDb, здається. Себто, це у вас буде зайвий рівень абстракції та дуплікація функціональності якщо ви колись заімплементите кластер — бо матимете 2 незалежних рівні shared-nothing.
2) Ви пропустили випадок оновлення даних *під час* серіалізації — власне, якщо форк робиться для серіалізації, то це і є основним випадком, і форк гарантує консистентність даних — бо усі сторінки пам’яті належать до одного снепшота.