-
yoshidashingo
- 966
- 3
- 0
- 0
-
- いいね！0
inductor / Kohei Ota
@_inductor_
先にインデックス作っちゃうのか・・・副作用は特にないのかな（よくわかってない） #serverlessjp
2020-08-26 21:15:51
s.hiruta
@web_se
Local Secondry index、作成時しか作れない。。インデックス付与して性能検証した際、作り直した覚え。それより、キーのアクセス集中して負荷試験でスロットリングした #serverlessjp
2020-08-26 21:18:43
taktstock@タクト
@taskforce_Hisui
先にLSIもGSIも作ってるのか... どうなるんだろう? 少なくともお金は増えるな... #serverlessjp
2020-08-26 21:20:02
michimani Lv.873
@michimani210
一つのテーブルに色々突っ込んじゃうと辛くなる(複雑になる)気もするけど、どうなんやろ。#serverlessjp
2020-08-26 21:20:51
Takanori Suzuki
@takanorig
DynamoDBのLSI、後から追加できないのは、ツラいところ。 割り切って、最初から作っているのか。 GSIは、後から追加可能だと思ったけど、それも最初に作ったのはなぜだろう？ #serverlessjp
2020-08-26 21:21:12
Michael H. Oshita
@ijin
マルチテナントじゃなかったらシングルテーブルでいけたけど、テナント毎のバックアップの復元の為に分けたと。なるほど。 #serverlessjp
2020-08-26 21:22:23
kusawake
@kksswwkk
主キーとかに物理的な項目名をつけないのは良いので、次一回マネしてみよう…と思ったけど、具体例聞いてみると1テーブルに色々なデータ構造がキー別に入ってるのか。 これはRDB脳だったら間違いなく拒絶反応示す設計ですね(笑) NoSQLならではの発想。 #serverlessjp
2020-08-26 21:22:28
iganari
@iganari_
Cloud Firestore (datastoreモード)はこちら！ cloud.google.com/datastore/docs… #serverlessjp
2020-08-26 21:23:14
Sonu Kim
@lopburny
DynamoDB の 2000 テーブルのマイグレーションの事例・・！結果整合性のタイミングを考慮つつやっていくのって難しい時ありますよね。 #serverlessjp
2020-08-26 21:29:49
kusawake
@kksswwkk
単一テーブル設計はやったことないけど、難しそう…という感想と同時に面白いそうだな！と素直に思うので、今回お話を聞いた事例を元にどこかで自身もやってみたいなーという気持ちになりました。 #serverlessjp
2020-08-26 21:31:22
iganari
@iganari_
> 今回の変更で費用はほぼ変わらず、管理が楽になった 運用にしんどみが少なくなったのは大きいですよね〜 #serverlessjp
2020-08-26 21:32:50
hrs(ひろせ)
@yh1224
・DynamoDB のインデックス設計、足りないとあとで面倒だから LSI 用の列を予め別に用意しておく ・違うデータ構造をネームスペースで分けてひとつのテーブルに統合する バッドノウハウのような感覚で抵抗がある...これがRDB脳 #serverlessjp
2020-08-26 21:33:24
Shinji Matsumoto
@smatsumt
range キーで 2 つ以上の値を組み合わせたいときは、zorder-curve で混ぜ込むという手がありますね。 zorder-curve 実装を Python に移植してみたので、興味がある方は試してもらえると... github.com/smatsumt/pyzor… #serverlessjp
2020-08-26 21:40:13