Google Megastore

Гигантский шаг в сторону распределенного будущего был предпринят командой Google App Engine в момент их релиза системы хранения данных с повышенным уровнем репликации. Она направленна на критичные для бизнеса приложения, которые требуют расположения копий данных как минимум в трех датацентрах, полной семантики ACID для групп сущностей и ограниченных гарантий консистентности между группами сущностей.

Это было большим достижением, ведь всего несколько компаний во всем мире способны на реализацию по-настоящему меж-датацентровой системы хранения данных. Помимо SimpleDB, как много других публично-доступных сервисов баз данных могут хранить информацию в нескольких датацентрах одновременно? Теперь эта возможность доступна каждому. Но всему есть цена: так как Megastore использует втрое больше ресурсов, чем обычное Master-Slave хранилище в GAE, стоимость так же увеличивается в три раза. Помимо этого стоит учитывать, что с ростом надежности и издержек, понижается производительность. Именно из-за этого, новая система хранения является альтернативой обычному хранилищу GAE для критичных задач, а не полной заменой.

Основные особенности Megastore

Megastore совмещает масштабируемость NoSQL систем хранения данных с удобством традиционных СУБД. Оно использовалось для внутренних проектов Google на протяжении нескольких лет. Более 100 приложений, 3 миллиардов транзакций на запись и 20 миллиардов на чтение, более петабайта данных распределены по множеству датацентров по всему миру.
Megastore - хранилище, разработанное для удовлетворения требований современных интерактивных онлайн сервисов. Используется синхронная репликация для достижения высокого уровня доступности и консистентности. Вкратце, оно предоставляет полную ACID семантику для удаленных реплик с достаточно низкой задержкой, чтобы использоваться в интерактивных приложениях. Хранилище партиционируется и каждая часть реплицируется отдельно, позволяя достичь полного соответствия ACID внутри партиции, но консистентность между ними гарантируется лишь ограниченно. Предоставляются некоторый функционал традиционных СУБД, такой как вторичные индексы, но только те из них, которые масштабируются без сильного негативного влияния на задержки и которые укладываются в семантику используемой схемы партиционирования.
Paxos используется для управлением синхронной репликацией между датацентрами. Это позволяет достичь очень высокого уровня надежности ценой повышения времени выполнения операций записи. Обычно Paxos используется только для координации, но в Megastore он также используются и для управления записью данных.
Поддерживается три уровня консистентности при чтении: текущий, снимок и неконсистентный.
Группы сущностей являются единицей консистентности и транзакционности. Они рассматриваются как маленькие независимые базы данных. Сами же данные внутри каждого датацентра хранятся в масштабируемом NoSQL хранилище.
Megastore, как и обычное хранилище в GAE, не поддерживает транзакции с использованием нескольких групп сущностей, это существенно повысило бы время их выполнения.
Группы сущностей - основной механизм группировки данных для быстрого осуществления операций. Их размер и композиция должны быть сбалансированы. В каждом приложении должен найтись способ естественным образом очертить границы групп сущностей. При оптимальном выборе групп сущностей ресурсоемкие кросс-групповые операции будут сведены к минимуму. По сути этот процесс чем-то напоминает нормализацию в реляционных СУБД.
Запросы с высокими требованиями по консистентности должны быть ограничены одной группой сущностей. Кросс-групповые запросу могут вернуть устаревшие результаты. Это является серьезным отличием в поведении от обычного хранилища GAE, где по-умолчанию используется высокий уровень консистентности для всех запросов, так как операции записи и чтения по-умолчанию происходят с мастера.
В обычном хранилище GAE иногда отключается в связи с запланированными техническими работами, а также вовремя непредвиденных проблем с инфраструктурой. Megastore в большинстве случаев не страдает этими проблемами.
Резервирование данных и избыточность достигаются посредством синхронной репликации, снимков и инкрементального лога транзакций.
API для доступа к данным остался прежним.
Операции записи могут достигать секунды для каждой группы сущностей, так что для приложений с высокой нагрузкой на запись оно подходит не так хорошо.
Только новые приложения могут воспользоваться опцией Megastore, существующие приложения необходимо пересоздать, чтобы использовать эту возможность. Впоследствии изменить тип хранилища невозможно.
Одно приложение не может использовать одновременно обычное хранилище и Megastore. Напрашивается использование одного приложения с Google Megastore для критически важных данных, а другое приложение с обычным хранилищем для всего остального, но такая схема противоречит правилам использования сервиса.
Автоматической миграции данных между Master/Slave хранилищем и Megastore не существует, разработчики приложения должны сами позаботиться об этом. Google предоставляют лишь набор инструментов и примеров кода, чтобы облегчить процесс миграции.
В приложениях, использующих Megastore, еще большее значение приобретает эффективное кэширование данных.

Материалы по теме

Еще не все возможности Google Megastore полностью доступны пользователям App Engine в виде High Replication Storage, но я думаю это вопрос времени. Хотелось бы пообсуждать в комментариях области применения новинки на практике: какие приложения, критичные к доступности и сохранности данных, можно позволить себе отдать в PaaS, пускай даже от Google?

P.S.: По традиции хочу напомнить, что читать Insight IT удобнее всего через RSS-reader.

22 февраля 2011 | Иван Блинков | Хранение данных