Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20190116 tectettec#7

194 views

Published on

2019-01-16
スプーキーズのテクテクテックDB勉強会の発表資料

Published in: Software
  • Be the first to comment

  • Be the first to like this

20190116 tectettec#7

  1. 1. 超素人がDynamoDB触ってみた
  2. 2. 本日お話しさせてもらうこと 1)お前何者だよ? 2)業務系のDBについて 3)RDBでやろうとしてみた 4)DynamoDBでやるぞ 5)まとめ
  3. 3. 1)お前何者だよ Otazoman twitter:@norikoni ●職種: 某金融系会社のマーケティング部所属、システムとも マーケとも言えない中途半端な立ち位置 ●経歴: 新卒でSIerに入社し退職後はずっと社内のシステム担当 です。7社を渡り歩いて2018年から現職です。システム 全然知りません(´;ω;`)
  4. 4. 2)業務系のDBについて データベース使うシュチュエーション?
  5. 5. 2)業務系のDBについて ・いや、それEXCELでもできるんじゃ ・EXCELは複数人でデータ更新するには 厳しい。速度も遅いよね データが多いとEXCEL壊れるし
  6. 6. 2)業務系のDBについて 価格 信頼度 高 高 低 低 とりあえずOracle ●お金ある ●パッケージ SQLServer ●お金ない MySQL
  7. 7. 2)業務系のDBについて おおよそのデータ構造 取引先 伝票 伝票明細 商品 売上担当営業 価格 基本はこんなパターンです。
  8. 8. 3)RDBでやろうとしてみた 複数社の料金比較したい 取引先 商品 オプショ ン 料金 オプショ ン組合 選択条件 選択条件の組合せで商品 を特定し、商品からオプ ションの組合せを選べる ようにする必要あり 種別
  9. 9. 3)RDBでやろうとしてみた ●実装しようとした商品について ・オプションと言っても、オプション単体の料金は管理不要。 ・オプション同士の組合せもない。 ・選択条件が特定できればある程度は商品が特定できる。 ・商品の中には複数パターンがあるものの細かいオプションなし
  10. 10. 3)RDBでやろうとしてみた こういう構造で十分だ プラン選択条件 + 料金 種別 商品説明 ●種別取ってきてプランに合致するコードに変換 ●種別+その他の条件でプランを特定する ●プランをキーに料金と商品説明を取ってくる
  11. 11. 3)RDBでやろうとしてみた CSVでもいいのではないか? 僕は素人なのでCSVでWebアプリ はムリィィィ
  12. 12. 4)DynamoDBでやるぞ 素人がやってもそこそこ安全なやつ Amazon DynamoDB 素人がやってもそこそこ安全なやつ
  13. 13. 4)DynamoDBでやるぞ AmazonDynamoDBって何? https://aws.amazon.com/jp/dynamodb/ =NOSQLのマネージドサービス
  14. 14. 4)DynamoDBでやるぞ 一意になるキーを特定してあげれ ば目的とする値を高速に取得でき るデータベース、ただし複数テー ブル結合は難しい。 ・NoSQLデータベース https://ja.wikipedia.org/wiki/NoSQL
  15. 15. 4)DynamoDBでやるぞ 今回の構成はざっくりこんな感じです。 AWS Cloud Region Select Insert Call Function & GetRequest SearchKey 静的ファイルは別にどこにおいてもいい。
  16. 16. 4)DynamoDBでやるぞ (1)ハッシュキー https://dev.classmethod.jp/series/conceptual-learning-about-dynamodb/ (2)複合キー 1個のキーで値を特定する。検索のキモの部分なのと ジョインができないのでRDBより頭は使わないとい けない。 1個のハッシュキーとレンジキーを組み合わせて 一意となる値を特定する。 ハッシュキーのみでも検索はできるけどパフォーマ ンスは悪いかもしれない。
  17. 17. 4)DynamoDBでやるぞ SQL書かなくていいのでデータ抜くところのロジックはシンプル。 Key={keyname:id} KeyConditionExpression= Key(key1).eq(id1) &Key(key2).eq(id2) ●get_itemでぶっこ抜く ●queryでぶっこ抜く ※テーブル結合しないのでパフォーマンス低下なぞ気にしなくてもよし!!
  18. 18. 4)DynamoDBでやるぞ ちなみに書き込むときもキーさえあれば、後は自由 Item = { ‘key-id’: tkey, ‘category’: category, ‘search- key’:searchkey, ‘createdate’:str(cd), 'expiredat':Decimal(et) } ●put_itemで書き込む値を指定する。 ※テーブル1か所だけに書き込めばいいので漏れの恐れは少ない。
  19. 19. 4)DynamoDBでやるぞ ざっくりコストだと0円/月でやれそうかもしれない。(検証は必要) ストレージ レコード読込 レコード書込 DynamoDBデータ転送 Lambda実行時間 Lambdaリクエスト件数 APIリクエスト数 キャッシュサイズ キャッシュなしで100万リクエスト程度 =0円 標準スペックで100万リクエスト実行 =0円 https://aws.amazon.com/jp/api-gateway/pricing/ https://aws.amazon.com/jp/lambda/pricing/ 1秒間に25回程度の読込 =0円 https://aws.amazon.com/jp/dynamodb/pricing/provisioned/
  20. 20. 5)まとめ ・料金面:今のところは0円で行けてる。 ・パフォーマンス面:現在の検証では問題出てない。 ※素人なのでブラウザで計測する方法とかご教示いただけるとありがたいです。 ※Readがメインになりますが、数か月に一度はWriteもあるのでどの程度の コストとなるのかは蓄積していく必要があります。 ※たぶん1万件以下なので問題ないと思いますが、100万件超レベルではどうだろうか? ・メンテナンス性:大きな課題です。 ※どうやってデータをDynamoDBにぶち込もうか、これ考えているところです。 一応EXCELでJSON吐いてS3に上げるマクロは作ってみたものの、、、 ※受けたデータをプログラム側で加工しないといけないので少し問題かも jsの魔術師がいれば何とかしてくれるはず。
  21. 21. 5)まとめ 素人でもできるはできた。 けどやりようによってはスパゲティなりそうな気がする。 データ構造次第ではフロントエンドの人が泣きそう。 その気になればRDB的なこともできなくはない。
  22. 22. ご清聴ありがとうございました。

×