みなさんこんにちは。フジサワです。前回の記事でお伝えしていたElasticsearchの検証がひと段落しましたので、検証結果をレポートいたします。
連載目次
- 『全文検索 〜 Elasticsearchとデータ匿名化手法』
- 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要
大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか?(Elasticsearch vs pg_bigm)』 ←今読んでいる記事
- データ匿名化 第2回:個人情報は匿名化しても意味がないのではないか?
- データ匿名化 第3回:個人情報を匿名化するプロセス
- データ匿名化 第4回:匿名化のために行うデータ項目の一般化とは
- データ匿名化 第5回:データ匿名化の指標
- データ匿名化 第6回:実際の匿名化
はじめに
検証を行うにあたり、私たちは前回、以下の通りゴール設定をしました。
『検索機能を有する新規サービスのアーキテクチャ検討段階で、RDBだけでなくElasticseachが比較検討材料として挙がる状態を作る』
この検証を行うにあたり、以下のようなサービスをモデルとして設定しました。
- 扱うデータのレコード数は、多くても100万件オーダー
※当社はBtoB向けのサービス、かつ中小企業のお客様を主たる顧客層としているので、1顧客でウン千万件、ウン億件というようなレコードが発生するケースよりは上記程度のデータ量が検証対象としては妥当だろうと判断しました。 - テキストデータに対する、中間一致検索(いわゆるLIKE検索)機能を持つ
※従来の技術領域を代替するもの、という位置付けでRDBでパフォーマンス劣化が発生しがちな中間一致検索を採用
また、当社ではRDBにPostgreSQLを採用する場合が多いのですが、デフォルトのPostgreSQLでは比較の余地がないので、PostgreSQLの全文検索プラグインであるpg_bigmを比較対象として採用することにしました。