Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
PostgreSQL vs Elasticsearch -ファセットカウント編-
Search
forcia_dev_pr
February 21, 2022
Programming
0
670
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
第7回ゆるふわオンサイト解説
forcia_dev_pr
0
130
第6回ゆるふわオンサイト解説
forcia_dev_pr
0
180
よくわかるFORCIAのエンジニア旅行SaaSプロダクト開発編
forcia_dev_pr
0
490
よくわかるフォルシアのエンジニア 新卒採用編
forcia_dev_pr
0
2.7k
第5回ゆるふわオンサイト解説
forcia_dev_pr
0
110
よくわかるフォルシアのエンジニア 旅行プラットフォーム部編
forcia_dev_pr
0
4.7k
React hooks を気合で理解する
forcia_dev_pr
0
300
k8sマニフェストを Typescriptで管理したい― cdk8s+を導入してみました ―
forcia_dev_pr
0
300
第4回ゆるふわ競技プログラミングオンサイト解説
forcia_dev_pr
0
480
Other Decks in Programming
See All in Programming
Better Code Design in PHP
afilina
PRO
0
130
『ドメイン駆動設計をはじめよう』のモデリングアプローチ
masuda220
PRO
8
540
Less waste, more joy, and a lot more green: How Quarkus makes Java better
hollycummins
0
100
見せてあげますよ、「本物のLaravel批判」ってやつを。
77web
7
7.8k
Kaigi on Rails 2024 〜運営の裏側〜
krpk1900
1
230
Tauriでネイティブアプリを作りたい
tsucchinoko
0
370
PHP でアセンブリ言語のように書く技術
memory1994
PRO
1
170
Enabling DevOps and Team Topologies Through Architecture: Architecting for Fast Flow
cer
PRO
0
340
ペアーズにおけるAmazon Bedrockを⽤いた障害対応⽀援 ⽣成AIツールの導⼊事例 @ 20241115配信AWSウェビナー登壇
fukubaka0825
6
2k
どうして僕の作ったクラスが手続き型と言われなきゃいけないんですか
akikogoto
1
120
リアーキテクチャxDDD 1年間の取り組みと進化
hsawaji
1
220
Webの技術スタックで マルチプラットフォームアプリ開発を可能にするElixirDesktopの紹介
thehaigo
2
1k
Featured
See All Featured
How GitHub (no longer) Works
holman
310
140k
Automating Front-end Workflow
addyosmani
1366
200k
Designing Experiences People Love
moore
138
23k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
410
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
The Pragmatic Product Professional
lauravandoore
31
6.3k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
Bash Introduction
62gerente
608
210k
GraphQLとの向き合い方2022年版
quramy
43
13k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
720
Why Our Code Smells
bkeepers
PRO
334
57k
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