DynamoDBでできないこと

この記事について 本記事は、筆者が普段AWSの各種サービスを使って感じた感想・気づきをもとに、クラウドアーキの設計やサービスのより良い使い方Tipsを考察するシリーズです。 第二弾も第一弾に引き続きDynamoDBについてです。 DynamoDBはkey-value型のNoSQLであり、従来よく使われていたRDBとは異なるDB特性・クエリ特性を持っています。 そのためRDBを設計するときと同じようなノリでスキーマ設計・テーブル設計を行うと、後から「この操作をやらせるならDynamoDBじゃないほうが良かったんじゃないか？」ということが発覚しがちです。 本記事では筆者が遭遇した「DynamoDBでやらせてみたら苦労した・できなくて設計変更を強いられた」というユースケースをまとめることで、DynamoDBのクエリ特性や適性を考察することを目指します。 使用する環境・バージョン 2024/1/1

[ustam]

でもクエリーって、後から「こういうのしたい」ってことが多いような気がする。

[Sampo]

イベントのたびに増えるデータがトランザクションデータだ、登録しないと増えないのがマスターデータ。「商品」はマスターで「取引」はトランザクションみたいなね。データ分析の世界だとディメンションって言うよ。

[fuji_haruka]

何年もソフトウェアエンジニアやっているけど、「マスターデータ」という言葉の意味がいまだにわからなくて困る。この記事ではどういう意味で使っているんだろう。／ブコメで理解、感謝

[takeag]

履歴だとかそれこそ大量なログで削除や複雑なsortが不要なものには向いてるのかもね。 スケーラビリティが高いRDBとして使うと死ねます

[Kil]

それでもだいぶマシになったよね。昔はGSIも1テーブルに2つしか張れなかったり、相当制限が厳しかった。

[kamm]

だいぶ前に、アプリが読み取ったシリアルコードが未使用ならユーザーに付与処理を行う、みたいな処理をLambdaで書いた時にdynamoDBを便利に使えた記憶。使い所が限られてるなーとは思った。

[remonoil]

全取得はS3エクスポートで出来る。検索機能などとして使うことは困難だけど

[earu]

メインで使わなくていいと思う。NoSQLはそれなりの使い方しかしなくていいと思っている

[daishi_n]

永続データベースではあっても、原則KVSだから適切なキーで読み取れることが大前提だからね。非永続KVSならElastiCacheもあるしRDBMSのようにはいかない。

[otchy210]

DynamoDB の話というか NoSQL vs. RDB の話かな？当たり前だが得手不得手を踏まえて適材適所すべき。世の中の大半のケースは RDB の方が楽よね。NoSQL じゃないとスケールしないケースなんて極小でしょう。

[akymrk]

“DynamoDBのDeleteItemは基本的に冪等になるように作られています。 そのため、通常は削除対象がなかったとしても正常応答を返す”

[door-s-dev]

できない事が多いのでうまくできる事を知ってその用途だけで使った方がいいかも

[makbai]

firestore/datastoreの微妙な使い辛さと大体同じかな

[yosio_ism]

マスタデータ全取得したいならテーブル分けてScanでいいと思う。あとはアプリ側でキャッシュかな。

[houyhnhm]

マスターテーブル⇔トランザクションテーブル、と考えればいいかなと。／DB内で出来ないあるいはやるべきではない、という整理は大事よね。

[coppieee]

マスターデータの全件取得にscan使うの特に問題ないのでは？？

[versatile]

何に向いてるのかな

[dorapon2000]

“そうなると全取得を行うためにはテーブルをScanするしかなくなりますが、大きなマスタデータになるとScanは負担になるので望ましくありません。”

[akiyoshi83]

“使用する環境・バージョン 2024/1/1時点で提供されている機能に基づき考察 読者”

[alcoolalcho]

一発の操作じゃできないけど全部工夫すればできることではある気がします