3

バックグラウンド

サーバー データベース (10k ~ 200k レコードのサイズ範囲) でFULLTEXT検索を実装する必要があります。MySQL

現在のところ、データベース検索は単純な実装 (LIKEクエリ) に基づいており、明らかに非効率的であり、構成できないことなどは言うまでもありません。

次の 2 つの選択肢が考えられます。

  1. のネイティブ FULLTEXT を有効MySQLにします (1 つ以上のMyISAMテーブルを追加する必要があります - データベース全体がInnoDB今すぐです)。

  2. をインストールしてSphinxいます。

(私たちは PHP 5.2 を使用しており、アップグレードはオプションではないため、ここでは InnoDB FULLTEXT は問題外です。)

問題

パフォーマンスに関する考慮事項があります。FULLTEXTどちらの方法で実装しても、より多くのディスク スペースが消費されるだけでなく、CPU への負担も増えることは理解できます。

目標は、どの程度かを調べることです。両方のソリューションを相互にベンチマークする必要があります (もちろん、現状も)。これらのテストをセットアップして実行する必要があります。

私がそれについて行く方法は次のとおりです。

  1. データベースを実際のデータ (たとえば 10 万行) で埋めます。

  2. 索引の作成に必要な時間を測定します。

  3. 数千行を挿入/更新することにより、再インデックスの必要性をシミュレートします。ここでも、必要な時間と CPU および RAM の使用量をプロファイリングします。

  4. ブール値モードと自然言語モードの両方で、短いフレーズと長いフレーズのセットを使用してクエリ速度をテストします。

これまでのところかなり単純ですが、私はデスクトップ/クライアントアプリの開発者であり、快適ゾーンから外れているため、アドバイスをいただければ幸いです.

質問

  1. 私は何が欠けていますか?このテスト シナリオは意味のある結果をもたらす可能性がありますか?

  2. cron スクリプトでない場合、サーバーの CPU と RAM の使用状況を監視する正しい方法は何ですか?

少し未解決の質問であることは承知していますが、閉じられないことを願っています。

4

1 に答える 1

3

そのシナリオは問題ないようです。Sphinx にデルタ インデックスを実装することをお勧めします (最後のインデックス以降の変更のみをインデックス化します)。

監視では、cacti または munin ツールをセットアップできますが、これらをこのテストにのみ使用する場合は、dstat で十分かもしれません。

于 2012-11-18T07:41:52.427 に答える