Англійська для розробників ScyllaDB

ScyllaDB — це широкостовпцева база даних NoSQL, сумісна з моделлю даних Cassandra, але переписана для архітектури shard-per-core, яка змінює те, як команди міркують про продуктивність. Слова, такі як «ключ розділу», «гарячий розділ», «надгробок» і «швидкий на ядрі» мають певну операційну вагу — їх неправильне використання призводить до дизайнів, які виглядають добре локально і перекриваються під виробничим трафіком. Цей підручник містить інформацію англійською мовою, яку використовують під час обговорення ScyllaDB з командою.

Ключовий словник

** Ключ розділу ** — частина первинного ключа, яка визначає, на якому вузлі (і шарді) знаходиться рядок; всі рядки, які мають спільний ключ розділу, зберігаються разом і ефективно читаються разом. “Запит за ідентифікатором користувача працює добре, оскільки це ключ розділу — запит за електронною поштою означає сканування кожного розділу, оскільки електронна пошта не є його частиною.”

** Горячий розділ ** — розділ, який отримує непропорційно більше читання або запису, ніж інші, часто з погано обраного ключа розділу (наприклад, один популярний ідентифікатор користувача), перевантажуючи один вузол, коли інші залишаються бездіяльними. “Ця конструкція розміщує кожну подію для даного дня під одним ключем розділу — у день з високою нагрузкою, це гарячий розділ, і один шард в кінцевому підсумку виконує всю роботу.”

Shard-per-core — архітектура ScyllaDB, де кожне ядро процесора виконує свій власний незалежний шард з власною пам’яттю і вхідними/вихідними даними, уникаючи крос-ядерного блокування, на відміну від моделі потокового пулу Cassandra. “Зважаючи на використання принципу «шард-на-ядро», додавання більшої кількості ядер до вузла збільшує пропускну здатність майже лінійно — немає спільного блокування між ядрами, що борються за ті ж самі дані.”

** Tombstone ** — маркер, записаний під час вилучення рядка або комірки, зберігається до тих пір, поки утиснення не вилучить його; надто багато надгробків (від таких шаблонів, як часте вилучення і повторное вставлення) уповільнює читання, яке має проганяти їх.

• “Ця таблиця черги постійно вилучає і вставляє знову — це накопичення надгробків, і читання сповільнюється, тому що вони сканують тисячі мертвих маркерів.” *

** Стратегія стиснення ** — фоновий процес (і його налаштована стратегія — з розрядами розмірів, рівнями, вікнами часу), який об’ єднує таблиці SST на диску, відновлює місце з вилучених даних і впливає на швидкодію читання і запису по- різному. “Переключити цю таблицю часових рядків на стратегію стиснення за часом — ступінчасте стиснення не призначено для даних, які записуються лише один раз і термін їх дії закінчується за розкладом.”

Звичайні фрази

• Чи буде цей ключ розділу створювати гарячий розділ, коли трафік збільшиться?»
• Чи бачимо ми накопичення надгробків на цій таблиці, і чи це від шаблону доступу з великим вилученням?
• Яка стратегія стиснення налаштована тут, і чи відповідає вона шаблону запису/читання цієї таблиці?
• Чи означає shard-per-core, що ми повинні думати про навантаження на shard, а не на вузол?
• Чи дійсно це має бути один розділ, чи потрібно його розділити далі, щоб розподілити навантаження?»

Приклади висловлювань

Перегляд запиту на звантаження: “Це використовує фіксовану константу як частину ключа розділу для всіх записів сьогодні — це підручник з розділів, які чекають на зростання обсягу.”

Пояснення рішення про проектування:

• “Ми обирали стиснення за часом для цієї таблиці, оскільки дані мають строгий TTL і ніколи не оновлюватимуться після запису — це відповідає шаблону доступу набагато краще, ніж типове.” *

Опис події: “Затримка читання в цій таблиці зростала протягом тижнів, перш ніж хтось помітив, що це накопичення надгробків — шаблон вилучення-вставлення з логіки повторних спроб тихо отруїв швидкість читання.”

Професійні поради

