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

Компания Google сорвала покрывало со своего нового сервиса баз данных, анонсировав публичную бета-версию Cloud Spanner.

За последние полтора года Google превратилась из дремлющего гиганта в компанию, бросившую долгосрочный вызов в облачной сфере таким фирмам, как AWS и Azure. Прошлым летом Google представила ключевые компоненты своей платформы данных, в том числе несколько баз данных на основе SQL и NoSQL.

Теперь же Google добавила последний недостающий элемент. Примечательно, что подобный элемент (еще) не реализован у AWS или Azure — речь идет о Google Cloud Spanner. Это одна из тех легендарных платформ Google, о которых простым смертным можно было что-то узнать только в опубликованных научных статьях. Внутри она представляет собой распределенную платформу обработки транзакций для реляционной базы данных F1, на которой работает ядро генератора прибыли Google — AdWords.

Уже долгое время о ней ходили слухи. На этой неделе в Google сорвали с нее завесу тайны, анонсировав публичную бета-версию нового сервиса баз данных Cloud Spanner. В рамках этого сервиса предоставляется доступ к географически распределенной облачной транзакционной СУБД с поддержкой SQL и сильной согласованностью, которая на голову обходит все, что сейчас есть на этом рынке. Это та самая Spanner, которую научные сотрудники Google описали в исследовательских работах, но теперь к ней есть API, доступный через Google Cloud Platform (GCP, облачный сервис Google). Несмотря на то, что Google рекламирует ее для таких сценариев, как глобальная консолидация баз данных, мы считаем, что в ближайшее время она лучше всего подойдет для решения нового поколения задач, коренным образом меняющихся за счет хранящихся в облаке данных — например, для управления глобальной цепью поставок.

Cloud Spanner займет свое место среди таких сервисов, как Cloud SQL — для более скромных по величине проектов электронной коммерции; Cloud Bigtable — в качестве базы данных NoSQL по принципу «ключ-значение» для масштабных операций чтения и записи; Cloud Datastore — в качестве базы данных документов для профилей пользователей и онлайн-игр; Big Query — для работы с хранилищами данных; и Cloud Dataproc — для Hadoop и Spark. По большей части портфель СУБД-продуктов Google соотносится с портфелями Amazon AWS и Microsoft Azure, но Cloud Spanner можно назвать в буквальном смысле большим исключением. Разумеется, самый главный вопрос в случае с Cloud Spanner — подходит ли он для компаний, которые не дотягивают до размеров самой Google.

Крепкий орешек

Характерная особенность баз данных с распределенными транзакциями состоит в том, что им приходится поддерживать оптимальное соотношение между двумя противоположными потребностями — в поддержании согласованности данных (согласованность, Consistency, отвечает за третью букву в акрониме ACID, описывающем требования к транзакционным системам) и в то же время в обеспечении доступности базы данных. Как правило, если вам нужно обновить запись, вы должны ее заблокировать, чтобы не допустить применения двух и более одновременно запрошенных конфликтующих обновлений, которые друг друга отменяют и/или повреждают данные.

Это означает несколько вещей. Во-первых, наиболее распространенные варианты применения распределенных баз данных подразумевают либо некие оперативные сценарии (например, обновление профилей пользователей, управление взаимодействием между игроками в режиме реального времени), где требования ACID не так строги, либо аналитику, в которой нет проблем с транзакционным обновлением.

Во-вторых, платформы транзакционных баз данных появились в качестве попытки справиться с трудностями распределенной системы. Сначала было программное дополнение Oracle RAC (Real Application Clusters), опиравшееся в работе на многослойную архитектуру, предусматривающую менеджер кластеров. Потом нахлынула волна баз данных NewSQL, предлагавших различные подходы к поддержанию целостности данных. Совсем недавно набрало популярность сегментирование, реализованное в хранилищах данных на базе NoSQL вроде MongoDB и в транзакционных SQL-базах данных, таких как Amazon Aurora и Oracle. При сегментировании необязательно распределять базу данных как таковую — нужно разбить на части таблицы и держать их в разных массивах хранения, повысив таким образом скорость доступа и производительность одного или нескольких экземпляров.

Большой и согласованный

Spanner меняет наши представления о масштабировании, в частности предположение, что транзакционные СУБД не могут вырастать до размеров аналитических СУБД. Если нам уже несколько приелась мысль о том, что на кластерах Hadoop могут работать тысячи узлов, то глобальные масштабы Spanner просто поражают воображение: он может работать на миллионах узлов в сотнях дата-центров, оперируя триллионами записей. И, кстати, он рассчитан на круглосуточную работу.

