問題タブ [database-performance]

ユーザー主導のウェブサイトがあります。メッセージング機能を追加したい。私の懸念は、データベースの管理性とパフォーマンスに関連しています。

私はそれを次のように整理することを考えています：ユーザーテーブルがあり、すべてのユーザーが一意のIDを持っています2人のユーザー間のユーザーが開始した会話には「会話」のレコードがあり、その会話のすべてのメッセージは参照する外部キーを使用しますそのconversation_id。

誰かがこのアプローチを採用しない理由を考えることができますか？インデックスを使用し、クエリをページごとに最大20の結果に制限すると、長期的にどの程度のパフォーマンスが得られるのでしょうか。

編集：送信者/受信者を追跡する方法がないことに気づきました。私の最初の本能は、conversations_messagesに「sender」列を追加することです。

それぞれが同じフィールド（数値ID）で結合された6つのテーブルから構築されたOracleビューに対していくつかのレガシーSQLSPを最適化しようとしています。ビュー内の一部のテーブルには、このIDフィールドのみであるインデックスがあり、他のテーブルにはありません。

このフィールドのみを使用してビュー内の残りのテーブルにインデックスを作成し、このフィールドを唯一のパラメーターとして使用して実際の選択クエリを実行すると、パフォーマンスが大幅に向上しますか？SPには他の欠陥があり、インデックス作成だけでは解決できない可能性があるため、必要に応じてs.procを投稿できます。問題のクエリは1行を返すのに約6秒かかります。どのテーブルにも大量のレコードが含まれておらず、とにかく100,000レコードを超えるものはありません。

前もって感謝します、

スコット

私たちは SQL タイムアウトを経験しており、そのボトルネックが監査テーブルであることを特定しました。システム内のすべてのテーブルには、新しい監査レコードの原因となる挿入、更新、および削除のトリガーが含まれています。

これは、監査テーブルがシステム内で最大かつ最もビジーなテーブルであることを意味します。ただし、データは入ってくるだけで出てこない (このシステムでは) ため、selectパフォーマンスは必要ありません。

返品を実行するselect top 10と、「最初の」レコードではなく最近レコードが挿入されます。 order byもちろん動作しますが、select top はディスク上の順序に基づいて行を返す必要があると思います.これは最低の PK 値を返すと思います.

クラスター化されたインデックスを削除することが提案されており、実際には主キー (一意の制約) も削除されています。前に述べたようにselect、このシステム内のこのテーブルからする必要はありません。

クラスター化インデックスがテーブルに作成するパフォーマンス ヒットはどのようなものですか? 索引付けされていない、クラスター化されていない、キーのないテーブルを持つことの (非選択) 影響は何ですか? 他の提案はありますか？

編集

私たちの監査にはCLR関数が含まれており、現在、PK、インデックス、FKなどを使用して、または使用せずにベンチマークを行って、CLR関数と制約の相対的なコストを決定しています。

調査の結果、パフォーマンスの低下はinsertステートメントに関連するものではなく、監査を調整する CLR 機能に関連するものでした。CLR を削除し、代わりに単純な TSQL プロシージャを使用すると、パフォーマンスが 20 倍向上しました。

テスト中に、クラスター化されたインデックスと ID 列は、少なくとも他の処理と比較して、挿入時間にほとんど、またはまったく違いがないことも確認しました。

このクエリを使用して、ジョブの検索データを取得します（以下を参照してください。簡単にするために省略します）。約100万件のレコードを扱っています。

ノート：

jobIdをREETEXTTABLEに渡して加重ランクを見つける必要があるため、通常の結合を使用できません。

問題：

その非常に遅い。

どうやら問題は計算列を比較することです。

Where SearchKeyMatchRank> 0を離陸すると、1秒もかかりません。

誰かがこれをどのように改善できるか考えましたか？

現在、提案されているテーブル構造は次のとおりです。

また

どのようなクエリが実行されますか? インプレッションは毎秒約 500 回更新されます。クリック数は毎秒約 1 回更新されます。ctr には毎秒約 500 の更新があります。

これで、アプリケーションは ctr を使用してデータを並べ替えます。ctr は によって算出されるクリック率ctr = clicks/impressionsです。クリックの更新がない限り、記事のすべてのインプレッションが増加し、同じ関係で ctr が減少しているため、ctr を更新する必要がないことに気付きました。クリックがない限り、ctr を更新する必要はありません。更新します。

現在、更新クエリは「UPDATE data_table SET インプレッション = インプレッション + 1、ctr = クリック / インプレッション WHERE 何か = 何か」のようなものです。

これは、一度に 2 つのフィールドが更新されても、実行されるクエリは 1 つだけであることを意味します。

