数据库的名字叫WawaDB，是用python实现的。由此可见python是灰常强大啊！
简介
记录日志的需求一般是这样的：
只追加，不修改，写入按时间顺序写入；
大量写，少量读，查询一般查询一个时间段的数据；
MongoDB的固定集合很好的满足了这个需求，但是MongoDB占内存比较大，有点儿火穿蚊子，小题大做的感觉。
WawaDB的思路是每写入1000条日志，在一个索引文件里记录下当前的时间和日志文件的偏移量。
然后按时间询日志时，先把索引加载到内存中，用二分法查出时间点的偏移量，再打开日志文件seek到指定位置，这样就能很快定位用户需要的数据并读取，而不需要遍历整个日志文件。
性能
Core 2 P8400,2.26GHZ,2G内存，32 bit win7
写入测试：
模拟1分钟写入10000条数据，共写入5个小时的数据， 插入300万条数据，每条数据54个字符，用时2分51秒
读取测试:读取指定时间段内包含某个子串的日志
数据范围 遍历数据量 结果数 用时（秒）
5小时 300万 604 6.6
2小时 120万 225 2.7
1小时 60万 96 1.3
30分钟 30万 44 0.6
索引
只对日志记录的时间做索引， 简介里大概说了下索引的实现，二分查找肯定没B Tree效率高，但一般情况下也差不了一个数量级，而且实现特别简单。
因为是稀疏索引，并不是每条日志都有索引记录它的偏移量，所以读取数据时要往前多读一些数据，防止漏读，等读到真正所需的数据时再真正给用户返回数据。
如下图，比如用户要读取25到43的日志，用二分法找25，找到的是30所在的点，
索 引：0 10 20 30 40 50 日志：|.........|.........|.........|.........|.........|>>>a = [0, 10, 20, 30, 40, 50]>>>bisect.bisect_left(a, 35)>>>3>>>a[3]>>>30>>>bisect.bisect_left(a, 43)>>>5>>>a[5]>>>50
所以我们要往前倒一些，从20（30的前一个刻度）开始读取日志，21，22，23，24读取后因为比25小，所以扔掉, 读到25,26,27,...后返回给用户
读取到40（50的前一个刻度）后就要判断当前数据是否大于43了，如果大于43（返回全开区间的数据），就要停止读了。
整体下来我们只操作了大文件的很少一部分就得到了用户想要的数据。
缓冲区
为了减少写入日志时大量的磁盘写，索引在append日志时，把buffer设置成了10k，系统默认应该是4k。
同理，为了提高读取日志的效率，读取的buffer也设置了10k，也需要根据你日志的大小做适当调整。
索引的读写设置成了行buffer，每满一行都要flush到磁盘上，防止读到不完整的索引行（其实实践证明，设置了行buffer，还是能读到半拉的行）。
查询
啥？要支持SQL，别闹了，100行代码怎么支持SQL呀。
现在查询是直接传入一个lambada表达式，系统遍历指定时间范围内的数据行时，满足用户的lambada条件才会返回给用户。
当然这样会多读取很多用户不需要的数据，而且每行都要进行lambda表达式的运算，不过没办法，简单就是美呀。
以前我是把一个需要查询的条件和日志时间，日志文件偏移量都记录在索引里，这样从索引里查找出符合条件的偏移量，然后每条数据都如日志文件里seek一次，read一次。这样好处只有一个，就是读取的数据量少了，但缺点有两个：
索引文件特别大，不方便加载到内存中
每次读取都要先seek，貌似缓冲区用不上，特别慢，比连续读一个段的数据，并用lambda过滤慢四五倍
写入
前面说过了，只append，不修改数据，而且每行日志最前面是时间戳。
多线程
查询数据，可以多线程同时查询，每次查询都会打开一个新的日志文件的描述符，所以并行的多个读取不会打架。
写入的话，虽然只是append操作，但不确认多线程对文件进行append操作是否安全，所以建议用一个队列，一个专用线程进行写入。
锁
没有任何锁。
排序
默认查询出来的数据是按时间正序排列，如需其它排序，可取到内存后用python的sorted函数排序，想怎么排就怎么排。
0
885
6KB
2015-03-17
41
