問題タブ [google-cloud-spanner]

Google の Spanner DBに関する論文を読んでいます。これは、 Rich Hickey の Datomicと同様の問題に対処しているようです。

Google の Spanner DB はEpochal Timeの概念を実装していますか?

Google の TrueTime API (Wired、Slashdot など) を複製するのは難しいとマスコミが一般的に言っている理由がわかりません。

Google が達成している低いエラー間隔を取得するのがいかに難しいかは理解できますが、API 自体がどれほど難しいかはわかりません。

たとえば、ハッキングされたバージョンを作成しました。間隔はこちら。

これが now 関数です。

最後に、before 関数と after 関数があります (now 関数のラッパーであり、DRY リファクタリングを少し使用できます)。

約 5,000us から 350,000us のインターバル エラーが発生しているようです (パブリック NTPd を使用)。これは Google の数字とはかけ離れていますが、どこかから始める必要があります。

精彩を欠いたパフォーマンス以外に、この設計に、Spanner のようなものを上に構築することを妨げる重大な欠陥はありますか?

Spanner: Google の Globally-Distributed Databaseのセクション 2.1 には、次のように書かれています。

レプリケーションをサポートするために、各スパンサーバーは各タブレットの上に単一の Paxos ステート マシンを実装します。(初期の Spanner 化身は、タブレットごとに複数の Paxos ステート マシンをサポートしていたため、より柔軟なレプリケーション構成が可能でした。その設計の複雑さにより、私たちはそれを放棄しました。)

Paxos ステート マシンは、一貫して複製されるマッピングのバッグを実装するために使用されます。

この単一の Paxos ステート マシンは、「Paxos Made Simple」で言及されている Paxos ステート マシンと似ていますか?

新しいリーダーが失われたすべてのデータを学習する方法を選択したときのことを知りたいです。Spanner での Paxos グループの詳細な実装について説明できる人はいますか?

BigQuery の代わりに Bigtable を使用する理由はありますか? どちらも読み取り操作と書き込み操作をサポートしているようで、後者は高度な「クエリ」操作も提供しています。

私はアフィリエイト ネットワークを開発する必要があります (したがって、クリック数と「売上」を追跡する必要があります)。BigQuery はより優れた API を備えた単なる Bigtable のように見えるため、その違いにかなり混乱しています。

これは、 Google Cloud Spanner Java API チームに対する実際の質問です...

新しいGoogle Cloud Spannerサービスを見ると、読み取り/書き込みトランザクションを実行する唯一の方法は、TransactionRunnerインターフェイスを介してコールバックを提供することです。

API がプログラマーの便宜のためにトランザクションを自動的に再試行する必要性の詳細を隠そうとしていることは理解していますが、この制限は少なくとも私にとっては深刻な問題です。トランザクションのライフサイクルを自分で管理できる必要があります。たとえそれが自分で再試行を実行する必要があるとしてもです (たとえば、ある種の「再試行可能な」例外をキャッチすることに基づいて)。

この問題をより具体的にするために、SpringPlatformTransactionManagerを Google Cloud Spanner に実装して、既存のコードに適合させ、既存の再試行ロジックを使用したいとします。現在の Java API でそれを行うことは不可能のようです。

TransactionContext下位互換性のある方法で API を拡張し、ユーザーに を返すメソッドを追加して、ユーザーが再試行を処理できるようにするのは簡単なようです。

何か不足していますか？この代替 (より伝統的な) トランザクション API スタイルを Java API に追加できますか?