2

私のスタートアップでは、Google アナリティクスに頼るのではなく、自分ですべてを追跡しています。私は実際にIPとユーザーIDとすべてを持つことができるので、これは素晴らしいです.

これは、追跡テーブルが約 200 万行増加するまでうまく機能しました。テーブルは と呼ばれacts、次のレコードが記録されます。

  • IP
  • URL
  • ノート
  • アカウントID

...利用可能な場合。

今、このようなことをしようとしています:

SELECT COUNT(distinct ip) 
  FROM acts
  JOIN users ON(users.ip = acts.ip) 
 WHERE acts.url LIKE '%some_marketing_page%';

基本的に終わらない。私はこれに切り替えました：

SELECT COUNT(distinct ip) 
  FROM acts
  JOIN users ON(users.ip = acts.ip) 
 WHERE acts.note = 'some_marketing_page';

しかし、注目すべきインデックスがあるにもかかわらず、それでも非常に遅いです。

私は明らかにmysqlのプロではありません。私の質問は：

大量のデータを持つ企業は、目標到達プロセスのコンバージョン率などをどのように追跡しますか? mysqlで行うことは可能ですか?知識が不足しているだけですか? そうでない場合、サイトがこれを行う方法について、どの本やブログを読むことができますか?

4

3 に答える 3

1

「立派」に近づいている間、200万行はまだテーブルの比較的小さいサイズです。（したがって、通常はより高速なパフォーマンスが可能です）

お気づきのように、フロントエンドのワイルドカードは特に非効率的であり、アプリケーションでそのユース ケースが一般的である場合は、これに対する解決策を見つける必要があります。

適切なインデックスのセットを持っていない可能性があります。ただし、先に進む前に、インデックスは通常、あらゆる種類の SELECT ステートメントで DBMS のパフォーマンスを向上させる一方で、"CUD" 操作 (つまり、SQL CREATE/INSERT、UPDATE 、 DELETE 動詞、つまり、データベースを読み取るだけでなく、データベースに書き込むクエリ)。場合によっては、「書き込み」クエリに対するインデックスの悪影響が非常に大きくなる可能性があります。

インデックスの相反する性質を特に強調する理由は、アプリケーションが操作の通常の部分としてかなりの量のデータ収集を行っているように見えるためです。INSERT クエリの速度が低下するにつれて、パフォーマンスが低下する可能性に注意する必要があります。 . 考えられる代替手段は、データ収集を比較的小さなテーブル/データベースに実行し、インデックスをまったくまたはほとんど持たずに実行し、この入力データベースから実際のデータ マイニングが行われるデータベースにデータを定期的にインポートすることです。(インポート後、行は「入力データベース」から削除される可能性があり、INSERT 機能のためにデータベースを小さく高速に保ちます。)

別の懸念/質問は、キャストテーブルの行の幅 (列の数とこれらの列の幅の合計) に関するものです。パフォーマンスの低下は、行が広すぎるためにテーブルのリーフ ノードの行が少なくなり、ツリー構造が必要以上に深くなることが原因である可能性があります。

インデックスに戻ります...
質問のいくつかのクエリを考慮すると、ip + noteインデックス（少なくともこれら2つのキーをこの順序で使用して作成されたインデックス）の恩恵を受けることができるようです。インデックス状況の完全な分析、および率直に言って、データベース スキーマの可能なレビューは、ここでは行うことができません (情報が十分ではありません...)。これらのケースに役立つデータベース インデックスを確認します。mySQL コマンド EXPLAIN を使用して、特定のクエリが最初に、またはインデックスが追加された後にどのように処理されるかについての洞察を収集できます。

ノーマライゼーション OR デモマライゼーション (または両方の組み合わせ) は、多くの場合、採掘作業中のパフォーマンスを改善するための実行可能なアイデアです。

于 2009-11-25T02:33:10.010 に答える
1

なぜ参加するのですか？ユーザーに関連付けられたレコードがない IP がアクトにならないことが想定できる場合は、参加する必要はありません。

SELECT COUNT(distinct ip) FROM acts
WHERE acts.url LIKE '%some_marketing_page%';

JOIN が本当に必要な場合は、最初にアクトから個別の IP を選択し、次にそれらの結果をユーザーに JOIN する必要があります (実行計画を調べて、これがより高速かどうかを実験する必要があります)。

第 2 に、先頭にワイルド カードを使用した LIKE は、行為の完全なテーブル スキャンを引き起こし、コストのかかるテキスト検索も必要とします。これを改善するには、次の 3 つの選択肢があります。

  1. 検索が列の値と正確に一致するように、保存する前に URL を構成要素に分解します。

  2. URL フィールドの途中ではなく、先頭に検索用語を表示する必要があります。

  3. 内部の LIKE 検索でもインデックスに対して実行できるように、url フィールドをインデックス化する全文検索エンジンを調査します。

最後に、acts.notes での検索の場合、notes のインデックスで検索が十分に改善されない場合は、notes の整数ハッシュを計算して保存し、それを検索することを検討します。

于 2009-11-25T02:47:14.287 に答える
0

クエリで「EXPLAIN PLAN」を実行してみて、テーブル スキャンがあるかどうかを確認してください。

これは LEFT JOIN である必要がありますか?

たぶん、このサイトが役立つかもしれません。

于 2009-11-25T02:33:53.067 に答える