about database in seeds company x

original slide of キッキャッ！APIだらけの新サービス開発裏舞台！（全部見せます）
report:
event:
https://career.levtech.jp/hikalab/event/detail/163/
https://atnd.org/events/94367

Transcript

1. DATABASE
2. Database • Amazon Aurora ➡ データストアとして利⽤ • Couchbase server ➡ データストアとして⼀部で利⽤ • Redis ➡ キャッシュ / セッション管理として利⽤
3. Amazon Aurora
4. What is Amazon Aurora? Photo by Tachina Lee on Unsplash • AWSの完全マネージド型のリレー ショナルデータベースエンジン • MySQL および PostgreSQL と互 換性がある
5. Why use Amazon Aurora? • MySQL5.7互換 • 完全マネージド型のデータベースサービスな ので、メンテが（ほぼ）不要 • 3つのアベイラビリティーゾーンを跨いでレプ リケーションを作れる • フェイルオーバーは60秒未満
6. Couchbase
7. What is COUCHBASE? Photo by Tachina Lee on Unsplash • オープンソースの分散型ドキュメン ト指向データベース • 「開発者がリラックスして、 カウ チソファに座っているようにデータ ベースの設計・構築・運⽤ができる ように」という思想の元、
 Simple (シンプル) 
 Fast (⾼速性)
 Elastic (柔軟) 
 をコンセプトにして作られている。
8. 採⽤前 • RDBMSで作っていた • 関連テーブルが多くなりすぎて管理が煩雑化 した • Go⾔語を使っているので、スキーマ定義をア プリケーションとデータベース両⽅で必要
9. Why use COUCHBASE? Photo by Tachina Lee on Unsplash
10. 検討したDB • Amazon DynamoDB • インデックスが限定的
 （ユニークとレンジが1つずつ） • 環境別の切り分けが難しい • ローカル環境で開発がしづらい • Cassandra • データの偏りが発⽣しやすい（チューニングが難しい） • スキーマ定義は必要 • ArangoDB • AQL（クエリ）を使う∕使わない場合と⽐較して極端に遅くなる場合があ る • 公式でGoのClient libraryが作られていない
