fix(backend): DBフォールバック有効時、複数のFTTソースから取得するタイムラインで取得漏れが起きる現象の修正 #13495

tai-cha · 2024-03-02T06:28:34Z

What

FTTにおいて複数のソースからノートを取得する際に複数ソースの中で（そのソース内の）最古のノートが（複数ソースの中で）一番新しいものまでを返すように制限した
FTTにおいてDBフォールバックを有効にしている際に、ノートがないソースがある場合はDBにフォールバックするように変更した

Why

（たくさん遡ると起きやすい）
複数のTLソースの中でも保存されている期間に差があり、取得できないノートが発生してしまうため

Fix: #13488
（#13488から再掲）

Additional info (optional)

Checklist

Read the contribution guide
Test working in a local environment
(If needed) Add story of storybook
(If needed) Update CHANGELOG.md
(If possible) Add tests

codecov · 2024-03-02T06:30:49Z

Codecov Report

Attention: Patch coverage is 7.69231% with 12 lines in your changes missing coverage. Please review.

Project coverage is 40.18%. Comparing base (32651ab) to head (48232ca).
Report is 8 commits behind head on develop.

Files	Patch %	Lines
.../backend/src/core/FanoutTimelineEndpointService.ts	8.33%	11 Missing ⚠️
...es/backend/src/server/api/endpoints/users/notes.ts	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #13495      +/-   ##
===========================================
+ Coverage    40.08%   40.18%   +0.10%     
===========================================
  Files         1524     1524              
  Lines       188758   188768      +10     
  Branches      3465     2619     -846     
===========================================
+ Hits         75656    75854     +198     
+ Misses      112528   112372     -156     
+ Partials       574      542      -32

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

github-actions · 2024-03-02T06:30:52Z

このPRによるapi.jsonの差分

差分はこちら

Get diff files from Workflow Page

u1-liquid · 2024-03-15T02:47:39Z

HTL/STLはこの実装で大丈夫そうですが、タイムラインの更新が緩やかなサーバー、ユーザー個人のタイムラインの場合FTTを利用できずDBにフォールバックしてしまう割合が高くなりそうという懸念点がありそうです

FTT実装当時しゅいろさんに共有した取得漏れの例ですが

ユーザープロフィールのFTTのlimitを4とした時
あるユーザーが
今日は一般のノートを5件、リプライを0件投稿
昨日は一般のノートを5件、リプライを1件投稿したとすると
今日時点でFTTに残るノートは今日の最新の4件、昨日のリプライ1件で
スクロールして遡ると今日の4件の後すぐ昨日のリプライが見えて、その後ずっと昨日のリプライ以降のノートが見えてくるはず
今日のノート1件が表示されないという結果になってしまう

この実装だとこのユーザーは一度もファイルをアップロードしていないため常にDBにフォールバックされてしまいそうです。
すぐフォールバックさせる代わりに次のページング処理で↓の部分をもう一度照会するとフォールバックなしでも解決できそうですがどうでしょう

tai-cha · 2024-03-15T12:00:41Z

確かにそうですね！（現在多忙な上に諸事情がありすぐに反映できないかもしれないですがそのほうがパフォーマンス上良さそうなので試してみます）

（ユーザーTLもこの実装を利用しているのをやや忘れていました…）

tai-cha · 2024-03-22T16:28:14Z

少し思考が散らかっているのでメモ書きです

（※ここでのDBはPostgreSQLないしRDBを指す）

改めて考えてみているけど一度もファイルをアップロードしていないかどうかはDBを見てみないとわからなくて（FTTのキャッシュがredisの内容が飛ぶなどの理由で不十分な場合もある）、もう一度残った部分のFTTを参照するだけではDBには存在するのにFTTには存在しないノートがあるかどうか（つまり取得漏れがあるかどうか）がわからない

FTTにないだけでDBにはノートがあるケースは割とredisが揮発するものである前提からして（またCacheにMaxが定められているのも含め）起きそうなので悩ましい

全くDBを参照させないというのは仕組み上難しそう（これがそもそも複数のTLのキャッシュが残っている幅の差分の間でフォールバックがきちんと効くようにするPRという趣旨なのもある）

