データ量に引けを取らない丁寧な仕事
次はSQLite DBを全クライアントのメモリーに....
日次でしか更新されないならレプリカを撒くのはいい選択だよなあ
“SQLite の Backup API を使い、Task 起動時にファイルモードとインメモリモードの 2 つの SQLite 接続を作成し、ファイル側からインメモリ側に全件コピーする 方法を取りました”
へえ、まあ SQLite3 は確かに軽量で速いし、こういう使い方なら規模の大きなところでも実戦投入できるわけか
SQLiteはちょっと用途を選ぶかな
これはすごくいい改善。
すべてのデータをインメモリモードの SQLite に配置 > コロンブスの卵的なかなか興味深いソリューション。
例えば EC サイトの購買履歴のような、その人だけのデータが見れれば良いケースでは、高々数 10 MB であろう全量データのコピーを SQLite でクライアント側のメモリに置いちゃうとすごい捗るな、とか夢想したことはある。
『長時間（約 4 時間半以上）ディスクに高い読み取り負荷をかけ続けると、AWS 側から性能に制限をかけられるような挙動が見られた』これが気になるな。アプリ側はどうだったのかな？型まわりとか
pragmaticな発想でとても好感もてる
DuckDBでも良さそうだが、合わなかったか
バッチ処理のために起動したFargateの中でインメモリDBを使ってデータ操作を行ってそれをマスタDBに書き戻すみたいなことはよくやりますね
sqliteを使ってるBaaSのPocketbaseもいい。実は世の中の半分くらいのDBはsqliteでも何とかなるんじゃなかろうかと思う今日この頃
面白い
トランザクションとか考えなくていい場合はそれなりの方策はあるからな。
はえー面白い
読み取り負荷どうすんのかと思ったらSQLiteぜんぶをメインメモリに入れると。それが "十分実用的" なのかよくわからんw
W/Rが1:99くらいの比率だととてもよく効くSQLite。
いい話
素晴らしい
更新されないデータであれば確かに効率いいだろうな
これ、キャッシュに近い用途だな。読み取り専用かつ随時更新される必要がないという特殊条件に加えて、SQLiteであれば既存のSQLクエリーをほぼそのまま流用できるというメリットがうまく噛み合った。
SQLiteを選んだ経緯やファイルをどこに置くかを決める時に直面した問題など色々書かれていて面白かった。ディスクに高い読み取り負荷をかけ続けたときの制限かかるのは何なんだろうね？ドキュメントに無いなんて。。。
良いね。 Lambdaでs3からsqliteのファイル都度取得するみたいな処理でも全然安いんだよね。
常に書き込みしないならばSQLiteに移行でもいいのか
あー、BigQuery BI Engineのリザーブドなキャッシュ容量のようなやつ。でもこっちの方が安い&カルテ方面の非機能要件に合わせやすそう。
実直だけど良い設計変更だと思う。というかこれ expireが24hのインメモリキャッシュをアプリ側に持つのじゃだめだったのかな。クエリは毎回違うの？カルテは異分野すぎてわからん。
アプリ本体にSQLiteごと静的リンクして使えるのかな(goミリしら)
「必要なスコアデータのみに絞ることでデータ量を数 GB 程度まで削減して、」とあるが、普段から消しておいたらレイテンシも元々抑えられた疑惑
読み取り専用 DB を Aurora から SQLite に移行してコストを 1/8 に削減した話 - エムスリーテックブログ
データ量に引けを取らない丁寧な仕事
次はSQLite DBを全クライアントのメモリーに....
日次でしか更新されないならレプリカを撒くのはいい選択だよなあ
“SQLite の Backup API を使い、Task 起動時にファイルモードとインメモリモードの 2 つの SQLite 接続を作成し、ファイル側からインメモリ側に全件コピーする 方法を取りました”
へえ、まあ SQLite3 は確かに軽量で速いし、こういう使い方なら規模の大きなところでも実戦投入できるわけか
SQLiteはちょっと用途を選ぶかな
これはすごくいい改善。
すべてのデータをインメモリモードの SQLite に配置 > コロンブスの卵的なかなか興味深いソリューション。
例えば EC サイトの購買履歴のような、その人だけのデータが見れれば良いケースでは、高々数 10 MB であろう全量データのコピーを SQLite でクライアント側のメモリに置いちゃうとすごい捗るな、とか夢想したことはある。
『長時間（約 4 時間半以上）ディスクに高い読み取り負荷をかけ続けると、AWS 側から性能に制限をかけられるような挙動が見られた』これが気になるな。アプリ側はどうだったのかな？型まわりとか
pragmaticな発想でとても好感もてる
DuckDBでも良さそうだが、合わなかったか
バッチ処理のために起動したFargateの中でインメモリDBを使ってデータ操作を行ってそれをマスタDBに書き戻すみたいなことはよくやりますね
sqliteを使ってるBaaSのPocketbaseもいい。実は世の中の半分くらいのDBはsqliteでも何とかなるんじゃなかろうかと思う今日この頃
面白い
トランザクションとか考えなくていい場合はそれなりの方策はあるからな。
はえー面白い
読み取り負荷どうすんのかと思ったらSQLiteぜんぶをメインメモリに入れると。それが "十分実用的" なのかよくわからんw
W/Rが1:99くらいの比率だととてもよく効くSQLite。
いい話
素晴らしい
更新されないデータであれば確かに効率いいだろうな
これ、キャッシュに近い用途だな。読み取り専用かつ随時更新される必要がないという特殊条件に加えて、SQLiteであれば既存のSQLクエリーをほぼそのまま流用できるというメリットがうまく噛み合った。
SQLiteを選んだ経緯やファイルをどこに置くかを決める時に直面した問題など色々書かれていて面白かった。ディスクに高い読み取り負荷をかけ続けたときの制限かかるのは何なんだろうね？ドキュメントに無いなんて。。。
良いね。 Lambdaでs3からsqliteのファイル都度取得するみたいな処理でも全然安いんだよね。
常に書き込みしないならばSQLiteに移行でもいいのか
あー、BigQuery BI Engineのリザーブドなキャッシュ容量のようなやつ。でもこっちの方が安い&カルテ方面の非機能要件に合わせやすそう。
実直だけど良い設計変更だと思う。というかこれ expireが24hのインメモリキャッシュをアプリ側に持つのじゃだめだったのかな。クエリは毎回違うの？カルテは異分野すぎてわからん。
アプリ本体にSQLiteごと静的リンクして使えるのかな(goミリしら)
「必要なスコアデータのみに絞ることでデータ量を数 GB 程度まで削減して、」とあるが、普段から消しておいたらレイテンシも元々抑えられた疑惑