• Використовуйте “ключ розділу” і “гарячий розділ” точно під час перегляду схеми — це єдине найпоширеніше джерело проблем виробництва в широкостовпчастих магазинах, і їх назва явно прискорює перегляд дизайну.
• Коли таблиця з великим обсягом видалення показує повільну затримку, запитайте “чи може це бути накопичення надгробків?”, перш ніж припустити, що це не пов’ язана регресія продуктивності.
• Згадайте shard-per-core явно, коли обговорюєте планування обсягу - це змінює одиницю масштабування з “додати вузол” на “мислити в осколках”, що впливає на те, як команди розміщують кластери.
• Назвіть ** стратегію стиснення ** безпосередньо під час запропонування схеми для часових рядків або даних з великою кількістю додатків — типова стратегія рідко є правильною для цих навантажень.

Практичні вправи

1. Поясніть у двох реченнях, яким чином погано обраний ключ розділу може створити « гарячий » розділ.
2. Написати коментар перегляду коду у одному реченні, у якому буде позначено шаблон з великою кількістю вилучень, що може призвести до накопичення надгробків.
3. Опишете вашими словами, що означає « осколків на ядро » і як це відрізняється від моделі « пул потоків ».

Національний гідрографічний інститут: Відповідь і відповіді

Для не-рідних англомовних носіїв, розуміння тонких відмінностей у фразування може бути значною перешкодою при обміні технічними ідеями. Це не просто про те, щоб знати * слова * для “shard” або “nambstone”, але як ці слова зазвичай використовуються в середовищі спільної розробки. Розглянемо деякі типові сценарії і як підійти до них з ясністю і впевненістю.

Однією з найчастіших ситуацій є отримання зворотнього зв’язку від перегляду коду. Коментар на зразок « Цей запит можна було б оптимізувати — розгляньте можливість використання більш вибіркового індексу » може здатися нечітким. Ключ не лише в розумінні концепції індексу, але й у конструктивному реагуванні. Замість того, щоб просто сказати « Добре », спробуйте щось на зразок: « Дякую за позначення цього! Я досліджу індекс і розгляну альтернативні формулювання запиту, щоб побачити, чи можемо ми зменшити розмір сканування. Чи можете ви розібратися, які конкретні частини запиту найбільше сприяють повільній швидкості роботи?» Це демонструє зацікавленість, підтверджує зворотній зв’ язок і запрошує до подальшого обговорення — ключового елемента у будь- якій успішній перевірці коду. Аналогічно, розмови Slack часто включають в себе запропоновані зміни; чітке формулювання вашого запиту є життєво важливим. Замість того, щоб просто сказати « Оновити це », запропонуйте щось на зразок: « Я планую перефакторизувати цей модуль, щоб він відповідав новій архітектурі ядра. Я буду оновлювати шар доступу до даних і переконатися, що всі запити використовують відповідну стратегію шардингу. ”

Іншою областю, де нюанс має велике значення, є описи запитів на витягування. При запропонуванні складної зміни, особливо пов’язаної з внутрішніми елементами ScyllaDB - наприклад, міграція даних до нового шарду - важливо надати достатній контекст. Хороший PR- опис не просто сказав би « Завершено міграцію шардів ». Замість цього він би сказав: « Впроваджено поетапну міграцію шардів для збірки « користувачів » з шарду 12 до шарду 18, дотримуючись найкращих практик ScyllaDB для мінімізації часу простою і ризиків несуперечності даних. Це включало створення надгробних записів для вилучених користувачів в початковому шарді і реплікацію їх на новий шард перед виведенням старого з експлуатації. Процес був відстежений за допомогою інструменту scyllalog, щоб переконатися, що під час реплікації не траплялося помилок

Зрозуміти ці тонкощі — зосередитися на тому, * чому * щось робиться, а не лише на тому, * що * робиться — значно поліпшить вашу здатність ефективно брати участь у обговореннях щодо розробки ScyllaDB і робити значний внесок у проекти. Це про будівництво спільного розуміння, а не просто перекладання слів.

scyllalog --format json | jq '.[]'