ハクソク

世界を動かす技術を、日本語で。

SQLiteはアメリカ議会図書館推奨のストレージフォーマットです

12時間前原文(sqlite.org)

概要

  • SQLite は米国議会図書館（Library of Congress）が推奨するデータセット保存フォーマットの一つ
  • 他の推奨フォーマットは XML、JSON、CSV のみ
  • 推奨フォーマットは 長期保存とアクセス性 を最大化する目的
  • 選定基準には 公開性、普及度、透明性 など複数の観点を含む
  • 詳細情報はLOC公式サイトで公開

LoC推奨保存フォーマット概要

  • SQLite は、データセット保存用推奨フォーマットとして米国議会図書館（Library of Congress, LOC）により選定
  • 推奨フォーマット一覧： SQLite、XML、JSON、CSV
  • 最新情報はLOC公式ページで確認可能
    • https://www.loc.gov/preservation/digital/formats/fdd/fdd000461.shtml#local
    • https://www.loc.gov/preservation/resources/rfs/data.html

推奨保存フォーマットとは

  • 推奨保存フォーマット ：デジタルコンテンツの長期保存・持続的アクセス性を最大化する形式
  • 選定は 保存専門家 による評価
  • 主な選定基準
    • 公開性 ：完全な仕様・技術的検証ツールの有無とアクセス性
    • 普及度 ：主要な作成者・利用者間での利用状況
    • 透明性 ：テキストエディタ等による直接解析のしやすさ
    • 自己記述性 ：基本的なメタデータ（説明、技術、管理情報）の内包
    • 外部依存性 ：ハードウェア・OS・ソフトウェアへの依存度と将来の対応難易度
    • 特許の影響 ：アーカイブ機関による維持管理を妨げる特許の有無
    • 技術的保護手段 ：信頼できるリポジトリによる保存を妨げる暗号化等の実装有無

推奨フォーマット選定基準の詳細

  • 公開性
    • 標準化団体の承認よりも 完全なドキュメント の存在が重視
  • 普及度
    • マスターフォーマット、エンドユーザー配布、システム間交換手段としての利用実績
  • 透明性
    • 人間可読性 やシンプルなツールでの解析性
  • 自己記述性
    • ファイル自身に含まれる 説明的・技術的・管理的メタデータ
  • 外部依存性
    • 特定の ハードウェアやソフトウェア への依存度
    • 将来的な技術環境での対応の複雑さ
  • 特許の影響
    • 特許権 による保存・維持の妨げリスク
  • 技術的保護手段
    • 暗号化等 による信頼できるリポジトリでの保存阻害有無

まとめ

  • SQLite は、他の主要なデータ保存フォーマット（XML、JSON、CSV）と並び、 長期保存・継続的アクセス に最適と評価
  • 選定基準 を満たすことで将来にわたるデータの 安全な保存 を実現

Hackerたちの意見

SQLiteが大好きなんだよね。でも、いくつかの企業ではその使用を禁止しているって聞いた。なんでだろう？アプリのためにデータベースを設定するのがめっちゃ簡単だから、アプリの超重要な部分がファイルみたいになっちゃうんだよね。拡張子は何でもありで、そのファイルを他のサーバーにコピーできちゃう。個人情報が含まれていても関係なし。これが会社のアプリの数だけあったら、ちょっとヤバいことになるよね。DevOpsやDBAのチームは、データベースが大きくて重い、明らかにデータベースサーバーって感じのものがいいんだろうね。接続したときも、すごく分かりやすいし。まあ、それでもSQLiteは好きなんだけど。

└

それ、めっちゃアホだね。

└

問題は、同じ企業がExcelを禁止しているかどうかだよね。Excelのスプレッドシートって、意外な場所でシャドウデータベースになっちゃうことが多いから。

└

DevOpsやDBAのチーム ああ、誰も聞くべきじゃない二つのチームだね。

└

sqliteには面白い使い方があるよ、これみたいなやつね: https://sqlite.org/sqlar.html

2026年推奨ストレージフォーマット: https://www.loc.gov/preservation/resources/rfs/data.html

公共部門のデータ保存に関しては、これが一番の選択肢かもしれない。仕様が公開されてるし、広く採用されてるし、将来的にも読みやすい可能性が高い。特定のOSやサービスへの依存が少なくて、特許リスクも低い。長期的な継続性の観点から、特定の会社やサービスに依存しないことはめっちゃ重要だよね。

└

アーカイビストもネイティブに近いフォーマットが好きなんだ。SQLiteは、csvでは表現できないリレーショナルな関係を持たせることができるから。

それ、めっちゃ面白い！ちょうど同僚の図書館員にSQLiteのこの事実を話してたところなんだよ！

この記事を書いている時点（2018年5月29日）で…このニュースはほぼ6年、いや8年も前のものだね。でも、今まで知らなかったから全然文句じゃないよ。むしろ、投稿してくれてありがとうって感じ。 （訂正ありがとう。数学のところでちょっと頭が混乱しちゃった。）

└

いや、2026年だよ。もう8年経ってる。

└

これを読んでデジャヴを感じてたところだった。

