博士

ロボ子、今日のITニュースはグラフDBのキー管理に関するものじゃ。AT Protoエコシステムが直面している課題と、その解決策について見ていくぞ。

ロボ子

なるほど、博士。AT Protoエコシステムは150億以上のレコードがあるのですね。かなりの規模です。

博士

`uint32`ではキー空間が足りなくなって、`uint64`への拡張が必要になったそうじゃ。これは大変じゃ。

ロボ子

`uint32`から`uint64`への拡張は、単純な変更ではないですよね。既存のシステムへの影響も考慮する必要がありそうです。

博士

そうじゃな。しかも、AT Proto Firehoseはピーク時に1秒あたり1,500イベントを超えるトラフィックがあるらしい。10倍から100倍のスケールに対応するには、毎秒15,000から150,000の新しいURIを`uint64`整数に変換する必要があるとは！

ロボ子

毎秒それだけのURIを処理するのは、確かに大変ですね。FoundationDBでのUID割り当てがボトルネックになっているというのも頷けます。

博士

そこで、`xxHash`という非暗号化ハッシュアルゴリズムを使って、文字列キーを`uint64`にハッシュ化することを考えたらしいぞ。

ロボ子

`xxHash`は高速なハッシュ関数として知られていますね。しかし、衝突の可能性もあるので、注意が必要ですね。

博士

そうなんじゃ。64ビットハッシュでは、50億キーで50%以上の確率で衝突が発生する可能性があるらしい。そこで、数十億のシーケンスを使う方法を考えたそうじゃ。

ロボ子

43億の異なるシーケンスを使用し、UIDを`uint64`として構築するのですね。上位32ビットをシーケンスID、下位32ビットをシーケンス内の値として使用するというのは、面白いアイデアです。

博士

そうじゃろ？これなら、1つのシーケンスあたり毎秒100回のインクリメントが可能になり、毎秒4,300億の新しいUIDを生成できるらしいぞ。すごいじゃろ！

ロボ子

シーケンスIDのビット数を調整することで、ストレージ要件を調整できるのも良いですね。柔軟性があります。

博士

大規模なキー空間を多数の小さなキー空間に分割することで、水平スケーリングを実現するというのは、Roaring Bitmapsなどの他のシステムにも見られるパターンに基づいているそうじゃ。

ロボ子

なるほど、既存の技術を応用しているのですね。実績のあるパターンを使うのは、リスクを減らす上で重要ですね。

博士

今回のニュースでは、筆者がBlueskyチームを離れて新たな冒険に乗り出すとのことじゃ。そして、Blueskyは求人募集をしているらしいぞ。

ロボ子

新しい挑戦は素晴らしいですね。私もいつか、博士のように自分の力で何かを成し遂げたいです。

博士

ロボ子ならきっとできるぞ！…ところでロボ子、キー空間が足りなくなったらどうする？

ロボ子

そうですね…、宇宙に新しいキー空間を探しに行くのはどうでしょうか？

博士

それじゃあ、キーだけに、宇宙遊泳…なんちゃって！