Litestreamが待望の刷新！
引用元：https://news.ycombinator.com/item?id=44045292
コードはここっぽいよ：
https://github.com/benbjohnson/litestream/tree/v0.5
これが見れてマジ嬉しいわ。2年前にLitestreamとlitefsを使おうとして、ちょっとイライラしてた時に書いたコメントがこれ：
https://news.ycombinator.com/item?id=37614193
これで大体の問題解決するのかな？今度は複数のライターの問題を気にせずにLitestreamをDBで自由に実行できるってこと？引き継ぎはどう処理されるんだろ。
リードレプリカのFUSEレイヤーはマジで良いね。
追記：あー、こうやって動くんだ：
https://github.com/benbjohnson/litestream/pull/617
＞ 別のLitestreamプロセスが起動して既存のリースを確認したら、成功するまで1秒ごとにリース取得を再試行する。この短い再試行間隔のおかげでローリングリスタートがすぐにオンラインになる。
いけそうだね！
この投稿は、まるで俺の心の中を読んで新しいLitestreamに欲しかったものを全部実装してくれたみたいだわ。マジで興奮するね。
ben、litestreamありがとう！
俺たちプロダクションで1年以上使ってるよ。書き込み多めの社内ユースケースで（圧縮して約12GB）、毎月数百円しかかかってない（azure）。
新しい変更が入るのが楽しみだわ。
ホスティングやデプロイの運用選択について少し教えてくれない？Azureのどのサービスを使ってるの？設定はどんな感じ？スループットはどんなもん？マイグレーションに関して何かコツとかある？専用サーバーかVPSか、どっち使ってる？
俺も今年の後半に似たようなデプロイする予定だから、このトピックについて読むの楽しいんだ。
この特定のデプロイについてはね、Azureのblob storageだけ使ってるよ。デプロイ先はオンプレのkubernetesクラスターで、replicas=1、strategy: recreate。スループットはそんなに重くない正直なところ。10秒に1回くらいのwebhookリクエストで、リクエストごとにテーブルに10～100件以上のエントリーが追加される感じ。マイグレーションは、社内コンソールだから、数時間ダウンタイムとってやったよ。
FlyがSQLite周りの開発者体験をもっと磨いてくれたらなー。結構近いんだけど、足りないんだよね：
1. VolumeからSQLiteを管理するUIとCLIが内蔵されてない。Fly Machineに初期DBを置くのに手間がかかりすぎる。
2. fly consoleがSQLiteで動かないんだ。別のMachineを起動するから、SQLiteデータがあるVolumeに繋がらないんだよね。代わりにfly ssh console —ptyを実行しないといけないって知らないといけない、これが事実上DBがあるMachineにSSHするってやり方なんだけどさ。
SQLiteを使ったウェブアプリの一般的な問題は、小さいアプリになりがちで、ホスティングでそこそこ稼ぐにはたくさん必要になるってことなんだ。
Brad、Rails 8とSQLiteについてどう思う？最近はPostgresよりそっちに傾いてきてる？
そうだよ！FlyのPG clusterデータベースをSQLiteに移行したばかりなんだ。DBリソースを過剰にプロビジョニングしちゃって、たまにノードがクラッシュするのに対応するのに疲れたからね。
正直言うと、Managed PG clusterを動かしてくれてたら、もっと簡単にスケールダウンできたのにとは思うけど、SQLiteには満足してるよ。
別のプロジェクトで、最大100ユーザーくらいの同時接続になるって分かってたやつにSQLiteを使ったんだけど、めちゃくちゃ上手くいったね。一番良かったのは、ユーザーがプロダクションエラーを報告してくれて、ローカルで再現できなかった時に、DBをダウンロードして、最新のプロダクションデータを使って自分のラップトップで再現できたことだわ。高コンプライアンスなアプリじゃできないことだけど、ほとんどのアプリはそうじゃないしね。
「SQLiteとRailsは最高だよ」って断言するのはちょっとためらうんだ。だって、自分のアプリが1つのノードで動くって分かってないといけないからさ。それが分かってたら最高だけどね。
なんて偶然だ、今日ちょうどLitestream調べてたんだ！VPSでSqlite使ってて、これ追加しようと思ってたんだよね。
これって、litestreamプロセスが動いてる間のどの時点にもDBをリストアできるようになるって理解で合ってる？だって、auto-checkpointingが動いてない間にWALを消費しちゃう可能性があるんでしょ？
極端な例で言うと、プロセスが2:00から3:00の間クラッシュしたとして、1:55か3:05にはリストアできるけど、2:00から3:00の間にリストアするのに必要な情報が失われるってこと？
LitestreamはWALセグメントを時間粒度に合わせて保存するんだ。デフォルトだと、1秒ごとにWALの変更を送り出すから、（保持期間内であれば）履歴の任意の秒にリストアできるはずだよ。
DST（夏時間冬時間）の扱い、問題ない？ ヨーロッパだと3月30日に時間が1時間ずれたんだけどさ。
これめっちゃいいね！昔DynamoDBをバックエンドにしたsqlite vfs、DonutDB作ったんだ。最近S3にCASが追加されたからS3版も考えたんだけど、Litestreamが対応してるなら自分でやらなくて済むじゃん！早く試したいな。
[0]: https://github.com/psanford/donutdb
S3にCASが追加って話、参照元ある？CASってcontent addressable storageのこと？ググってもAWSのドキュメント見つかんないんだけど。
Compare And Swapだよ。
TL;DR（超要約）は、Amazon S3が「条件付き書き込み」をサポートしたってこと。他の人が書き込んでたら失敗する保証付き。ETagを送って実現してるんだ。Litestreamはこれを使って複数ライターを処理してる。楽観的ロックみたいな感じ。AWSの告知リンクもあるよ。
https://aws.amazon.com/about-aws/whats-new/2024/11/amazon-s3…
二人ともありがとね！俺が仕事で使ってる感じだとCASはcontent-addressable-storageの意味なんだわ。俺の間違いだ。
LLMコード書くロボットもSQLite好きになるかもって密かに思ってる。コード試して失敗しても状態ごとロールバックできるのがエージェントにとって超重要。タイムトラベルで並行探索できると強いよね。ワークフローで決定論保つのが大変って話も。ReplitがNeonのタイムトラベルをエージェントに統合したのも同じ理由[0]。ReplitはGCPとかの上にあるから、Oracleみたいになんないか心配だよ。
[0]: https://blog.replit.com/safe-vibe-coding
LitestreamでたくさんのDB（一人一個とか）をレプリケーションしたい場合、実行中に新しいDBを追加する指示ってどうやるの？設定ファイルは変わんないし、DB追加を指示するAPIも見つかんなかったんだけど。
この問題は解決されるはずだよ。新しいsqlite見つけるのはちょっと難しいけど、できないことじゃない。とりあえず今はライブラリとして使うのが結構簡単だよ。
Benのことずっと追ってるけど、LiteFSが彼の仕事ベースだって知らなかったわ。結局、自分で分散DBやるならrqliteがいいかって落ち着いたんだけどね。
https://github.com/rqlite/rqlite リンク貼っとくわ。
LiteFSと似たアプローチだけど、rqliteはConsulに頼らずRaftをプロジェクトに組み込んでるんだって。https：//youtu.be/8XbxQ1Epi5w？si=puJFLKoVs3OeYrhR
全然似てないと思うな。LiteFSはConsulを使ってPostgresみたいにシングルリーダー・マルチレプリカ構成のリーダー選出をするんだ。rqlite（前に見た感じだとね）は直接Raftを動かして、書き込みごとにクォーラムを取る。どっちが良いってわけじゃないけど、LiteFSはrqliteみたいな意味での”分散SQLite”じゃないよ。何十年も前からあるログシッピングみたいにリードオンリーレプリカを作るためのシステムだよ。
rqliteは専用のクライアントライブラリを使う必要があるけど、LiteFSはプログラムからは透過的だよ。
＞ Now that we’ve switched to LTX, this isn’t a problem any more. It should thus be possible to replicate /data/*.db, even if there’s hundreds or thousands of databases in that directory.
これが最大のネックだったんだよね。これで（理論的には）テナントごとにDBを持つマルチテナント構成で、各ユーザーが特定の時点にロールバックしたり、DBを完全にダウンロードして持ち出したりするのが可能になるはずだよ。
今のLitestream使ってる人が新しいのにアップグレードするには何が必要なの？バージョン上げるだけでいけるのか、それとも他に何かいる？
超いいね！これすごい賢いし、デプロイめっちゃ簡単になるね。うちは（たくさんの）数千個のSQLite DBをバックアップしなきゃいけなくて使えなかったんだ。とりあえずfanotifyとSQLiteのBackup API使って適当にコピるの作ったけど、ワイルドカードレプリケーションでこのファイル数いけるならLitestreamに乗り換えてみるつもりだよ。
新しいLitestreamって、条件付き書き込みに対応してないオブジェクトストレージでも動くの？
アプリの新バージョンをデプロイするとき、一般的なマネージドソリューションだと新しいサーバーインスタンスを立てて、ヘルスチェックが通ったら古いのは落として新しい方にトラフィックを流すよね。前はこれだと新しいインスタンスが古いサーバーの変更を取りこぼす可能性があって問題だったんだけど、今回の変更で解決されたの？
サーバーをWebサーバーインスタンスじゃなくプロダクションDBとして考える必要があると思うよ。自分のPython/SQLite Webアプリの新バージョンデプロイでは、マシン全体は変えず、Pythonパッケージ上げてsystemdサービス再起動するだけ。ダウンタイム減らしたいならSO_REUSEPORT移行も考えられるけど、DB同時使用への対応が必要。スキーマ変更あるアップグレードだとダウンタイム避けられるか不明。従来のDBでもできるか分からないけどね。
これって簡単に解決されるわけじゃないと思うな。リースを持ってるライターはまだ一つだけだからね。新しいサービスが起動しても、前のサーバーがシャットダウンするまで書き込みリースは取れないよ。これを検知して、片方のライターを止めてもう片方を起動するツールはあるだろうけど、サービスはリクエストのキューイングかダウンタイムを経験することになるだろうね。
もっとコメントを表示（1）
fossil（sqliteベース）とこれ（Litestream）を組み合わせたらSCM（ソースコード管理）になるの？
fossil版のGitHubを誰か作ってくれないかな。名前がPaleontologyだったらマジ最高なんだけど。
fossilを便利にするのにそんなの必要？基本Gitで言うGitHubみたいに全部入ってるし、P2Pで動くから centralized serviceはいらないでしょ。discovery（見つける）のためなら分かるけど、”GitHub for Fossil”じゃなくて検索エンジンとかポータルみたいなもんじゃない？
あと、俺の知る限りだとCI連携が全くないんだよね。組織で使うプラットフォームとしてはそれって絶対必要（個人的には）。そういえばfossilの今の状況調べてたらこれ見つけたんだけど、https://fossil-scm.org/home/doc/trunk/www/qandc.wiki#:~:text… これ見て爆笑したけど、正直導入のハードル高いよ。Bugzillaファンがいるのは知ってるけど、あんなゴミみたいなBugzillaで仕事するくらいなら速攻辞めるね。
大規模にみんなに使われるのを妨げてるのって、結局Discovery（見つけてもらうこと）と market dominance（市場での支配力）だけみたいだよね。
”mass”（大規模普及）ってのをどう考えるかによるよね。だって（a）世の中にはGitHub APIしか対応してないツールがめちゃくちゃいっぱいあるし（GitLab、Giteaとかは言うまでもないとして）、（b）AIUIではfossil開発者たちは履歴変更をめっちゃ嫌うらしいから。それは彼らにとっては良いけど、一部のGitユーザーには全然良くない。Mercurialの”please don’t”をもっと強くした感じかなって俺は思ってる。
LitestreamってLiteFSの機能も取り込む感じなの？ Re：PITR（ポイントインタイムリカバリ）の話だけど、これってAIが作ったコード変更をlive data（実データ）の一部で自動A/Bテストするのに使える？その方向でマジ色々面白いことできそう。Ben、これマジ最高だわ！
最高すぎる！ これで1つのLitestreamプロセスでSQLiteの*.dbファイルがフォルダごと全部複製できるようになるっていう、俺の一番欲しい機能が叶ったわ。ついに来たって感じで超嬉しい。これでMulti tenant（マルチテナント）でユーザーごとにSQLite使うのが、もっとやりやすくなるはず。
こういうアーキテクチャの本当の”advantages”（利点）がまだよく分かんないんだよね。centralized（中央集権型）のPostgresサーバーでも同じくらいのデータ処理できるんじゃないの？
データベースサーバーへのクエリのネットワークのやり取りって積み重なっていくから、それがクエリの設計にも影響するんだ（n-tier（n層アーキテクチャ）が当たり前になってきて、今はあんまり意識しないけどね）。SQLiteのadvantage（利点）は、クエリがめちゃくちゃ速いことだよ。
なるほど！ありがとう。
Litestreamは”レプリケーションされるローカルDB”って言われるけど、”中央DBで、サーバーコードの近くに同期されるローカルキャッシュがある”って見た方が分かりやすいかもね。同じことだけど、ローカルキャッシュで読み書きするっていう意図が明確になる気がするよ。
これいいね！特にLitestreamがちゃんとメンテされてて嬉しいよ。
バックアップ以外の使い道ってあるのかな？
オ●フラインファーストは好きだけど、デバイスのSQLiteインスタンスを一つの中央インスタンスに同期する方法があるといいな。
バックアップとリードレプリカが主な使い道だよ。
ローカルファーストに興味があるなら、cr-sqlite[1]みたいなプロジェクトをチェックしてみるといいよ。
[1]: https://github.com/vlcn-io/cr-sqlite
＞ リードレプリカ
これってLitestreamだけでできるの？それともLiteVFSはまだ開発中？去年LiteFSのFUSEによる書き込みパフォーマンス低下[1]でやめたんだよね。LiteVFSはまだWIP[2]で1年以上更新されてないみたいだし。
[1] https://fly.io/docs/litefs/faq/#what-are-the-tradeoffs-of-us…
[2] https://github.com/superfly/litevfs
Benさん、素晴らしい仕事ありがとう！
あと、これについても調べたのを覚えてるよ: https://github.com/vlcn-io/cr-sqlite/issues/444
すごくいいね！
ここにタイポがあるかもね:
＞ The most straightforward way around this problem is to make sure only one instance of Litestream can replication to a given destination.
”can replicate” か ”can do replications” かな？
Fly.ioの人いる？
PostgreをCloudflare D1（これもSqliteベースだよね）みたいにこれで置き換えられるの？
Compare-And-SwapをサポートしてるS3互換オブジェクトストレージプロバイダーのリスト持ってる人いる？
進捗が見れて聞けて最高だよ。
Benが何か開発してシェアしてくれるのはいつも嬉しいね。
この調子で頑張って！
安定版から0.5ブランチへの移行ガイドってある？
DockerサイドカーとしてPythonアプリと一緒にLitestreamを使ってて、SQLiteのDBがS3にバックアップされててすごく安心なんだ。
Litestreamのアップデート超嬉しい！ずっとPocketbaseと使ってて、安くて reliable で safe な backend にはチートコードみたいだよ。
Litestream、最近あんまり開発されてないと思って心配だったんだよね。でもBen Johnsonが続けてくれて嬉しいわ。新しい計画も exciting だね。
LitestreamとLiteFSのアイデア大好きで、ちっちゃなプロジェクトで使ってるんだ。でも開発止まったかと心配してた。「もう完成」と「放置」って紙一重だし。この分野にはまだまだ untapped potential あるし、benbjohnsonが開発続けてくれて嬉しい。新しいリリースで複数のDBファイルを replication できるのは超いいね！S3とかTigrisが conditional write support 提供してるって話だけど、SFTPとか一部のS3互換ストレージにはこの機能ないから、これが hard requirement にならないことを願うよ。
俺も数ヶ月前に似たツール調べた時、同じ結論になったよ。Litestreamの最終リリース2023年でDockerイメージ1年以上前だったから。結局、ちょっと不便でもバックアップ頻繁に取る方が safer かなと思った。
BenってBoltDBも書いた人だけど、あれもcommunity活発なのに何年も untouched （archivedまで）だったんだよね。完成したらもういいって時もあるんだよ！
2週間前にactiveなcommitあるみたいだよ。mainブランチじゃないけどね。
S3 compatibleなobject storageから直接ページ fetch して cache できるようになるって？それってSQLiteのDBサイズがlocal disk capacityに制限されなくなるってこと？
LiteVFSのrepo見ると、いくつかの limitation 付きでそうみたい。「LiteVFSはLiteFS Cloudをbacking storeとして使うSQLite向けのVirtual Filesystem extensionだよ」
Limitations：
・journal_mode=walなDBはLiteVFS経由で変更ダメ（readはOK）
・auto-vacuumなDBはLiteVFS経由で開けない
・VACUUMは未support
SQLiteに手ぇ加えないで（Tursoの人がやったみたいにね）、WAL indexをネットワーク越しに共有するのって大変（impossibleじゃないけど）なんだよね。多分それが理由かな。俺、数千回mptestをCIで何ヶ月も回してるけど問題ないって結構 confident なhack知ってるよ。Benがinterestedかもだからここにlink貼っとく。
read-replicas に対応してて、cold data を object storage に offload できるSQLite DB、めっちゃ useful だろうね。
もっとコメントを表示（2）
Benが見てるみたいだから聞くんだけど、刷新されたLitestreamはトランザクションがストレージに永続的にコミットされたときだけACKを返すような解決策を持つのか？
バックエンドはプラグイン形式になってるの？楽観的並行性制御をサポートするkey value storeなら何にでも書き込めるように設定できるの？
今のところプラグインはサポートしてないけど、いくつかのバックエンドはあるよ（S3、Azure Blob Storage、Google Cloud Storage、SFTPなど）。
ちょっと話それるけど、今のSQLiteって書き込みはまだ直列なの？ピーク時に何千もの書き込みが発生する可能性があるアプリの技術スタックを選ぶときの俺の主な心配事なんだ。
そうだよ、でも秒間何千回もの書き込みでベンチマークしてみると、SQLiteは全然大丈夫だってわかるはず。秒間何万回とか何十万回とかになると問題が出てくるかもしれないけど、適切なハードウェアならそれでも大丈夫な場合もあるよ。
これについては2022年に書いた記事があるよ、今でも通用する内容だよ：https://www.golang.dk/articles/benchmarking-sqlite-performan…
そうだよ、でもね：https://sqlite.org/wal.html
pipで簡単にインストールできるLivestreamみたいなものってあるの？
すごく良いアイデアだね。fly.ioで小さなPostgres vmを使ったら、データ容量が少ないのにメモリ不足で失敗ループに入ってリカバリーに苦労した経験があるんだ。簡単に始められたけど、その後のリカバリーで時間を無駄にしちゃったよ。元はsqlite使ってたんだけどね。
この投稿はFly.ioのプラットフォーム提供物とは全然関係ない話だよ。LitestreamはFly.ioとは完全に切り離されてるんだ。Benは彼がここに来る前にこれを始めたんだよ。
確かに、fly.ioがLiteFS/Litestreamをユーザー向けの理想的なDBとして推してるんだから、fly.ioと関係あるって思われるのは当然だよね。他のfly.ioのサービスと比べられるのも無理ないと思うよ。
いやいや、fly.ioはLiteFS/Litestreamをそんな推してないって。うちはPostgresがメインだし、昔あったLiteFS Cloudも1年以上前に終わってるよ。今はマネージドPostgresに力入れてるんだ。記事を書くのは、その人が興味あるからだよ。BenがLitestreamについて書いてるのも、基本的には自分の興味からなんだよ。
LiteFSもLitestreamも（当たり前だけど）終了してないよ。どっちもオープンソースのプロジェクトで、fly.ioに頼らなくても動くように慎重に設計されてるんだ。
Supabaseとの連携はどうなったの？これも立ち消えになったみたいだね。
マネージドPostgresをまだ提供してないのが変だなって思うんだよね。RenderとかHerokuはやってるのに、fly.ioはGPUとかLitestreamに注力してるみたいだね。スタートアップでPaaSを選んだ時、Postgresが必要だったからfly.ioは検討もできなくて、Renderにしたんだ。
マネージドPostgresは、すごくゆっくりだけど展開してるところだよ。
あれ、ベータ中だと思うよ。マネージドRedisもあったら良かったんだけどね。PostgresはNeon (neon.tech) を使うことにして、今のところすごく満足してる。セットアップも立ち上げもすごく簡単だし、Webインターフェースからデータを簡単に見れるのも気に入ってるよ。
fly.ioのマネージドPostgresのドキュメントだよ。
Railway 使ってみなよ．こいつらマジ最高．値段も手頃だし，開発者のUXもめちゃ良いよ．
それってsupabaseの代替になるの？
renderとかRailwayとかnorthflankとかflyみたいなやつだよ．新しい世代のPaaSの一部かな．
月29ドル払ってみるのも手だよ．メールサポートはめちゃくちゃ良いと思ったね．
それが，彼らのPostgresインスタンスを使わない理由の一つなんだ．その代わりに専用のデータベースサービスを使ってるよ．でも，バックエンドアプリのデプロイにはかなり良いと思う．
ちょっと注意ね，”Litestreamは完全にオープンソースだよ”って呼びかけの中のリンクが間違ってるよ．https://http//litestream.io/ に飛んじゃう．
かなり新しいものにしては，もう選択肢が多すぎる気がするな．一つの名前で戦略を決めて，良いデフォルトといくつか設定オプションだけにしてほしいな．
それ，もしかしたら構造かCSSの問題だと思うな．デスクトップだと記事の左側にあるんだけど（ウィンドウを縮小したら確かに記事の下に来たよ）．
