NoSQLの付き合い方

2022.06.30 LT会 江藤さん発表資料

Transcript

1. NoSQLのテーブル設計
2. ある時期のNoSQL
4. NoSQL is 素晴らしい • 早い + 軽量 ◦ 分散処理 • シンプル ◦ 巨大なjson = 扱いやすい ◦ 学習コストも低い • 柔軟性が高い ◦ json形式で巨大なデータも突っ込める
5. 今のNoSQL
7. NoSQL is 辛い • 検索が貧弱 ◦ 絞り込みの制約が辛い • トランザクション ◦ 保証できないもの ▪ 昔NoSQLでトランザクションを実現する黒魔術があった • 拡張性がありすぎる ◦ 同じテーブルでも 値の形が違ったりする
8. つまりNoSQLには 特有の向き合い方が必要
9. 今回はテーブル設計(dynamo)のお話
10. • table ◦ RDBのテーブルに相当する。この中にデータを入れる • parimary key ◦ データを一意に絞るためにキーで partion key, sort key がある ▪ 後述 • Attribute ◦ primary key 以外のカラムのこと ◦ dynamoはカラムに対して型を指定できる。 • index ◦ GSI, LSI があるが、目的は検索条件を増やすため ◦ 今回はGSIを使っている(以下indexと呼称) 基礎概念
11. • partion key(pk), sort key(sk)を使ってテーブルを作る ◦ pkは一意なIDでこれで検索をかける ▪ PKを指定したらひもづく Attributeが全て取得できる ◦ skはソートに使うキーで range検索やdescなどができる ▪ skだけで検索を行うことはできない。 • indexでwhere対象を増やす ◦ indexをカラムに当てるとそのカラムで検索がかけられるようになる • 検索上限は取得サイズで決まる ◦ 一度の検索で最大1MG dynamoのクエリ制約
12. pk
13. index
14. クエリパターンから考えるしかない!
15. サンプル(ユーザーの記事投稿サービス) • ユーザーの一覧情報を取得したい • ユーザーの一覧を登録した順にソートしたい • ユーザーの記事一覧を最新順で取得したい • ユーザーの記事一覧でいいねが多い順に取得したい
16. キーの設計 概念名 PK SK user user_name register_at post user_name post_at
17. サンプル(ユーザーの記事投稿サービス) • ユーザーの一覧情報を取得したい ◦ dynamoはデフォルトで全件取得があるからいけそう • ユーザーの一覧を登録した順にソートしたい • ユーザーにひもづく記事一覧を最新順で取得したい • ユーザーにひもづく記事一覧でいいねが多い順に取得したい
18. テーブル設計 PK SK Attribute user user_nam e(john) resgiter_at (20210312 ) birth_day (1月2日) profile (こんにち わ) post user_nam e(john) post_at (20221203 ) title (記事1) content (テスト) like_count (12)
19. サンプル(ユーザーの記事投稿サービス) • ユーザーの一覧情報を取得したい ◦ dynamoはデフォルトで全件取得があるからいけそう • ユーザーの一覧を登録した順にソートしたい ◦ userテーブルでregister_atをsortkeyにしてるからいけそう • ユーザーにひもづく記事一覧を最新順で取得したい ◦ postテーブルでpost_atをsort keyにしてるからいけそう • ユーザーにひもづく記事一覧でいいねが多い順に取得したい
20. indexの設計 PK SK Attribute post user_nam e like_count title content post_at
21. サンプル(ユーザーの記事投稿サービス) • ユーザーの一覧情報を取得したい ◦ dynamoはデフォルトで全権取得があるからいけそう • ユーザーの一覧を登録した順にソートしたい ◦ userテーブルでregister_atをsortkeyにしてるからいけそう • ユーザーにひもづく記事一覧を最新順で取得したい ◦ postテーブルでpost_atをsort keyにしてるからいけそう • ユーザーにひもづく記事一覧でいいねが多い順に取得したい ◦ index貼って,user_nameから検索がかけられる ◦ like_countをskにしてるからいけそう
22. 完
23. 最後に
24. クエリパターンを最初に考えましょう