いいねとその通知機能をDynamoDBで設計したら思ったよりムズい - エムスリーテックブログ

【Unit4 ブログリレー4日目】 こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 今回は、SNSではごく一般的ないいねとその通知機能をDynamoDBを利用して実装したら思ったより大変だったので、その詳細をご紹介します。 キャナルシティ劇場は、福岡県福岡市博多区の複合商業施設「キャナルシティ博多」のシアタービル最上階に位置する劇場。本文には特に関係ありません。 m3ラウンジ m3ラウンジのいいねとその通知の要件 RDBで実装したらどうなるか いいね機能 通知機能 DynamoDBで実装する いいね機能 通知機能 いいねする いいねを取り消す 通知を表示する 未読の通知の取得 未読の通知数 未読の通知を既読にする テーブル設計むずい PKとSKに何を選ぶか LSIは途中から作れない DynamoDBをローカルで動かして設計する まとめ We are h

[turanukimaru]

真面目な記事に悪いが、いいね！の数は正確でなくても誰も困らない。読んですぐ既読通知が「来なくても」割と困らない。良いね数カラムを作ってロック抜きで更新して投降後1分毎に再集計するとかでも意外と困らない

[non_117]

GSIを使うと少ないテーブル数で実現できそう。例: いいねテーブルにいいねした人, された人, 既読時刻を持って、GSIのPK:いいねされた人ID, SK:既読時刻にする。ユースケースは深く読めてないので間違ってたらすみません。

[funwarioisii]

最近通知を MySQL で作ったから式年遷宮時の参考にしよう

[umai_bow]

DynamoDBは要件固まらないと設計できないのはマジでそう。たまに「スタートアップで DynamoDBで手軽に〜」みたいなの見るけど、ビジネスが固まってない現場でマジでそれはない

[taguch1]

これ系はトランザクションいらん設計にする。例え正確な数字が欲しくてもリアルタイムではやらないかな。

[txjp]

結果整合性までの保証で十分であるということに一旦して、書き込み時間の許容幅を広げられないかな。いや知らんけど

[taiyow]

ddbのトランザクションはRDBのそれとは違って、並列更新されてたら失敗する仕様なので、同じコメントにいいねをみんなでつけると失敗しあって辛いことになる。いいねはTxの外で集計してずれてもokにするのが良い。

[masatotoro]

いいねから通知までを“TransactWriteItems”でトランザクション管理。

[kiririmode]

RDBを使うとどうしてもスケールが難しくなる、コメントへの「いいね」とそれに伴うユーザ通知をDynamoDBを使って設計した例

[versatile]

DynamoDB は結構扱いがむずいイメージ。

[surume000]

なるほど

[otihateten3510]

俺はFirestoreでやろうとして諦めた

[onesplat]

何がムズいのか最初に書けや。ダラダラダラダラ前提が長い割に最後まで読んでも結局何が難しいのかパリッとせんし。多分まだ頭の中とっちらかってんねやろな。言語化できないうちは何やっても身にならんで。

[taruhachi]

『DynamoDBでは利用ケースを十分に精査した上でテーブル設計が必要』そうなんだよなぁ。早すぎる最適化に陥るリスクはある。

[hase0510]

タイトルがサラダ記念日っぽいと思ったんだけど五七五七七にはなってなかった

[kondoly]

ユーザーとコメントのリレーションに、関係性としていいねの有無にすればよいのでは。

[aox]

医師免許がないとアカウント作れないSNSってハードル高すぎませんか、実習が必要なので大学に入らないとまずダメですし

[south-radburn-2023]

m3はいいねがポイントに変換されるのかな。タイムラインでのいいね表示はどういうクエリなんだろ

[so-apps]

参考になる事例。