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
810
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
"書く文化"を仕組みで育てる──フォルシアの技術ブログ継続戦略
forcia_dev_pr
1
140
新しいおもちゃを見つけたい私がやっている情報収集
forcia_dev_pr
2
390
「Pythonの環境構築について」と記事作成で意識したこと
forcia_dev_pr
1
130
Neovim で VS Code みたいにコーディングする
forcia_dev_pr
1
140
なぜ・どうやって・何を書く? 〜技術記事を書く習慣の作り方〜
forcia_dev_pr
1
150
第8回ゆるふわオンサイト 解説スライド
forcia_dev_pr
0
90
第7回ゆるふわオンサイト解説
forcia_dev_pr
0
230
第6回ゆるふわオンサイト解説
forcia_dev_pr
0
230
よくわかるFORCIAのエンジニア旅行SaaSプロダクト開発編
forcia_dev_pr
0
740
Other Decks in Programming
See All in Programming
第9回 情シス転職ミートアップ 株式会社IVRy(アイブリー)の紹介
ivry_presentationmaterials
1
260
WebViewの現在地 - SwiftUI時代のWebKit - / The Current State Of WebView
marcy731
0
110
ペアプロ × 生成AI 現場での実践と課題について / generative-ai-in-pair-programming
codmoninc
0
200
AIエージェントはこう育てる - GitHub Copilot Agentとチームの共進化サイクル
koboriakira
0
480
新メンバーも今日から大活躍!SREが支えるスケールし続ける組織のオンボーディング
honmarkhunt
1
300
プロダクト志向ってなんなんだろうね
righttouch
PRO
0
170
スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略
sutochin26
0
250
Create a website using Spatial Web
akkeylab
0
310
Cursor AI Agentと伴走する アプリケーションの高速リプレイス
daisuketakeda
1
130
設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
panda_program
6
1.8k
データの民主化を支える、透明性のあるデータ利活用への挑戦 2025-06-25 Database Engineering Meetup#7
y_ken
0
340
Composerが「依存解決」のためにどんな工夫をしているか #phpcon
o0h
PRO
1
250
Featured
See All Featured
Six Lessons from altMBA
skipperchong
28
3.9k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.4k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Agile that works and the tools we love
rasmusluckow
329
21k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Writing Fast Ruby
sferik
628
62k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Designing for humans not robots
tammielis
253
25k
Code Reviewing Like a Champion
maltzj
524
40k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Adopting Sorbet at Scale
ufuk
77
9.4k
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