Max Home IndustryGoogle опубликовал подробную информацию о гибридной базе данных с соответствующим названием F1, которая заменила MySQL в платформе компании Adwords.
Google Adwords — это огромная система, в которой задействованы сотни приложений, тысячи пользователей, и все они используют общую базу данных размером более 100 ТБ. В презентации на конференции по очень большим базам данных (VLDB) Google сказал, что пользователи генерируют сотни тысяч запросов в секунду и что база данных выполняет запросы SQL, которые сканируют десятки триллионов строк данных в день.
Как объяснялось, когда мы первоначально сообщали об этом, F1 — это гибридная база данных, которая сочетает в себе высокую доступность, масштабируемость систем NoSQL, таких как Bigtable, и согласованность и удобство использования традиционных баз данных SQL. F1 основан на Spanner, базе данных Google, которая является крупнейшей базой данных в мире. Spanner предназначен для масштабирования на миллионы серверов и распространяется по всему миру, представляя собой единое целое. Система хранения и вычислений Spanner охватывает все центры обработки данных Google. F1 был разработан одновременно с F1 и в тесном сотрудничестве. Spanner решает проблемы хранения нижнего уровня, такие как постоянство, кэширование, репликация, отказоустойчивость, сегментирование и перемещение данных, поиск местоположения и транзакции.
Использование Spanner дает F1 синхронную репликацию между центрами обработки данных и высокую согласованность. В своей статье по F1, представленной на конференции VLDB, группа исследователей Google говорит, что синхронная репликация подразумевает более высокую задержку фиксации, но это можно частично преодолеть, используя модель иерархической схемы со структурированными типами данных. F1 также включает полнофункциональный распределенный механизм запросов SQL и автоматическое отслеживание и публикацию изменений.
F1 является отказоустойчивым, глобально распределенным и поддерживает как OLTP, так и OLAP. Он был разработан для замены сегментированной реализации MySQL, которая не соответствовала требованиям Google с точки зрения масштабируемости и надежности. В документе говорится, что сегментированную базу данных, основанную на MySQL, трудно масштабировать, а еще труднее перебалансировать. Пользователи нуждались в сложных запросах и объединениях, а это означало, что им приходилось тщательно сегментировать свои данные, а изменение сегментации данных без нарушения работы приложений было сложной задачей.
Цели дизайна F1 — тривиально и прозрачно масштабироваться, просто добавляя ресурсы. Что касается доступности, система никогда не должна выходить из строя по какой-либо причине: система хранит данные для основного бизнеса Google, и любой простой существенно влияет на доход.
Последовательность — третья цель; F1 должен поддерживать транзакции ACID и всегда должен предоставлять приложениям согласованные и правильные данные. «Разработка приложений, позволяющих справиться с аномалиями параллелизма в их данных, очень подвержена ошибкам, требует много времени и в конечном итоге не стоит повышения производительности», — считает Google.
Конечная цель — удобство использования; F1 должен обеспечивать полную поддержку запросов SQL и другие функции, которые пользователи ожидают от базы данных SQL: «Такие функции, как индексы и специальные запросы, не просто приятно иметь, но и являются абсолютными требованиями для нашего бизнеса».
F1 добавил ряд функций к тем, которые предоставляет Spanner. Он поддерживает распределенные запросы SQL, включая объединение данных из внешних источников данных. Он также поддерживает вторичные индексы, согласованные между транзакциями; асинхронные изменения схемы, включая реорганизацию базы данных, оптимистичные транзакции, а также автоматическую запись и публикацию истории изменений.
Реляционные функции идут дальше традиционных систем РСУБД, особенно в области явной иерархии таблиц.
Таблицы логически организованы в виде иерархии. Дочерние таблицы хранятся в кластере со строками родительской таблицы и чередуются внутри них. Первичный ключ дочерней таблицы состоит из собственного уникального идентификатора и внешнего ключа, который идентифицирует ее родительскую таблицу. Например, схема Ad-Words содержит таблицу Customer с первичным ключом (CustomerId), в которой есть дочерняя таблица Campaign с первичным ключом (CustomerId, CampaignId), которая, в свою очередь, имеет дочернюю таблицу AdGroup с первичным ключом (CustomerId, CampaignId, AdGroupId). Это позволяет выполнять быструю обработку соединений в общем случае.
Буферы протокола позволяют использовать повторяющиеся поля. Они используются вместо дочерних таблиц, когда количество дочерних записей невелико. Повторяющиеся поля позволяют избежать накладных расходов на производительность и сложности, связанной с хранением и объединением нескольких дочерних записей, и упрощены для пользователей, которые могут читать и записывать свои логические бизнес-объекты без создания нескольких объединений таблиц.
F1 включает интерфейс на основе ключей / значений NoSQL, который обеспечивает быстрый и простой программный доступ к строкам. Запросы на чтение могут включать любой набор таблиц, запрашивая определенные столбцы и диапазоны ключей для каждой. Этот интерфейс используется уровнем ORM, а также доступен для прямого использования клиентами. Многие приложения предпочитают использовать этот интерфейс NoSQL, потому что в коде проще создавать структурированные запросы чтения и записи, чем генерировать SQL. Этот интерфейс также можно использовать в MapReduce, чтобы указать, какие данные следует читать.
Интерфейс SQL можно использовать для всех запросов OLTP с малой задержкой к большим запросам OLAP. F1 поддерживает объединение данных из своего хранилища данных Spanner с другими источниками данных, включая Bigtable, файлы CSV и хранилище агрегированных аналитических данных для AdWords. Диалект SQL расширяет стандартный SQL за счет конструкций, которые позволяют получить доступ к данным, хранящимся в буферах протокола.
В документе Google указывается, что в последние годы общепринято было считать, что если вам нужно высокомасштабируемое хранилище данных с высокой пропускной способностью, единственный жизнеспособный вариант — использовать хранилище ключей / значений NoSQL и обойти отсутствие ACID. транзакционные гарантии и отсутствие таких удобств, как вторичные индексы и SQL. Это было невозможно для AdWords из-за сложности работы с хранилищем данных, отличных от ACID, и необходимости в запросах SQL. В F1 компания Google заявляет, что построила систему распределенных реляционных баз данных, которая сочетает в себе высокую доступность, пропускную способность и масштабируемость систем NoSQL, а также функциональность, удобство использования и согласованность традиционных реляционных баз данных, включая транзакции ACID и запросы SQL. В статье делается вывод:
«F1 показывает, что на самом деле можно иметь хорошо масштабируемую и высокодоступную распределенную базу данных, которая по-прежнему обеспечивает все гарантии и удобства традиционной реляционной базы данных».