問題タブ [database-indexes]

テーブルのデータベース パフォーマンスを向上させるインデックスはどれですか

とのリクエストについてWHERE my_table.word_set @> '<some word>'

すべてのインデックスは SQL Server B ツリーにありますか?
確かに主キーと外部はハッシュベースのインデックスであるべきですか?

最新のリリースで、「パフォーマンスの問題」のためにスーパーカラムは望ましくないことを読みましたが、これはどこに説明されていません。

次に、スーパーカラムを使用して素晴らしいインデックスパターンを提供するこのような記事を読みました。

これにより、Cassandraでインデックス作成を行うための現在の最良の方法がわかりません。

1. スーパーカラムのパフォーマンスの問題は何ですか？
2. インデックス作成の現在のベストプラクティスはどこにありますか？

「Col1、Col2、Col3」という 3 つの列があり、Col1 にインデックスがあるとします。Col3 のデータを更新した場合 (例: int を変更)、インデックス付きの列 (Col1 の) データにまったく触れていなくても、インデックスを再作成または更新する必要がありますか?

複合列に関しては、Cassandraのストレージエンジンを理解しようとしています。残念ながら、これまで読んだドキュメントにはエラーが含まれており、少し空白のままになっています。

まず、用語。

複合列は、複合主キーを使用して完全に非正規化された幅の広い行で構成されます。

これは誤解を招くように思われます。なぜなら、AFAIKの複合列は複合キーに使用でき、キーとは別に単純に複合列としても使用できるからです。

1：複合キーと列名はどのように実装されますか？私が見つけることができるすべてのCQLの例では、複合キーのみが列として表示され、プレーンな複合列は表示されません。

主な複合キーとして列'a'、'b'、'c'、'd'+列'e'、'f'があるとします。「a」が行とパーティションのキーになることはわかっています。

次のデータを想定してみましょう。

2：これはどのようにボンネットの下に保管されますか？ここでの本当の問題は、列が定義上階層的ではないため、「b」、「c」、「d」がどのようにマップされるかということだと思います。

3：私が読んだドキュメントには、コンパクトストレージはもう使用すべきではないと書かれています。しかし、非主キー列を追加する必要がない場合はどうなりますか...それを使用しない理由は何ですか？

データベースのインデックスがどのように機能するかについての簡単な質問です。

列id（primary_key）、名前、およびGPAを持つテーブル「Student」があるとします。id にインデックスがあり、他の列にはインデックスがないと仮定します

名前とGPA（IDではなく）を使用してレコードを照会すると、すべてのレコードで一致を検索する必要があります。ここでのインデックスの利点は何ですか?

インデックスは、クエリにインデックス付きの列が含まれている場合にのみ有効ですか?

これまでのところ、現在の Cassandra アーキテクチャについて私が理解していることは次のとおりです。

1. パフォーマンスの問題により、スーパー カラムは望ましくなくなりました。
2. 複合列 (実際にはキー) は、階層キーのインデックス作成に適しています。
3. 複合列には、ネストされたコンポーネントがソートされた順序で格納されます。実際のインデックスはありません。

いくつか質問があります:

1. 私が述べたことはすべて正しいですか？
2. 複合列はコンポーネントごとに範囲クエリを効率的に処理できますか (論理的な使用法を想定)?
3. 複合列は、非常に多数の行に適していますが、迅速なクエリ結果を生成します (それ自体はインデックスではないことを考慮して)?
4. 複合列に対してセカンダリ インデックスを作成できますか。はいの場合、範囲クエリを効率的に実行できますか?

前もって感謝します。

次のDB構造がある

とします。アプリケーションは、すべての詳細（モデル、製品ファミリー、ブランド、プロデューサー）を含む記事のリストを表示する必要があります。そのためには、必要なデータを取得するために、より多くのJOINを作成する必要があります。

次のようにArticleテーブルに冗長FKを作成して、アプリケーションのパフォーマンスを向上させても大丈夫ですか？それは実際にパフォーマンスを向上させますか？

テーブル定義、UNIQUEインデックスに注意してください:

そのため、MySQL は検索でインデックスを使用する必要がありますWHERE name = 'tag' and type = 'cat'(左端のプレフィックス) と同様に検索しますWHERE type = 'tag'。

やった：

結果は次のとおりです (5 列目はpossible_keys):

私は何かが欠けていると確信していますが、何が見つかりません。どんな手掛かり？

多くの分野で検索＆ソートできるモンゴコレクションがあります。たとえば（機密保持のため、実際のコレクションを置くことができません）、次のようにしましょう。

Creator、Difficulty、Categorie、NbOfQuestionで検索できます。そして、好き、嫌い、成功、失敗で並べ替えます。

元：

• 難易度3の問題を教えてください。カテゴリ20で、いいねの数で並べ替えます。
• 5つの質問の問題を教えてください。失敗順に並べ替えます。
• 難易度1、カテゴリ10、2の質問で、アインシュタインによって作成された問題を教えてください。
• すべての問題を成功順に並べ替えてください。

など...すべての順列が可能であり、オプションで1つのフィールドで並べ替えることができます。

ここでの問題は、何百万もの記録があることです。インデックス作成には少なくとも30ギガの費用がかかりました。また、インデックスが非常に多いため、このコレクションの書き込み速度が低下します。そして、それが書き込みを押しつぶしている間、それは読み取りをロックしています。したがって、読み取りは多く、書き込みはおそらく少し少なくなりますが、それでも多くなります。

「検索エンジンソリューション」を検索しましたが、「全文検索」でしか見つけられませんでした。

また、難易度CategorieとNbOfQuestionを1つの配列にマージして（値に10の係数を掛けて、それらをアパートに保つことにより）、この配列のみにインデックスを付け、スペースを節約しようとしました。

後知恵は大歓迎です！

ありがとう、

チャールズ