t_wの輪郭

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

https://github.com/aws-amplify/amplify-category-api/issues/439

いや、「ベクトル検索ぐらいマネージドサービスあるやろ」とはなるんだけど、たけーのよ。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言語に切り替えるうまみがあるはず。

ブログのお引越し作業中

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

うぐー！！！！純朴な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/

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

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

https://dev.classmethod.jp/articles/vector-search-capabilites-amazon-documentdb-amazon-dynamodb-ga/

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

CloudShellはDynamoDBのデータを一括変換する時にも便利

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

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

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