Google запустила бета-версію Cloud Spanner — СУБД покоління NewSQL



Google відкрила для всіх бета-версію сервісу Cloud Spanner, глобально розподіленої высокомасштабируемой мультиверсионной NewSQL БД з підтримкою розподілених транзакцій.

Кілька років Google використовувала цей сервіс виключно для внутрішніх потреб. На ньому працюють ключові системи Google, в тому числі AdWords і Google Play. Spanner — еволюційний розвиток NoSQL-попередника Google Bigtable. Сам же c Spanner відносять до сімейства NewSQL-рішень, тобто воно поєднує в собі переваги реляційних і нереляційних СУБД. Це ACID-транзакції і синтаксис SQL традиційних СУБД без шкоди для горизонтального масштабування і високої доступності, властивих NoSQL.

Виходячи з досвіду роботи системи всередині компанії, Google пропонує клієнтам аптайм 99,9999% (шість дев'яток, тобто максимум 31,5 секунди простою в рік), клієнтські бібліотеки з підтримкою Java, Go, Python, Node.js та ін

Принцип роботи Spanner описаний в науковій роботі James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, JJ Furman, et al. Spanner: google's Globally-Distributed Database. Proceedings of OSDI, 2012. См. опис Spanner на Хабре (2013).



Через кілька років внутрішнього використання Google прийняла рішення викотити цей інфраструктурний сервіс в загальне користування. Оформити передплату пропонують корпоративним клієнтам, яким потрібно розгорнути високонадійне надійне хмарне додаток. Раніше їм доводилося вибирати між традиційними БД з гарантованою узгодженістю транзакцій і базами NoSQL з простим управлінням, горизонтальним масштабом і розподіленим зберіганням даних. Сервіс Cloud Spanner покликаний усунути ці суперечності, об'єднавши всі переваги обох технологій.



Cloud Spanner завершує лінійку сервісів БД в хмарі Google Cloud Platform (GCP), доповнюючи Cloud SQL, Cloud Datastore і Cloud Bigtable.

В Cloud Spanner немає теоретичного межі на максимальний розмір бази. В той же час цей сервіс можна використовувати і для маленьких проектів. Основна перевага тут — не тільки масштабованість, але і можливість здійснювати глобальні транзакції одночасно в усіх дата-центрах по всьому світу.

Вартість використання сервісу Cloud Spanner встановлена в розмірі $0,90 за вузол на годину і $0,30 за один гігабайт зайнятого дискового простору в місяць. Оплата за трафік усередині регіону не стягується, між регіонами США — $0,01 за гігабайт, між країнами — від $0,08 до $0,12 за гігабайт, в Китай — від $0,20 до $0,23 за гігабайт, в Австралії — від $0,15 до $0,19 за гігабайт.

Ключова інновація в Spanner
На Хабре публікувалася стаття, чому Google довелося відмовитися від NTP (Network Time Protocol) і запровадити власну систему перевірки часу з GPS і атомними годинами, більш точну і надійну. Її назвали TrueTime API. Впровадження такої системи необхідно було для забезпечення цілісності бази даних Google Spanner.

Забезпечення цілісності даних за рахунок нової системи кодування інформації про час транзакцій — одна з ключових інновацій Spanner (так зазначено у вищезгаданій науковій роботі). Інженери Google розробили багаторівневу систему перевірки часу, записи тимчасових інтервалів транзакцій і оцінки рівня надійності міток часу. Це ключовий фактор, від якого залежить надійність системи.

Замість прийому даних з зовнішніх годин, компанія Google обладнала дата-центри власними атомними годинами і ресиверами GPS. Це обладнання підключено до деяких серверів, які роздають мітки часу всім іншим сервери в дата-центрі. За фактом, на кожній машині в дата-центрі працює у фоновому режимі демон, який постійно опитує сервер часу в дата-центрі та аналогічні сервери часу в інших дата-центрах. Таким чином, сервери Google у всьому світі гарантовано працюють на одному часу.



Через Google TrueTime API забезпечується синхронізація даних, коли різні дата-центри намагаються одночасно записати в одну і ту ж комірку у БД. Інтерфейс TrueTime API видає значення інтервалу часу TTinterval: це час із закладеною похибкою вимірювання та невизначеністю. Якщо інтервали TTinterval двох конкурентних транзакцій не перетинаються, то можна з упевненістю сказати, яка з них сталася раніше. Якщо вони перетинаються, це означає деяку частку невизначеності.

Дотримання CAP-теореми
Spanner поєднує властивості реляційних і нереляційних СУБД, не порушуючи при цьому CAP-теорему. як таке стало можливим пояснює автор CAP-теореми Ерік Брюер, раніше професор Каліфорнійського університету, а нині віце-президент Google по інфраструктурі.



Бета-версію Cloud Spanner вже деякий час використовують обрані партнери. Наприклад, про свій досвід розповів інженер компанії Quizlet. Це цікавий погляд зсередини на інтерфейс і протоколи Spanner, адже крім офіційної документації у нас поки немає інформації про це унікальний сервісі.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.