SQLiteデータベースの現実的で現実的な最大サイズとは何ですか？

SQLiteの適切な使用に関するこの記事によると、SQLiteは140テラバイトに制限されていますが、クライアント/サーバーRDBMSはより適切に動作する可能性があります。

SQLiteデータベースのサイズは、140テラバイト（2 ⁴⁷バイト、128ティビバイト）に制限されています。また、より大きなデータベースを処理できたとしても、SQLiteはデータベース全体を単一のディスクファイルに保存し、多くのファイルシステムはファイルの最大サイズをこれよりも小さいものに制限します。したがって、この規模のデータベースを検討している場合は、コンテンツを複数のディスクファイル、おそらく複数のボリュームに分散するクライアント/サーバーデータベースエンジンの使用を検討することをお勧めします。

一般的に、私はこれに同意しますが、SQLiteの最大制限が非常に高いことを知って驚いたのです！私の経験では、30〜100GBのサイズのSQL Serverデータベースをかなり使用しました。また、Oracle、Postgres、またはCassandraを使用して、はるかに大きなデータベースを間接的に操作しました。そのうち、少なくとも私の知る限り、140TBに近づいている人はいませんでした。私はDBAではないので、これは私の直接的な経験から「大」と考えるものです。

データベースが小さい場合にのみ、SQLiteを検討しました。最大で数十メガバイト。

この記事を読んだ後でも、数百ギガバイトを必要とするかもしれないもののためにSQLiteを検討することをまだ確信していません。しかし、その能力を過小評価していたのではないかと思っています。実際の使用でのSQLiteデータベースの現実的な最大サイズ制限とは何ですか？

（一部のSqliteデータベースのサイズの）現実的な制限は、データファイルの現実的な制限と同じです。そして、その制限はコンピューターとシステムの多くに依存します。現在のLinuxデスクトップでは、350ギガバイトのファイルよりもはるかに大きい余裕はありません（経験則として、1つのファイルがディスクパーティションの半分以上を消費することは避けています）。ところで、その実際的な制限は、PostGreSQLやMariaDBなどの他のSQL RDBMSにも影響を与えます（ただし、これらのほとんどは複数のファイルにデータを保持しています。異なるファイルシステムに保持する場合があり、それらの一部はリモートマシン上の分散データを管理できます）。 ）

この記事を読んだ後、数百ギガバイトを必要とするかもしれないもののためにSQLiteを検討することをまだ確信していない

あなたは正しいと間違っています。

あなたの言うとおりです。今日のコンピューター（スーパーコンピューターやデータセンターサーバーではなく、ラップトップとデスクトップ）では、100ギガバイトが依然として非常に大きなディスクスペースです。したがって、実際には、このような大規模なデータベースを考える場合、特に実際のSQLサーバー（PostGreSQLなど）を想像する方が良いでしょう。リモートアクセス、実質的に同時アクセス、およびおそらく分散データとテーブルが必要になるからです。

SQLiteは数百ギガバイトのデータベースを扱うことができる（そしてテストされることもある）ので、あなたは（原則として、私が試したことはありません）間違っています。少なくとも）。

私は確かに（時には）数十ギガバイトのデータベースにSQLiteを検討します（かつて、このような大きな.sqliteファイルである40GバイトのIIRCを試しました）。現在の（スーパーコンピューターではない）マシンでは、何百ギガバイトのSQLiteデータベースがあるのをためらうでしょう。なぜなら、そのようなファイルは今日の慣例ではかなり大きいからです。

特殊なファイルシステムマシンを販売しているハードウェアベンダーのIIRCが、テラバイトのsqliteアプリケーションの1つを私に話しました（しかし、私は間違っているかもしれません）。

もちろん、SQLiteの性能は（すべてのSQLデータベースのように）依存し、多くのテーブル、そのインデックス、関連するSQLクエリの数と幅の。そして、（多くの異なるプロセスによる）同時アクセスを望んでおらず、トランザクションを使用する必要があります（経験により、数メガバイトの小さなSQLITEデータベースでも、例えば1000件の挿入要求をBEGIN TRANSACTION＆END TRANSACTION、それをしないと、Sqliteが大きな要因（10倍以上）で遅くなります）。

そして、個人的な経験により、適切な構成と編成により、SQLiteは使用可能なRAMよりも大きいデータベースを管理できます（したがって、30Gバイトは問題になりません）。

「スーパーコンピューター」または高価なワークステーション（たとえば、512GバイトのRAM、8Tバイトのディスク、512GバイトのSSD）用に何かをコーディングする場合、テラバイトのSqliteデータベースを使用できます。ただし、1つ（または非常に少数）のプロセスがそのデータベースにアクセスしている場合にのみ、おそらくそれを行う必要があります。同じデータベースに同時にアクセスするプロセスが多数ある場合は、実際のSQL RDBMS（MalaDBまたはPostGreSQL）をより適切にインストールします。

また、.sqliteデータベースファイルの（バイナリ）形式は「ポータブル」であると文書化されていますが、SQL テキスト形式（を使用sqlite3 mydb.sqlite .dump > mydb.sql）でデータベースをバックアップすることを好みます。次に、テキストダンプ用に追加のディスク領域も必要になります（現実的な制限を下げます）。

通常、Sqliteはボトルネックではありません。しかし、ディスクはそうかもしれません。

PS。GDBMを使用して、同じ推論を大きなインデックス付きファイルに適用できます。

^{PPS。私にはexpjsの私のMELTモニター（githubの上のGPLv3のフリーソフト）の枝（sept.2016）私は持続新鮮Sqliteをデータベース内部JSONで全体のアプリケーション・ヒープを。私は数百万のオブジェクト（非常に「大」）を使って、驚くことなく小さな実験を実行しました。YMMV。}