はじめに
(NoSQL)データベースをコンテンツ管理システム（CMS）あるいはファイルストレージとして利用するというアイディアはとりわけ珍しいものではなく、その機能を提供しているNoSQLサーバーもあります(例えば、MongoDB)。
ここでは、その意義と現状について整理します。
データベースによるファイル管理
データベースでファイル管理を行うメリットとして、まず機能面において、以下が考えられます。
- ファイルシステムの持つ制約からの解放（ディレクトリ内のファイル数上限など）
- メタデータ管理
上記の要件については、コンテンツ管理システムを用いることがまず考えられます。
あえて、データベースを用いる理由としては、以下が考えられます。
- シングル・プラットフォームで（準）構造化データと非構造化データの両方を管理したい
- 両方のデータに相互的に関連するロジックの実現
- 複数プラットフォームを管理する運用負担・コストの軽減
- 利用するデータベースに固有のメリットを活用したい
- 分散アーキテクチャの持つ利点（高信頼性、等）の活用、等
実現例の検討
MongoDB
一般にNoSQL（ドキュメント指向）データベースでは、扱えるドキュメントの最大サイズが決まっており、そのサイズを超えるデータを扱うことができないという制約があります。
MongoDBでは、その制約に対する対応として、複数のドキュメントで一つのファイルを管理する、GridFSという機能を提供しています。
Couchbase
Couchbaseもまたドキュメント最大サイズの制約を持ちます。
Couchbaseには、ビルトインの機能はありませんが、以下の様な試みが発表されています。
この試みでも、MongoDBのGridFSと同様、ファイルをチャンクに分割して保存する方式が取られています。
Flexible and Scalable Content Management using Apache Chemistry OpenCmis and Couchbase
Storing blobs in Couchbase for Content Management
クロスデータセンターレプリケーション (XDCR)
Couchbase Serverが採用される理由の一つとして、XDCR(Cross Data Center Replication)の機能があります（例えば、「安定稼動を実現したKDDI Business ID、その理由とは？」を参照）。
XDCRの存在は、地理分散コンテンツ管理システムをCouchbaseを用いて実現したいと考える動機になるかもしれません。
地理分散システム
「地理分散」という言葉から思い受かべられるイメージは、必ずしも一様ではないと思われ、ここで具体的な内容を整理したいと思います。以下の二つのパターンについて、混同しないことが必要です。
- 地理分散したノード間でデータをレプリケーションしながら、一つのクラスターを構成する
- 地理分散した複数のクラスター間で、データを双方向にコピーする
NoSQLの文脈で「地理分散」と言ったときに、はじめのケースを思い浮かべられる向きもあるかと思い、冗長だったかもしれませんが、あえて整理しました。
XDCRが実現するのは後者のケースです。この場合、クライアント/ユーザは、近いロケーションにあるクラスターを利用することで、データアクセス（リード/ライト）時に最適な応答速度を得ることができます。特にサイズの大きいファイルへのアクセスを考えると、近いロケーションのクラスターを利用する利点は、より大きいと考えられます。
最後に
幾分ニッチな話題を扱いましたが、本記事を目にされた方の関心と何らかの接点があれば、嬉しく思います。
参考情報
コンテンツ管理標準
CMIS (Content Manaement Interoperability Services
MongoDB
https://github.com/mdirolf/nginx-gridfs
MongoDBでゆるふわDB体験 第7回 GridFS─大容量のファイルをMongoDBに保存する仕組み
Couchbase
https://github.com/cecilelepape/cmis-couchbaseonly
https://github.com/cecilelepape/cmis-couchbase