esとredisの違い

#es と redis の違い

ElasticSearch

コースのおすすめ→: 「Elasticsearch 全文検索実戦」 (実践動画)

コースより

「1000万レベルのデータ同時実行ソリューション(理論実践戦闘)」

MongoDBやRedisと比べると、1年後にリリースされたESの知名度は低いかもしれませんが、検索エンジン分野でのESの評価は確実に高いです。 。他のハイエンド データベース製品と比較すると、ES の背景ははるかに質素です。

ES の創始者であるシェイ・バノンは、かつては失業中のプログラマーで、何もすることがないときに妻がレシピを検索できるようにするために ES を作成しました (もちろん、当時は ES とは呼ばれていませんでした)。予期せぬ介入により、今日最も人気のある検索エンジンのデータベースが作成されました。案の定、プログラマーにとって女性は働く最大のモチベーションです。

ESも独自のElastic会社を設立し、数億ドルの資金調達を受けており、当時負け組プログラマーだったシェイ・バノン氏はすでに反撃してCEOとなり、人生の頂点に達しています。プログラマーの皆さん、この話を読んで、自分がCEOになって白富美と結婚する日をすでに想像し始めていますか?

ESの特徴はその名の通り検索です。厳密に言えば、ES はデータベースではなく検索エンジンであり、ES のすべての側面は検索を中心に設計されています。 ES は全文検索に対応しています。全文検索とは何かを簡単に説明します。「私は北京のインターネット会社で働いています」などのデータの場合、「北京」、「インターネット」、「北京」などのキーワードで検索すると、 「仕事」、これを打てばいい データがあればこれが全文検索 皆さんが普段使っているBaiduやGoogleも全文検索です。

ES の全文検索は中国語も適切にサポートしており (中国語の単語セグメンターだけでも多数あります)、中国のほとんどの人々の全文検索のニーズを確実に満たすことができることは言及する価値があります。検索に加えて、ES はすべてのフィールドに自動的にインデックスを付けて、高パフォーマンスの複雑な集計クエリを実現します。したがって、データが ES に保存されている限り、集計クエリがどれほど複雑であっても、良好なパフォーマンスを得ることができます。さまざまな複雑なインデックスの作成方法について心配する必要はもうありません。

ES の利点をたくさん述べてきましたが、ES はほぼ全能であると思いますか?

残念ながらそうではありませんが、ES には多くの欠点もあります。最も明らかな欠点は、フィールド タイプを変更できないこと、書き込みパフォーマンスが低いこと、ハードウェア リソースの消費量が多いことです。前述したように、ES は自動的にインデックスを作成します。これにより、全文検索やクエリの集計に多くの利点がもたらされ、インデックスを作成する手間が省けますが、この機能は多くの問題ももたらします。

ES はフィールドを作成する前に事前にマッピングを確立する必要があります。マッピングには各フィールドの型情報が含まれます。ES はマッピングに基づいてフィールドに対して適切なインデックスを確立する必要があります。このマッピングの存在により、ES のフィールドの型は作成後に変更できません。

(たとえば、構築したデータ テーブルのフィールドに全文検索を追加するのを忘れたとします。一時的に追加したいと考えていますが、テーブルはすでに構築されており、大量のデータがあります。現時点ではどうするべきですか? いいえ、申し訳ありませんが、データ テーブル全体を削除して、再度再構築することしかできません!)

したがって、ES はデータ構造の柔軟性において MySQL よりも優れていますが、MongoDB にははるかに劣ります。 ES の欠点はこれだけではなく、インデックスの自動作成も ES の書き込みパフォーマンスに影響を及ぼし、MongoDB に比べて大幅に低下します。

同じデータの場合、ES が占有するストレージ スペースは MongoDB よりも大幅に大きく (スペースを占有せずに非常に多くのインデックスを構築できますか?)、ハードウェア リソースの消費も非常に大きくなります。 64GメモリのSSDは基本的に大容量のデータを扱うのが一般的で、データベースでは貴族的なサービスとも言えるので、上司がケチな人はES選びに注意が必要です！

ES の全文検索機能により、ES は検索エンジンを構築するための強力なツールになります。さらに、ES は複雑な集計クエリを非常によくサポートしているため、ES はデータ分析に非常に適しています。

実際、ES はログ収集からデータ可視化分析までワンストップのサービスを提供するために独自の ELK スイートも特別に作成しており、ハイエンドのデータ分析プラットフォームを構築するための強力なツールであることは間違いありません。 。

ただし、ESはコストが高く書き込み性能が低いという欠点もあり、データの価値が高くなく、書き込み性能が要求され、データ量が多く、コストが限られているシナリオでの使用には適していません。 . .

Redis

Redis は、現在最も人気のあるキー/値データベースです。 MongoDB とともに 2009 年にリリースされた、ビッグデータ時代初期のデータベースの代表作でもあります。

Redis の最大の特徴は、言うまでもなく、キーバリュー ストレージによってもたらされるシンプルさと高いパフォーマンスです。いわゆるキーと値のストレージとは、テーブルやフィールドなどの従来のデータベースを使用せずに、実際の家の番号や居住者と同じように、各レコードにはデータをクエリするためのキーと、データを保存するための対応する値のみが含まれることを意味します。では必要ですが、すべてのクエリはキー値のみに依存します。

したがって、キーと値のデータベースはデータベース内で最も単純なデータ構造であると言えます。この単純な構造と、Redis がすべてのデータをメモリにロードするという事実のおかげで、Redis はより高い結果を達成できます。 MongoDB などの従来のデータベースの書き込みパフォーマンスも同様です。もちろん、Redis の機能は単純な Key-Value ストレージだけではなく、Key-Value の前身である Memcached と比較して、データの永続化、リストやセットなどのさまざまなデータ構造、マスターなどの一連の機能もサポートしています。 -スレーブのレプリケーションとバックアップ したがって、Redis は間違いなく最も包括的で使いやすいキー/値データベースです。

Redis のキー/値ストレージはパフォーマンス上の利点をもたらしますが、複雑なクエリに多くの制限ももたらします。データテーブルやフィールドなどの重要な機能が削除され、すべてのクエリがキーに依存するため、Redis は従来のデータベースが備えていた複数列クエリやセクションクエリなどの複雑なクエリ機能を提供できません。

同時に、Redis はデータをメモリに保存する必要があるため、Redis が保存できるデータ量も大幅に制限され、データ規模が大きいアプリケーション シナリオでは Redis を使用することが困難になります。

Redis は、大幅なパフォーマンスの向上と引き換えに、従来のデータベースのデータ テーブルや複雑なクエリなどの機能を犠牲にしています。読み取りおよび書き込みのパフォーマンスに対する非常に高い要件があり、単純なデータ テーブル構造 (キー) を持つユーザーに特に適しています。 -value 、 list 、 set など)、クエリ条件も単純なアプリケーション シナリオです。

データ テーブルの構造が非常に複雑で、複雑なクエリ操作を頻繁に実行する必要がある場合は、MongoDB または SQL を使用することをお勧めします。

Redis 関連の知識の詳細については、Redis 使用法チュートリアル 列をご覧ください。

以上がesとredisの違いの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。