Teams sometimes need lower latency, lower costs (especially as they scale) or the ability to run their applications somewhere other than AWS. Легко зрозуміти, чому так багато команд звернулися до Amazon DynamoDB з моменту його введення в 2012 році. Почати легко, особливо якщо ваша організація вже вкорінена в екосистемі AWS. Вона відносно швидка і масштабована, з низькою кривою навчання. І оскільки вона повністю керована, вона абстрагує операційні зусилля та ноу-хау, традиційно необхідні для підтримки бази даних і роботи в здоровому стані. Але з плином часу з'являються недоліки, особливо по мірі масштабування робочих навантажень та розвитку бізнес-вимог. Команди іноді потребують меншої затримки, менших витрат (особливо по мірі масштабування) або можливості запускати свої додатки в іншому місці, ніж AWS. У цих випадках ScyllaDB, який пропонує API, сумісний з DynamoDB, часто вибирається як альтернатива. Розглянемо виклики, які змусили три команди покинути DynamoDB. Гнучкість та економія витрат Yieldmo - це онлайн-рекламна платформа, яка з'єднує видавців і рекламодавців в реальному часі за допомогою аукціонної системи, оптимізованої за допомогою ML. Їхній бізнес залежить від доставки оголошень швидко (в межах 200-300 мілісекунд) та ефективно, що вимагає ультрашвидких, високопропускних пошуків бази даних в масштабі. Спочатку вони побудували платформу на DynamoDB. Однак, хоча DynamoDB був надійним, значні обмеження з'явилися, коли вони зростали. Як пояснив Тодд Колман, технічний співзасновник і головний архітектор, їхні основні турботи були двоякими: зростаючі витрати і географічні обмеження. Досліджуючи альтернативи DynamoDB, вони сподівалися знайти варіант, який би підтримував швидкість, розширюваність та надійність, знижуючи витрати та забезпечуючи незалежність постачальника хмари. Yieldmo спочатку розглянув можливість залишитися з DynamoDB і додати кэшинг. Однак кэшинг не зміг вирішити проблему географічної затримки. Вони також досліджували Aerospike, який запропонував швидкість та підтримку у хмарному режимі. Однак індексація в пам'яті Aerospike вимагала б великої і дорогих кластерів для обробки великої кількості дрібних об'єктів даних Yieldmo. Тоді вони виявили ScyllaDB. І DynamoDB-сумісний API (Alternator) ScyllaDB був змінником гри. Тодд пояснив: «ScyllaDB підтримував розгортання між хмарами, вимагав керованої кількості серверів і запропонував конкурентні витрати. Найкраще, його API був сумісний з DynamoDB, що означає, що ми могли мігрувати з мінімальними змінами коду. Процес міграції був ретельно спланований, використовуючи існуючу архітектуру черги повідомлень Kafka, щоб забезпечити цілісність даних. Вони провели два тестування Proof-of-Concept (POC): спочатку з однією таблицею з 28 мільярдів об'єктів, а потім по всіх п'яти регіонах AWS. Результати були вражаючими. Тодд поділився, "Наші витрати на базу даних були скорочені вдвічі, навіть з цінами на резервну потужність DynamoDB".І крім економії витрат, Yieldmo отримав гнучкість, щоб потенційно розгортати між різними постачальниками хмар. Їх латентність покращилася, і ScyllaDB був настільки ж простий у використанні, як DynamoDB. У підсумку Тодд підсумував: «Одним з наших початкових занепокоєнь було відхилення від доведеної надійності DynamoDB. Однак ScyllaDB був відмінним партнером. Їх команда забезпечує моніторинг наших кластерів, попереджає нас про потенційні проблеми і консультує нас, коли необхідно масштабування з точки зору постійного обслуговування. Досвід був порівнянним з DynamoDB, але з більшою незалежністю та значною економією витрат». Повідомлення від Yieldmo Перехід до GCP з кращою продуктивністю та меншими витратами Digital Turbine, великий гравець в галузі мобільних рекламних технологій з річним доходом в 500 мільйонів доларів, зіткнувся з зростаючими проблемами з його впровадженням DynamoDB.Хоча його основна мотивація для міграції була стандартизацією на Google Cloud Platform після придбання, існуюче рішення DynamoDB викликало як проблеми з продуктивністю, так і з витратами в масштабі. "Це може бути трохи дорого, коли ви масштабуєте, щоб бути чесним", - пояснив Джозеф Шортер, віце-президент з архітектури платформ в Digital Turbine. "Ми знаходили деякі проблеми з продуктивністю.Ми робили тонну читань - 90% всіх взаємодій з DynamoDB були операціями читання. З усіма цими операціями ми виявили, що досягнення продуктивності вимагали від нас масштабувати більше, ніж ми хотіли, що збільшило витрати". Основною проблемою, за словами Шортера, було: «Як ми можемо мігрувати без радикального перетворення нашої платформи, зберігаючи при цьому принаймні таку ж продуктивність і цінність – і уникаючи ситуації аварій і спалахів? Після оцінки декількох варіантів, Digital Turbine перейшов на ScyllaDB і досяг негайних поліпшень. «Різниця в витратах на 20% - це велика цифра, незалежно від того, про що ви говорите, - зауважив Шортер. - І коли ви розглядаєте наші плани розширити ще більше, це стає ще більш значним». Окрім економії витрат, вони виявили себе "мало використовуючи кластери ScyllaDB", що передбачає простір для ще більшого зростання без пропорційного збільшення витрат. Створення Digital Turbine Висока швидкість написання з низькою затримкою та меншими витратами Команда «Статус користувача» та «Налаштування» одного з найбільших у світі сервісів потокового медіа використовувала DynamoDB протягом декількох років.У той час як вони перебудовували два існуючі випадки використання, вони задавалися питанням, чи настав час для зміни бази даних. Пауза / продовження: Якщо користувач дивиться шоу і зупиняє його, він може підібрати, де він зупинився - на будь-якому пристрої, з будь-якого місця. Статус перегляду: Використовуючи ті ж дані, визначте, чи переглянув користувач шоу. Ось проста архітектурна схема: Кожні 30 секунд клієнт надсилає серцебиття з оновленою позицією головної частини шоу, а потім надсилає ці події до бази даних. Edge Pipeline завантажує події в тому ж регіоні, що і користувач, в той час як Authority (Auth) Pipeline об'єднує події для всіх п'яти регіонів, які обслуговує компанія. Нарешті, дані повинні бути зібрані і відправлені назад до клієнта для підтримки відтворення. Дві основні технічні вимоги для підтримки цієї архітектури були: Щоб забезпечити великий досвід користувача, система повинна була залишатися високодоступною, з низькою затримкою і можливістю масштабування на основі збільшення трафіку. Щоб уникнути обширного налаштування інфраструктури або роботи з DBA, вони потребували легкої інтеграції зі своїми послугами AWS. Після того, як ці коробки були перевірені, команда також сподівалася знизити загальні витрати. "Наша існуюча інфраструктура мала дані, поширені по різних кластерах DynamoDB і Elasticache, тому ми дійсно хотіли щось просте, яке могло б об'єднати їх у набагато нижчу систему витрат", - пояснив їхній інженер. Зокрема, їм потрібна база даних з: Підтримка багатьох регіонів, оскільки сервіс був популярний у п'яти основних географічних регіонах. Оновлення не мали суворої угоди про рівень обслуговування (SLA), але система повинна була виконувати умовні оновлення на основі часових позначок подій. Можливість обробляти понад 78K читання в секунду з затримкою P99 від 10 до 20 мілісекунд. Випадок використання включав тільки прості точкові запити; такі речі, як індекси, розділення та складні шаблони запитів, не були основною проблемою. Приблизно 10 ТБ даних з простором для зростання. За словами їхнього інженера, «DynamoDB міг чудово підтримувати наші технічні вимоги. але з огляду на наш розмір даних і високу (писання важких) пропускну здатність, продовження з DynamoDB було б, як викидати гроші в вогонь». Виходячи з їхніх вимог щодо продуктивності та вартості написання, вони вирішили дослідити ScyllaDB. Для підтвердження концепції, вони створили кластер тестування ScyllaDB Cloud з шістьма вузлами AWS i4i 4xlarge і завантажили кластер з 3 мільярдами записів. Вони виконали об'єднані навантаження 170K записів на секунду і 78K читань на секунду. Ці низькі затримки, у поєднанні з значною економією витрат (понад 50%), переконали їх залишити DynamoDB. На додаток до більш низьких затримок за більш низькою ціною, команда також оцінила наступні аспекти ScyllaDB: Конструкція ScyllaDB, орієнтована на продуктивність (будується на основі Framework Seastar, використовує C++, є NUMA-свідомим, пропонує драйвери, які не усвідомлюються тощо), допомагає команді скоротити час та витрати на технічне обслуговування. Стратегія інтенсивного стиснення допомагає їм значно зменшити посилення написання. Наприклад, Auth використовує консистенцію кворуму, а Edge використовує рівень консистенції «1» через дублювання даних і високу пропускну здатність. Їхній інженер-бак-енд зробив висновок: «Вибирати базу даних важко. Ви повинні враховувати не тільки функції, а й витрати. "У нашому випадку, через високі вимоги пропускної здатності та затримки, DynamoDB без сервера не був чудовим варіантом.Також, не недооцінюйте роль апаратного забезпечення. Дізнайтеся більше Ваша команда наступна? Якщо ваша команда розглядає , Зареєструйтеся, щоб відкрити щоб розповісти більше про ваш випадок використання, SLA, технічні вимоги та те, що ви сподіваєтеся оптимізувати. ми дамо вам знати, чи є ScyllaDB гарним і, якщо так, що міграція може означати з точки зору змін додатків, моделювання даних, інфраструктури тощо. Перехід від DynamoDB ScyllaDB може бути варіантом Технічна консультація Бонус: Ось швидкий погляд на те, як ScyllaDB порівнює з DynamoDB: Написано від : Гільєрме да Сілва Ног'єра та Феліпе Карденєті Мендес . Написано від Гільєрме да Сілва Ног'єра Феліпе Карденєті Мендес
