【供養】DynamoDBでも部分一致検索したかった

@Ya8 2024

Transcript

1. Copyright © RevComm Inc. 【供養】DynamoDBでも部分一致検索したかった 2024.03.15＠Ya8 大谷紗良
2. Copyright © RevComm Inc. • 大谷 紗良（Sara Ohtani） • Software Engineer, Backend ◦ 　 • RevComm Inc. • 　 @sara_ohtani_mt2 • #ya8 #ya8B 自己紹介 2
3. Copyright © RevComm Inc. 練馬で祭りを！？ 😳 祭りやってるなぁと思って来ました 3
4. Copyright © RevComm Inc. awsのNoSQL DB、DynamoDBはスピードやコストの点で期待が高い でもなかなか利用シーンが限られているようで・・・ でもでもよく調べると色々できそうで・・・ でもでもでも試したらやはりちょっとできなかった、という話 今日の話 この資料は slide share公開済みです https://tech.revcomm.co.jp/partial-match-search-with-dynamodb 4
5. Copyright © RevComm Inc. DynamoDB使ったことあるひとー？ 質問 5
6. Copyright © RevComm Inc. DynamoDBのGSI使ったことあるひとー？ (GSI: グローバルセカンダリインデックス) 質問 6
7. Copyright © RevComm Inc. • DynamoDBは気になるけど 実際に使ってサービス開発をしたことはない方 • シンプルにKeyと一致するデータを取得したことはあるけど DynamoDBのさらなる可能性について知りたい方 想定聴講者 7
8. Copyright © RevComm Inc. 今日のみんなのGOAL DynamoDBで できそうなこと DynamoDBでできなさそうなこと 8
9. Copyright © RevComm Inc. 今日のみんなのGOAL DynamoDBでできないこと DynamoDBで できそうなこと DynamoDBで できること 9
10. Copyright © RevComm Inc. 1. 今回検証するにいたった背景 2. DynamoDBでできることできないこと 3. テーブルとデータ取得コードの例 4. まとめ アジェンダ 10
11. Copyright © RevComm Inc. 1. 今回検証するにいたった背景 2. DynamoDBでできることできないこと 3. テーブルとデータ取得コードの例 4. まとめ アジェンダ 11
12. Copyright © RevComm Inc. コミュニケーションを再発明し 人が人を想う社会を創る 12
13. Copyright © RevComm Inc. 電話営業や顧客応対を自動録音、AIが文字 起こし、解析・可視化することにより、顧 客と担当者が「何を」「どのように」話し ているか分からない、というブラックボッ クス問題を解消し、商談獲得率・成約率の 向上やセルフコーチングを後押しします。 Service トーク解析AI 13
14. Copyright © RevComm Inc. 連絡先情報を一覧で表示する画面があり キーワード検索する機能がある 電話機能があり、電話帳機能がある 14
15. Copyright © RevComm Inc. 連絡先情報を一覧で表示する画面があり キーワード検索する機能がある 電話機能があり、電話帳機能がある リニューアル中！ 15
16. Copyright © RevComm Inc. データ量の多さとそれを起因とする遅さ • 1テナントにつき最大50万件の連絡先 ※現在最大75万件 • できれば1秒以下で取得したい 📞　🐢...　📇　 リニューアルするにあたって意識している課題 16
17. Copyright © RevComm Inc. リニューアルにあたり、DBの分割も検討している このあたりの話は盛り上がりすぎてしまうので今日はしない とにかく検討しているんだ！！！！！ そして何を使うか改めて考えている DB選定を改めてする 17
18. Copyright © RevComm Inc. 速い！安い！楽！（※） DynamoDBの魅力のイメージ 18
19. Copyright © RevComm Inc. データ規模にかかわらず処理速度が速いらしい 速い速いと聞くけど実感としてどの程度速いかわかってない これを機に知りたいという動機もあって検証してみた DynamoDBを使って早くならないものか・・・ 19
20. Copyright © RevComm Inc. 1. 今回検証するにいたった背景 2. DynamoDBでできることできないこと 3. テーブルとデータ取得コードの例 4. まとめ アジェンダ 20
21. Copyright © RevComm Inc. DynamoDBのデータ { "id": { "N": “1” }, "name": { "S": "John" }, "type": { "S": "dog" } } Partition Key Sort Key (※option) その他 Attributes id name 1 John type dog item 21
22. Copyright © RevComm Inc. Scan検索でなくQuery検索を使う • Query検索は全体のデータ量にあまり影響を受けず速い • しかしQuery検索は柔軟な検索ができない • 余談 ◦ Query検索で一度に取得できるデータは1MBまで ◦ 一度で取得できなかったときには LastEvaluatedKeyに値が入ってくる 速さを活かすためには 22
23. Copyright © RevComm Inc. Scan検索でなくQuery検索を使う • Query検索は全体のデータ量にあまり影響を受けず速い • しかしQuery検索は柔軟な検索ができない • 余談 ◦ Query検索で一度に取得できるデータは1MBまで ◦ 一度で取得できなかったときには LastEvaluatedKeyに値が入ってくる 速さを活かすためには 23
24. Copyright © RevComm Inc. Keyで絞り込んで該当itemが取得できる DynamoDBのQuery検索とは Partition Key Sort Key その他Attributes id name 1 John type dog ・・・ ・・・ ・・・ ・・・ ・・・ 2 Paul cat ・・・ ・・・ item 24
25. Copyright © RevComm Inc. Keyで絞り込んで該当itemが取得できる DynamoDBのQuery検索 Partition Key Sort Key その他Attributes id name 1 John type dog ・・・ ・・・ ・・・ ・・・ ・・・ 2 Paul cat ・・・ ・・・ item Query検索の場合、絞り込み条件として Partition Keyは必ず指定しなければならない 完全一致検索のみ 25
26. Copyright © RevComm Inc. Keyで絞り込んで該当itemが取得できる DynamoDBのQuery検索 Partition Key Sort Key その他Attributes id name 1 John type dog ・・・ ・・・ ・・・ ・・・ ・・・ 2 Paul cat ・・・ ・・・ idわからないけどnameが Johnのデータが欲しいな 26
27. Copyright © RevComm Inc. Keyで絞り込んで該当itemが取得できる DynamoDBのQuery検索 Partition Key Sort Key その他Attributes id name 1 John type dog ・・・ ・・・ ・・・ ・・・ ・・・ 2 Paul cat ・・・ ・・・ idわからないけどnameが Johnのデータが欲しいな 27
28. Copyright © RevComm Inc. Keyで絞り込んで該当itemが取得できる DynamoDBのQuery検索 Partition Key Sort Key その他Attributes id name 1 John type dog ・・・ ・・・ ・・・ ・・・ ・・・ 2 Paul cat ・・・ ・・・ item Sort KeyはPKを指定した上であれば 「EQ | LE | LT | GE | GT | BEGINS_WITH | BETWEEN」で絞り込める （Sort Keyの指定はオプション） 28
29. Copyright © RevComm Inc. Keyで絞り込んで該当itemが取得できる DynamoDBのQuery検索 Partition Key Sort Key その他Attributes id name 1 John type dog ・・・ ・・・ ・・・ ・・・ ・・・ 2 Paul cat ・・・ ・・・ item KeyとKey以外はQuery検索で扱う上で 全く別物といっていい 29
30. Copyright © RevComm Inc. もっと柔軟に検索したい！！！ 😵 でも・・・ 30
31. Copyright © RevComm Inc. そこで GSI じゃ 󰩂 テーブルに対して自由に追加できるインデックスを使うんじゃ 31
32. Copyright © RevComm Inc. 1item内にフラットに情報を並べるのではなく、 情報を縦に持つ GSIを活用する前提の設計の考え方 PK, GSI-SK Sort Key その他Attributes ID DataType 1 Name DataValue John ・・・ ・・・ ・・・ ・・・ ・・・ 1 Type dog ・・・ ・・・ GSI-PK Primary Table 32
33. Copyright © RevComm Inc. 1item内で横に情報を持つイメージ DynamoDBのQuery検索とは Partition Key Sort Key その他Attributes id name 1 John type dog ・・・ ・・・ ・・・ ・・・ ・・・ 2 Paul cat ・・・ ・・・ item 33
34. Copyright © RevComm Inc. 1item内にフラットに情報を並べるのではなく、 情報を縦に持つ GSIを活用する前提の設計の考え方 PK, GSI-SK Sort Key その他Attributes ID DataType 1 Name DataValue John ・・・ ・・・ ・・・ ・・・ ・・・ 1 Type dog ・・・ ・・・ GSI-PK Primary Table 34
35. Copyright © RevComm Inc. 1item内にフラットに情報を並べるのではなく、 情報を縦に持つ 使うとどうなる？ GSI-PK GSI-SK Projected Attributes DataValue ID John 1 DataType Name ・・・ ・・・ ・・・ ・・・ ・・・ dog 1 Type ・・・ ・・・ (PK) dog 3 Type GSI Table 35
36. Copyright © RevComm Inc. Query検索の考え方は同じ 使うとどうなる？ GSI-PK GSI-SK Projected Attributes DataValue ID John 1 DataType Name ・・・ ・・・ ・・・ ・・・ ・・・ dog 1 Type ・・・ ・・・ (PK) dog 3 Type GSI Table idわからないけどnameが Johnのデータが欲しいな ⭕ 36
37. Copyright © RevComm Inc. Query検索の考え方は同じ 使うとどうなる？ GSI-PK GSI-SK Projected Attributes DataValue ID John 1 DataType Name ・・・ ・・・ ・・・ ・・・ ・・・ dog 1 Type ・・・ ・・・ (PK) dog 3 Type GSI Table dogのデータ・・・⭕ 37
38. Copyright © RevComm Inc. 50万件の連絡先を縦に展開してみたら サンプルデータは2000万件ほどに 😇 縦に持つということはデータ量はさらに増える・・・ 38
39. Copyright © RevComm Inc. それでも1秒未満で検索できた！※ 🚀 爆速 39
40. Copyright © RevComm Inc. Primary TableのPK以外での検索はできた でもKeyの検索だと部分一致検索ができない😢 where name like ‘%hoge%’ … 40
41. Copyright © RevComm Inc. それはそう でも部分一致検索したい 完全一致か 前方一致じゃ だめですよね？ 😉 PO: それはちょっと・・・ 😉 41
42. Copyright © RevComm Inc. DynamoDBで部分一致検索はできないのか？ 42
43. Copyright © RevComm Inc. Key検索＋α ならできそう？ なんかできそう・・・？ https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Query.FilterExpression.html 43
44. Copyright © RevComm Inc. Key検索＋α ならできそう？ なんかできそう・・・？ https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Query.FilterExpression.html できるけどScan同様、 データ量に応じて遅くなることがわかった 44
45. Copyright © RevComm Inc. フィルター条件を指定するとデータ量に応じて遅くなる 実質Scan 45
46. Copyright © RevComm Inc. 残念ながら要件を満たせなかったので 今回はDynamoDB採用を見送りました でも良いシチュエーションがあったら全然使いたい 結果としては 46
47. Copyright © RevComm Inc. どんなシチュエーションならよかったか？ 47
48. Copyright © RevComm Inc. 1. データ抽出条件が完全一致、あるいは前方一致で良い 2. データ件数が多く、今後もさらに増加が予想される 3. アクセスパターンや要件がはっきりしている 4. データ検索する際の絞り込み条件となる項目が多くない 5. 基本的にテーブルをjoinする必要がない 6. 並び順は問わない DynamoDBがマッチすると思われるユースケース 48
49. Copyright © RevComm Inc. これらの条件と一致するサンプルケースで設計してみる 49
50. Copyright © RevComm Inc. ここで甘い飲み物を飲みます 50
51. Copyright © RevComm Inc. 後半！🛎 51
52. Copyright © RevComm Inc. 1. 今回検証するにいたった背景 2. DynamoDBでできることできないこと 3. テーブルとデータ取得コードの例 4. まとめ アジェンダ 52
53. Copyright © RevComm Inc. 1. 業務分析とデータのモデリング 2. アクセスパターン設計 3. テーブルとインデックス設計 4. クエリ条件設計 DynamoDBのテーブル設計の流れ 53
54. Copyright © RevComm Inc. 中の人 @_kensh さんより https://speakerdeck.com/_kensh/dynamodb-design-practice?slide=49 54
55. Copyright © RevComm Inc. 業務分析 RDRAでやってみました 誰に価値を与え、 そのために誰が関わるのか ? 関わる人が価値を出すための 仕事の流れ 55
56. Copyright © RevComm Inc. データモデルの形に整理 ※実際のシステムとは異なります 56
57. Copyright © RevComm Inc. アクセスパターン→ユースケースリストを出す システムに関わる登場人物と システムの接点 誰がどんなI/Fで何を？ 57
58. Copyright © RevComm Inc. テーブル・インデックス設計 58
59. Copyright © RevComm Inc. テーブル・インデックス設計 RDBならテーブル分割するようなものもキャパシティを効率的に使うため できるだけ1つのテーブルで表現する データを重複なく保管し、 ホットパーティションが発生しないようにするための PK, SKを設定 59
60. Copyright © RevComm Inc. 特定のデータ範囲に対してアクセスが集中すると 「ホット」なパーティションが作成される場合がある これにより、スロットリングが発生することや、 プロビジョニングされた I/O 容量が効率的に 使用されないことがある ホットパーティションとは 60
61. Copyright © RevComm Inc. 1処理ずつのアクセスだけでなく、 バッチ処理でそれぞれのアクセスが パーティションに集中してもホットになる ホットパーティションとは ID DataType 1 Name DataValue John 1 Type dog 2 Paul cat batchWriter AWS Lambda Amazon DynamoDB 61
62. Copyright © RevComm Inc. ❌　Tenant_{account_tenant_id} 　　#Contacts ⭕　Contacts 　　#Tenant_{account_tenant_id} 　　#Contact_{contact_id} ホットパーティションとは 62
63. Copyright © RevComm Inc. テーブル・インデックス設計 検索のためのPK, SKをGSI用に設定 GSIでは全カラムをもつ必要がないため、 検索とソートに必要な項目だけ基本テーブルから射影 GSIは増やすとその分書き込みコストがあがるため 数を抑えたい 63
64. Copyright © RevComm Inc. テーブル・インデックス設計 検索のためのPK, SKをGSI用に設定 GSIでは全カラムをもつ必要がないため、 検索とソートに必要な項目だけ基本テーブルから射影 GSIは増やすとその分書き込みコストがあがるため 数を抑えたい 64
65. Copyright © RevComm Inc. テーブル・インデックス設計 DataType: なんのデータ#どのテナントと紐づいてるか #どの連絡先と紐づいてるか 65
66. Copyright © RevComm Inc. テーブル・インデックス設計 DataType: なんのデータ#どの連絡先と紐づいてるか SearchType: 検索の種類#テナントid SearchValue: "なんのデータ"の値 CreatedAt(ソートしたい項目): id取得のための検索itemと基本情報itemにだけセットすればいい 66
67. Copyright © RevComm Inc. テーブル・インデックス設計 DataType: なんのデータ#どの連絡先と紐づいてるか #紐づくデータ SearchType: 検索の種類#どのデータと紐付けるか（ ON的な）#紐付ける値 67
68. Copyright © RevComm Inc. このクエリ条件をもとに実際に動かしてテストしていく クエリ条件設計 機能 Entity UseCase Lookup parameters order by Table/Index Key Filter 一覧表示 contacts, contact_sample getContactsByTenantId, getContactSampleByContactId 1. {tenant_id}, 2. {contact_id} created_at (DESC) 1. GSI 2. Primary Table 1. SearchType = “FreeWord#Tenant_{acco unt_tenant_id}” 2. ID = :contact_id and DataType = “Tenant_{account_tenant _id}#Contacts” - 一覧表示 (検索) contacts, contact_sample getContactsByTenantId, getContactSampleByContactId 1. {tenant_id}, 2. {contact_id} created_at (DESC) 1. GSI 2. Primary Table 1. SearchType = “FreeWord#Tenant_{acco unt_tenant_id}” and SearchValue BEGINS_WITH :tenant_id”#”:param 2. ID = :contact_id and DataType BEGINS_WITH “Contacts#Tenant_{acco unt_tenant_id}#Contact_” - 個別表示 contacts, contact_sample ・ ・ ・ 電話発信 contacts 商談後情報入力 contact_sample ・ ・ ・ 68
69. Copyright © RevComm Inc. このクエリ条件をもとに実際に動かしてテストしていく クエリ条件設計 機能 Entity UseCase Lookup parameters order by Table/Index Key Filter 一覧表示 contacts, contact_sample getContactsByTenantId, getContactSampleByContactId 1. {tenant_id}, 2. {contact_id} created_at (DESC) 1. GSI 2. Primary Table 1. SearchType = “FreeWord#Tenant_{acco unt_tenant_id}” 2. ID = :contact_id and DataType = “Tenant_{account_tenant _id}#Contacts” - 一覧表示 (検索) contacts, contact_sample getContactsByTenantId, getContactSampleByContactId 1. {tenant_id}, 2. {contact_id} created_at (DESC) 1. GSI 2. Primary Table 1. SearchType = “FreeWord#Tenant_{acco unt_tenant_id}” and SearchValue BEGINS_WITH :tenant_id”#”:param 2. ID = :contact_id and DataType BEGINS_WITH “Contacts#Tenant_{acco unt_tenant_id}#Contact_” - 個別表示 contacts, contact_sample ・ ・ ・ 電話発信 contacts 商談後情報入力 contact_sample ・ ・ ・ テーブル設計とクエリ条件設計を往復・・・ 69
70. Copyright © RevComm Inc. 一覧表示(検索)のサンプルコードはこちら 主な流れ 1. GSI経由で検索用データから条件に一致する contact_id一覧を取得する 2. 取得したcontact_id一覧から基本データを取得する • 部分一致検索の書き方を検索していると今は非推奨の古い書き方例がかなりよく出てくるので注意 • SDKのresourceは古いため非推奨となっており、代わりにclientを使うことが推奨されている データ取得イメージ 70
71. Copyright © RevComm Inc. 1. 今回検証するにいたった背景 2. DynamoDBでできることできないこと 3. テーブルとデータ取得コードの例 4. まとめ アジェンダ 71
72. Copyright © RevComm Inc. 1. データ抽出条件が完全一致、あるいは前方一致で良い 2. データ件数が多く、今後もさらに増加が予想される 3. アクセスパターンや要件がはっきりしている 4. データ検索する際の絞り込み条件となる項目が多くない 5. 基本的にテーブルをjoinする必要がない 6. 並び順は問わない あらためてDynamoDBがマッチすると思われるユースケース 72
73. Copyright © RevComm Inc. 今回DynamoDBを採用しなかった一番の理由 部分一致だと大量データの検索がスピーディにできない 完全一致、あるいは前方一致でなら 高パフォーマンスを発揮できる 1. データ抽出条件が完全一致、あるいは前方一致で良い 73
74. Copyright © RevComm Inc. データ数が多くてもユースケースがマッチしていて 設計がうまくいけばかなり速い 50万件のitemに対する検索でも、 2000万件のitemに対する検索でも 同じくらいのスピードで結果が返ってくる🤩 2. データ件数が多く、今後もさらに増加が予想される 74
75. Copyright © RevComm Inc. 事前の設計がかなり大事 アクセスパターンがはっきり決まっていない状態で GSIを活用した検索の仕組みにするのはおすすめできない 特にホットパーティションが生まれないように注意 3. アクセスパターンや要件がはっきりしている 75
76. Copyright © RevComm Inc. 今回のような設計にすると項目が多ければ多いほど 1件の連絡先あたりのitem数が増えることになり 書き込み・読み込み時のコストも増えていくことになる 4. データ検索する際の絞り込み条件となる項目が多くない 76
77. Copyright © RevComm Inc. これもEntityとリレーションを貼るテーブルが多いほど 1件の連絡先あたりのitem数が増えることになる 全体のクエリも複雑になるのでできればない方がいい 5. 基本的にリレーションがない 77
78. Copyright © RevComm Inc. SQLでいうところのorder byがない Sort Key順以外の並び順にしたいときは 一度全検索結果のidと並び順条件の情報を取得した上で アプリ側でソートすることになる そうすると本当は1MBまでで取れるデータだけでいいところが 全結果を取得しないといけなくなる 並び順はいっそ選べないと思っていたほうが良さそう 6. 並び順は問わない 78
79. Copyright © RevComm Inc. 最終的に2000万件のitemの検証になり、 かなり大規模な検証となりました 個人ではここまで試しきれなかったと思います 今回DynamoDB採用には至りませんでしたが せめて得たものを広く共有することで供養になればと思います 🙏 RIP🙏 79
80. Copyright © RevComm Inc. Thank you!
81. Copyright © RevComm Inc. おまけ
82. Copyright © RevComm Inc. • 特に参考にした記事 ◦ https://speakerdeck.com/_kensh/dynamodb-design-practice ◦ https://speakerdeck.com/handslabinc/dynamodbdemojian-suo-sitai • DynamoDBのテーブル設計における多対多の考え方 ◦ https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/bp-adja cency-graphs.html ◦ https://hack-le.com/dynamodb-many-to-many/ • ホットパーティションについて ◦ https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/bp-part ition-key-uniform-load.html • クエリのパフォーマンスと継続した負荷に対してDynamoDBはどのように対応するか検証記事 ◦ https://aws.amazon.com/jp/blogs/news/part-2-scaling-dynamodb-how-partitions-ho t-keys-and-split-for-heat-impact-performance/ 参考