最近のプロジェクトでexFATを使う必要があったんだけど、exFATは色々とひどい理由があって、特に問題だったのはジャーナリングがないこと。電源が切れたりするとファイルが壊れる可能性があったんだ。最初は一連のファイルを書いて、新しいファイルで擬似的な追加専用のことをやって、古いファイルを圧縮してジャーナリングを再発明しようとしたんだけど、まあそれなりにはうまくいったけど、すごくアドホックで悪かったし、後で直さなきゃいけないバグを隠してたと思う。そしたらSQLiteを思い出した。ACIDが自分のニーズには十分安全だって気づいて、再発明してた難しい部分は、きちんと監査されてテストされたものを使った方が速くて壊れにくいだろうと思ったから、やってたことを全部SQLiteに書き直したら、うまくいったよ。exFATが燃えて消えて、ジャーナリングファイルシステムが「どこでも使える一つのファイルシステム」として置き換わってほしいけど、それが実現するまでSQLiteが存在してくれて感謝してる。

└

exFATが燃えて消えて、ジャーナリングファイルシステムが「どこでも使える一つのファイルシステム」として置き換わってほしい それって具体的にどこが「どこでも」なの？Win32？Linux全部？BSD？MacOS？iOS？…

└

問題は、実際の一番大きな問題を解決してないってことだよ。まだ問題にぶつかってないから、自分の問題が解決したと思ってるだけなんだ。

「SQLiteはおもちゃみたいな製品で、実データには信頼できない」と思ってたのが、「ほとんどすべてにSQLiteを使おう」って考えに変わったよ。SQLiteは、単一のライターと複数のリーダーのパターンに収まるならすごく良い。正しい設定を使えばデータを失うことはないし、それを理解するのにGoogle検索で1分もかからないよ。今では、ほとんどのアプリが単純にGoバイナリ + SQLite + systemdサービスファイルで構成されてる。まだデータを失ったことはない。パフォーマンスも素晴らしくて、ほとんどのアプリには十分だよ。

└

シングルライターの問題は、実際には言われているほど大きくないよ。最近のnvmeドライブはすごくて、最適化されたWALセットアップで毎秒5kの書き込みが簡単にできるんだ。ほとんどのアプリが夢にも思わないくらい多いよ。それに、バッチライターパターンを使って、一般的なVPSで毎秒180kの書き込みを実現したこともあるよ。

SQLiteが大好きで、シェアしてくれてありがとう！でも、タイトルの最後に「(2018)」が必要だと思う。 > 現時点（2018-05-29）で、データセットのために推奨される他のストレージ形式はXML、JSON、CSVだけだよ。

└

ちなみに、その後にリストにもっと多くの形式が追加されたよ。優先されるのは、1. プラットフォームに依存しない、文字ベースの形式が、ネイティブやバイナリ形式よりも好まれる。データが完全で、詳細と精度を保持している限りね。好まれる形式には、よく発展していて広く採用されている事実上の市場標準が含まれる。例えば、a. 公開された検証ツールがあるよく知られたスキーマを使用した形式 b. 行指向、例えばTSV、CSV、固定幅 c. プラットフォームに依存しないオープン形式、例えば.db、.db3、.sqlite、.sqlite3 2. 職業の事実上の標準であるか、複数のツールにサポートされているプロプライエタリ形式（例：Excel .xlsまたは.xlsx、Shapefile） 3. 文字エンコーディング、好まれる順に: a. UTF-8、UTF-16（BOM付き）、b. US-ASCIIまたはISO 8859-1 c. その他の名前付きエンコーディング --- データに関して（好まれる順に）: 1. プロフェッショナルコミュニティまたは政府機関によって標準として支持されている、非プロプライエタリで公に文書化された形式、例：CDF、HDF 2. 利用可能なスキーマを持つテキストベースのデータ形式 集約または転送用: 1. 暗号化やパスワード、その他の保護メカニズムなしのZIP、RAR、tar、7z。 https://www.loc.gov/preservation/resources/rfs/data.html

SQLiteにはいつもインスパイアされてる。全体的には好きだけど、書き込みをしないなら本当にオーバーキルだよね。だから、SQLiteを超えないフォーマットを作ったんだ。ただ、すごく軽くて速くて、zstd圧縮ファイルで動くんだ。インデックスがすごく小さくて、SQLiteみたいにバイナリやテキストも含められる。データベースを解凍して読み込んで検索するためのwasm部分は38kb（未圧縮で、もしかしたら16kb gzipped）なんだ。SQLiteの1.2mbのwasmとグルーコードと比べると、サイズは3%だけど、検索と読み込みはずっと速いよ。僕のプログラムは本当にカラムベースじゃなくて、スプレッドシートの管理には向いてないけど、辞書や画像・音声のファイルアーカイブには最適だよ。jbig2デコーダーを17kbのwasmモジュールとして移植したから、8kbのモノクロスキャンを読み込んでもまだ判読できるんだ。 https://github.com/tnelsond/peakslab SQLiteはすごくよく設計されてるけど、PeakSlabはすごくシンプルだね。

└

なんか、XKCDの競合する標準についての話があったような…

└

もしかしてバカな質問かもしれないけど、書き込みしないでデータをどうやって入れるの？

職業の事実上の標準で、複数のツールにサポートされているプロプライエタリ形式（.xls、.xlsx）が優先セクションに含まれているのには驚いたよ。[1] 「十分に知られている」って、保存の観点から「オープン」と同じくらい良いのかな。 [1] https://www.loc.gov/preservation/resources/rfs/data.html

└

xlsxを解凍して、中のxmlを読むことができるよ。これが最悪の形式ってわけじゃないね。

└

特にOffice 365が、マイクロソフトですらOfficeファイルを表示できるソフトを作れないことを示している時には…もしWordアプリで作成されたり、修正されたWordファイルがあったら、Office 365でブラウザを通して扱うのは本当に面倒だよ。ウェブ版では削除も移動もできない画像があったり、絶対に間違った場所に表示されることがあるからね。