そのFTTソースに対応する条件のノートがDBに本当に存在しないかを確かめるには少なくともCOUNT句か何かでDBを見て比較自体はしないと結局問題が解決しない気がする

もう一度FTTのうちのページングで取得するだけでは取得漏れをきちんと漏らさないことは実現不可能なのでは…？

tai-cha · 2024-03-22T16:32:25Z

そもそもFTTに含まれていないノートをDBから持ってくるという趣旨なのでFTTが空な場合にフォールバックするのは自然ではある気がしてきた、ただ一度もファイルを投稿していなければFTTが空で常にフォールバックが起こってしまう（DBへの負荷を減らすためのFTTなのに効果が弱くなる）というのは理解できるのでどうやって落とし所つけようかしら…

tai-cha · 2024-03-22T17:18:16Z

タイムラインが穏やかなサーバーでDBへのフォールバック頻度が増えることはあまり大きな問題ではない気がする、それだけアクティブなユーザーも少なくなることが予想されるので（また、DBフォールバックは無効にもできる）

むしろLTLが緩やかなサーバーではより取得漏れが起きやすく深刻

フォローが0人のときもSTLで同様に毎回フォールバックが起きる問題が発生してしまう

フォールバック回数抑えつつ取得漏れをなくすにはよりもっと根本的なところを変える必要がある…？

tai-cha · 2024-06-15T08:49:48Z

~~なんかいけそうな気がしてきたので改良するか~~
なんでいけそうな気がしてきたか忘れた

… fix-stl-note-fetch

tai-cha · 2024-07-25T07:14:56Z

タイムラインの更新が緩やかなサーバー、ユーザー個人のタイムラインの場合FTTを利用できずDBにフォールバックしてしまう割合が高くなりそうという懸念点がありそうです

ユーザーTLではDBにフォールバックさせないようにしました（これは取得漏れをさせずDBフォールバックをしない実装するのが難しいため）
そのうえでタイムラインが緩やかなサーバーに関する懸念に関してはそもそもDBへの参照回数もユーザー数が少なければ落ちるのであまり問題ないと考えています

tai-cha · 2024-07-25T07:18:34Z

FanoutTimelineNameごとにdbFallbackの手段があれば単純にその区間の行数のcountをしてくればいいのでもう少し楽になりそうではある

anatawa12 · 2024-07-31T16:37:56Z

packages/backend/src/core/FanoutTimelineEndpointService.ts

+		let shouldFallbackToDb = ps.useDbFallback &&
+			(ps.preventEmptyTimelineDbFallback !== true && redisResult.length > 1 && redisResult.some(ids => ids.length === 0));


デフォルト値がこっちのほうがわかりやすそう

Suggested change

let shouldFallbackToDb = ps.useDbFallback &&

(ps.preventEmptyTimelineDbFallback !== true && redisResult.length > 1 && redisResult.some(ids => ids.length === 0));

ps.preventEmptyTimelineDbFallback ??= false;

let shouldFallbackToDb = ps.useDbFallback &&

(!ps.preventEmptyTimelineDbFallback && redisResult.length > 1 && redisResult.some(ids => ids.length === 0));

あとはtrueのときに無効化するというのがちょっと分かりづらい気がするので

Suggested change

let shouldFallbackToDb = ps.useDbFallback &&

(ps.preventEmptyTimelineDbFallback !== true && redisResult.length > 1 && redisResult.some(ids => ids.length === 0));

ps.fallbackToDbIfHasEmptyTimeline ??= true;

let shouldFallbackToDb = ps.useDbFallback &&

(ps.fallbackToDbIfHasEmptyTimeline && redisResult.length > 1 && redisResult.some(ids => ids.length === 0));

とかのほうがいいのかもしれないと思いました

このPR作成時に「中身が存在しないTLがある場合はDBを参照しに行く方が取得漏れがなくなるので妥当」という意味でprevent...をtrueにするという命名を行っていたけれどtrueの時に無効化はこの命名でも、紛らわしいか…？（ちょっと上の案、下の案、あるいはやらない、ほかの案などもそれぞれ考えてみます）

anatawa12 · 2024-07-31T17:32:29Z

現在のmasterにこれを取り込むと #13978 でSTLに追加したlocalTimelineWithReplyTo:${userId}によりSTLの一部の(db fallbackすると落ちるタイプの)テストが落ちることが確認されています (niri-la#217 等が実際に落ちてる事例になります)

