最近、ユーザーの急増とトラフィックの急上昇により、同時に多くの検索が行われるようになりました。
現在、約120万件の投稿で検索のタイムアウトが発生しています。
大規模なフォーラムでは、検索機能についてどのような対応をとられていますか？Discourseのコア検索機能から脱却されましたか、それともまだ順調に機能していますか？検索アルゴリズムやクエリをより制限的・特化型に更新されましたか？データベースのチューニングも行われましたか？
ご意見をお待ちしています！
「いいね！」 1
サーバーの仕様と、どのリソースが最もボトルネックになっているか教えてください。
約2000万件の投稿（公開投稿とプライベート会話を含む）を持つボードを移行する可能性を検討しており、大規模なボードにおける潜在的なパフォーマンスの問題について学ぶことに非常に興味があります。
「いいね！」 1
100万件の投稿から200万件の投稿への道のりは遠く、両者に共通して適用できるアドバイスはほとんどありません。参考までに、私はi7-7500U @ 2.7GHz、16GBのRAMを搭載したサーバーで900万件の投稿を持つサイトを持っており、許容できるパフォーマンスを達成しています。同じサーバーには他にもいくつかの低ボリュームサイトがあります。
AWSデータベースを使用し、8GBのRAMを持つ400万件の投稿のサイトは、特に検索で苦労しています。
@Jumanji さん、あなたのサーバー仕様を教えていただけますか？
「いいね！」 6
「いいね！」 11
AWS を使用しています。フォーラムは 4 インスタンス（t3.large と推測されます）で実行されており、それぞれ 4 vCPU と 16 GB の RAM を搭載しています。Kubernetes をカスタム Docker イメージ上で実行しています。データベースは別のインスタンス（m4.large）で、2 vCPU と 8 GB の RAM です。データベースインスタンスの RAM が確かにボトルネックになっている可能性があります。
タイムアウトしているクエリは、一般的に単一の単語などの汎用的な検索語です。60 秒以上実行されたものもありました。また、先月、当社のウェブサイトへのトラフィックが急増しました。前月比で 40% 増加しました。この期間中に v1.9 から v2.4 へ移行しており、v1.9 以降、検索機能にオートコンプリート検索が追加されたため、データベースサーバーへの負荷が増加したと考えています。
クエリ分析を行ったところ、以下のクエリが 20〜60 秒の間実行されていました：
`SELECT "posts".*
FROM "posts"
JOIN (
SELECT *, row_number() over() row_number
FROM (
SELECT topics.id, min(posts.post_number) post_number
FROM "posts"
INNER JOIN "post_search_data" ON "post_search_data"."post_id" = "posts"."id"
INNER JOIN "topics" ON "topics"."id" = "posts"."topic_id" AND ("topics"."deleted_at" IS NULL)
LEFT JOIN categories ON categories.id = topics.category_id
WHERE
("posts"."deleted_at" IS NULL)
AND "posts"."post_type" IN (1, 2, 3)
AND (topics.visible)
AND (topics.archetype <> 'private_message')
AND (post_search_data.search_data @@ TO_TSQUERY('english', '''a'':*ABD & ''price'':*ABD'))
AND (categories.id NOT IN (SELECT categories.id WHERE categories.search_priority = 1))
AND ((categories.id IS NULL) OR (NOT categories.read_restricted))
GROUP BY topics.id
ORDER BY
MAX((
TS_RANK_CD(
post_search_data.search_data,
TO_TSQUERY('english', '''a'':*ABD & ''price'':*ABD'),
1|32
) * (
CASE categories.search_priority
WHEN 2
THEN 0.6
WHEN 3
THEN 0.8
WHEN 4
THEN 1.2
WHEN 5
THEN 1.4
ELSE
CASE
WHEN topics.closed
THEN 0.9
ELSE 1
END
END
)
)) DESC,
topics.bumped_at DESC
LIMIT 6
OFFSET 0
) xxx
) x ON x.id = posts.topic_id AND x.post_number = posts.post_number
WHERE ("posts"."deleted_at" IS NULL)
ORDER BY row_number;
---
Sort (cost=495214.55..495214.56 rows=1 width=1177) (actual time=20529.725..20529.727 rows=6 loops=1)
Sort Key: (row_number() OVER (?))
Sort Method: quicksort Memory: 29kB
-> Nested Loop (cost=495164.08..495214.54 rows=1 width=1177) (actual time=20525.899..20529.703 rows=6 loops=1)
-> WindowAgg (cost=495163.65..495163.80 rows=6 width=16) (actual time=20520.976..20521.078 rows=6 loops=1)
-> Limit (cost=495163.65..495163.66 rows=6 width=24) (actual time=20520.969..20521.063 rows=6 loops=1)
-> Sort (cost=495163.65..495232.24 rows=27438 width=24) (actual time=20520.967..20520.969 rows=6 loops=1)
Sort Key: (max((ts_rank_cd(post_search_data.search_data, '''price'':*ABD'::tsquery, 33) * (CASE categories.search_priority WHEN 2 THEN 0.6 WHEN 3 THEN 0.8 WHEN 4 THEN 1.2 WHEN 5 THEN 1.4 ELSE CASE WHEN topics.closed THEN 0.9 ELSE '1'::numeric END END)::double precision))) DESC, topics.bumped_at DESC
Sort Method: top-N heapsort Memory: 25kB
-> GroupAggregate (cost=493642.90..494671.83 rows=27438 width=24) (actual time=19082.214..20506.763 rows=32951 loops=1)
Group Key: topics.id
-> Sort (cost=493642.90..493711.50 rows=27438 width=400) (actual time=19082.184..19283.907 rows=191436 loops=1)
Sort Key: topics.id
Sort Method: external merge Disk: 77632kB
-> Hash Left Join (cost=36655.60..486646.69 rows=27438 width=400) (actual time=1562.696..18611.724 rows=191436 loops=1)
Hash Cond: (topics.category_id = categories.id)
Filter: (((categories.id IS NULL) OR (NOT categories.read_restricted)) AND (NOT (SubPlan 1)))
-> Gather (cost=36645.63..486471.60 rows=58991 width=400) (actual time=1562.623..18249.349 rows=191436 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Nested Loop (cost=35645.63..479572.50 rows=24580 width=400) (actual time=1556.547..18541.793 rows=63812 loops=3)
-> Hash Join (cost=35645.20..328688.61 rows=157831 width=25) (actual time=1551.912..13356.416 rows=285279 loops=3)
Hash Cond: (posts_1.topic_id = topics.id)
-> Parallel Seq Scan on posts posts_1 (cost=0.00..286245.92 rows=504559 width=12) (actual time=0.280..11249.160 rows=404770 loops=3)
Filter: ((deleted_at IS NULL) AND (post_type = ANY ('{1,2,3}'::integer[])))
Rows Removed by Filter: 21884
-> Hash (cost=33938.80..33938.80 rows=92912 width=17) (actual time=1549.103..1549.103 rows=80351 loops=3)
Buckets: 65536 Batches: 2 Memory Usage: 2557kB
-> Seq Scan on topics (cost=0.00..33938.80 rows=92912 width=17) (actual time=0.010..1492.606 rows=80351 loops=3)
Filter: ((deleted_at IS NULL) AND visible AND ((archetype)::text <> 'private_message'::text))
Rows Removed by Filter: 216751
-> Index Scan using posts_search_pkey on post_search_data (cost=0.43..0.96 rows=1 width=383) (actual time=0.017..0.017 rows=0 loops=855836)
Index Cond: (post_id = posts_1.id)
Filter: (search_data @@ '''price'':*ABD'::tsquery)
Rows Removed by Filter: 1
-> Hash (cost=9.43..9.43 rows=43 width=9) (actual time=0.059..0.059 rows=43 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 10kB
-> Seq Scan on categories (cost=0.00..9.43 rows=43 width=9) (actual time=0.007..0.045 rows=43 loops=1)
SubPlan 1
-> Result (cost=0.00..0.01 rows=1 width=4) (actual time=0.000..0.000 rows=0 loops=191436)
One-Time Filter: (categories.search_priority = 1)
-> Index Scan using index_posts_on_topic_id_and_post_number on posts (cost=0.43..8.45 rows=1 width=1169) (actual time=1.435..1.435 rows=1 loops=6)
Index Cond: ((topic_id = topics.id) AND (post_number = (min(posts_1.post_number))))
Filter: (deleted_at IS NULL)
Planning time: 3.508 ms
Execution time: 20541.411 ms
(46 rows)`
「いいね！」 1
データベースの合計サイズは 8 GB 未満ですか？可能な限り多くのデータを RAM に収めるようにしてください。
これは遅くなります。ディスクがネットワークマウントの場合は、さらに悪化します。
また、上記の私の返信にある調整案もご確認ください。
「いいね！」 8
@Jumanji 月間アクセス数が数百万を超える、Discourse を採用している高トラフィックなフォーラムサイトのリンクを共有していただけますか？
私は Discourse チームのメンバーではありませんが、検索で見つけました。
「いいね！」 1
24 GB です。インスタンスに割り当てられている RAM よりも明らかに大きいです。
場合によっては、大規模な移動後に vacuum analyze を実行するとパフォーマンスが向上することがあります。
また、AWS をご利用の場合、RDS を使用されていますか？もしそうでなければ、なぜ使用していないのでしょうか？
「いいね！」 5
ありがとうございます。はい、それを実行し、RDS 上で動作しています。
17件の投稿が新しいトピックに分割されました：投稿に数秒かかる