8

そこで、1 週間前にベータ アプリケーション内で ElasticSearch を使用して Haystack を実装しました。私が気付いたことの 1 つは、一部のデータ (大量) をユーザーに返すこと (たとえば、アプリケーション内のすべてのユーザーを一覧表示するなど) は、Django の ORM よりも Haystack を経由する方がはるかに高速であることです。現在、iPad、Nexus タブレットなどから情報にアクセスできるようにしたいので、今後数週間以内に可能なタブレットにサービスを提供する REST サービス (TastyPie を使用) をリリースする予定です。

私が疑問に思っていたことの 1 つは、いつ ORM と Haystack/ElasticSearch を照会する必要があるかということです。たとえば、タブレットのユーザーが特定のユーザーのセットを要求している場合、TastyPie に ORM をクエリさせるべきでしょうか、それとも ElasticSearch に行くべきでしょうか?

この回答Django: Haystack or ORMを見ると、DB がデータの取得と書き込みのために作成されていることに全員が同意できます。しかし、検索エンジンが更新されれば、Haystack/ElasticSearch を使用すると、より高速に取得できると言えますか?

私は少し混乱しています。Haystack の方がはるかに高速である場合、クエリを実行すべきではないでしょうか?!

4

1 に答える 1

6

明確にするために、データベースからのデータを使用して検索結果のオブジェクトを後でインスタンス化せずに、Haystack を介して Elasticsearch にクエリを実行することについて話していると思います。

他の投稿で言及されている点以外に考慮すべき点がいくつかあります。

  • Elasticsearch のような検索エンジンは、全文検索を処理する際に高度に最適化されています (SQL で何かを行う場合、使用しているデータベース/エンジンに大きく依存します)。

  • 多くの関係/結合を含むクエリは、ORM で処理するのが最も簡単ですが、一方で、ES を使用する場合は、外部キー関係から非正規化された方法でデータを保存できます。これにより、パフォーマンスが向上する可能性があります。 . もちろん、データベース テーブルを非正規化することもできますが、パフォーマンスのボトルネックを解決する場合など、自分が何をしているのかを知っている限り、これは悪い習慣と見なされることがよくあります。

  • ES はスケーリングが非常に簡単ですが、SQL DB のスケーリングはより複雑になる可能性があります。

  • ほとんどの場合、これはユース ケース、処理するデータの量、および実行する予定のクエリに大きく依存する決定です。したがって、もちろん最善の方法は、いつものように、自分でベンチマークを行い、この 2 つのソリューションを比較することです。ただし、ORM の大きな利点の 1 つは物事をシンプルに保つことであるため、時期尚早の最適化を行わないでください。データの整合性を気にしたり、追加のシステムを維持したりする必要はありません。

于 2013-06-06T13:49:54.393 に答える