これの対策にもなり、またredistimelineがからになってしまってすべてのノートをdbから取得してしまう問題の対策として、各種TL要素のうちuserTimeline${string}:${userId}や${timeline}WithReplyTo:${userId}のようにユーザに関わるものについて、ユーザがアカウントに登録した際に一つだけダミーのデータを追加するというのはどうでしょうか。

懸念点としてはノートを一切しない人のためにuserTimeline系をRedisに保存することになることだと思います。

tai-cha · 2024-08-19T07:04:34Z

Note:

現在のmasterにこれを取り込むと #13978 でSTLに追加したlocalTimelineWithReplyTo:${userId}によりSTLの一部の(db fallbackすると落ちるタイプの)テストが落ちることが確認されています (niri-la#217 等が実際に落ちてる事例になります)

niri-la@92a55ad のようにテスト環境で挙動を回避すれば問題なさそうなのは確認したし正しそう

これの対策にもなり、またredistimelineがからになってしまってすべてのノートをdbから取得してしまう問題の対策として、各種TL要素のうちuserTimeline${string}:${userId}や${timeline}WithReplyTo:${userId}のようにユーザに関わるものについて、ユーザがアカウントに登録した際に一つだけダミーのデータを追加するというのはどうでしょうか。

これは確かにこれから作成するユーザに関してはユーザー作成時にやれば解決はできるけど、既存ユーザーのうち対象となるノートが一個もない人では引き続き同じことが起きる上にそれを既存ユーザーにまで適用しようと思うとデータを全部作ってあげるのが大変そうな気が…？（純粋に参照されたときになければ作るでいいかもしれないけど）

anatawa12 · 2024-08-19T07:10:07Z

参照したときに作るか古い人はある程度負荷を許容するか、サーバー規模で必要ならバッジを叩いてもらうかあたりを考えてました

ある程度期間参加してる人はFTTに一切ノートがないってことは少なさそうなのでそんなに発生するのかなという気がしています

tai-cha · 2024-08-19T07:31:36Z

Redis自体の内容が飛んだ場合や大規模サーバーで休眠ユーザーが多い場合とかはある程度考えた方がいいかも（実際割合どれぐらいいるのかわからないので有識者が意見してくれる方がありがたい）

kozakura913 · 2024-08-19T18:52:03Z

DBに1件も無い事を示すマーカーをredisに埋め込む事を思いついた。
マーカーが記録されてるとredisが揮発していない、かつDBにもデータが無い事がDBを叩かず認識できるはず。
DBフォールバックした時に無ければredisにマーカー立てる感じで
マーカーがTTL落ちしても通常のDBフォールバックが起こるはずだから破損しないはず？

tai-cha and others added 2 commits March 2, 2024 15:23

fix(backend): DBフォールバック有効時、複数のFTTソースから取得するタイムラインで取得漏れが起きる現象の修正

82bec76

Merge branch 'develop' into fix-stl-note-fetch

0c65b80

github-actions bot added the packages/backend Server side specific issue/PR label Mar 2, 2024

Update CHANGELOG.md

5615675

tai-cha marked this pull request as ready for review March 2, 2024 06:44

tai-cha mentioned this pull request Mar 2, 2024

Feat: HTLとSTLをローカルのみに絞り込む機能 tai-cha/misskey#3

Open

5 tasks

tai-cha and others added 2 commits March 7, 2024 01:55

Fix timeline fetch when using sinceId

4a8ffe2

Merge branch 'develop' into fix-stl-note-fetch

d3228d5

This was referenced Apr 21, 2024

ぶいみみリレータイムラインにおいて、DBフォールバックの内容が正しくない可能性がある niri-la/misskey.niri.la#178

Closed

fix db fallback with FTT niri-la/misskey.niri.la#184

Merged

anatawa12 mentioned this pull request Jul 8, 2024

fix(backend): fallback if sinceId is older than the oldest in cache when using FTT #14061

Merged

5 tasks

tai-cha added 4 commits July 25, 2024 14:23

Merge branch 'develop' of https://github.com/misskey-dev/misskey into…

6cc0138

… fix-stl-note-fetch

