Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
PostgreSQL vs Elasticsearch -ファセットカウント編-
forcia_dev_pr
February 21, 2022
Programming
0
230
PostgreSQL vs Elasticsearch -ファセットカウント編-
「FORCIA Meetup #4 高速検索を支えるPostgreSQLのノウハウ」の資料です
forcia_dev_pr
February 21, 2022
Tweet
Share
More Decks by forcia_dev_pr
See All by forcia_dev_pr
フォルシアのフレームワークとTypeScript
forcia_dev_pr
0
30
TypeScript(WebGL)+React+Viteで、さくっとGeodesic Polyhedronを描画してみた
forcia_dev_pr
0
20
RedCoderがTypeScriptで競技プログラミングに挑戦して挫折した話
forcia_dev_pr
0
25
エンジニア募集 ~技術は「売れて」初めて価値となる~
forcia_dev_pr
0
73
Gitlab CIでMRを自動生成する
forcia_dev_pr
0
290
フォルシアにおけるPostgreSQLの活用
forcia_dev_pr
0
180
PostgreSQL開発とテスト
forcia_dev_pr
0
190
そのSQL、もっと速くなりますよ。
forcia_dev_pr
0
220
AWS LambdaでのRust利用
forcia_dev_pr
1
280
Other Decks in Programming
See All in Programming
42tokyo-born2beroot-review
love42
0
110
Unity+C#で学ぶ! メモリレイアウトとvtableのすゝめ 〜動的ポリモーフィズムを実現する仕組み〜
rossam
1
310
Swift Concurrency in GoodNotes
inamiy
4
1.4k
Hasura の Relationship と権限管理
karszawa
0
180
10年以上続くプロダクトの フロントエンド刷新プロジェクトのふりかえり
yotahada3
2
340
ECS Service Connectでマイクロサービスを繋いでみた
xblood
0
720
Hono v3 - Do Everything, Run Anywhere, But Small, And Faster
yusukebe
4
130
23年のJavaトレンドは?Quarkusで理解するコンテナネイティブJava
tatsuya1bm
1
130
低レイヤーから始める GUI
fadis
18
9.4k
TSX First な Zero-Runtime SSG potato4d/dodai とその仕組み / owned static site generator #kyotojs
potato4d
0
390
和暦を正しく扱うための暦の話
nagise
10
6.6k
2023年にクル(かもしれない)通信ミドルウェア技術(仮)
s_hosoai
0
220
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1351
200k
Faster Mobile Websites
deanohume
295
29k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
236
1.1M
Designing on Purpose - Digital PM Summit 2013
jponch
108
5.9k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
10
1.3k
Building Your Own Lightsaber
phodgson
96
4.9k
4 Signs Your Business is Dying
shpigford
171
20k
Atom: Resistance is Futile
akmur
256
24k
Why You Should Never Use an ORM
jnunemaker
PRO
49
7.9k
How STYLIGHT went responsive
nonsquared
89
4.2k
Designing for Performance
lara
600
65k
Designing the Hi-DPI Web
ddemaree
273
32k
Transcript
PostgreSQL vs Elasticsearch -ファセットカウント編- 籏野 拓 @フォルシア株式会社 2022.02.15 FORCIA Meetup#4
自己紹介 • 籏野 拓 (Taku Hatano) ◦ 新卒4年目 • ソフトウェアエンジニア@フォルシア株式会社
◦ 福利厚生系アプリ中心に自社プロダクトもちらほら • 活動領域 ◦ webアプリケーション (TypeScript, Node.js, React, Next.js, PostgreSQL) ◦ インフラ関連(Ansible, AWS, k8s, docker) 2
フォルシアの検索 3
What is Spook®? 4 各企業が独自に持つ膨大で複雑なデータに合わせて、 最適な検索を実現するための「技術基盤」
Spook®の特長 5 検索対象の属性を軸に絞り込みを行う →PostgreSQLの独自関数を利用し、 より高速な検索を実現
さらなる展開 6 近年、キーワード検索への需要の高まりも感じている ↓ の利用検討中
PostgreSQL vs Elasticsearch 7
キーワード検索編 普通はElasticsearchの方が5倍早い • C言語による拡張機能(extension) ◦ システム開発者向け • 形態素解析器を呼び出せるが 基本的に自作 •
Javaによる拡張機能(plugin) ◦ 応用的・ユーザー志向 • キーワード検索に必要な機能 ワンストップで提供 8 [参考] FORCIA CUBE「Elasticsearch vs. PostgreSQL」 https://www.forcia.com/blog/001551.html
ファセットカウント編 9 「ファセットカウント」 →条件で絞り込む際に 該当の条件が何件であるかを事前に表示する 実際にPostgreSQLとElasticsearchで速度比較してみた
対象データ 10 • 1レコードが複数のカテゴリを持つようなデータを対象とする。 • カテゴリは1~100のランダムな整数 • 1レコードあたり1~10のランダムな数のカテゴリをもつ • postgresはint配列、elasticsearchはNested
Typeでデータを持つ { "_index" : "search", "_type" : "_doc", "_id" : "eFHgw34BVdsiHW0pykMc", "_score" : 1.0, "_source" : { "categories" : [{ "id" : 37}, {"id" : 83}] } } id | categories ----+--------------------------------- 1 | {69,87,96,98}
集計クエリ 11 select unnest(categories) as category ,count(*) from search group
by category order by category { "size": 0, "aggs": { "categories" : { "nested": { "path": "categories" }, "aggs": { "count": { "terms": { "field": "categories.id" , "size": 101, "order": { "_key": "asc" } } } } } } }
計測方法 12 • 以下を10回繰り返して実行時間の平均を算出する ◦ 1万/10万/100万行のランダムなデータを生成する ◦ それぞれにクエリを投げて実行時間を計測 ※あるアプリでは施設数3万件、プラン数120万件くらい
計測結果 13 レコード数 PostgreSQL平均 Elasticsearch平均 10000 0.028s 0.021s 100000 0.130s
0.039s 1000000 1.429s 0.373s • レコード数が少ない場合は同等のスピード • レコード数が多いとElasticsearchに軍配 ◦ NestedTypeは配列の要素ごとに異なるドキュメント(≒レコード)として保 持されているので展開の必要がない
補足: Elasticsearchのオブジェクト配列 14 (公式: https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html ) 単純なオブジェクトの配列でマッピングされている場合、 フラットな構造に展開されてインデックスされる PUT my-index-000001
/_doc/1 { "group" : "fans", "user" : [ { "first" : "John", "last" : "Smith" }, { "first" : "Alice", "last" : "White" } ] } { "group" : "fans", "user.first" : [ "alice", "john" ], "user.last" : [ "smith", "white" ] } firstとlastの組み合わせが維持されない first = “Alice” and last = “Smith” がヒットしてしまう →
補足: Elasticsearch Nested Type 15 (公式: https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html ) Nested Typeを利用することで元の組み合わせを保持してインデックスされる
{ "group" : "fans", "user.first" : "john", "user.last" : "smith" } { "group" : "fans", "user.first" : "alice", "user.last" : "white" } 「nested documents are indexed as separate documents」 ←インデックスされるイメージ first = “Alice” and last = “Smith” はヒットしない
Spook®でも計測を行ってみた 16 レコード数 PostgreSQL平均 Elasticsearch平均 Spook®平均 10000 0.028s 0.021s 0.010s
100000 0.130s 0.039s 0.022s 1000000 1.429s 0.373s 0.090s • PostgreSQLでもチューニングにより十二分な速度が出る
まとめ 17 • ElasticsearchのAggregationsという機能を使うことで GROUP BY相当の集計ができる • チューニングなどしなくてもある程度の速度が出る ◦ デフォルトでフラットな構造にしてインデックスしてくれるため
• PostgreSQLでもチューニングを行うことで高速化は可能
EOF