技術日記4/15-4/19
日記の先延ばしぐせがひどい..
graphql-javaでdataloaderの実装軽く試したけどうまく動くところまでいかなかった
今回の設計的にそんな深い構造のjsonを返すことがなさそうなので一旦後回しにした
必要そうなら改めてチャレンジする
nodejsでスクレイピングプロジェクトを作ったのでeslint入れた
ルールはairbnbのやつで
ここ1年ぐらいjs触ってなかったからだいぶ久しぶり感
knativeでnodejsのスクレイピング動かしたとき、podがCrashLoopBackOffする問題がまだ原因不明
EKS環境作ったのにうまくpodが立ち上がらないと思ってたら、ワーカーノードをクラスターと結合するというところが出来ていなかった
Amazon EKS の使用開始 - Amazon EKS
書いてあることちゃんと読め自分
今週はDB設計やってた
ユースケースをガッと書き出してDB設計して各ユースケースの動きを満たせるか確認していった
複雑なエラーパターンが存在しそうな機能の部分は個別にフローを丁寧に見て、エラーパターンあぶり出していった
使うDBを迷っている
AWS Aurora, MongoDB, DynamoDB
基本的にはRDBでいいんだけど、一箇所jsonデータのようなものを保存したくてそれをMongoやDynamoのようなdocumentDB(正確にはDynamoはKVS?jsonサポートしてるしdocument型の側面もある認識)に入れることを検討している
ただMySQLのJson型も使えるんじゃなかろうかと思っている
json型使えるなら使うDBがAuroraだけで済むし嬉しい
MongoはAmazon DocumentDBという名前で2019年1月に出たばっかで、Tokyoリージョンもなさそうだしナシかな
Mongoにあるクエリの柔軟性も今回のこの部分にはまぁいらないでしょう、ということでMongoとDynamoだったらDynamoを使えば良さそう
あとは他のデータ含めて全部DynamoDBでもよくね?とも思ったけど、ドキュメント型DBは気をつけて使わないとデータが散乱するとか使い方が難しそうということもあって、やっぱり基本はRDB使って必要そうならDynamo使う感じでいいかなと思ってる
Json型使っちゃおうかなー
Json型はインデックス貼れないとかあるけどまぁそういう用途では使わなそうなので
DynamoDBは読み込み/書き込みの多いシステムとかで使うのが良さそうだけど
そういうシステムの設計やってみたいなー
案件落ちてないかな?
テーブル設計でサロゲートキー使うか複合主キー使うか迷ったんだけど、複合主キーを使うと更新時とかに投げるAPIのパラメータが増えそうなので、やっぱりサロゲートキー使うでいいかと思った
もちろん時と場合で使い分けるでいいと思う
今更感あるけどMySQLの基礎が抜けてそうな感じだったので改めて下記の書籍を購入して再勉強中っていうね
- 作者: 遠藤俊裕,坂井恵,館山聖司,鶴長鎮一,とみたまさひろ,班石悦夫,松信嘉範
- 出版社/メーカー: 翔泳社
- 発売日: 2011/08/26
- メディア: 大型本
- 購入: 9人 クリック: 82回
- この商品を含むブログ (9件) を見る
詳解MySQL 5.7 止まらぬ進化に乗り遅れないためのテクニカルガイド (NEXT ONE)
- 作者: 奥野幹也
- 出版社/メーカー: 翔泳社
- 発売日: 2016/08/26
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る