Fix: shouldFallbackToDbがすでにtrueの場合にそれが無視される

685fc2b

Refactor: const naming

3564bf5

ユーザーTLではFTTのソースが空の際にDBにFallbackしないように

48232ca

anatawa12 reviewed Jul 31, 2024

View reviewed changes

zyoshoka mentioned this pull request Aug 15, 2024

チャンネルに発言した日以降のノートが上手く表示されない #14413

Open

1 task

tai-cha mentioned this pull request Aug 19, 2024

2024.8.0-nade.1.5.7 nadesskey/nadesskey#52

Merged

5 tasks

kozakura913 mentioned this pull request Aug 19, 2024

ソーシャルTLを遡りすぎるとローカル投稿しか出てこない yojo-art/cherrypick#341

Open

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(backend): DBフォールバック有効時、複数のFTTソースから取得するタイムラインで取得漏れが起きる現象の修正 #13495

fix(backend): DBフォールバック有効時、複数のFTTソースから取得するタイムラインで取得漏れが起きる現象の修正 #13495

tai-cha commented Mar 2, 2024 •

edited by kakkokari-gtyih

Loading

codecov bot commented Mar 2, 2024 •

edited

Loading

github-actions bot commented Mar 2, 2024 •

edited

Loading

u1-liquid commented Mar 15, 2024

tai-cha commented Mar 15, 2024 •

edited

Loading

tai-cha commented Mar 22, 2024 •

edited

Loading

tai-cha commented Mar 22, 2024 •

edited

Loading

tai-cha commented Mar 22, 2024 •

edited

Loading

tai-cha commented Jun 15, 2024 •

edited

Loading

tai-cha commented Jul 25, 2024 •

edited

Loading

tai-cha commented Jul 25, 2024

anatawa12 Jul 31, 2024

tai-cha Aug 19, 2024

anatawa12 commented Jul 31, 2024

tai-cha commented Aug 19, 2024

anatawa12 commented Aug 19, 2024

tai-cha commented Aug 19, 2024

kozakura913 commented Aug 19, 2024

		let shouldFallbackToDb = ps.useDbFallback &&
		(ps.preventEmptyTimelineDbFallback !== true && redisResult.length > 1 && redisResult.some(ids => ids.length === 0));

fix(backend): DBフォールバック有効時、複数のFTTソースから取得するタイムラインで取得漏れが起きる現象の修正 #13495

Are you sure you want to change the base?

fix(backend): DBフォールバック有効時、複数のFTTソースから取得するタイムラインで取得漏れが起きる現象の修正 #13495

Conversation

tai-cha commented Mar 2, 2024 • edited by kakkokari-gtyih Loading

What

Why

Additional info (optional)

Checklist

codecov bot commented Mar 2, 2024 • edited Loading

Codecov Report

github-actions bot commented Mar 2, 2024 • edited Loading

u1-liquid commented Mar 15, 2024

tai-cha commented Mar 15, 2024 • edited Loading

tai-cha commented Mar 22, 2024 • edited Loading

tai-cha commented Mar 22, 2024 • edited Loading

tai-cha commented Mar 22, 2024 • edited Loading

tai-cha commented Jun 15, 2024 • edited Loading

tai-cha commented Jul 25, 2024 • edited Loading

tai-cha commented Jul 25, 2024

anatawa12 Jul 31, 2024

Choose a reason for hiding this comment

tai-cha Aug 19, 2024

Choose a reason for hiding this comment

anatawa12 commented Jul 31, 2024

tai-cha commented Aug 19, 2024

anatawa12 commented Aug 19, 2024

tai-cha commented Aug 19, 2024

kozakura913 commented Aug 19, 2024

tai-cha commented Mar 2, 2024 •

edited by kakkokari-gtyih

Loading

codecov bot commented Mar 2, 2024 •

edited

Loading

github-actions bot commented Mar 2, 2024 •

edited

Loading

tai-cha commented Mar 15, 2024 •

edited

Loading

tai-cha commented Mar 22, 2024 •

edited

Loading

tai-cha commented Mar 22, 2024 •

edited

Loading

tai-cha commented Mar 22, 2024 •

edited

Loading

tai-cha commented Jun 15, 2024 •

edited

Loading

tai-cha commented Jul 25, 2024 •

edited

Loading