SPHiveDB: 基于 sqlite 的数据库服务器

在 share nothing 的架构中，如果数据规模很大，为了提高可用性，通常采用数据库分片（database sharding）的策略。常见的分片策略是按主键把数据分散到不同的数据库中。在使用常规的 RDBMS 的场景中，分片策略中使用的数据库个数通常在100以下。在某些特殊的场景中，可能希望采用更极端的分片方法，比如在类似地址本这种应用中，可以为每个用户创建一个数据库。

SPHiveDB 就是为这种极端的分片方法而实现的一个数据库服务器。SPHiveDB 基于 sqlite ，用 JSONRPC over HTTP 为 sqlite 提供了网络访问接口。为了能够支持大量的数据库实例，SPHiveDB 把多个 sqlite 数据库合并保存到一个文件中；支持同时使用多个数据库文件。

http://code.google.com/p/sphivedb/
http://freshmeat.net/urls/01b9b3be9ec4e19ebd6a8e6208f3a0a1
http://sphivedb.googlecode.com/files/spmemvfs-0.2.src.tar.gz

×× 内部结构示意图



SPHiveDB 使用 Tokyo Cabinet 作为最终的物理存储，每个用户对应的 sqlite 数据库以用户名为 key 保存在 Cabinet 中。为了支持能够从 Cabinet 中加载 sqlite 数据库，为 sqlite 实现了一个 memvfs 。通过 memvfs ，使得 sqlite 能够在内存中加载和保存数据。SPHiveDB 支持一个进程同时使用多个 Cabinet 文件，使得单一 server 能够支持尽可能大的存储空间。


×× JSONRPC 请求和响应示例

{
        "method" : "execute",
        "params" : [
                {
                        "dbfile" : 0,
                        "user" : "foobar",
                        "dbname" : "addrbook",
                        "sql" : [
                                "insert into addrbook values ( 1, \"foo@bar.com\" )",
                                "select * from addrbook"
                        ]
                }
        ],
        "id" : "foobar"
}

dbfile 指定操作哪一个 Cabinet 文件；user + dbname 指定操作哪一块数据；sql 需要执行的 sql 语句，支持批量执行多个 sql 语句，使用 all-or-nothing 的策略，要么全部成功，要么全部失败。dbname 还用于指明第一次操作一块数据时，用什么语句来创建 sqlite 数据库。用于创建 sqlite 数据库的语句保存在 sphivedbsvr.ini 配置文件中。以 ddl. 开头的配置节用于指定对应数据库的创建语句。

[ddl.addrbook]
create table if not exists addrbook ( id int, addr varchar(64) );

{
        "result" : [
                {
                        "name" : [ "affected", "last_insert_rowid" ],
                        "type" : [ "int", "int" ],
                        "row" : [ [ 1, 1 ] ]
                },
                {
                        "name" : [ "id", "addr" ]
                        "type" : [ "int", "varchar(64)" ],
                        "row" : [ [ "1", "foo@bar.com" ] ],
                }
        ],
        "id" : "foobar"
}

result 返回 sql 语句执行的结果，name 对应的 array 为 column 的名字，type 对应的 array 为 column 的类型，row 对应的 array 是返回 recordset 。特别地，对于 INSERT/UPDATE/DELETE 也使用类似 select 的方式来返回，affected 是 sql 语句执行之后 sqlite3_changes 返回的值，last_insert_rowid 是 sql 语句执行之后 sqlite3_last_insert_rowid 返回的值。

发布 0.2 版。新增特性
1.在数据目录中，增加一层子目录，以便容纳更多的 tokyo cabinet 数据库文件。和 0.1 版的数据文件分布不兼容了。
2.按数据库种类，分成不同的文件。
3.根据配置文件中的 create table 语句，自动修改已经存在的 sqlite 数据库。目前只支持 add column 这一类的修改。

数据文件和目录的结构示意图



对应的配置文件

[ddl.addrbook]
create table if not exists addrbook ( id  INTEGER PRIMARY KEY AUTOINCREMENT, addr varchar(64), freq int, unique( addr ) );

[ddl.album]
create table if not exists album ( id  INTEGER PRIMARY KEY AUTOINCREMENT, name varchar(64), desc varchar(256), path varchar(256), size int );

这里展示了每个用户有两个数据库的情况，一个是 addrbook ，一个是 album 。
1）tokyo cabinet 文件以数据库名作为前缀，以 0 开始编号。
2）同样编号的各种数据库文件放在同一个子目录中。
3）每个子目录存放 100 个编号。

很好，，这个和我目前的架构有些类似的地方。

不过我是用 mysql来存放tokyo cabinet的key。

发布 0.3 版本。新增特性：
增加 spsqlitesvr ，接口和 sphivedbsvr 一样，使用同样的协议格式，唯一不同的就是数据的实际存储方式。spsqlitesvr 不使用 tokyo cabinet 来保存 sqlite 数据库，每个 sqlite 数据库直接对应一个文件。

文件的分布方式如下图所示：

能否描述一下你的架构呢？在网上找了一下，很少有类似架构的描述

JSON-RPC不如 cloudkit 使用的REST接口直观

http://timyang.net/architecture/yahoo-pnuts/

所谓的 REST 接口，现在还不懂，稍后 google 一下。
就以 cloudkit 的接口来看，它的功能是完全针对 json 数据库来做的。

sphivedb 采用 json-rpc ，是使用 json 来封装 sql 和 resultset 。
同时 json-rpc 几乎也在所有的语言中都有实现，容易做多语言的支持。

从这段描述来看， pnuts 在逻辑上是一个单一的表，然后支持了类似 mysql 分区的功能，当然这个分区的功能比 mysql 强大很多。

对数据文件格式，是如何设计的，能否多说点。

我在考虑，这会涉及数据读取方面，而这个是比较关心的