IPアドレスを主キーとして使用することはscylla dbの良い習慣ですか？

私はscylla dbを使用しており、IPアドレスを主キーとして使用するテーブルがあります。クラスターのRFは3です。owns統計値が近い（31％〜35％）場合でも、一部のノードは他のノードよりも負荷が大きい（ディスク容量が多い）ことがわかります

IPアドレスを主キーとして使用していて、一部のIPアドレスが他のIPアドレスよりも高いため（これらのIPでの更新の増加など）、それは疑問です。

他のIPアドレスよりも多くの読み取りまたは書き込みを取得する-一部のIPアドレスがより高温であるという事実は、通常、大きな問題ではなく、かなり普通です。Scyllaはそれらを異なるノード（および各ノードのコア）の間でランダムに分割し、クラスター内のコアよりもはるかに多くのホットパーティションがある限り、負荷とディスク使用量はかなりバランスが取れているはずです。

極端なケースでは状況が異なる可能性があります。たとえば、更新ごとにパーティションが大きくなる（つまり、行が追加される）場合や、非常にホットなパーティションがわずかしかない場合などです。たとえば、リクエストをログに記録するために使用されるデータベースを想像できます。1日10リクエストの100万の通常のクライアントに加えて、1日に100万リクエストを行う10人の「攻撃者」もいます。このような極端な場合、一部のノードが他のノードよりもはるかに多くの負荷やディスク容量を担っていることがわかります。このような極端な場合は、他の問題も引き起こす可能性があります。Scyllaの巨大なパーティションのサポートは最近改善されましたが、まだ完全ではありません。このような極端な場合を回避できれば、より良いでしょう。

最後に、「IPアドレスを主キーとして使用することはscylla dbで良い習慣ですか？」という元の質問に戻ると、答えは「はい、しかし」です。

ScyllaはIPアドレスをキーとして特定の問題を抱えていないため、「はい」です。異なるIPアドレスをランダムに（「murmur3」ハッシュ関数を使用して）異なるノードに分散し、IPアドレスが集中するという事実に特別な問題はありません。一緒に（たとえば、同じサブネットからの複数のクライアントが同じクラスターノードに送信されるだけではありません）。

問題はIPアドレス自体ではなく、むしろ格納する予定のパーティションの内容、および異なるパーティションの更新頻度とサイズがどのように偏っているのかということです。

ああ、最後の注意点：

あなたが使用している場合はサイズTierd圧縮戦略（STCS）、任意の特定の瞬間における最大のディスク・スペースの使用量を実際のデータ量が格納されているよりもかなり高くなり得ます。ワークロードの上書きが多い場合（データは追加されず、置換、削除など）、圧縮が作業を完了する前に、ディスク上のデータは実際のデータ量の2倍になる可能性があります。この場合は、あなたがいくつかのランダムな時間にシステムを検査した場合、あなたは意志この測定を行うときの圧縮作業におけるランダムな位置に応じて、一部のノードは他のノードよりもディスク上のデータが多いことに注意してください。これが表示されているものかどうかを確認するためにできることは、すべてのノードで「メジャーコンパクション」を呼び出し、ディスク使用量を測定することです。ノード間でのディスク領域使用量がはるかに均一になることが期待されます。

あなたはおそらく正しい、別のフィールドを追加してデータをよりよく分散させる

IPアドレスを主キーとして使用することはscylla dbの良い習慣ですか？

IPアドレスが均一に分散されており、アクセスパターンが均一に分散されていると仮定すると、質問に答えるだけで、データシャーディングのあるデータベースではまったく問題ありません。多くの場合、ディストリビューションがあまり均一でない場合も問題ありません。たとえば、アクセスパターンは他のIPよりもいくつかのIPに影響します。

データベースのシャーディング戦略によっては、単調に増加する値（シーケンシャルIPなど）（MongoDB、Spanner、DataStoreなど）を取り込む場合に違いが生じます。ただし、ScyllaDBの場合、Scyllaはデフォルトで各パーティションキーをMurMurHash3でハッシュするため、データの取り込みがトークンリング全体に均一に分散されていると想定できます。

とにかく、Key == IPで読み書きする必要がある場合、選択肢はあまりありません。それはあなたの仕事の詳細に依存することができます。

所有統計が近い（31％〜35％）場合でも、一部のノードの負荷が他のノードよりもはるかに多い（ディスク領域を多く消費する）ことを確認します

通常、負荷は、ディスクIOPSまたはアプリケーションリクエスト/秒、または使用率（％）であるスループットで測定されます。ディスク領域の使用率を検討する場合、それはまったく別の話です。

相対的なスループットのノード使用率を意味する場合、それは例えば：

• データの配布
• キースペースでの負荷（アクセス）の分散、読み取りと書き込みの関係
• ノードトークンの分布。％分散のみを与えることができます。

ディスク容量を意味している場合、私が述べたこと以外にも他の多くの要因があります：

• ヒント
• 修復されていないインスタンス、修復スケジュール
• トゥームストーン、GC、コンパクション

IPアドレスを主キーとして使用しているので、

番号。

一部のIPアドレスは他のIPアドレスよりも高温になっていますか（それらのIPでの更新の増加など）？

これは、上記の要因と、負荷が何を意味するかによって異なります。ディスク容量を意味する場合、読み取りアクセスはそれに影響しません。書き込みができます。

これらの理由により、IPアドレスを主キーとして持つことはお勧めできません。

1. IPアドレスは変更される可能性があります。その場合、古いIPアドレスを使用してクエリを実行する方法がわかりません。
2. 予約済みのIPアドレス（静的で変更されていない）がある場合、少数のIPからより多くの要求を取得すると、均等に分散されたノードが作成されません。
3. 別のフィールドを追加すると状況が改善する可能性がありますが、アクセスパターンがわからない場合はお勧めできません。