Sui представила Tidehunter — спеціально розроблений блокчейн-двигун зберігання даних, створений для заміни RocksDB шляхом зменшення ампліфікації записів і забезпечення більш високої, стабільної пропускної здатності та нижчої затримки для навантажень валідаторів і повних вузлів.
Sui, мережа блокчейн рівня 1, представила Tidehunter — новий двигун зберігання, розроблений відповідно до вимог щодо продуктивності, характеристик доступу до даних та операційних обмежень, що характерні для сучасних інфраструктур блокчейнів.
Система позиціонується як потенційний наступник існуючого рівня бази даних, що використовується як валідаторами, так і повними вузлами, відображаючи ширший рух до модернізації основної інфраструктури у відповідь на зростаючі масштаби та профілі навантажень виробничих блокчейн-систем.
Спочатку Sui використовувала RocksDB як основний рівень зберігання ключ-значення — широко застосовуване та зріле рішення, що дозволяло швидко розвивати протокол. Однак із розширенням платформи та зростанням операційних вимог почали проявлятися фундаментальні обмеження універсальних LSM-дерев баз даних у виробничих умовах.
Ретельне налаштування та глибока внутрішня експертиза не могли повністю подолати структурні недоліки, що конфліктували з характерними моделями доступу до даних у блокчейнах. Це спричинило стратегічний перехід до розробки двигуна зберігання, оптимізованого саме для навантажень блокчейну, що й призвело до створення Tidehunter.
Одним із ключових факторів цього рішення була постійна ампліфікація записів. Вимірювання у реалістичних навантаженнях Sui показали рівень ампліфікації приблизно у десять-дванадцять разів, що означає, що відносно невеликі обсяги даних додатків генерували непропорційно великий обсяг дискового трафіку. Хоча така поведінка є поширеною у системах на основі LSM, вона зменшує ефективну пропускну здатність зберігання та посилює конкуренцію між фоновою компресією та операціями читання. У навантаженнях з високою інтенсивністю записів або балансом читання і запису цей наклад стає дедалі більш обмежувальним при масштабуванні пропускної здатності.
Тестування навантаження на високопродуктивних кластерах підтвердило цей вплив: використання диска наближалося до максимальної межі, незважаючи на помірні швидкості запису застосунків, що підкреслює зростаючу невідповідність між традиційними архітектурами зберігання та сучасними вимогами до продуктивності блокчейнів.
Архітектура Tidehunter: двигун зберігання, оптимізований для моделей доступу до даних у блокчейнах і стабільних високопродуктивних навантажень
Поведінка зберігання у Sui та подібних платформах визначається невеликим набором повторюваних моделей доступу до даних, і Tidehunter розроблений саме навколо цих характеристик. Значна частина стану адресована за допомогою криптографічних хеш-ключів, які рівномірно розподілені і зазвичай відповідають досить великим записам, що усуває локальність, але спрощує цілісність і правильність.
Одночасно блокчейни сильно залежать від структур, орієнтованих на додавання даних, таких як журнали консенсусу та контрольні точки, де дані записуються послідовно і потім витягуються за допомогою монотонно зростаючих ідентифікаторів. Такі середовища також за своєю природою є write-heavy, але при цьому вимагають швидкого доступу на затримко-критичних шляхах читання, тому надмірна ампліфікація записів є прямою загрозою як пропускній здатності, так і швидкодії.
У центрі Tidehunter — висококонкурентний конвеєр запису, побудований для використання паралельних можливостей сучасних твердотільних накопичувачів. Вхідні записи спрямовуються через безблоковий журнал перед записом, здатний підтримувати надзвичайно високі швидкості операцій, при цьому конкуренція обмежена мінімальним кроком виділення пам’яті.
Копіювання даних відбувається паралельно, і система уникає системних викликів для кожної операції, використовуючи записувані файли з пам’яттю, що мапується, а надійність забезпечується асинхронно фоновими службами. Такий дизайн створює передбачуваний і високопаралельний шлях запису, здатний наситити пропускну здатність диска без обмежень через навантаження на ЦП.
Зменшення ампліфікації записів розглядається як основна архітектурна ціль, а не просто оптимізація. Замість використання журналу як тимчасової зони, Tidehunter зберігає дані постійно у сегментах журналу та створює індекси, що безпосередньо посилаються на оффсети, виключаючи повторні перезаписи значень.
Індекси сильно розподілені для зменшення ампліфікації записів і підвищення паралельності, що усуває потребу у традиційних структурах LSM-дерев. Для наборів даних, орієнтованих на додавання, таких як контрольні точки та записи консенсусу, застосовуються спеціальні стратегії шардування, що тримають недавні дані щільно згрупованими, щоб зберегти стабільність накладних витрат навіть при зростанні історичних даних.
Для таблиць із рівномірно розподіленими хеш-ключами Tidehunter вводить у дію уніфікований індекс пошуку, оптимізований для передбачуваного, низьколатентного доступу. Замість кількох дрібних випадкових читань, індекс зчитує трохи більший смугастий регіон, що статистично містить потрібний запис, дозволяючи більшість пошуків завершуватися за один оберт диска.
Такий підхід навмисно жертвує частиною пропускної здатності читання заради нижчої та більш стабільної затримки — компроміс, який стає практичним, оскільки зменшена ампліфікація записів звільняє значний обсяг дискової пропускної здатності для читання. Результатом є більш стабільна продуктивність у чутливих до затримки операціях, таких як виконання транзакцій і валідація стану.
Щоб ще більше контролювати затримки на кінцях масштабування, Tidehunter поєднує прямий I/O з кешуванням, керованим застосунком. Великі історичні читання обходять кеш сторінки операційної системи, щоб уникнути забруднення кешу, тоді як недавні та часто використовувані дані зберігаються у кешах користувацького простору, що інформуються моделями доступу застосунків. У поєднанні з індексною структурою це зменшує зайві обертання диска і підвищує передбачуваність при тривалому навантаженні.
Управління життєвим циклом даних також спрощене: оскільки записи зберігаються безпосередньо у сегментах журналу, видалення застарілих даних можна виконати шляхом видалення цілого файлу журналу, коли він виходить за межі збережувального вікна. Це уникає складних і ресурсомістких механізмів компресії, необхідних у базах даних на основі LSM, і дозволяє швидше та передбачуваніше очищати дані навіть при зростанні обсягів.
На основі тестів із реальним використанням Sui Tidehunter демонструє вищу пропускну здатність і нижчу затримку ніж RocksDB, при цьому споживаючи значно менше дискового запису. Найбільш очевидним покращенням є майже повна відмова від ампліфікації записів, що дозволяє активності диска більш точно відповідати записам застосунків і зберігати I/O-місткість для читань. Ці ефекти підтверджуються як у контрольованих бенчмарках, так і у повних розгортаннях валідаторів, що свідчить про те, що переваги виходять за межі синтетичних тестів.
Оцінка проводиться за допомогою незалежного бенчмарку, що моделює реальні сценарії вставки, видалення, точкових пошуків і ітерацій. Тести параметризуються для відображення розподілів ключів, розмірів значень і співвідношень читання-запису, і виконуються на апаратному забезпеченні, відповідному рекомендаціям для валідаторів. За цих умов Tidehunter стабільно підтримує вищу пропускну здатність і нижчу затримку ніж RocksDB, особливо у сценаріях з високим навантаженням на запис і балансом.
Бенчмарки валідаторів додатково підтверджують ці результати. Інтеграція безпосередньо у Sui і під час тривалого навантаження транзакцій системи з Tidehunter зберігають стабільну пропускну здатність і нижчу затримку при точках роботи, де розгортання на RocksDB починає страждати від зростання навантаження на диск і деградації продуктивності. Вимірювання показують зменшення навантаження на диск, стабільніше використання ЦП і покращену затримку остаточного підтвердження, що свідчить про чітке розходження у поведінці при порівнянних навантаженнях.
Tidehunter є практичною відповіддю на операційні вимоги довготривалих, високопродуктивних систем блокчейну. Оскільки блокчейни рухаються до стабільних, а не сплескових навантажень, ефективність зберігання стає фундаментальним вимогою для продуктивності протоколу. Конструкція Tidehunter відображає перехід до інфраструктури, створеної спеціально для наступної стадії масштабування, з додатковими технічними деталями та планами розгортання, що з’являться пізніше.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Tidehunter: База даних наступного покоління Sui, оптимізована для низької затримки та зменшення підсилення запису
Коротко
Sui представила Tidehunter — спеціально розроблений блокчейн-двигун зберігання даних, створений для заміни RocksDB шляхом зменшення ампліфікації записів і забезпечення більш високої, стабільної пропускної здатності та нижчої затримки для навантажень валідаторів і повних вузлів.
Sui, мережа блокчейн рівня 1, представила Tidehunter — новий двигун зберігання, розроблений відповідно до вимог щодо продуктивності, характеристик доступу до даних та операційних обмежень, що характерні для сучасних інфраструктур блокчейнів.
Система позиціонується як потенційний наступник існуючого рівня бази даних, що використовується як валідаторами, так і повними вузлами, відображаючи ширший рух до модернізації основної інфраструктури у відповідь на зростаючі масштаби та профілі навантажень виробничих блокчейн-систем.
Спочатку Sui використовувала RocksDB як основний рівень зберігання ключ-значення — широко застосовуване та зріле рішення, що дозволяло швидко розвивати протокол. Однак із розширенням платформи та зростанням операційних вимог почали проявлятися фундаментальні обмеження універсальних LSM-дерев баз даних у виробничих умовах.
Ретельне налаштування та глибока внутрішня експертиза не могли повністю подолати структурні недоліки, що конфліктували з характерними моделями доступу до даних у блокчейнах. Це спричинило стратегічний перехід до розробки двигуна зберігання, оптимізованого саме для навантажень блокчейну, що й призвело до створення Tidehunter.
Одним із ключових факторів цього рішення була постійна ампліфікація записів. Вимірювання у реалістичних навантаженнях Sui показали рівень ампліфікації приблизно у десять-дванадцять разів, що означає, що відносно невеликі обсяги даних додатків генерували непропорційно великий обсяг дискового трафіку. Хоча така поведінка є поширеною у системах на основі LSM, вона зменшує ефективну пропускну здатність зберігання та посилює конкуренцію між фоновою компресією та операціями читання. У навантаженнях з високою інтенсивністю записів або балансом читання і запису цей наклад стає дедалі більш обмежувальним при масштабуванні пропускної здатності.
Тестування навантаження на високопродуктивних кластерах підтвердило цей вплив: використання диска наближалося до максимальної межі, незважаючи на помірні швидкості запису застосунків, що підкреслює зростаючу невідповідність між традиційними архітектурами зберігання та сучасними вимогами до продуктивності блокчейнів.
Архітектура Tidehunter: двигун зберігання, оптимізований для моделей доступу до даних у блокчейнах і стабільних високопродуктивних навантажень
Поведінка зберігання у Sui та подібних платформах визначається невеликим набором повторюваних моделей доступу до даних, і Tidehunter розроблений саме навколо цих характеристик. Значна частина стану адресована за допомогою криптографічних хеш-ключів, які рівномірно розподілені і зазвичай відповідають досить великим записам, що усуває локальність, але спрощує цілісність і правильність.
Одночасно блокчейни сильно залежать від структур, орієнтованих на додавання даних, таких як журнали консенсусу та контрольні точки, де дані записуються послідовно і потім витягуються за допомогою монотонно зростаючих ідентифікаторів. Такі середовища також за своєю природою є write-heavy, але при цьому вимагають швидкого доступу на затримко-критичних шляхах читання, тому надмірна ампліфікація записів є прямою загрозою як пропускній здатності, так і швидкодії.
У центрі Tidehunter — висококонкурентний конвеєр запису, побудований для використання паралельних можливостей сучасних твердотільних накопичувачів. Вхідні записи спрямовуються через безблоковий журнал перед записом, здатний підтримувати надзвичайно високі швидкості операцій, при цьому конкуренція обмежена мінімальним кроком виділення пам’яті.
Копіювання даних відбувається паралельно, і система уникає системних викликів для кожної операції, використовуючи записувані файли з пам’яттю, що мапується, а надійність забезпечується асинхронно фоновими службами. Такий дизайн створює передбачуваний і високопаралельний шлях запису, здатний наситити пропускну здатність диска без обмежень через навантаження на ЦП.
Зменшення ампліфікації записів розглядається як основна архітектурна ціль, а не просто оптимізація. Замість використання журналу як тимчасової зони, Tidehunter зберігає дані постійно у сегментах журналу та створює індекси, що безпосередньо посилаються на оффсети, виключаючи повторні перезаписи значень.
Індекси сильно розподілені для зменшення ампліфікації записів і підвищення паралельності, що усуває потребу у традиційних структурах LSM-дерев. Для наборів даних, орієнтованих на додавання, таких як контрольні точки та записи консенсусу, застосовуються спеціальні стратегії шардування, що тримають недавні дані щільно згрупованими, щоб зберегти стабільність накладних витрат навіть при зростанні історичних даних.
Для таблиць із рівномірно розподіленими хеш-ключами Tidehunter вводить у дію уніфікований індекс пошуку, оптимізований для передбачуваного, низьколатентного доступу. Замість кількох дрібних випадкових читань, індекс зчитує трохи більший смугастий регіон, що статистично містить потрібний запис, дозволяючи більшість пошуків завершуватися за один оберт диска.
Такий підхід навмисно жертвує частиною пропускної здатності читання заради нижчої та більш стабільної затримки — компроміс, який стає практичним, оскільки зменшена ампліфікація записів звільняє значний обсяг дискової пропускної здатності для читання. Результатом є більш стабільна продуктивність у чутливих до затримки операціях, таких як виконання транзакцій і валідація стану.
Щоб ще більше контролювати затримки на кінцях масштабування, Tidehunter поєднує прямий I/O з кешуванням, керованим застосунком. Великі історичні читання обходять кеш сторінки операційної системи, щоб уникнути забруднення кешу, тоді як недавні та часто використовувані дані зберігаються у кешах користувацького простору, що інформуються моделями доступу застосунків. У поєднанні з індексною структурою це зменшує зайві обертання диска і підвищує передбачуваність при тривалому навантаженні.
Управління життєвим циклом даних також спрощене: оскільки записи зберігаються безпосередньо у сегментах журналу, видалення застарілих даних можна виконати шляхом видалення цілого файлу журналу, коли він виходить за межі збережувального вікна. Це уникає складних і ресурсомістких механізмів компресії, необхідних у базах даних на основі LSM, і дозволяє швидше та передбачуваніше очищати дані навіть при зростанні обсягів.
На основі тестів із реальним використанням Sui Tidehunter демонструє вищу пропускну здатність і нижчу затримку ніж RocksDB, при цьому споживаючи значно менше дискового запису. Найбільш очевидним покращенням є майже повна відмова від ампліфікації записів, що дозволяє активності диска більш точно відповідати записам застосунків і зберігати I/O-місткість для читань. Ці ефекти підтверджуються як у контрольованих бенчмарках, так і у повних розгортаннях валідаторів, що свідчить про те, що переваги виходять за межі синтетичних тестів.
Оцінка проводиться за допомогою незалежного бенчмарку, що моделює реальні сценарії вставки, видалення, точкових пошуків і ітерацій. Тести параметризуються для відображення розподілів ключів, розмірів значень і співвідношень читання-запису, і виконуються на апаратному забезпеченні, відповідному рекомендаціям для валідаторів. За цих умов Tidehunter стабільно підтримує вищу пропускну здатність і нижчу затримку ніж RocksDB, особливо у сценаріях з високим навантаженням на запис і балансом.
Бенчмарки валідаторів додатково підтверджують ці результати. Інтеграція безпосередньо у Sui і під час тривалого навантаження транзакцій системи з Tidehunter зберігають стабільну пропускну здатність і нижчу затримку при точках роботи, де розгортання на RocksDB починає страждати від зростання навантаження на диск і деградації продуктивності. Вимірювання показують зменшення навантаження на диск, стабільніше використання ЦП і покращену затримку остаточного підтвердження, що свідчить про чітке розходження у поведінці при порівнянних навантаженнях.
Tidehunter є практичною відповіддю на операційні вимоги довготривалих, високопродуктивних систем блокчейну. Оскільки блокчейни рухаються до стабільних, а не сплескових навантажень, ефективність зберігання стає фундаментальним вимогою для продуктивності протоколу. Конструкція Tidehunter відображає перехід до інфраструктури, створеної спеціально для наступної стадії масштабування, з додатковими технічними деталями та планами розгортання, що з’являться пізніше.