Cloud Bigtableサービスが提供する耐久性と可用性の保証について、Google の誰かにガイドラインを提供してもらいたいです。
これまでの私の理解は次のとおりです。
最小クラスターに 3 つのノードが必要であるという事実は、少なくともゾーン内では、データの耐久性が高く、3 つのノードにレプリケートされることを示唆しています。
ただし、 Googler によるこの回答では、「Cloud Bigtable はデータを複製しません」と述べており、「複製されたストレージ戦略で構築されている」と主張するCloud Bigtable ホームページの引用と真っ向から矛盾しています。それで、それはどれですか？複製されているかどうか。もしそうなら、いくつのコピーが保管されていますか?
クラスターは特定のゾーン内でしかセットアップできないという事実は、クラスターの可用性がそのゾーンの可用性に直接結びついていることを示唆しています。では、高可用性の Bigtable ベースのデータ ストレージが必要な場合、複数のゾーンにわたって独立したクラスターをセットアップし、クラスター全体の書き込みの同期を自分で処理するのがベスト プラクティスでしょうか?
ゾーン間の Bigtable クラスタが独立しているかどうかについての情報はありません。複数のゾーンにまたがるクラスターをセットアップし、1 つのゾーンがダウンした場合、他のゾーンのクラスターが機能し続けることを期待できますか? それとも、複数のゾーンにまたがってもクラスターに影響を与える可能性がある、根本的な単一障害点はありますか?
これらの詳細について非常に具体的な App Engine データストアと比較して、Cloud Bigtable のドキュメントはかなり不足しています。または、少なくとも、これらの側面について詳しく説明しているページを見つけることができませんでした。
Cloud Bigtableのドキュメントは、値のサイズ制限など、他の側面についても同様にあいまいです。ドキュメントでは、個々の値は「セルあたり最大 10 MB」未満に抑える必要があると記載されています。「~10 MB」とは一体何を意味するのでしょうか?! 正確に 10MB の制限をハードコードして、それが常に機能することを期待できますか?それとも未知の要因に応じて日々変化しますか?
とにかく、私が動揺しているように聞こえたら、申し訳ありません。Bigtable サービスを利用したいと思っています。しかし、おそらく他の多くの人と同じように、私はそれに投資する前に、その耐久性/可用性の側面を理解する必要があります. ありがとうございました。