OSの高速化で話題になる「SQLite」って何？

データを検索するために

コンピュータに入力したデータは、そのほとんどがあとから容易に検索でき、素早く見つけることができます。ただ、テキストファイルのようなデータはそうはいきません。本連載のような2ページ程度の記事から指定した単語を拾い出す程度ならともかく、何百ページもある書類から指定した1枚だけを探し出すといった検索は、コンピュータでもそう簡単にはできないのです。

そこで、ただ単純にデータを積み上げるのではなく、検索しやすく、処理しやすいようデータの形を整え順序よく並べ直すことで、検索や更新、削除の効率を上げるということがコンピュータの黎明期より行われてきました。この、検索しやすいよう整理されたデータの集まりを「データベース」と呼びます。

一方、データベースの中でも個別データを格納する「表」と、「その表と他の表にあるデータの間の関係」を定めて、より複雑な条件での検索ができるデータベースを「リレーショナルデータベース（Relational DataBase＝以下、RDB）といいます。そして、このRDBを作ったり、その中のデータを検索したり編集したりする一連のソフトウェアが「RDBMS（Relational DataBase Management System）です。

自由に使える「SQLite」

「SQLite」は、D・リチャード・ヒップ氏が提供しているRDBMSです。その特徴は2つ。パブリックドメインで誰もが自由に利用できること、そして、組み込み型RDBMSであることです。

業務向けの「オラクル（Oracle）」や「SQLサーバ」、オープンソースの「MySQL」や「PostgreSQL」といった一般的なRDBMSは、「サーバクライアント型」になっています。RDBMSとしての処理は強力なサーバマシンで行い、データベースを利用したい各ソフトウェアはクライアントとして接続するという方式です。この方式を採用すると、同じデータベースを多数のクライアントで共有できますし、処理を別マシンに分けることで性能の向上も期待できます。

一方、SQLiteはライブラリの形で提供され、ソフトウェアなどに内蔵されます（「組み込み形式」）。そのため、データベースの利用はソフトウェアだけにとどまります。この方式は、サーバを利用してデータを上手に共用したり、負荷を分散することには向いていませんが、メールの送信者や件名を全部データベースに格納しておく、ブックマークを格納しておくなどして検索を高速化するなど、デスクトップソフトウェア個別での利用に適しているといえます。

macOSやiOSでは、SQLiteをメールやサファリといったソフトウェアからコアデータ（CoreData）まで、さまざまなところでデータの管理に利用されています。また、アップル以外にも、WEBブラウザ「ファイアフォックス」などもSQLiteを内部で使用していることで知られます。

組み込み形式

データベースはローカルマシンに存在し、ソフトウェアなどに組み込まれたRDBMSからアクセスされます。複雑な処理や拡張性は乏しいですが、ソフトウェアの持つデータを管理するなら十分といえます。RDBMSを利用することでデータの管理方法、検索方法をプログラマが自身で実装する必要がなく、工数が省ける点もメリットになります。

サーバクライアント方式

データベースはサーバマシンで管理され、ネットワークを通じてクライアントから検索やデータの更新処理が行われます。高負荷のデータベースの処理はサーバで集中でき、また多数のクライアントで同じデータベースを検索できることから、拡張性も大きいのです。

「vacuum」で並び直す

SQLiteがOSの高速化テクニックによく出てくるのは、そのデータベースが定期的にメンテナンス処理が必要になるという点にあります。SQLiteは、データの更新や削除のときに「このデータは無効」とマーキングだけを行い、実際の削除などを行わないためです。

こうした追加削除の繰り返しにより、データの並びが雑然と分かれてしまう「断片化」が発生し、必要なデータへのアクセスがわずかながら遅くなっていくのです。さらにマークされただけの無効なデータを抱えたままのデータベースファイルは当然肥大化していきます。肥大化することで、単なるアクセスにもより多くのIOが必要になります。

そこで、SQLiteにはマークされた無効データを削除し、データをよりアクセスしやすいよう並び直す操作が用意されています。このコマンドが「vacuum」です。

vacuumを実行すると隣に新しいデータベースファイルを作成し、有効なデータだけを順序よくコピーして、アクセスしやすいように並べ直し、コピーが終わったら元のデータベースファイルと入れ替えをします。不要なデータはコピーされないので、データベースファイルは必要なサイズに縮小され、断片化も解消するので読み込みが速くなります。

ファイルの肥大化を防ぐ

さて、では頻繁にvacuumを実行する必要はあるでしょうか? 実のところ、そこまで頻繁にする必要はありません。

まず、そもそもSQLiteは多少の断片化程度では性能が落ちません。こまめにvacuumしなくても、遅いと感じるようになってから実施すれば十分なのです。年末の大掃除のついでとか、季節に1回とかその程度のタイミングで構いません。

また、最近のSQLiteのデータベースファイルでは、ファイルの肥大を防ぐ「auto_vacuum」が有効になっていることが多いためです。auto_vacuumは2005年頃のSQLiteから追加された機能で、書き込みや削除といった操作の直後に、マーク済みのデータだけになったページをファイルの最後尾に持っていき、切り落とすという操作を行い、ムダなデータがデータベースファイルを占めることを予防します。

注意しなくてはいけないのが、auto_vacuumは「表」が作られる前にデータベースファイルに設定する必要があるということです。つまり、もう作成されているデータベースファイルには追加することができません。また、データベースファイルの肥大化は防げますが、データの断片化に関しては対応できません。なので、auto_vacuumがあればvacuumがまったく不要というわけでもないのです。

最近のmacOSのデータベースファイルではauto_vacuumは有効になっているので、さらにvacuumの必要性は低く、定期的に行わず、本当に「遅いと感じたら」で十分になってきています。

【 SQLiteのライセンス】

SQLiteが選択される理由として、「パブリックドメイン」である点も見逃せません。オープンソースやフリーソフトではそのソフトウェア著作権自体は作者が保持しており、あくまで利用許諾の一環として「ソースを公開すること」、「ソースの改変の許可する」などを取り決めています。一方、パブリックドメインでは著作権そのものも放棄して、誰のものでもないもの、世間で自由に共有できるものといえます。SQLiteを利用すること自体はもちろん、自身のソフトウェアに組み込んだりSQLiteの内部を改造しても構いません。また、オープンソースと異なり、改造した結果のソースコードを公開する義務もありません。営利企業であるアップルとしては非常に扱いやすいソフトウェアであるといえます。

【サーバクライアント方式のRDBMS 】

データベースそのものは中央の強力なサーバに配置し、端末やWEBサーバのように、データベースにアクセスする側にはクライアントソフトウェアをインストールし、クライアントからサーバに問い合わせをする方式がクライアントサーバ方式です。多数のユーザが同時に同じデータベースをアクセスできること、常に最新の情報にもアクセスできること、強力なサーバマシンに負荷の高いデータベースの処理をまかせられることなどの利点があります。「MS SQL Server」やオラクルといった著名なRDBMSはほとんどがクライアントサーバ方式です。

【ページ】

SQLiteでは「ページ」という単位でデータベースファイルを管理しています。ページサイズは512バイトから64KBまで設定可能で、デフォルトは1KBないし4KB（SQL3.12.0以降）です。

【削除】

SQLiteでは、データの更新は「新しいデータの書き込み」と「前のデータの削除」で実装されています。なので、更新でも削除が発生し、無効なデータが生じるというわけです。