Non progredi est regredi. Не йти вперед - значить, йти назад. Стародавні, прорік цю універсальну мудрість, звичайно ж, передбачали, що може бути застосована вона буде і через століття. Так і вийшло.
Перевірена часом і успішної експлуатацією в десятках сервісів NoSQL-рішення Bigtable виявилося нездатним впоратися з головною вимогою, що пред'являються Google+, - непротиворечивостью призначених для користувача даних, тисячі копій яких розкидані по сотням тисяч серверів Google.
Сховище Bigtable просто не мало механізмів, що забезпечують абсолютну впорядкованість в часі дій над репліками призначених для користувача даних Google+. Механізмів, які відмінно працюють в реляційних СУБД, що підтримують концепцію ACID по відношенню до виконання розподілених SQL-транзакцій.
NewSQL - масштабованість системи і несуперечність даних в одній упряжці
Чому NewSQL? Все просто. Продукти, що відповідають цій концепції зберігання даних, є компромісом між необхідністю масштабування сховища і забезпечення суворої несуперечності зберігаються в них даних.
Google Spanner, звичайно, не єдине NewSQL-рішення, але однозначно наймасштабніше, а унікальна архітектура робить його особливо цікавим.
Архітектурним предком Spanner, безумовно, є Bigtable, від якої новачок успадкував принцип поділу таблиць на Таблет і розподіл їх за багатьма span-серверів.
Дані, що зберігаються в Spanner, як і в Bigtable, підтримують мультіверсіі завдяки тимчасові м мітках (timestamps), проте сама таблиця Spanner не є плоскою, а ґрунтується на інформаційно-логічної моделі і підтримує SQL-запити. Таке гібридне рішення дає право називати Spanner полуреляціонной системою управління даними.
Архітектура кластера Spanner настільки масштабна, що іменується Всесвіту (Universe). В її «галактиках» Zones мешкають безліч span-серверів, здатних обробляти SQL-запити.
Підтримка SQL і розподілених транзакцій - це важливо, проте головне достоїнство Spanner полягає в іншому. Нова система зберігання Google здатна дати гарантію, що при виконанні транзакцій в численних репліках її таблиць не з'явиться розбіжностей, що впливають на цілісність і несуперечність даних.
Яким чином Spanner справляється з цією проблемою? За допомогою спеціального програмного інтерфейсу, іменованого TrueTime API (від англійського true time - «справжнє час»).
Настінний годинник і майстри Армагеддона на службі суворої несуперечності
В основі TrueTime API лежить концепція єдиного часу, що діє в рамках всього сховища Spanner, розподіленого за кількома дата-центрам. Воно називається global wall-clock time - «глобальні настінні годинники», спільні для всіх дата-центрів.
Глобальне час в Spanner, звичайно ж, зберігається не в одному місці. Воно теж розподілено. У складі кожного Цода виділяються спеціальні сервери, іменовані «майстрами часу» (Time Master Devices - TMD). Більшість з них отримує сигнали точного часу від супутникової системи GPS, однак для надійності (хіба мало що може трапитися з супутниковим каналом в найвідповідальніший момент) в числі TMD є особливі екземпляри, які називаються «майстрами Армагеддона» (Armageddon Masters). Ці «годинникарі» несуть на своєму борту ... найточніші атомний годинник. І навіть це не все. Всі сервера TMD постійно синхронізують час, спілкуючись один з одним за допомогою спеціального сервісу timeslave. Ось вже воістину TrueTime.
Щоб бібліотека TrueTime могла повернути кожному з Span-серверів точне глобальне час, до складу Spanner включені «майстри часу» - вузли, пов'язані з системою GPS і навіть використовують власні атомні годинники.
Глобальне час в TrueTime API не так вже й глобально. Правильніше буде назвати його часом з обмеженою невизначеністю. Чому? У розподіленої системі практично неможливо домогтися миттєвого відгуку всіх вузлів «тут і зараз». Тому функція TT.now () бібліотеки TrueTime повертає значення часу у вигляді інтервалу (TT.now (). Latest - TT.now (). Earliest), що враховує неминучу похибку. Таким чином, виклик будь-яким вузлом Spanner функції TT.now () призводить до повернення поточної глобальної часу, але у вигляді тимчасового інтервалу.
Наявність цього тимчасово го зазору і дозволяє вузлам Spanner вирішувати питання узгодженості змінюваних в ході транзакції даних. Базовим в даному випадку є так званий протокол двофазної фіксації транзакції (2-Phase Commit Protocol), що відмінно зарекомендував себе в розподілених реляційних СУБД. Він заснований на дуже простому принципі: якщо транзакція, що виконується в одному вузлі, впливає на зміни в вузлах, що містять репліки даних цього вузла, то вона повинна бути або зафіксована (результат зміни збережений на диску вузла) на всіх цих вузлах, або ж не виконано (відкат) ні на одному з них.
В основі концепції TrueTime лежить поєднання принципу нестрого певного глобального часу і протоколу двофазної фіксації транзакцій, що забезпечує сувору несуперечливість даних.
Для реалізації протоколу двофазної фіксації в Spanner застосовується перевірений в ході експлуатації Bigtable алгоритм вирішення колізій Paxos.
Що трапиться, якщо хоча б один з вузлів не встигне відрапортувати про готовність до фіксації в відведений часовий інтервал? Координатор відкотить виконання транзакції і не дасть команду на її фіксацію вузлів-учасникам, які теж будуть змушені виконати відкат. Після цього спроба виконання транзакції повториться.
Очевидно, що реалізація протоколу двофазної фіксації в високонадійних серверах баз даних, на яких виконуються реляційні СУБД, сильно відрізняється від його реалізації в свідомо ненадійних серверах кластерів Google. І саме тому унікальної є комбінація апаратно реалізованої в TMD-вузлах технології синхронізації глобального часу і функцій бібліотеки TrueTime, що представляє цей час у вигляді інтервалу, в рамках якого вузли встигають «домовитися» про узгодженість даних.
Недарма Google назвала своє нове сховище Spanner ( «гайковий ключ»). Концепції, закладені в цю NewSQL-систему, міцно скрутили між собою все найкраще, що було досягнуто Bigtable в області безпрецедентною масштабованості і відмовостійкості, з суворою непротиворечивостью збережених даних, характерної для розподілених реляційних СУБД. П'ять років зусиль, витрачених інженерами Google на отримання цього міцного з'єднання технологій, не пропали даремно.