いくつかの欠点があります。バイト以上を使用します。他のオプションでは、このように多くのストレージを使用しません。レコードに関する情報がありません。使用するとホットスポットがなくなります)。連続した値をビット順逆転する一意の数値の主キーを生成する場合、続いて現れる数値の上位ビットが数値空間全体にほぼ均等に分散する必要があります。つの方法は、従来の方法で連続した数値を生成し、それをビット順逆転して最終値を得ることです。ビット順逆転すると、主キー全体で一意の値が維持されます。コードで元の値を再計算できるので、反転値だけを格納する必要があります。未満にする必要があります。行のサイズには、最上位の行と、すべてのそのインターリーブされた子とインデックス行が含まれます。達すると新しいスプリットを作成します。最上位の行間でのみスプリットを作成します。超えると、書き込みスループットが影響を受ける可能性があります。最上位の行間でのみスプリットを作成します。テーブルを使用しています。人の歌手のアルバムと曲が格納されるようにスプリットを作成します。テーブルの分割を行うことができません。曲に基づいてスプリットを作成できます。キーの降順での格納タイムスタンプをキーとする履歴用のテーブルがある場合で、次のいずれかに該当するときは、キー列を降順に格納することを検討してください。テーブルを使用しており、親行も読み取ることになる場合。タイムスタンプ列を使用することで、最新の履歴エントリが親行に隣接して格納されます。しないと、親行とその最新の履歴を読み取る際、途中の古い履歴をスキップするためにシークが必要となります。連続したエントリを日付の新しい順に読み込む場合に、いつまで日付をさかのぼるか不明なとき。個のイベントを取得したり、特定の行数を読み取った後に読み取りをキャンセルしたりする場合です。キーが降順で格納されているほうが効率的です。キーワードを追加します。キーを降順に並べ替える。前に説明した主キーの不適切な使用方法と似ていますが、主キー列でなくても、値が単調に増加または減少する列にインターリーブされていないインデックスを作成するのも適切な方法とは言えません。以下のテーブルを定義する場合について考えてみましょう。列にインデックスを定義するのが便利なように見えます。プラクティスで説明した結果と同じ問題が発生します。テーブルは、値が単調に増加する列を最初のキー部分として使用します。インターリーブされたインデックスの作成は問題ありません。インターリーブされたインデックスの行は、対応する親の行にインターリーブされるため、親の単一行で毎秒数千件のイベントが生成される可能性はありません。値が単調に増加または減少する列に、インターリーブされていないインデックスを作成しない。次のステップスキーマ設計の例を見る。データの一括読み込みについて学ぶ。