ソリューションとテクノロジーで成功への道筋をつけることができます。Cloudわかりやすい料金体系により、お客様のビジネスにより総合的な価値をもたらします。安全でインテリジェントなプラットフォームを今すぐ利用しましょう。プロダクトをお試しいただけます。テクノロジーは、世界最大級のアプリケーションでも利用されています。これらのシステムを使うと常にこのような規模に自動的になるわけではありません。設計者は、データをモデル化する方法を慎重に検討して、アプリケーションがさまざまな次元で成長したときに確実にスケールおよび実行できるようにする必要があります。パターンを考える必要があります。分散システムの性質上、設計者はデータと処理の局所性について考える必要があります。クエリとトランザクションをサポートします。利点をフルに活用するには慎重な設計が必要になります。このページでは、アプリケーションを任意のレベルにスケールしてパフォーマンスを最大限に引き出すことができるようにするための重要なアイデアについて説明します。つのツールはスケーラビリティに大きな影響を与えます。辞書順に編成されます。句での宣言順序で列を連結することによって順序が決まります。これにより、局所性に関するすべての標準的な特性が示されます。辞書順にテーブルをスキャンするのが効率的です。ブロックに格納され、一緒に読み込まれてキャッシュされます。可用性とスケーラビリティのためにデータを複数のゾーンに複製するので、各ゾーンがデータの完全なレプリカを保持します。リソースが確保されます。リソース間に分割されます。つの物理階層レベルで編成されます。リソースに分散させるときの単位です。時間が経つと、スプリットは小さな部分に分割されたり、マージされたり、インスタンス内の他のノードに移動されたりして並列性が高まり、アプリケーションのスケールが可能になります。スプリットをまたぐオペレーションは、通信が増加するため、スプリットをまたがない同等のオペレーションより高コストになります。これは、スプリットがたまたま同じノードによって提供される場合でも当てはまります。種類のテーブルがあります。インターリーブされたテーブルは、その親として別のテーブルを指定することによって定義され、インターリーブされたテーブルの行は親の行とともにクラスタ化されます。ルートテーブルには親はなく、ルートテーブルの各行は新しい最上位の行またはルート行を定義します。このルート行とインターリーブされた行は子行と呼ばれ、ルート行とすのすべての子孫のコレクションは行ツリーと呼ばれます。サイズや負荷のために必要と判断された場合にはスプリットを自動的に分割しますが、分割はルート行の境界でのみ行われます。つのスプリットに保持されます。そのため、以下のようになります。行ツリー内のオペレーションは、他のスプリットとの通信を必要としないため、より効率的になる傾向があります。行ツリーのサイズは、それをホストするスプリットのサイズの下限です。以下に保つように注意する必要があります(詳細はこちらをご覧ください)。つのノードの最大スループットに制限され、大きな値ではありますが、無限ではありません。ルートにするテーブルの選択は、スケーラブルなアプリケーションを設計する上で重要な決定です。通常、ルートはユーザー、アカウント、プロジェクトなどであり、子テーブルは当該エンティティに関する他のほとんどのデータを保持します。推奨事項:局所性を高めるため、同じテーブル内の関連する行には共通のキー接頭部を使用します。意味があるときは常に、関連するデータを別のテーブルにインターリーブします。局所性のトレードオフデータがまとめて書き込まれたり読み取られたりすることが多い場合は、主キーを慎重に選択してインターリーブを使用することでデータをクラスタ化すると、レイテンシとスループットの両方の点でメリットがあります。ブロックとの通信には常に固定コストがかかるためであり、できる限り有効に利用する必要があります。レイテンシの増加につながります。コストとレイテンシがわずかに大きくなります。反対に、データに関連性があっても、まとめてアクセスされることがあまりない場合は、データを分離する方法を検討してください。これは、頻繁にアクセスされるデータが大きい場合に最も効果的です。多くのデータベースでは、大きいバイナリデータはプライマリ行データのバンド外に格納され、その大きいデータへの参照のみがインターリーブされます。オペレーションは、分散データベースでは避けられないことに注意してください。すべてのオペレーションの局所性を完璧にすることにこだわりすぎないようにしてください。パターンについて必要な局所性を実現することに焦点を当て、頻度の低い分散オペレーションまたはパフォーマンスの影響を受けにくい分散オペレーションは必要に応じて実行されるようにします。分散読み取りは、スキーマを簡素化し、プログラマーの労力を軽減するのに役立ちます。パフォーマンス重視のユースケースを除き、そのままにすることをおすすめします。推奨事項:一緒に読み書きされるデータが近くになるように、データを階層構造に整理します。大きい列は、あまり頻繁にアクセスされない場合は、インターリーブされていないテーブルに格納することを検討します。分散トランザクション機能とリモート読み取り機能が効果的に行われるようにします。インデックスを使用すると、主キー以外の値で行をすばやく見つけることができます。インターリーブされていないインデックスとインターリーブされたインデックスの両方をサポートします。サポートされているものと最も似たタイプです。インデックス付け対象の列に対する制限はなく、強力ですが、必ずしも最良の選択であるとは限りません。親テーブルと接頭部を共有する列にはインターリーブされたインデックスを定義して、局所性を細かく制御できるようにする必要があります。テーブルの設計上の考慮事項の多くは、インデックスにも適用されます。インターリーブされていないインデックスは、ルートテーブルにデータを格納します。ルートテーブルは任意のルート行の間で分割できるため、インターリーブされていないインデックスは、ほとんどどのようなワークロードでも、ホットスポットを無視して、任意のサイズに拡大できます。データと同じスプリットに含まれないことも意味します。これにより、書き込みプロセスでは余分な作業とレイテンシが発生し、読み取り時には参照するスプリットが増えます。インターリーブされたインデックスでは、データはインターリーブされたテーブルに格納されます。これらは、単一エンティティのドメイン内を検索する場合に適しています。インターリーブされたインデックスでは、データとインデックスのエントリは強制的に同じ行ツリーに格納され、それらの間の結合がはるかに効率的になります。タイトル、アルバムなど、さまざまな並べ替え順序で写真にアクセスする場合。特定のタグセットを持つすべての投稿を検索する場合。特定の商品を含む以前の購入注文を検索する場合。推奨事項:データベース内のどこからでも行を検索する必要がある場合は、インターリーブされていないインデックスを使用します。検索範囲が単一のエンティティのときは常に、インターリーブされたインデックスを使用することをおすすめします。インデックスを使用すると、主キー以外の属性で行を検索できます。レコードを読み取ることなく、それだけで照会できます。これにより、結合が不要なため、重要なリソースを節約できます。制限されており、格納できるものには限りがあります。句を使用して任意のインデックスに余分なデータを格納する機能があります。使用すると、値が複製されて、インデックスにはコピーが格納されます。ビューはネイティブにサポートされていません)。インデックスの一部として使用することです。これにより、効率的にスキャンできるテーブルの疎なサブセットの実質的な実体化されたビューを定義できます。スキャンで未読メッセージのビューを提供できます。サイズおよび書き込み時間のパフォーマンスをトレードオフします。多くのスキーマ設計者は、ルートテーブルをタイムスタンプの順序になっていて、すべての書き込みで更新されるように定義する傾向があります。理由は、このような設計では、容易に緩和することができない巨大なホットスポットがテーブルの最後に作成されるためです。増え、ロック競合イベントやその他の問題も同様になります。多くの場合、この種の問題は小規模な負荷テストでは発生せず、アプリケーションがしばらく運用された後に発生します。つにインターリーブすることによってログをローカルにできるかどうかを検討します。これには、多くのルートにホットスポットを分散できる利点があります。各個別ルートの書き込みレートが十分低くなるように注意する必要があります。レベルのシャーディングを使用します。個の区分にテーブルを分割することです。列で接頭部を追加することによって行います。ランダムに選択されるか、または基本キーの一部をハッシュすることによって選択されます。ハッシングは、特定の型のすべてのレコードが同じシャードに含まれるようにして、検索のパフォーマンスを向上させることができるため、しばしば好まれます。いずれにしても、目標は、時間の経過とともに、書き込みがすべてのシャードに均等に分散されるようにすることです。このアプローチは、読み取りのときにすべてのシャードをスキャンして、書き込みの本来の全体順序を再構築する必要があることを意味する場合があります。推奨事項:書き込みレートが高いタイムスタンプ順テーブルおよびインデックスを作成することは、絶対に避けてください。なんらかの方法で、ホットスポットを分散させたり、別のテーブルにインターリーブしたり、シャーディングしたりします。シーケンス(または自動インクリメント)を使用して主キーを生成することを好みます。時代からのこの習慣は(サロゲートキーと呼ばれます)、前述のタイムスタンプ順アンチパターンとほとんど同じくらい有害です。シーケンスは、準単調な方法で値を生成し、時間の経過とともに、相互に近いクラスタ化された値を生成する傾向があるからです。通常これは、主キーとして使用されると(特にルート行の場合)、ホットスポットが生成されます。従来の知恵とは対照的に、できる限り、主キーには現実の属性を使用することをおすすめします。これは特に属性が変更されない場合に当てはまります。一意の数値の主キーを生成したい場合は、後続の数値の上位ビットを数値空間全体にほぼ均等に分散させることを目指します。つの方法は、従来の手段で連続番号を生成し、次にビットを反転して最終値を得ることです。関数が同じように作成されているわけではなく、一部の関数はタイムスタンプを上位ビットに格納するため、メリットが実質的に失われます。ジェネレータが上位ビットを擬似ランダムに選択することを確認してください。推奨事項:増分するシーケンス値を主キーとして使用しないでください。サロゲートキーではなく実際の値を主キーに使用します。