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

底层的物理存储，sphivedb 用的是 tokyo cabinet ，spsqlitesvr 直接使用 sqlite 。这个项目本身没有设计自己的文件格式。要说有一点相关的，就是在 tokyo cabinet 里面，用 user 作为 key ，sqlite 的数据库整个作为一块 buffer 保存为 对应的 value 。

只是类似。。我们是multi-tenant application
每个tenant 对应若干个 .tch file

mysql 存放相关索引。--》 tch的key value

第一次听说 multi-tenant 这个名词，查了一下，貌似是 SaaS 领域中的一个概念？



这种模型和 one database per user 模型的确很相似。在 multitenant 模型中，应该说是 one database per tenant 。

你这个模型 对我有些启发。。现在我有个比较奇怪的问题是 每个user中需要保存大量的session数据，这些数据多到光用memcached是不能解决的， 用share-nothing结构，为每个user都建立单独的sqlite db很合适。下一步我会考虑这样改进。

有空多交流。

发布 0.4 版。新增特性
1.支持在一个数据库中创建多个表
2.把 sqlite 的错误代码和错误信息返回给客户端

http://sphivedb.googlecode.com/files/sphivedb-0.4.src.tar.gz

支持多个表，简单的例子如下

[ddl.addrbook]
create table addrgroup ( gid INTEGER PRIMARY KEY AUTOINCREMENT, name varchar(64) );
create table addrbook ( id INTEGER PRIMARY KEY AUTOINCREMENT, gid int, addr varchar(64), freq int, unique( addr ) );

假设地址本需要支持分组，有一个 addrgroup 表，addrbook 表有一个 gid 来标识每个地址所属的组。

至此，sphivedb 的功能算是比较完整了。

cabinet可以当HDB、BDB、FDB、TDB，偏偏不是Document-oriented DB，我觉得这是问题的症结：楼主需要的是一个有tokyo cabinet特征（轻量、可靠、高效）的document-oriented DB。
我昨天查了一下，mongodb看上去比较符合上述条件：

http://www.mongodb.org


这是一个较新的开源产品，但看起来也有模有样了，目前版本0.9，文档很全，开发活跃度很高，支持多种语言的客户端(它称为Driver），我试了ruby的，感觉相当好。
据说性能不错，能管理大数据量，作者发过一篇博文，大致意思是搞文件系统没用（GFS、HDFS那种分布式文件系统），如果数据库就能做到呢？他们以前做过一个叫GridFS的文件系统，后来成为mongodb的基础了－－ 在云计算里弄潮的数据库都走轻量级、简约化路线了。

它提供了master-slave模式和sharding机制，似乎还比较初级（？）。

从它的roadmap上看，我最期待的是map-reduce支持，因为尽管SQL语言作为一种DSL，在应对多数问题上提供了很好的抽象和表达能力，但对于某些复杂情况却不好用。这时，传统数据库只支持SQL（包括存储过程），反而成了一个大大的限制。目前主流数据库只支持有限制的并行计算，而完全支持map-reduce的只看到一个商业产品greenplum。

象cabinet这种作为lib被任意语言直接使用的方式让我感觉很舒服。（或许我需要先恶补一个BI常识？）

用过mongodb或类似轻量级解决方案的朋友，谈谈看法吧。

下载了一份代码，可惜不是用 make 来 build 的，暂时没有办法编译运行。
简单看了一下，有如下几个印象：
1.client 端 api ，使用不是 sql ，而是一套自定义的查询语法
2.用到了 boost， libexecinfo， pcre， spidermonkey 这几套库
3.要使得对象能够保存到 mongodb 中，需要从 Model 类继承

btw：现在有越来越多的项目用 scons 来 build 了

mongodb有针对各平台编译好的包，我没从源码编译。
http://www.mongodb.org/display/DOCS/Downloads

更正，最新版本是0.9.5。

还有个需要更正，关于分布式文件系统和mongodb数据库的由来，作者是这样写的：
http://www.10gen.com/blog/2008/7/you-don-t-need-a-file-system



我前面说反了。

这篇博客连同后面的comments都值得一读。
读后感：对于桌面系统、服务器和分布式环境上的文件系统，需要的功能有很大差异。而且，分布式环境下的文件系统和数据库在功能需求上有很多重合的地方，所以，这种建立在 “泛数据库”之上的文件系统，想像空间更大，比如，借助数据库的能力给文件添加元数据，借助文件系统的能力让数据库更具可伸缩性。我理解的分布式文件系统，是一种”虚拟文件系统“。

关于map-reduce和RDBMS的争论，那些大牛们都吵过了，总的来说map-reduce核心是个算法，不是存储，与RDBMS不在一个层面上。但多数map-reduce框架都提供存储（GFS、HDFS..）。象GFS、mongodb这样的存储跟RDBMS的不同在于前者的侧重点在于海量数据、分布式、容错，而不看重写操作（比如transaction）。

有什么东西是SQL做不到或做不好而map-reduce做的好的呢？我看到的例子都是如何处理半结构化或非结构化数据。我觉得还有个问题是传统RDBMS只允许用户使用SQL、存储过程进行操作，高级点的允许嵌入java代码，但代码执行的时机或者是用户发起的，或者是特定的触发时机（trigger,scheduler），并没有提供底层更细节步骤的定制入口，比如传入一个函数，用来定制group_by，aggregation等。看mongodb:
http://www.mongodb.org/display/DOCS/Aggregation


这里的reduce是实现的sum算法，但通过传入函数，可以定制更复杂的aggregation函数。同理，group_by可以通过指定keyf传入函数 － 比如做map-reduce的经典工作：对大量文档进行分析，做单词索引。缺少了这个，我不知道建立在RDBMS上的OLAP会不会痛苦？

作为一个开发者，我喜欢：
1. 对SQL执行的细节步骤开放定制接口。
2. 最好是把数据库当成lib用，本地代码和SQL可以混着用，写法可以跟LINQ相似或不同，关键是数据库直接执行混合代码。－－难度很大。

有什么东西是map-reduce做不好而SQL做的好的呢？相对于map-reduce算法，RDBMS在机制上，或者SQL语言在表述上有没有本质性的障碍？我看到很多数据库都提供了部分并行计算功能，那么是不是可以认定map-reduce和数据库可以鱼与熊掌可以兼得？这些也是我一直存有疑虑的地方。

让我给拐跑题了。

发布 0.5 版。新增特性
1.增加完整的 C++ client api ，支持多个 server
2.增加 java client api ，还不支持 http 长连接
3.增加了一个压力测试工具，压力测试结果表明 sphivedbsvr 的确比 spsqlitesvr 快
4.修正了一个加锁失败的 bug

http://sphivedb.googlecode.com/files/sphivedb-0.5.src.tar.gz

client 端配置文件，配置连接池和多个 server

$bash# cat sphivedbcli.ini 

[SocketPool]
ConnectTimeout = 6
SocketTimeout  = 6
MaxIdlePerEndPoint = 10
MaxIdleTime = 3600

[EndPointTable]
EndPointCount = 2
TableKeyMax = 1000           ; 指明目前使用多少个 cabinet 文件

[EndPoint0]
KeyMin = 0
KeyMax = 499                 ; server0 负责处理的文件是 0-499
ServerIP = 192.168.119.128
ServerPort = 8080

[EndPoint1]
KeyMin = 500
KeyMax = 999                 ; server1 负责处理的文件是 500-999
ServerIP = 192.168.119.129
ServerPort = 8080

good..楼主这个东西开始运用没有？