現在のボトルネックは、これらの 500 の更新により、このテーブルの選択が遅くなることです。1 秒あたり約 20 の選択があります。そこで、テーブルを分けることにしました。新しいテーブル スタイルでは、更新は別のテーブルで行われ、選択は別のテーブルで行われることが提案されています。インプレッションを含むデータ テーブルは非常に頻繁に更新されるため、インプレッションの更新を実行すると、このテーブルのパフォーマンスが大幅に向上します。これは、data_table_2 の選択も高速になり、誰かがクリックするたびに ctr を更新できることを意味します。

そのため、新しいテーブル構造を使用する必要があるかどうかを知りたかっただけです。あなたは何を提案していますか？私の提案の長所と短所！

私は、ログオンが電子メールで行われ、メンバーが自分の名前/ニックネームを変更できるコミュニティサイトを構築しています。

メンバーテーブルのメンバー名/ニックネームをメンバーの他のプロパティと一緒に保持するか、別のテーブルを作成し、そのテーブルにメンバー名/ニックネームを書き込んでメンバーのIDを関連付ける必要があると思いますか。

私は2番目のオプションを支持しています。なぜなら、そこからメンバー名を取得する方が速いと思うからです。

それは正しい/より良い方法ですか？

更新：他のテーブルの理由は、さまざまなセクションのユーザー名を取得する必要があるためです。たとえば、フォーラム。fromトピックの各投稿のユーザー名ごとに小さなテーブルをクエリする方が速いのではないでしょうか。

URL をデータベースに保存しています。新しい URL を挿入するときに、その URL がデータベースに既に存在するかどうかを確認したいと考えています。

一般的な方法 (私が間違っていなければ) は、md5 や sha-1 などを使用して URL をハッシュし、新しいフィールドを挿入する前にデータベース内のそのフィールドの重複をチェックすることです。

私はmd5が衝突を引き起こす可能性があることを知っています.sha-1も...

あなたは私に何を提案しますか? 私のニーズは次のとおりです。

• DB サイズ:最終的にデータベースに 1000 万から 2000 万のレコード

• パフォーマンス/速度:ハッシュ サイズが小さいため、データベースの重複チェックに大きな負荷がかかりません (もちろん、そのフィールドにはインデックスが作成されます)。

• 許容範囲: 100,000 レコードごとに 1 つの衝突が発生してもかまいません。私のニーズは、0% の衝突 (大きなハッシュ) ではなく、パフォーマンス (小さなハッシュ) です。

• 意図的に衝突を引き起こす不正な URL による攻撃の可能性:非常に低い

• このような攻撃が成功した場合に可能な最大ダメージ:非常に低い

質問:

• md5 で十分だと思いますか (もっと良い提案があります)。

• たぶん、md5 は私にとってやり過ぎであり、もっと単純なものを使用することでパフォーマンス上の利点を真剣に得ることができますか?

よろしくお願いします！

ソートされたクエリでパフォーマンスが低下します。

これは、NHibernateによってクエリが生成およびレンダリングされる方法です。

太字の部分（**-記号内）は、すべての結果をフェッチして整理しています。これには時間がかかります。このクエリをより効率的にする方法はありますか？オーバーヘッドをあまり発生させずに、並べ替えとページングを可能にしたいだけです。

NHibernate2.1を使用しています。私の問題に関連する将来のリリースでの改善はありますか？

よろしく、マティアス

Joomlaのようないくつかの主要なシステムは、タグをコンマ区切りのテキストとしてメインの記事データベースに保存しますが、記事、タグ、タグの関係として3つのテーブルの正規化されたシステムが推奨されます（Wordpressのような他のシステムが使用するように）。構造と読書についてはたくさんの議論と質問があります。しかし、3つのテーブルに挿入する必要があるため、最適なINSERTコマンドを見つけることができませんでした。1回のSQL実行でこのプロセスをすばやく実行するにはどうすればよいですか？または、最初に記事を挿入し、次に各タグを挿入し、最後に関係を記述する必要がありますか？

もう1つの質問は、タグの一意性についてです。このシステムの主な利点は、各用語を1回だけ保存する必要があることです（その後、対応する記事に接続します）。重複を避けるためにmysqlUNIQUEを使用することは実用的ですか？または（どこかで読んだように）タグのリスト全体を配列として読み取って、タグIDをキャッチし、用語の保存を回避するための重複を見つける必要がありますか？

プロセス全体を3つの個別のステップとして実行しますか？

1. 記事を挿入
2. UNIQUEを使用してタグを挿入しますが、それらの関係は関係ありません
3. 各タグIDを見つけて、記事IDとの関係を作成します

私は正しいですか？私が尋ねた理由は、人々がタグを配列としてキャッチして比較するのを見たからです。私にとっては非常に遅く、特にUPDATEの場合はパフォーマンスが低下します。