Google Cloud Bigtable выглядит фантастически, однако у меня есть несколько вопросов по резервному копированию и избыточности.
Есть ли варианты резервного копирования данных для защиты от человеческих ошибок?
В настоящее время кластеры работают в одной зоне. Существуют ли какие-либо способы смягчения последствий недоступности зоны?
Один из способов сделать резервную копию ваших данных, доступных сегодня, — запустить экспорт MapReduce, как описано здесь:
https://cloud.google.com/bigtable/docs/exporting-importing#export-bigtable
Вы правы в том, что на сегодняшний день доступность Bigtable Cluster привязана к доступности Zone, в которой они работают. Если вас беспокоит более высокая доступность, вы можете рассмотреть различные методы репликации ваших записей (например, kafka), но имейте в виду, что это усложняет систему, которую вы строите, например, управление согласованностью между кластерами. (Что произойдет, если в вашем программном обеспечении есть ошибка, и вы пропустите распространение некоторых записей?)
Использование другой системы, такой как Cloud Datastore, позволяет избежать этой проблемы, поскольку это не единая зональная система, но при этом необходимо учитывать другие компромиссы.
Похоже, что на данном этапе функция репликации недоступна, поэтому я вижу следующие параметры, учитывая, что доступ для чтения к журналу упреждающей записи (или как там называется журнал BigTable TX) не предоставляется:
В Google мы доверяем. Положитесь на их опыт в обеспечении доступности и восстановления. Одним из преимуществ размещения BigTable для разработчиков HBase является снижение административных издержек и отсутствие необходимости беспокоиться о резервном копировании и восстановлении.
Разверните дополнительный кластер BigTable в другой зоне доступности и отправьте ему копию каждой мутации в асинхронном режиме с более агрессивной буферизацией записи на клиенте, поскольку низкая задержка не является приоритетом. Вы даже можете развернуть обычный кластер HBase вместо кластера BigTable, но пока неизвестно, в какой степени клиент HBase от Google и клиент Apache HBase могут сосуществовать в одной среде выполнения.
Скопируйте мутации в локальный файл, выгружаемый по расписанию в классы хранилища GCP по выбору: стандартный или DRA. Воспроизведите файлы при восстановлении.
Вариант 3). Создайте кластер Kafka, распределенный по нескольким зонам доступности. Реализуйте производителя и отправьте мутации в Kafka, его пропускная способность в любом случае должна быть выше, чем у BigTable/HBase. Отслеживайте смещения и повторяйте мутации, используя сообщения от Kafka при восстановлении.
Еще одна мысль... если история чему-то учит, у AWS не было опции Multi-AZ с самого начала. Им потребовалось время, чтобы развиться.
Вы можете рассмотреть https://github.com/egnyte/bigtable-backup-and-restore. Это оболочки Python для затененного jar-файла java-bigtable-hbase, которые экспортируют/импортируют данные Bigtable в/из корзины GCS в виде серии файлов последовательности Hadoop.
На момент написания этого ответа Cloud Bigtable поддерживает управляемые резервные копии, которые позволяют сохранять копии схему и данные таблицы, а затем восстановить из резервной копии новую таблицу позже.