11. 採⽤理由（他社の利⽤状況） etc…
12. 採⽤理由（学習コスト） DB RDBMS Couchbase クエリ SQL N1QL（SQL準拠） インデックス ◯ ◯ ジョイン ◯ ◯ 取得/保存形式 テーブル （⼀階層のKey/Value） JSON 多階層構造 △（*1） ◯ スキーマ設計 必要 不要 ※1 MySQL5.7でjson型を使えば⼀部対応可
13. 採⽤理由（その他） • GoのSDKが⽤意されていた • docker上での実⾏が公式に検証されている • オフライン設計がなされている • ネイティブアプリを作る時など • マルチマスタ • 単⼀障害点が存在しない • ほぼすべての⾔語・プラットフォームの公式SDKが存在する • Enterprise Edition（商⽤サポート）が存在する • ⽇本に代理店がある
14. Good • 出⼒/保存形式はJSON • SQL準拠 • スキーマレス • マルチマスタ • LRUキャッシュ • フォーラムや開発が活発 • インフラの構築・管理が簡易 • etc Photo by Isaiah McClean on Unsplash
15. Good • 出⼒/保存形式はJSON • SQL準拠 • スキーマレス • マルチマスタ • LRUキャッシュ • フォーラムや開発が活発 • インフラの構築・管理が簡易 • etc Photo by Isaiah McClean on Unsplash
16. SQL準拠 SELECT id, airline, sourceairport, destinationairport, schedule FROM `travel-sample` WHERE type="route" AND airline="KL" AND sourceairport="ABQ" AND destinationairport="ATL" LIMIT 1; { "results": [ { "airline": "KL", "destinationairport": "ATL", "id": 36159, "schedule": [ { "day": 0, "flight": "KL858", "utc": "18:59:00" }, { "day": 1, "flight": "KL672", "utc": "19:19:00" }, { "day": 2, "flight": "KL173", "utc": "07:18:00" }, { "day": 5, "flight": "KL169", "utc": "23:41:00" } ], "sourceairport": "ABQ" } ] } ग़ྗ݁Ռ͸JSON
17. SQL拡張 （配列絞込み） { "results": [ { "fri_evening_flights": [ { "day": 5, "flight": "KL169", "utc": "23:41:00" } ] } ] } { "results": [ { "airline": "KL", "destinationairport": "ATL", "id": 36159, "schedule": [ { "day": 1, "flight": "KL672", "utc": "19:19:00" }, { "day": 2, "flight": "KL173", "utc": "07:18:00" }, { "day": 5, "flight": "KL169", "utc": "23:41:00" } ], "sourceairport": "ABQ" } ] } SELECT ARRAY v FOR v IN schedule WHEN v.utc > "19:00" AND v.day = 5 END AS fri_evening_flights FROM `travel-sample` WHERE type="route" AND airline="KL" AND sourceairport="ABQ" AND destinationairport="ATL" AND ANY v IN schedule SATISFIES v.utc > "19:00" END LIMIT 1; SELECT id, airline, sourceairport, destinationairport, schedule FROM `travel-sample` WHERE type="route" AND airline="KL" AND sourceairport="ABQ" AND destinationairport="ATL" LIMIT 1; ഑ྻΛߜΓࠐΈ ઌఔͷΫΤϦ
18. Good • 出⼒/保存形式はJSON • SQL準拠 • スキーマレス • マルチマスタ • LRUキャッシュ • フォーラムや開発が活発 • インフラの構築・管理が簡易 • etc Photo by Isaiah McClean on Unsplash
19. LRUキャッシュ σʔλߋ৽
20. LRUキャッシュ σʔλࢀর
21. Good • 出⼒/保存形式はJSON • SQL準拠 • スキーマレス • マルチマスタ • LRUキャッシュ • フォーラムや開発が活発 • インフラの構築・管理が簡易 • etc Photo by Isaiah McClean on Unsplash
22. フォーラムや開発が活発 σʔλࢀর
23. ϑΥʔϥϜ΍։ൃ͕׆ൃ σʔλࢀর Couchbaseࣾͷissue͕ݟΕΔ
24. Good • 出⼒/保存形式はJSON • SQL準拠 • スキーマレス • マルチマスタ • LRUキャッシュ • フォーラムや開発が活発 • インフラの構築・管理が簡易 • etc Photo by Isaiah McClean on Unsplash
25. インフラの構築・管理が簡易 σʔλࢀর ほぼ全てWebUIで完結
26. Bad • docker/ECSͱͷ૬ੑ͕ྑ͘ͳ͍ • ΫΤϦʹΑͬͯϨεϙϯεܗࣜ ͕ҟͳΔ • ࠷దԽʹؔ͢Δ஫ҙ Photo by Thought Catalog on Unsplash
27. docker/ECSͱͷ૬ੑ͕ྑ͘ͳ͍ • ノードの情報がIPアドレスで管理されてるの で、containerのオートスケール対応が困難 • 利⽤ポート数が多いので、ECSのポート制限を 超える • 最新版だとKubernetes対応がはいっているの で、EKSやGCPだと問題が起きないかも
28. クエリによってレスポンス形式が異なる { "results": [ { "travel-sample": { "airportname": "Calais Dunkerque", "city": "Calais", "country": "France", "faa": "CQF", "geo": { "alt": 12, "lat": 50.962097, "lon": 1.954764 }, "icao": "LFAC", "id": 1254, "type": "airport", "tz": "Europe/Paris" } } ] } { "results": [ { "callsign": "MILE-AIR" }, { "callsign": "TXW" }, { "callsign": "atifly" }, { "callsign": null }, { "callsign": "LOCAIR" } ] } SELECT * FROM `travel-sample` WHERE type="airport" LIMIT 1; SELECT callsign FROM `travel-sample` LIMIT 5; HASH ARRAY
29. ࠷దԽʹؔ͢Δ஫ҙ • େྔʹσʔλมߋ͕ߦΘΕͨ࣌ʹRebalance ͕૸Δ ✦ Rebalance͕ߦΘΕͯΔϊʔυ͸࢖༻Ͱ͖ͳ͍ ✦ ϊʔυ਺͕଍Γͳ͍৔߹͸೺Ѳͭͭ͠࢖Θͳ͍ͱ͍͚ͳ͍ ʢ։ൃ؀ڥͳͲʣ
30. Practices ⼀対多のデータを持ちたい • データの分割（関連テーブル）が不要になり、設計・監理も楽になる 階層構造のデータを管理したい • 基本的にCouchbaseがよい • 下位の階層が検索対象になる場合はRDBMSのほうがいい場合も いろんなソート、絞り込みをしたい • RDBMSのほうがいい。あくまでもNoSQLなので プロトタイプのアプリでDBを使いたい • スキーマレスなので、スピーディに構築できる • ただしそのまま商品化できるかは検討が必要