Azərbaycanca
Беларускі
Dansk
Deutsch
Española
Français
Indonesia
Italiana
日本語
Қазақ
Lietuvos
Nederlands
Português
Русский
සිංහල
แบบไทย
Türkçe
Українська
中國人
United State
Afrikaans
Amazon DynamoDB — це повністю керована власницька NoSQL база даних, яка підтримує структурну парадигму «ключ—значення» як для даних, так і для документів. Вона пропонується Amazon.com як одна зі служб Amazon Web Services. DynamoDB заснована на аналогічній моделі даних та отримала свою назву від [en], але в своїй основі має іншу реалізацію. Dynamo мало багатопрофільний дизайн, який вимагав від клієнта вирішення конфліктів версій, а DynamoDB використовує синхронну реплікацію в декількох центрах обробки даних, що забезпечує високу довговічність та доступність. DynamoDB була представлена CTO Amazon [en] 18 січня 2012 року як еволюція рішення Amazon SimpleDB.
 | |
| Тип | NoSQL і хмарна база даних |
|---|---|
| Розробник | Amazon.com |
| Перший випуск | січень 2012 |
| Операційна система | Багатоплатформна |
| Доступні мови | English |
| Ліцензія | Власницька |
| Вебсайт | aws.amazon.com/dynamodb/ |
Історія розробки
В анонсі проекту 2012 року Вогель описує причини його створення. Amazon розпочався як децентралізована мережа послуг. Спочатку служби мали прямий доступ до баз даних один одного. Коли це стало вузьким місцем в інженерних операціях, служби відійшли від цієї схеми прямого доступу на користь API, орієнтованого на широкий загал. Тим не менш, сторонні системи управління реляційними базами даних намагалися впоратись з клієнтською базою Amazon. Це завершилося крахом під час свят 2004 року, коли декілька технологій не владнали з масштабуванням високого навантаженого трафіку.
Інженери нормалізували ці реляційні БД для зменшення надмірності даних, що є стандартним підходом при оптимізації сховищ даних. При такому підході в жертву приносяться «елементи» даних (наприклад, інформацію, що стосується товару в базі даних продукту), які розкладаються на записи в різних таблицях, і потрібен час, щоб зібрати окремі частини для обробки запиту. Багато служб Amazon вимагали в основному читання по первинному ключу своїх даних, і швидкість має першочерговий пріоритет, тому складання цих фрагментів в одне ціле вимагає занадто багато додаткових операцій.
Відповіддю Amazon, з компромісною ефективністю зберігання, було використання [en]: це високодоступне сховище з парадигмою «ключ—значення», яке було створено для внутрішнього використання. Здавалося, що Dynamo мало все потрібне інженерам, але впровадження затримувалось. Розробники Amazon обрали підхід «просто працює» за допомогою S3 та SimpleDB. Хоча ці системи мали суттєві недоліки, проте вони не вимагали додаткових витрат на обладнання, масштабування та перерозподіл даних. Для Amazon наступною ітерацією технології NoSQL, була DynamoDB, яка автоматизувала ці операції з управління базами даних та полегшила працю розробників.
Огляд
DynamoDB відрізняється від інших служб Amazon тим, що дозволяє розробникам купувати послугу на основі пропускної здатності (throughput), а не на зберігання (storage). Якщо ввімкнено автоматичне масштабування, то база даних буде масштабуватися автоматично. Крім того, адміністратори можуть робити запити на зміну пропускної здатності, а DynamoDB поширюватиме дані та трафік на декілька серверів, використовуючи твердотільні накопичувачі, що забезпечує прогнозовану продуктивність. Можлива інтеграція з Hadoop через Elastic MapReduce.
У вересні 2013 року Amazon випустила версію для локальної розробки DynamoDB, щоб розробники могли тестувати додатки, підтримувані DynamoDB, локально.
Розробка з DynamoDB
Моделювання даних
DynamoDB таблиця включає записи (item), які мають атрибути, деякі з яких утворюють первинний ключ. Якщо в реляційних системах запис містить кожен атрибут таблиці (або оперує значеннями «null» чи «unknown» за їх відсутності), то записи в DynamoDB не мають схеми. Єдиний виняток: при створенні таблиці розробник вказує первинний ключ, а таблиця вимагає цього ключа для кожного запису. Первинні ключі повинні бути скалярними (рядки, числа чи двійкові) і можуть мати одну з двох наступних форм. Первинний ключ з одним атрибутом відомий як «ключ секції» (partition key) таблиці. Ключ секції визначає секцію по хешу запису, бо ідеальний ключ секції повинен мати рівномірний розподіл діапазону. Первинний ключ також може мати другий атрибут, який DynamoDB називає табличним «ключем сортування». У цьому випадку ключі секцій не повинні бути унікальними; вони поєднуються з ключами сортування для утворення унікального ідентифікатора для кожного запису. Ключ секції все ще використовується для визначення того, в якій секції зберігається запис, але в кожній секції записи сортуються за ключем сортування.
Індекси
У реляційній моделі індекси, як правило, служать «допоміжною» структурою даних для доповнення таблиці. Вони дозволяють СУБД оптимізувати запити з використанням методів прихованих від користувача, і вони не покращують функціональність запитів. У DynamoDB немає оптимізатора запитів, а індекс — це просто інша таблиця з іншим ключем (або двома), що зберігається разом з оригіналом. Коли розробник створює індекс, то створюється копія даних, але копіюються лише ті поля, які вказані (як мінімум поля, які індексуються та первинний ключ базової таблиці).
Запити записів користувачів DynamoDB адресується безпосередньо до власних індексів. Доступні два типи індексів. Глобальний вторинний індекс (global secondary index, GSI) містить ключ розділу (і необов'язковий ключ сортування), який відрізняється від ключа розділу оригінальної таблиці. Локальний вторинний індекс (local secondary index, LSI) містить той самий ключ розділу, що і початкова таблиця, але інший ключ сортування. Обидва індекси вводять абсолютно нову функціональність запитів у базу даних DynamoDB, дозволяючи виконувати запити на нових ключах.
Ця система індексації є надмірністю даних, чистою та простою, чого не дозволяється в реляційних БД. Індекси — це яскравий приклад того, як DynamoDB надає пріоритет швидкості над ефективністю використання простору. Як і у реляційних системах, DynamoDB оновлює індекси автоматично при додаванні/оновленні/видаленні записів, тому варто бути обережними при створенні індексів, бо інакше є ризик сповільнення важкої на запис бази даних через гальмування оновлення індексу.
Синтаксис
DynamoDB використовує JSON для свого синтаксису через його популярність у розробників. Створення таблиці вимагає лише трьох аргументів: TableName, KeySchema — список, що містить ключ секції та необов'язковий ключ сортування — та AttributeDefinitions — список атрибутів записів, серед яких повинні бути атрибути, що використовуються як ключі секції та сортування. Тоді як реляційні бази даних пропонують надійні мови запитів, DynamoDB пропонує лише операції Put, Get, Update та Delete. Запити додавання запитів (Put) містять атрибут TableName та атрибут Item, який складається з усіх атрибутів та значень, які має запис. Запит на оновлення Update відповідає тому ж синтаксису. Аналогічно, щоб отримати записи (Get) або видалити (Delete) запис, просто вказують TableName та Key.
Архітектура системи
Структури даних
DynamoDB використовує як хешування, так і B-дерева для управління даними. Після введення дані спочатку поширюються на різні секції шляхом гешування ключа секції. Кожна секція може зберігати до 10 ГБ даних та обробляти за замовчуванням 1000 одиниць ємності запису (Write Capacity Units, WCU) та 3000 одиниць ємності зчитування (Read Capacity Units, RCU). Один RCU являє собою одне узгоджене зчитування в секунду або два не узгоджених читання в секунду для записів розміром до 4 КБ. Один WCU являє собою один запис в секунду для запису розміром до 1 КБ.
Щоб запобігти втраті даних, DynamoDB оснащено дворівневою системою резервної реплікації та довготривалого зберігання. Кожна секція містить три вузли, кожен з яких містить копію даних цієї секції. Кожен вузол містить також дві структури даних: B-дерево, яке використовується для пошуку елементів, і журнал реплікації, який зазначає всі зміни, внесені до вузла. DynamoDB періодично робить знімки цих двох структур даних і зберігає їх протягом місяця в S3, щоб інженери могли виконати своєчасне відновлення баз даних у разі потреби.
У кожній секції один з трьох вузлів позначається «лідером» (leader node). Усі операції запису проходять спочатку через цей лідер-вузол перед поширенням на інші вузли, що робить записи узгодженими в DynamoDB. Для підтримки свого статусу лідер-вузол кожні 1,5 секунди надсилає кожному вузлу «пульс» (heartbeat). Якщо інший вузол перестане приймати пульс, він може ініціювати нові вибори лідера. DynamoDB використовує алгоритм Паксос для обрання лідерів.
Інженери Amazon спочатку уникали використання Dynamo через додаткові інженерні витрати, такі як забезпечення ресурсів, керування секціями та вузлами. Тому команда DynamoDB створила сервіс AutoAdmin для управління базою даних. AutoAdmin замінює вузол, коли він перестає реагувати, для цього дані копіюються з іншого вузла. Коли секція перевищує будь-яке із трьох порогових значень параметрів на читання чи запис (RCU, WCU) або розмір даних перевищує 10 Гб, AutoAdmin автоматично додає нові секції для подальшої сегментації даних.
Подібно до систем індексації в реляційній моделі, DynamoDB вимагає, щоб будь-які оновлення таблиці відображалися в кожному з індексів таблиці. DynamoDB робить це за допомогою служби, яка називається «розповсюджувач журналів» (log propagator), та підписана на журнали реплікації кожного вузла і надсилає додаткові запити Put, Update та Delete в індекси за необхідності. Оскільки використання індексів призводить до суттєвого впливу на продуктивність запитів, які виконують запис, то DynamoDB дозволяє користувачеві робити не більше п'яти запитів до будь-якої таблиці.
Виконання запиту
Припустимо, що користувач DynamoDB виконує операцію запису (Put, Update або Delete). У той час як типова реляційна система перетворює SQL-запит у формулу реляційної алгебри і запускає алгоритми оптимізації, DynamoDB пропускає ці обидва процеси і отримує дозвіл на виконання. Запит надходить на маршрутизатор запитів DynamoDB, який підтверджує автентифікацію — «Чи надходить запит звідти та від того, кім він себе оголосив?» Припускаючи, що ці перевірки виконуються успішно, система гешує ключ секції для відправки у відповідну секцію. Всередині є три вузли, кожен з яких має копію даних секції. Система спочатку виконує запис у лідер-вузол, потім записує на другий вузол, потім надсилає повідомлення про успішне виконання операції і, нарешті, поширюється на третій вузол. Записи є узгодженими, бо вони завжди спочатку надходять через лідер-вузол.
Нарешті, служба «розповсюджувач журналів» поширює зміни на всі індекси. Для кожного індексу він бере значення цього індексу первинного ключа з запису, а потім виконує те саме записування цього індексу без поширення логування. Якщо операція є оновленням до вже існуючого елемента, оновлений атрибут може слугувати первинним ключем для індексу, і, таким чином, B-дерево для цього індексу також має оновлюватись. B-дерева обробляють лише операції вставлення, видалення та читання, тому на практиці, коли розповсюджувач журналу отримує операцію «Update», він видає операцію «Delete» та «Put» всім індексам.
Тепер припустимо, що користувач DynamoDB виконує операцію Get. Маршрутизатор запитів проходить, як і раніше, аутентифікацію та авторизацію. Далі, як зазначено вище, ми гешуємо наш ключ секції, щоб потрапити у відповідний геш. Тепер ми стикаємося з проблемою: як можна вирішити, що слід досліджувати, з трьома вузлами в можливій відповідності один одному. DynamoDB надає користувачеві два варіанти при видачі читання: узгоджене та [en]. При узгодженому читанні відвідується лідер-вузол. Але, тут знов виникає компроміс щодо узгодженості та доступності: у системах важких для читання завжди читання від лідера може перевантажити окремий вузол і зменшити доступність.
В другому варіанті, зрештою узгоджене читання, вибирає випадковий вузол. На практиці саме тут DynamoDB поступається узгодженістю відносно доступності. Якщо ми оберемо цей маршрут, які шанси на неузгодженість? Нам знадобиться операція запису, щоб повернути «успіх» і розпочати поширення на третій вузол, але не закінчити. Нам також знадобиться наш Get, щоб націлитись на третій вузол. Це означає, що ймовірність виникнення неузгодженості 1 до 3 у часовому вікні розповсюдження запису. Якого розміру це часове вікно? Так можливі численні катастрофи, які можуть спричинити відставання вузла, але в переважній більшості випадків третій вузол оновлюється протягом мілісекунд після лідера.
Мовне зв'язування
Мови та програмні каркаси із мовною прив'язкою до DynamoDB включають Java, JavaScript, Node.js, Go, C# .NET, Perl, PHP, Python, Ruby, Haskell, Erlang, Django та Grails.
Продуктивність
DynamoDB надає показники продуктивності, які допомагають користувачам правильно підтримувати безперебійну роботу програм із використанням DynamoDB:
- Запити та throttling
- Помилки: ConditionalCheckFailedRequests, UserErrors, SystemErrors
- Метрики, пов'язані зі створенням глобального вторинного індексу [ 28 грудня 2019 у Wayback Machine.]
Ці показники можна відстежувати за допомогою консолі управління AWS, використовуючи інтерфейс командного рядка AWS або інструмент моніторингу, що інтегрується з Amazon CloudWatch.
Див. також
- [en]
- [en]
- Служба реляційних баз даних Amazon
- [en]
Примітки
- . www.allthingsdistributed.com. Архів оригіналу за 12 листопада 2020. Процитовано 14 вересня 2019.
- . Amazon Web Services, Inc. Архів оригіналу за 19 січня 2021. Процитовано 13 вересня 2019.
- Clark, Jack (19 січня 2012). . ZDNet. Архів оригіналу за 21 січня 2012. Процитовано 21 січня 2012.
- . Amazon Web Services. Архів оригіналу за 19 січня 2021. Процитовано 13 вересня 2019.
- Vogels, Werner (18 січня 2012). Amazon DynamoDB – a Fast and Scalable NoSQL Database Service Designed for Internet Scale Applications. All Things Distributed blog. Архів оригіналу за 1 січня 2013. Процитовано 21 січня 2012.
- . Amazon Web Services, Inc. Архів оригіналу за 19 січня 2021. Процитовано 3 червня 2019.
- DeCandia, Giuseppe; Hastorun, Deniz; Jampani, Madan; Kakulapati, Gunavardhan; Lakshman, Avinash; Pilchin, Alex; Sivasubramanian, Swaminathan; Vosshall, Peter; Vogels, Werner (October 2007). Dynamo: Amazon's Highly Available Key-value Store. SIGOPS Oper. Syst. Rev. 41 (6): 205—220. doi:10.1145/1323293.1294281. ISSN 0163-5980.
- . docs.aws.amazon.com. Архів оригіналу за 21 жовтня 2019. Процитовано 5 липня 2017.
- . Amazon Web Services. 12 вересня 2013. Архів оригіналу за 22 червня 2014. Процитовано 13 вересня 2013.
- . AWS. 10 серпня 2012. Архів оригіналу за 18 жовтня 2019. Процитовано 18 липня 2019.
- Gunasekara, Archie (27 червня 2016). . Shine Solutions Group (англ.). Архів оригіналу за 3 серпня 2019. Процитовано 3 серпня 2019.
- (англ.), архів оригіналу за 20 серпня 2019, процитовано 3 серпня 2019
- . Amazon Web Services. Архів оригіналу за 4 квітня 2019. Процитовано 13 вересня 2019.
- . Архів оригіналу за 25 липня 2020. Процитовано 13 вересня 2019.
- . Архів оригіналу за 25 липня 2020. Процитовано 13 вересня 2019.
Посилання
- Офіційний сайт
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
Amazon DynamoDB ce povnistyu kerovana vlasnicka NoSQL baza danih yaka pidtrimuye strukturnu paradigmu klyuch znachennya yak dlya danih tak i dlya dokumentiv Vona proponuyetsya Amazon com yak odna zi sluzhb Amazon Web Services DynamoDB zasnovana na analogichnij modeli danih ta otrimala svoyu nazvu vid en ale v svoyij osnovi maye inshu realizaciyu Dynamo malo bagatoprofilnij dizajn yakij vimagav vid kliyenta virishennya konfliktiv versij a DynamoDB vikoristovuye sinhronnu replikaciyu v dekilkoh centrah obrobki danih sho zabezpechuye visoku dovgovichnist ta dostupnist DynamoDB bula predstavlena CTO Amazon en 18 sichnya 2012 roku yak evolyuciya rishennya Amazon SimpleDB Amazon DynamoDBTipNoSQL i hmarna baza danihRozrobnikAmazon comPershij vipusksichen 2012 12 rokiv tomu 2012 01 Operacijna sistemaBagatoplatformnaDostupni moviEnglishLicenziyaVlasnickaVebsajtaws amazon com dynamodb Istoriya rozrobkiV anonsi proektu 2012 roku Vogel opisuye prichini jogo stvorennya Amazon rozpochavsya yak decentralizovana merezha poslug Spochatku sluzhbi mali pryamij dostup do baz danih odin odnogo Koli ce stalo vuzkim miscem v inzhenernih operaciyah sluzhbi vidijshli vid ciyeyi shemi pryamogo dostupu na korist API oriyentovanogo na shirokij zagal Tim ne mensh storonni sistemi upravlinnya relyacijnimi bazami danih namagalisya vporatis z kliyentskoyu bazoyu Amazon Ce zavershilosya krahom pid chas svyat 2004 roku koli dekilka tehnologij ne vladnali z masshtabuvannyam visokogo navantazhenogo trafiku Inzheneri normalizuvali ci relyacijni BD dlya zmenshennya nadmirnosti danih sho ye standartnim pidhodom pri optimizaciyi shovish danih Pri takomu pidhodi v zhertvu prinosyatsya elementi danih napriklad informaciyu sho stosuyetsya tovaru v bazi danih produktu yaki rozkladayutsya na zapisi v riznih tablicyah i potriben chas shob zibrati okremi chastini dlya obrobki zapitu Bagato sluzhb Amazon vimagali v osnovnomu chitannya po pervinnomu klyuchu svoyih danih i shvidkist maye pershochergovij prioritet tomu skladannya cih fragmentiv v odne cile vimagaye zanadto bagato dodatkovih operacij Vidpoviddyu Amazon z kompromisnoyu efektivnistyu zberigannya bulo vikoristannya en ce visokodostupne shovishe z paradigmoyu klyuch znachennya yake bulo stvoreno dlya vnutrishnogo vikoristannya Zdavalosya sho Dynamo malo vse potribne inzheneram ale vprovadzhennya zatrimuvalos Rozrobniki Amazon obrali pidhid prosto pracyuye za dopomogoyu S3 ta SimpleDB Hocha ci sistemi mali suttyevi nedoliki prote voni ne vimagali dodatkovih vitrat na obladnannya masshtabuvannya ta pererozpodil danih Dlya Amazon nastupnoyu iteraciyeyu tehnologiyi NoSQL bula DynamoDB yaka avtomatizuvala ci operaciyi z upravlinnya bazami danih ta polegshila pracyu rozrobnikiv OglyadDynamoDB vidriznyayetsya vid inshih sluzhb Amazon tim sho dozvolyaye rozrobnikam kupuvati poslugu na osnovi propusknoyi zdatnosti throughput a ne na zberigannya storage Yaksho vvimkneno avtomatichne masshtabuvannya to baza danih bude masshtabuvatisya avtomatichno Krim togo administratori mozhut robiti zapiti na zminu propusknoyi zdatnosti a DynamoDB poshiryuvatime dani ta trafik na dekilka serveriv vikoristovuyuchi tverdotilni nakopichuvachi sho zabezpechuye prognozovanu produktivnist Mozhliva integraciya z Hadoop cherez Elastic MapReduce U veresni 2013 roku Amazon vipustila versiyu dlya lokalnoyi rozrobki DynamoDB shob rozrobniki mogli testuvati dodatki pidtrimuvani DynamoDB lokalno Rozrobka z DynamoDBModelyuvannya danih DynamoDB tablicya vklyuchaye zapisi item yaki mayut atributi deyaki z yakih utvoryuyut pervinnij klyuch Yaksho v relyacijnih sistemah zapis mistit kozhen atribut tablici abo operuye znachennyami null chi unknown za yih vidsutnosti to zapisi v DynamoDB ne mayut shemi Yedinij vinyatok pri stvorenni tablici rozrobnik vkazuye pervinnij klyuch a tablicya vimagaye cogo klyucha dlya kozhnogo zapisu Pervinni klyuchi povinni buti skalyarnimi ryadki chisla chi dvijkovi i mozhut mati odnu z dvoh nastupnih form Pervinnij klyuch z odnim atributom vidomij yak klyuch sekciyi partition key tablici Klyuch sekciyi viznachaye sekciyu po heshu zapisu bo idealnij klyuch sekciyi povinen mati rivnomirnij rozpodil diapazonu Pervinnij klyuch takozh mozhe mati drugij atribut yakij DynamoDB nazivaye tablichnim klyuchem sortuvannya U comu vipadku klyuchi sekcij ne povinni buti unikalnimi voni poyednuyutsya z klyuchami sortuvannya dlya utvorennya unikalnogo identifikatora dlya kozhnogo zapisu Klyuch sekciyi vse she vikoristovuyetsya dlya viznachennya togo v yakij sekciyi zberigayetsya zapis ale v kozhnij sekciyi zapisi sortuyutsya za klyuchem sortuvannya Indeksi U relyacijnij modeli indeksi yak pravilo sluzhat dopomizhnoyu strukturoyu danih dlya dopovnennya tablici Voni dozvolyayut SUBD optimizuvati zapiti z vikoristannyam metodiv prihovanih vid koristuvacha i voni ne pokrashuyut funkcionalnist zapitiv U DynamoDB nemaye optimizatora zapitiv a indeks ce prosto insha tablicya z inshim klyuchem abo dvoma sho zberigayetsya razom z originalom Koli rozrobnik stvoryuye indeks to stvoryuyetsya kopiya danih ale kopiyuyutsya lishe ti polya yaki vkazani yak minimum polya yaki indeksuyutsya ta pervinnij klyuch bazovoyi tablici Zapiti zapisiv koristuvachiv DynamoDB adresuyetsya bezposeredno do vlasnih indeksiv Dostupni dva tipi indeksiv Globalnij vtorinnij indeks global secondary index GSI mistit klyuch rozdilu i neobov yazkovij klyuch sortuvannya yakij vidriznyayetsya vid klyucha rozdilu originalnoyi tablici Lokalnij vtorinnij indeks local secondary index LSI mistit toj samij klyuch rozdilu sho i pochatkova tablicya ale inshij klyuch sortuvannya Obidva indeksi vvodyat absolyutno novu funkcionalnist zapitiv u bazu danih DynamoDB dozvolyayuchi vikonuvati zapiti na novih klyuchah Cya sistema indeksaciyi ye nadmirnistyu danih chistoyu ta prostoyu chogo ne dozvolyayetsya v relyacijnih BD Indeksi ce yaskravij priklad togo yak DynamoDB nadaye prioritet shvidkosti nad efektivnistyu vikoristannya prostoru Yak i u relyacijnih sistemah DynamoDB onovlyuye indeksi avtomatichno pri dodavanni onovlenni vidalenni zapisiv tomu varto buti oberezhnimi pri stvorenni indeksiv bo inakshe ye rizik spovilnennya vazhkoyi na zapis bazi danih cherez galmuvannya onovlennya indeksu Sintaksis DynamoDB vikoristovuye JSON dlya svogo sintaksisu cherez jogo populyarnist u rozrobnikiv Stvorennya tablici vimagaye lishe troh argumentiv TableName KeySchema spisok sho mistit klyuch sekciyi ta neobov yazkovij klyuch sortuvannya ta AttributeDefinitions spisok atributiv zapisiv sered yakih povinni buti atributi sho vikoristovuyutsya yak klyuchi sekciyi ta sortuvannya Todi yak relyacijni bazi danih proponuyut nadijni movi zapitiv DynamoDB proponuye lishe operaciyi Put Get Update ta Delete Zapiti dodavannya zapitiv Put mistyat atribut TableName ta atribut Item yakij skladayetsya z usih atributiv ta znachen yaki maye zapis Zapit na onovlennya Update vidpovidaye tomu zh sintaksisu Analogichno shob otrimati zapisi Get abo vidaliti Delete zapis prosto vkazuyut TableName ta Key Arhitektura sistemiStrukturi danih DynamoDB vikoristovuye yak heshuvannya tak i B dereva dlya upravlinnya danimi Pislya vvedennya dani spochatku poshiryuyutsya na rizni sekciyi shlyahom geshuvannya klyucha sekciyi Kozhna sekciya mozhe zberigati do 10 GB danih ta obroblyati za zamovchuvannyam 1000 odinic yemnosti zapisu Write Capacity Units WCU ta 3000 odinic yemnosti zchituvannya Read Capacity Units RCU Odin RCU yavlyaye soboyu odne uzgodzhene zchituvannya v sekundu abo dva ne uzgodzhenih chitannya v sekundu dlya zapisiv rozmirom do 4 KB Odin WCU yavlyaye soboyu odin zapis v sekundu dlya zapisu rozmirom do 1 KB Shob zapobigti vtrati danih DynamoDB osnasheno dvorivnevoyu sistemoyu rezervnoyi replikaciyi ta dovgotrivalogo zberigannya Kozhna sekciya mistit tri vuzli kozhen z yakih mistit kopiyu danih ciyeyi sekciyi Kozhen vuzol mistit takozh dvi strukturi danih B derevo yake vikoristovuyetsya dlya poshuku elementiv i zhurnal replikaciyi yakij zaznachaye vsi zmini vneseni do vuzla DynamoDB periodichno robit znimki cih dvoh struktur danih i zberigaye yih protyagom misyacya v S3 shob inzheneri mogli vikonati svoyechasne vidnovlennya baz danih u razi potrebi U kozhnij sekciyi odin z troh vuzliv poznachayetsya liderom leader node Usi operaciyi zapisu prohodyat spochatku cherez cej lider vuzol pered poshirennyam na inshi vuzli sho robit zapisi uzgodzhenimi v DynamoDB Dlya pidtrimki svogo statusu lider vuzol kozhni 1 5 sekundi nadsilaye kozhnomu vuzlu puls heartbeat Yaksho inshij vuzol perestane prijmati puls vin mozhe iniciyuvati novi vibori lidera DynamoDB vikoristovuye algoritm Paksos dlya obrannya lideriv Inzheneri Amazon spochatku unikali vikoristannya Dynamo cherez dodatkovi inzhenerni vitrati taki yak zabezpechennya resursiv keruvannya sekciyami ta vuzlami Tomu komanda DynamoDB stvorila servis AutoAdmin dlya upravlinnya bazoyu danih AutoAdmin zaminyuye vuzol koli vin perestaye reaguvati dlya cogo dani kopiyuyutsya z inshogo vuzla Koli sekciya perevishuye bud yake iz troh porogovih znachen parametriv na chitannya chi zapis RCU WCU abo rozmir danih perevishuye 10 Gb AutoAdmin avtomatichno dodaye novi sekciyi dlya podalshoyi segmentaciyi danih Podibno do sistem indeksaciyi v relyacijnij modeli DynamoDB vimagaye shob bud yaki onovlennya tablici vidobrazhalisya v kozhnomu z indeksiv tablici DynamoDB robit ce za dopomogoyu sluzhbi yaka nazivayetsya rozpovsyudzhuvach zhurnaliv log propagator ta pidpisana na zhurnali replikaciyi kozhnogo vuzla i nadsilaye dodatkovi zapiti Put Update ta Delete v indeksi za neobhidnosti Oskilki vikoristannya indeksiv prizvodit do suttyevogo vplivu na produktivnist zapitiv yaki vikonuyut zapis to DynamoDB dozvolyaye koristuvachevi robiti ne bilshe p yati zapitiv do bud yakoyi tablici Vikonannya zapitu Pripustimo sho koristuvach DynamoDB vikonuye operaciyu zapisu Put Update abo Delete U toj chas yak tipova relyacijna sistema peretvoryuye SQL zapit u formulu relyacijnoyi algebri i zapuskaye algoritmi optimizaciyi DynamoDB propuskaye ci obidva procesi i otrimuye dozvil na vikonannya Zapit nadhodit na marshrutizator zapitiv DynamoDB yakij pidtverdzhuye avtentifikaciyu Chi nadhodit zapit zvidti ta vid togo kim vin sebe ogolosiv Pripuskayuchi sho ci perevirki vikonuyutsya uspishno sistema geshuye klyuch sekciyi dlya vidpravki u vidpovidnu sekciyu Vseredini ye tri vuzli kozhen z yakih maye kopiyu danih sekciyi Sistema spochatku vikonuye zapis u lider vuzol potim zapisuye na drugij vuzol potim nadsilaye povidomlennya pro uspishne vikonannya operaciyi i nareshti poshiryuyetsya na tretij vuzol Zapisi ye uzgodzhenimi bo voni zavzhdi spochatku nadhodyat cherez lider vuzol Nareshti sluzhba rozpovsyudzhuvach zhurnaliv poshiryuye zmini na vsi indeksi Dlya kozhnogo indeksu vin bere znachennya cogo indeksu pervinnogo klyucha z zapisu a potim vikonuye te same zapisuvannya cogo indeksu bez poshirennya loguvannya Yaksho operaciya ye onovlennyam do vzhe isnuyuchogo elementa onovlenij atribut mozhe sluguvati pervinnim klyuchem dlya indeksu i takim chinom B derevo dlya cogo indeksu takozh maye onovlyuvatis B dereva obroblyayut lishe operaciyi vstavlennya vidalennya ta chitannya tomu na praktici koli rozpovsyudzhuvach zhurnalu otrimuye operaciyu Update vin vidaye operaciyu Delete ta Put vsim indeksam Teper pripustimo sho koristuvach DynamoDB vikonuye operaciyu Get Marshrutizator zapitiv prohodit yak i ranishe autentifikaciyu ta avtorizaciyu Dali yak zaznacheno vishe mi geshuyemo nash klyuch sekciyi shob potrapiti u vidpovidnij gesh Teper mi stikayemosya z problemoyu yak mozhna virishiti sho slid doslidzhuvati z troma vuzlami v mozhlivij vidpovidnosti odin odnomu DynamoDB nadaye koristuvachevi dva varianti pri vidachi chitannya uzgodzhene ta en Pri uzgodzhenomu chitanni vidviduyetsya lider vuzol Ale tut znov vinikaye kompromis shodo uzgodzhenosti ta dostupnosti u sistemah vazhkih dlya chitannya zavzhdi chitannya vid lidera mozhe perevantazhiti okremij vuzol i zmenshiti dostupnist V drugomu varianti zreshtoyu uzgodzhene chitannya vibiraye vipadkovij vuzol Na praktici same tut DynamoDB postupayetsya uzgodzhenistyu vidnosno dostupnosti Yaksho mi oberemo cej marshrut yaki shansi na neuzgodzhenist Nam znadobitsya operaciya zapisu shob povernuti uspih i rozpochati poshirennya na tretij vuzol ale ne zakinchiti Nam takozh znadobitsya nash Get shob nacilitis na tretij vuzol Ce oznachaye sho jmovirnist viniknennya neuzgodzhenosti 1 do 3 u chasovomu vikni rozpovsyudzhennya zapisu Yakogo rozmiru ce chasove vikno Tak mozhlivi chislenni katastrofi yaki mozhut sprichiniti vidstavannya vuzla ale v perevazhnij bilshosti vipadkiv tretij vuzol onovlyuyetsya protyagom milisekund pislya lidera Movne zv yazuvannyaMovi ta programni karkasi iz movnoyu priv yazkoyu do DynamoDB vklyuchayut Java JavaScript Node js Go C NET Perl PHP Python Ruby Haskell Erlang Django ta Grails ProduktivnistDynamoDB nadaye pokazniki produktivnosti yaki dopomagayut koristuvacham pravilno pidtrimuvati bezperebijnu robotu program iz vikoristannyam DynamoDB Zapiti ta throttling Pomilki ConditionalCheckFailedRequests UserErrors SystemErrors Metriki pov yazani zi stvorennyam globalnogo vtorinnogo indeksu 28 grudnya 2019 u Wayback Machine Ci pokazniki mozhna vidstezhuvati za dopomogoyu konsoli upravlinnya AWS vikoristovuyuchi interfejs komandnogo ryadka AWS abo instrument monitoringu sho integruyetsya z Amazon CloudWatch Div takozh en en Sluzhba relyacijnih baz danih Amazon en Primitki www allthingsdistributed com Arhiv originalu za 12 listopada 2020 Procitovano 14 veresnya 2019 Amazon Web Services Inc Arhiv originalu za 19 sichnya 2021 Procitovano 13 veresnya 2019 Clark Jack 19 sichnya 2012 ZDNet Arhiv originalu za 21 sichnya 2012 Procitovano 21 sichnya 2012 Amazon Web Services Arhiv originalu za 19 sichnya 2021 Procitovano 13 veresnya 2019 Vogels Werner 18 sichnya 2012 Amazon DynamoDB a Fast and Scalable NoSQL Database Service Designed for Internet Scale Applications All Things Distributed blog Arhiv originalu za 1 sichnya 2013 Procitovano 21 sichnya 2012 Amazon Web Services Inc Arhiv originalu za 19 sichnya 2021 Procitovano 3 chervnya 2019 DeCandia Giuseppe Hastorun Deniz Jampani Madan Kakulapati Gunavardhan Lakshman Avinash Pilchin Alex Sivasubramanian Swaminathan Vosshall Peter Vogels Werner October 2007 Dynamo Amazon s Highly Available Key value Store SIGOPS Oper Syst Rev 41 6 205 220 doi 10 1145 1323293 1294281 ISSN 0163 5980 docs aws amazon com Arhiv originalu za 21 zhovtnya 2019 Procitovano 5 lipnya 2017 Amazon Web Services 12 veresnya 2013 Arhiv originalu za 22 chervnya 2014 Procitovano 13 veresnya 2013 AWS 10 serpnya 2012 Arhiv originalu za 18 zhovtnya 2019 Procitovano 18 lipnya 2019 Gunasekara Archie 27 chervnya 2016 Shine Solutions Group angl Arhiv originalu za 3 serpnya 2019 Procitovano 3 serpnya 2019 angl arhiv originalu za 20 serpnya 2019 procitovano 3 serpnya 2019 Amazon Web Services Arhiv originalu za 4 kvitnya 2019 Procitovano 13 veresnya 2019 Arhiv originalu za 25 lipnya 2020 Procitovano 13 veresnya 2019 Arhiv originalu za 25 lipnya 2020 Procitovano 13 veresnya 2019 PosilannyaOficijnij sajt