2017-01-27 10 views
0

私は、かなり関連するデータモデルを持つB2Bノードアプリケーションを構築しています。現在のところ、独自の検索クエリを使用していますが、クエリの一部を拡大すると、クエリが低迷するように見えます。自分のビルドよりもホストされた検索サービスを利用するメリット

多言語検索とコンテンツベースの検索(関連するデータ内の一致するコンテンツの検索)をサポートする必要があります。

クエリがますます複雑になり(それぞれがジョインでジョインに複数のジョインを持つ)、今ではAlgoliaなどのホスト型検索ツールを検討しています。

以下の懸念から、自分のクエリを作成し続けるのではなく、ホスト型クラウド検索サービスを使用する必要があるのはなぜですか?

  • データプライバシーが
  • 重要なデータは、私たち自身のpostgres DBにホストされている - が重要であることとの統合(例:?私は今、手動Algoliaで私たちのDBデータとデータを維持する必要があります)
  • スピード複数の言語
  • 間でコンテンツベースの検索を行うことができる必要があります
  • 重要ではなく、そんなに今
  • ます私たちは今、開発者の小さなチームですので、DEVリソース時間が
不可欠です

検索機能の決定に役立つその他の事項は何ですか? DBとクラウドの両方のデータのメンテナンスについて


、すべてのデータを取得し、それをキャッシュし、クラウドに格納するのと同じくらい簡単だと思われる:

var index = Algolia.initIndex('contacts'); 
var contactsJSON = require('./contacts.json'); 

index.addObjects(contactsJSON, function(err, content) { 
    if (err) { 
    console.error(err); 
    } 
}); 

答えて

1

Algoliaまたは自己のような検索サービスElasticsearch/solrは、リレーショナルDBクエリではなくフルテキスト検索として動作します。

しかし、ボトルネックのように聞こえるのは継続的な再結合です。リレーショナルデータをフルテキストのドキュメントDBのように動作させることができれば、より効率的なインデックスのタイプ(事前結合されたソート)になります。

また、ビューやデータウェアハウス(多分スタースキーマ)を調べることもできます。

しかし、あなたが自分のelasticsearchをホストしている可能性があります検索ルートを検討している場合。

詳細なヘルプが必要な場合は、データベース、スキーマ、SQL、インデックス、クエリの詳細を指定できます。

+0

ジェイソンので、私たちのデータの生活であればDB内の関連モデルとして、検索機能は大規模なクエリ( 'to_tsvector(text)@@ to_tsquery( 'hi&there')')内でFTS機能を使用することです。 'Algolia'のようなものを使うために私たちのデータベース層を再構成する必要がありますか?リレーショナルデータベースのクエリではなく、フルテキスト検索として動作することを意味しているのかどうかはわかりません。 ""そして、 "あなたのリレーショナルデータをフルテキストドキュメントdbのように動作させることができるなら" Postgresqlを使用して、一連のレコードの個々のフィールドでFTSを実行します。 – Growler

+0

私はsolrやelasticsearchを設定しようとしましたが、それほど難しくなく、あなたはそれを制御できます。 elasticsearchまたはAlgoliaを使用するかどうかは、データをコピーするために必要な個別のインデックス/ドキュメントストアになります。それはあなたのリレーショナルテーブルに当たらないでしょう。 –

+0

''しかし、もしあなたが探索経路を進んでいるのであれば、あなた自身の弾性サーチをホストしているかどうか調査するかもしれません。 " - 私はこれを理解しているのか分かりません。私は現在、 'tsvector'を使って検索することができます。 – Growler

0

完全開示:企業や開発者は、検索インフラストラクチャ(ops)のツールの設定、管理、スケーリング、構築に時間を費やすべきではないという前提で、Measured Searchという会社を設立しました。機能、製品、または顧客であるかどうかに関わらず、従業員は会社の価値を創造することができます。

Lucene(Apache Solr/Elasticsearch)をベースにしたオープンソース検索ソリューションは、検索エンジンの機能の観点から、今すぐ必要なものと近い将来必要なものを備えています。オープンソース検索を専門とする成熟したサービスプロバイダー/ AS-A-Service会社を探して、すべての人に対処させてください。それはおそらく、あなたのdevsの操作に時間を費やす時間と努力の価値はないが、今は少しの努力のように見えるかもしれません。上記のあなたの懸念のために

データのプライバシーは、プライバシーとセキュリティの周りのあなたの懸念は、アドレス可能である

重要です。 Solr環境を保護するには複数の方法があり、適切なMSPまたはManaged Solutionプロバイダがそれらに対処できる必要があります。

a。 トランスポート層のセキュリティは、SSL証明書で対処できます。すべてのデータは暗号化されています。

b。 IPフィルタリングとユーザーベースの認証はにアクセスし、誰にアクセスするかはである必要があります。 Measured SearchによるSolr-as-a-Service提供は、両方をサポートします。

c。 安心のセキュリティは、OSレベル/ファイルの暗号化など、複数の方法で対処できますが、サービスプロバイダであっても検索可能な暗号化技術を使用してそのデータにアクセスできないようにすることもできます。

プライバシーに関する懸念事項はすべて&に記載されています。条件 - あなたの法務部門は、サービスプロバイダの観点からそれを扱うことを確信しています。データは、私たち自身のPostgresのDBにホストされている

- 統合はそれで重要な

Solrには、従来のリレーショナルデータベース(MySQLやPostgresのは、Oracleなど)を介して直接(DIH)にデータをインポートする機能を提供します。 Solrが定期的にデータをプルできるように、またはSolr APIを介してデータをプッシュするための独自の簡単なスクリプトを作成することができます。

クラウド(AWS)でホストされている場合は、Solrのデプロイメントだけがサーバーからデータを取得でき、データベースサーバーは世界中に公開されないようにトンネルを作成できますDIHルート。

スピードが重要になりますが、それほど今のSolrは、検索速度のために構築されてい

- あなたの問題があることを行っているところ私はそれはないと思います。測定された検索のようなサービス提供 - AWSまたはAzureでサポートされているすべてのデータセンターでクラスタをスピンアップし、検索展開をアプリケーションサーバーに近づけることで待ち時間のオーバーヘッドを最小限に抑えることができます。

は、複数の言語

間でコンテンツベースの検索を行うことができる必要がありますはい、Solrにはそれをサポートしています。 30以上の言語。

我々は今、開発者の小さなチームですので、DEVリソース時間が

不可欠である私はここにバイアスされていますが、私は私の開発者は、業務上の多くの時間を費やす必要があり、それらは、彼らが何をすべきかに焦点を当てることはできないだろう最善の方法 - 限界を押し進めてビジネス価値をもたらす優れた製品機能を構築する。

あなたが測定された検索によって提供されるようにSolrのサービスとしてを使用して対それを自分でやっての比較およびROIをすることに興味がある場合は、この論文をチェックアウト - https://www.measuredsearch.com/white-papers/why-measured-search-is-better-than-diy-solr-infrastructure/

関連する問題