Google Cloud Bigtable は素晴らしく見えますが、バックアップと冗長性についていくつか質問があります。
人的エラーから保護するためにデータをバックアップするオプションはありますか?
クラスターは現在単一のゾーンで実行されています。ゾーンが利用できなくなることを軽減する方法はありますか?
質問する
1186 次
4 に答える
4
現在利用可能なデータをバックアップする 1 つの方法は、ここで説明されているようにエクスポート MapReduce を実行することです。
https://cloud.google.com/bigtable/docs/exporting-importing#export-bigtable
今日の時点で、Bigtable クラスタの可用性はそれらが実行されているゾーンの可用性に関連付けられていることは間違いありません。より強力な可用性が懸念される場合は、書き込みを複製するためのさまざまな方法 (kafka など) を検討できますが、これには注意してください。クラスター間の一貫性の管理など、構築中のシステムに他の複雑さが追加されます。(ソフトウェアにバグがあり、一部の書き込みの配布をスキップした場合はどうなりますか?)
Cloud Datastore などの別のシステムを使用すると、単一のゾーン システムではないため、この問題を回避できますが、他のトレードオフを考慮する必要があります。
于 2015-06-12T16:20:07.613 に答える
1
この段階ではレプリケーション機能は使用できないようです。そのため、先行書き込みログ (または BigTable TX ログの名前が何であれ) への読み取りアクセスが提供されていない場合、次のオプションが表示されます。
Google は信頼しています。可用性とリカバリを確保する上で、彼らの専門知識に頼ってください。ホストされた BigTable の HBase 開発者にとっての魅力の 1 つは、管理オーバーヘッドが少なく、バックアップとリカバリについて心配する必要がないことです。
セカンダリ BigTable クラスターを別の AZ にデプロイし、各 Mutation のコピーを非同期モードで送信します。低レイテンシーは優先事項ではないため、クライアントでより積極的な書き込みバッファリングを行います。BigTable クラスターの代わりに通常の HBase クラスターをデプロイすることもできますが、Google の HBase クライアントと Apache HBase クライアントが同じランタイムでどの程度共存できるかはまだわかりません。
Mutation をローカル ファイルにコピーし、選択した GCP ストレージ クラス (標準または DRA) にスケジュールに従ってオフロードします。回復時にファイルを再生します。
3) のバリエーション。複数のアベイラビリティーゾーンに分散された Kafka クラスターを立ち上げます。プロデューサーを実装し、Mutations を Kafka に送信します。そのスループットはとにかく BigTable/HBase よりも高くなるはずです。回復時に Kafka からのメッセージを消費することで、オフセットを追跡し、ミューテーションをリプレイします。
別の考え... 歴史が教訓である場合、AWS には最初からマルチ AZ オプションがありませんでした。進化するのに時間がかかりました。
于 2015-05-08T08:45:35.133 に答える