0

MySQLデータベースが正規化されているため、パフォーマンスの問題が発生しています。

データベースを使用する私のアプリケーションのほとんどは、いくつかの重いネストされたクエリを実行する必要があります。私の場合、これには多くの時間がかかります。インデックスを使用すると、クエリの実行に最大2秒かかる場合があります。インデックスなしで約45秒。

数か月前に私が思いついた解決策は、より高速でより線形なドキュメントベースのデータベース(私の場合はSolr)をプライマリデータベースとして使用することでした。MySQLデータベースで何かが変更されるとすぐに、Solrに通知されました。

これは本当にうまくいきました。Solrデータベースを使用するすべてのクエリは、約3ミリ秒しかかかりませんでした。

数字は良さそうですが、問題があります。

  • 巨大なデータベース

MySQLデータベースは約200MBで、Solrデータベースには約1.4Gbのデータが含まれています。テーブル/列を変更する必要があるたびに、データベースのインデックスを再作成する必要があります。この例では、12時間以上かかりました。

  • 濡れることなくSolrオブジェクトとActiveRecord(MySQL)オブジェクトの両方をレンダリングすることは困難です。

ビューは特定のオブジェクトに依存しています。オブジェクト自体がActiveRecordオブジェクトであるかSolrオブジェクトであるかは、そのオブジェクトの属性のセットを呼び出すことができる限り、関係ありません。

このような。

# Controller
@song = Song.first

# View
@song.artist.urls.first.service.name

私の場合の問題は、Solrから返されるデータがこのようにフラットであるということです。

{
  id: 123,
  song: "Waterloo",
  artist: "ABBA",
  service_name: "Groveshark",
  urls: ["url1", "url2", "url3"]
}

これにより、ビューに渡すことができるアクティブなレコードオブジェクトを作成する必要があります。

私の質問

問題を解決するためのより良い方法はありますか?複雑なクエリを高速に処理できる、ある種の超高速プライマリ読み取り専用データベースがあれば便利です。

4

2 に答える 2

8

Solr 個々のフィールドの更新

スキーマ変更時のすべての再インデックス化について: Solrはまだ個々のフィールドの更新をサポートしていませんが、これに関するJIRAの問題がまだ解決されていません。しかし、何回スキーマを変更しますか?

モンゴDB

RDBMS なしで (結合、スキーマ、トランザクション、外部キー制約なしで) 生活できる場合は、MongoDBや CouchDB などのドキュメント ベースの DB が最適です。(ここにそれらの間の良い比較があります)

MongoBD を使用する理由:

  • データはネイティブ形式です ( Mongoid のような ORM マッパーをビューで直接使用できるため、Solr の場合のようにレコードを調整する必要はありません)
  • 動的クエリ
  • 非全文検索クエリで非常に優れたパフォーマンス
  • スキーマレス (移行の必要なし)
  • 組み込み、簡単にセットアップできるレプリケーション

SOLR を使用する理由:

  • 高度で高性能な全文検索

MySQL を使用する理由

  • 結合、制約、トランザクション

ソリューション

したがって、ソリューション(組み合わせ)は次のようになります。

  1. MongoDB + Solr を使用する

    • ただし、スキーマの変更時にすべてのインデックスを再作成する必要があります
  2. MongoDB のみを使用する

    • ただし、高度な全文検索のサポートを中止します
  3. マスター/スレーブ構成で MySQL を使用し、スレーブからのバランス読み取り ( octupusなどのプラグインを使用) + Solr

    • セットアップの複雑さ
  4. 現在の設定を維持し、MySQL でデータを非正規化します

    • 混雑

Solr 再インデックスの遅さ

MySQL データベースは約 200MB で、Solr データベースには約 1.4Gb のデータが含まれています。テーブル/列を変更する必要があるたびに、データベースのインデックスを再作成する必要があり、この例では 12 時間以上かかりました。

Solr で 200MB の DB を再インデックスするのに 12 時間かかるべきではありません! ほとんどの場合、次のような他の問題も抱えています。

MySQL:

SOLR:

http://outoftime.github.com/pivotal-sunspot-presentation.htmlから:

  • デフォルトでは、Sunspot::Rails は、Solr インデックスを更新するすべてのリクエストの最後にコミットします。それをオフにします。
    • Solr の autoCommit 機能を使用します。それはsolr/conf/solrconfig.xmlで構成されています
    • 想定される矛盾を喜んでください。結果が最新である必要がある場合は、検索を使用しないでください。
  • その他のセットアップの問題 (http://wiki.apache.org/solr/SolrPerformanceFactors#Indexing_Performance)

詳細については、ログを参照してください

于 2011-10-22T09:39:25.880 に答える
1

データをSolrにプッシュしてレコードをフラット化する代わりに、読み取り専用アクセス用に最適化された別のテーブルをMySQLデータベースに作成してみませんか。

また、あなたは自分自身と矛盾しているようです

ビューは特定のオブジェクトに依存しています。オブジェクト自体がActiveRecordオブジェクトであるかSolrオブジェクトであるかは、そのオブジェクトの属性のセットを呼び出すことができる限り、関係ありません。

私の場合の問題は、Solrから返されるデータがフラットであるということです...これにより、ビューでレンダリングできる偽のアクティブレコードオブジェクトを作成する必要があります。

于 2011-10-13T01:14:06.560 に答える