t_wの輪郭

Feedlyでフォローするボタン
AWS『個人開発のコストはDB次第』PartiQLNoSQL
あれあれ『Is there a way to specifiy thedynamodb tablename when creating a api resource using amplify?』『[速報]Amazon DocumentDBおよびAmazon DynamoDBのベクトルサーチ機能が一般提供開始に！』Vector search for Amazon DynamoDBあれあれあれあれあれ『Add Similarity Search to DynamoDB with Faiss』DynamoDBでも索引を作ればいい感じに検索できる説DynamoDBのitemの容量は400KBまであれあれあれ『DynamoDB の update_item() で、SET・REMOVE・ADD・DELETEを同時に実行する | DevelopersIO』あれあれ「DynamoDBも使ったことあるけどNoSQLはまじでやめといたほうがいい」『技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL』あれDynamoDB Streams『AWS LambdaのNode.jsランタイムでTCP接続を使いまわそう!(AWS_NODEJS_CONNECTION_REUSE_ENABLED) | DevelopersIO』『Amazon Aurora PostgreSQL および Amazon DynamoDB の Amazon Redshift とのゼロ ETL 統合の一般提供を開始 | Amazon Web Services ブログ』『PostgreSQL: DynamoDB fdw 1.0.0 released』あれあれ

あれ

2025/4/5 9:45:00

Datomicはすごいらしいぞ。
DynamoDBやS3をDBのストレージとして使えるらしいぞ。

あれ

2024/12/7 11:39:00

DynamoDBの属性ベースのアクセスコントロール (ABAC)って、マルチテナントシステムを作るときに別テナントにデータが行かないように制御するとかできるのかな。

あれ

2024/9/1 18:04:00

「SQLにビジネスロジックを寄せる」というのを最近知って、良さそうだなと思ってたんだけど、ビジネスロジックの入力がDBから与えられるので、テストがしづらそうでもある。

そこで、「データ永続化用のDBと、ビジネスロジック用のDBを分けると良いのではないか」という考えが浮かんできた。


「ビジネスロジック用のDB」と、「データ永続化用のDB」がいい感じに連携できるのであれば、「データ永続化用のDB」にDynamoDBを使っちゃったとしても、なんか、こう、いい感じに、やれたらいいなって。

あれ

2024/8/26 23:33:00

DynamoDB+AppSync、初動のみ爆速で、その後の開発速度の失速も早かった。
AmplifyのDataStoreも同様。半年以内で負の遺産だった。

あれ

2024/8/26 23:15:00

コレを私は今痛感している。PostgreSQLに切り替えてぇ。
Amazonを作るならDynamoDBは便利だと思う。でもAmazonを私は作ってない。

「DynamoDBで安く済ませようぜ！！」
　→開発中はスキーマ変更しまくり ＆ スキーマ変更が大変すぎて爆死
　　↑今ここ

あれ

2024/2/14 22:46:00

DynamoDBのつらみ

  • 既存のテーブルにデータをインポートする機能がない
  • データ投入するときはスクリプトで流し込む必要がある
  • テーブルのスキーマを変更すると全データの変換作業が必要になる

あれ

2024/2/14 22:40:00

DynamoDBにデータ投入するときは、いつも泣きながらスクリプト書いてる。


DynamoDBにいい感じにデータ投入する方法欲しい。マジで。

DynamoDBはCSVやJSONのインポートがテーブル作成の時だけできるので、CDKでテーブルを毎回作り直すという富豪的解決はできるかもしれない。


BatchWriteItem（25個まで）

おふぁっくですわ

あれ

2023/12/3 12:52:00

Amplifyに乗っけたNext.jsから直接DynamoDBたたくの大変っぽい。テーブル名を同定でけへん。

あれ

2023/11/26 18:54:00

いや、改めて文章化してみると、この検索にかかる時間が5〜6秒で済んでるのが異常に早いぐらいなことをしているな。

あと、この前景と後景を辿るという処理は、DynamoDBと相性が悪い。RDBのJOINを使ったほうが速い予感がする。

あれ

2023/11/20 23:32:00

おっしゃるとおりで、DynamoDBが対応しているのはSPARQLではなく、PartiQLでした！
間違った情報でお手間を取らせてしまってすみません。

あれ

2023/11/4 20:48:00

ブログのお引越し作業中

実質システムの作り直しなのでまだまだ時間がかかる

うぐー！！！！純朴なPostgresqlで作ったブログシステムに、読み込み速度で勝てない！！DynamoDB使ってるのに！！！

Postgresql先生、DynamoDBで2秒かかってるものを、300msで返してくるのは止めていただきたく。

DynamoDBつーか、AppSyncのAPIを叩きまくってるアレのせいな気はする。

Next.jsのcacheを有効化したら、ページの取得に2秒とか要していたのが、100msになった。良き。

むむ、localhostで動いてたのをAWSに移すと遅くなるな。そりゃそうか。

AWSに移したら遅くなったのが気に入らなかったので、CloudFrontに乗っけた。
運が良くCloudFrontのキャッシュにHitすると10ms程度でページが取得されるようになった。
https://main.d21776nrisgiy.amplifyapp.com/

あれ

2023/8/13 22:06:00

いや、「ベクトル検索ぐらいマネージドサービスあるやろ」とはなるんだけど、たけーのよ。Azure Cognitive Searchとか、一番安いので月額1万円以上する。

DynamoDBとLambdaでやりくりすれば、維持費をほぼ0円、処理があっても月額100円ぐらいで何とかなるはずなんや。

で、そのために文章をベクトル化（Sentence Embedding）する処理が必要だったのだけどもですね、世のSentence Embeddingするライブラリやら言語モデル（BERTとか）やらはファイルサイズが巨大で、Lambda関数に乗り切らんかったわけです。

そこで、BERTを小型化したALBERTでSentence Embeddingが取れるように学習してたんですけども、やっとこさそれらしい結果が出せるようになってきた。

となると、次の課題はベクトル検索のDB部分なわけです。今はJavaScriptのライブラリを使ってるので速くないので、Go言語とかでやりたい。

というか、JavaScriptでのSentence Embeddingの計算は遅いはずなので、そこもGo言語に切り替えるうまみがあるはず。

あれ

2023/5/24 9:00:00

AWSでベクトル検索しようとするとAmazon OpenSearchとかいうのを使うのが正攻法なのだけど、OpenSearchはEC2インスタンスが立ち上がってしまって費用的にも労力的にも良くない。そこで、ベクトル検索ライブラリで生成したインデックスをAmazon DynamoDBのインデックスにすればサーバーレスで安価に運用できる気がしている。

未検証。できるかどうか不明。果たして、任意のインデックスをレコードに設定することができるのか？

というか、そういう機能をAWSが作るべきだと思う。作るでしょ。そのうち。