熊崎 宏樹:疑問自体は妥当です。 トランザクション間の順序関係を整理するために論理時間をインクリメントして採番する戦略はTrue Time APIに相当する物が使えない時の戦略として順当ですし、Raftを用いて採番サービス(Placement Driver)を冗長化することで故障に備えるのも正しい設計に思います。Raft自体は値の確定に2往復の通信を必要とするので高速とは言い難いですがリーダーの変更がめったに起こらない前提を応用すれば一度にまとまった量だけインクリメントしてその間の細かい値をリーダーが配る設計にすることでスループットを稼ぐ事ができます。 https://tikv.org/deep-dive/distributed-transaction/timestamp-oracle/ （+Google翻訳） > We use batching and preallocating techniques to increase the timestamp > oracle’s throughput, and also we use a Raft group to tolerate node failure, > but there are still some disadvantages to allocating timestamps from a single > node. One disadvantage is that the timestamp oracle can’t be scaled to > multiple nodes. Another is that when the current Raft leader fails, there is a > gap wherein the system cannot allocate a timestamp before a new leader has > been elected. > バッチ処理と事前割り当ての手法を使用してタイムスタンプ オラクルのスループットを向上させ、Raft > グループを使用してノードの障害を許容しますが、単一のノードからタイムスタンプを割り当てることにはまだいくつかの欠点があります。1 つの欠点は、タイムスタンプ > オラクルを複数のノードにスケーリングできないことです。もう 1 つの問題は、現在の Raft > リーダーが失敗すると、新しいリーダーが選出される前にシステムがタイムスタンプを割り当てることができないギャップが生じることです。 リーダーが故障した場合にRaft内でのリーダー再選出等の待機が発生するのはこの設計の欠点ではありますがRaftのリーダーが物理故障するのは1日に何度もあるイベントではないですし、上記の最適化により現状でも260億/秒ほどのカウントができるそうなので当面の心配は無さそうです。以下引用です。 https://dzone.com/articles/tidbs-timestamp-oracle （+Google翻訳） > Fortunately, the PD Leader can generate 260 million timestamps per second and > has undergone many optimizations. As of yet, I haven’t seen a performance > bottleneck. > 幸いなことに、PD リーダーは 1 秒あたり 2 億 6000 > 万のタイムスタンプを生成でき、多くの最適化が行われています。今のところ、パフォーマンスのボトルネックは見られません。