Google позиционирует Spanner как полностью управляемый, критически важный сервис реляционных СУБД с надежностью в 99,999%, который способен обеспечить сильную согласованность при глобальных масштабах. Несмотря на то, что в своих научных статьях Google охарактеризовала Spanner как полуреляционную базу данных с SQL-подобным языком запросов, коммерческая версия будет в целом совместима со стандартом ANSI SQL 2011. Также доступ к сервису можно будет получить через клиентские библиотеки функций на языках Java, Python, Go, Node.js и Ruby, а еще предусмотрен драйвер JDBC для совмещения со сторонними инструментами для бизнес-аналитики и интеграции данных.

Кажется, нам понятно, откуда растут ноги у Spanner: в Google его разработали, когда себя исчерпала их собственная реализация MySQL. Когда дело дошло до десятков терабайт, инженерам Google пришлось вручную разбить базу данных на сегменты — в последний раз на эту операцию ушло несколько лет. Хотя у Google еще была Bigtable, база данных NoSQL, на основе которой позже было разработано хранилище данных HBase, она не была рассчитана на повсеместное соблюдение принципов ACID.

Spanner преодолел эту трудность путем автоматической сегментации и репликации, которые равномерно распределяют глобальную нагрузку на хранилище данных. В то время как Spanner автоматизирует размещение данных, приложения могут контролировать их физическое расположение. Это крайне важно в случае с географически разнесенными базами данных, когда законы государственной принадлежности данных диктуют необходимость хранить информацию в пределах границ конкретной страны, или в случае, когда нужно контролировать местонахождение данных с целью оптимизировать быстродействие.

Подобно многим СУБД с распределенными транзакциями, новый сервис использует вариант алгоритма Paxos, при котором очередность фиксации изменений определяется выбором главного узла (того, у которого есть полномочия применять изменения). В Google утверждают, что их реализация Paxos работает быстрее, чем большинство открытых реализаций, доступных на практике.

Секретным ноу-хау Spanner можно считать TrueTime API от Google — такие себе глобальные часы, выполняющие операции, слишком сложные, чтобы изложить их здесь подробно (массу информации можно найти в исследовательской статье на тему Spanner). Именно этот механизм отвечает за синхронизацию Spanner. Достаточно будет отметить, что все операции commit снабжены временной меткой, а эти метки применяются только после того, как система проверила фактическое время. Или же, цитируя статью о Spanner: «API непосредственно выявляет неопределенность показаний часов... Если эта неопределенность велика, Spanner замедляется, чтобы ее переждать». Но в данном случае замедление равноценно задержке от силы в 10 мс или около того.

Но кому же нужна подобная масштабируемость?

Потребность в СУБД с распределенными транзакциями подстегивается Интернетом: взаимодействие в Интернете носит глобальный характер, а клиенты ожидают, что сайты и сервисы всегда будут работать. Среди классических примеров — торговля или игры по Интернету, когда клиенты не потерпят задержек по причине того, что базе нужно обновить их записи. Google рекламирует Cloud Spanner в качестве средства для консолидации баз данных или для NoSQL-приложений, требующих повышенной согласованности транзакций.

Очевидной нишей здесь будут географически распределенные приложения, требующие доступа к единой согласованной базе данных. В этом случае на ум приходят глобальные торговые системы: сегодня эти системы обычно подразделяются на многочисленные региональные объекты с большим покрытием и репликацией практически в режиме реального времени. Также потенциальным прикладным сценарием может стать консолидация баз данных.

Но следует учесть, что на предприятиях долго и неохотно меняют транзакционные системы — и у них на это есть разумные причины. На этих системах строится ядро их бизнеса, а нарушать его работу хочется в последнюю очередь. В противоположность аналитическим или операционным прикладным реализациям, транзакционные системы, как правило, не создают новых источников дохода. Обработка транзакций — дело крайне сложное, а на разработку всемирно известных надежных движков СУБД вроде Oracle, SQL Server или DB2 ушли десятки лет. К тем, кто попытается нарушить устоявшийся порядок вещей, будет применена презумпция виновности, пока они не докажут обратное. Скажем, архитектура Spanner на поверку немного отличается от баз данных SQL. На Google будет возложено бремя доказательства того, что Spanner полностью совместим с SQL и поддерживает все, чего ждут от него компании.

Будучи новичком, Google постарается конкурировать за счет цены. Но таким авторитетным провайдерам, как Oracle, ценовые войны не страшны. Настоящие перемены, продвигаемые Google, за ночь не свершаются. Но у Google неплохие шансы в этом длительном забеге, ведь архитектура Spanner достаточно уникальна, чтобы в долгосрочной перспективе вывести обработку транзакций на новый уровень.