Key-Value数据库实现Part 2:使用已有的K-V数据库作模型

这篇文章中,我会解释为何在项目中使用已有的模型而不是彻底从零开始。我会列出一系列选择K-V数据库模型的标准。最后会概述并选择一些广为人知且符合所列标准的K-V数据库。文章将会主要涵盖:html

  1. 不要重复造轮子
  2. 可供参考的模型和选择标准
  3. 被选中数据库的概要

1.不要重复造轮子git

  K-V数据库已经存在至少30多年了[1]。其中最有记念意义的项目是DBM,是于1979年由Kenneth Tompson为Unix version 7编写的最初的数据库管理软件[2]。工程师们面对这有关这些数据库的种种情形sql

和问题,对其设计和数据结构或接纳或反对。他们已经经过实际生产中遇到的问题获得了不少经验,不顾这些前驱们的工做从零开始会显得很蠢,那样只会重复他们已经犯过的错误。数据库

Gall定律,由John Gall提出[3]编程

   一个能正常工做的复杂系统永远都是从一个能工做的简单系统演化而来的。反之同样成立:一个从零开始设计的复杂系统历来不能正常工做也没法调试到正常工做。你得推倒重来,从一个能工做的简后端

单系统开始。网络

  这段引用给个人K-V数据库项目奠基了两个基调:数据结构

  1.使用模型。我须要找一些已经存在了一段时间的K-V数据库项目,更理想的状况是找一些成功的K-V数据库的后续项目。由于这些项目一般设计得很牢固,并且在屡次的迭代开发过程当中不断完善。这些架构

K-V数据库将会被用做我本身项目的模型。oracle

  2.从小作起。项目的第一个版本应该小巧而简单,这样方便测试和验证。若是须要改进和额外的功能则应该在后续的版本中添加。

 

2.候选模型和选择标准

  在K-V数据库和NoSQL数据库方面作了一点功课后,我决定在下列数据库里面作更全面的选择:

  • DBM
  • Berkeley DB
  • Kyoto Cabinet
  • Memcached 和 MemcacheDB
  • LevelDB
  • MongoDB
  • Redis
  • OpenLDAP
  • SQLite

  个人选择标准以下:

  • 我想用面向对象编程的方法来实现一个K-V数据库,因此须要从OOP语言编写的数据库中得到灵感。
  • 对于底层的数据结构,我想基于硬盘上的hash table实现,因此候选者们须要提供对硬盘进行读写的方法。
  • 数据库须要支持网络访问
  • 不须要查询引擎或者结构化访问数据
  • 不须要支持完整的ACID规范
  • 鉴于项目须要我独自完成,我想找一些小团队的实现,一两我的的最好

3.最后敲定的K-V数据库的概述

  最后的三大赢家是Berkeley DB,Kyoto Cabinet和LevelDB。Berkeley DB和Kyoto Cabinet都是DBM的继任项目。除此以外,这二者都不是初始版本,而是其做者的第N个版本了。这一般意味着他们

比其余初次完成的项目更可靠。LevelDB年代更近,底层数据结构基于LSM Tree而不是hash table。可是他的代码是我见过全部代码中最干净的。上述三个项目都是一或两我的开发的,下面是他们的详细信

息。

Berkeley DB

  该项目始于1986年,距离我写这篇文章已有26年之久了。Berkeley DB是DBM的后续项目,底层由hash table实现。第一个版本由Margo Seltzer[22]和Ozan Yigit[23]实现,他们当时还在UCB。其后由

Oracle接手并继续开发。

  Berkeley DB最初用C语言实现,至今仍然纯C语言开发。整个开发过程逐步推动,每一个主要版本会添加一些新特性。如今已经支持concurrency, transaction, recovery和replication[4]. Berkeley DB已经

普遍的用于部署中[5],证实了其架构的高度可靠。关于其设计的更多信息能够参考“Berkeley DB Programmer's Reference Guide”[6]以及“The Architecture of Open Source Applications, Volume 1”[5]

Kyoto Cabinet

  Kyoto Cabinet于2009年由Mikio Hirabayashi[24]发布,如今仍然活跃。这个项目是做者发布的Tokyo Cabinet (2007)和QDBM (2003)的后续项目。QDBM曾做为高性能DBM的后续实现[7].。Kyoto Cabinet

由于其纯正的DBM血统和做者超过12年的K-V数据库开发经验而格外让人感兴趣。在实现这三个K-V数据库的这么多年中,做者必然对须要的数据结构有了扎实的理解,更不用说对于性能瓶颈所在的直觉。

  Kyoto Cabinet用C++实现,并实现了hash table,B+ Tree和一些比较深奥的数据结构。其提供了至关出色的性能表现[16]。虽然如此,他彷佛仍是存在一些初始化参数致使的性能问题。正如不少人反馈的

那样,当数据量小于一个跟bucket array大小成比例的阈值(其由建立数据库文件的初始化参数肯定)时,性能很好没有问题。一旦超过阈值,性能将会急剧降低[18][19]。一样的问题也在Tokyo Cabinet[20][21]

中出现。这意味着使用这二者时,一旦项目的需求发生了变更,可能会致使很严重的后果。你们也都懂软件领域中真正不变的东西到底有多少......

LevelDB

  LevelDB是一个由谷歌员工Jeffrey Dean (译者:这位强到不是人))[8]和Sanjay Ghemawat[9]实现,他们都曾参与Google的Mythical Infrastructure项目:MapReduce和BigTable。鉴于这两位在Google工

做时遇到的大规模问题的经验,他们很大程度上是清楚本身在作什么的。LevelDB不一样于其余K-V数据库的颇有趣的一点是他没有用hash table或者B-Tree作底层数据结构,而是基于Log-Structured Merge Tree[12]。

LSM据称对SSD作了优化[13]。你能够在High Scalability blog上找到一堆关于LevelDB的资料[17].

  LevelDB发布于2011年,基于C++实现,并被设计为更高层存储系统的基础模块[10]。Chrome将来版本中的IndexedDB HTML5 API将会使用LevelDB[10][11]。根据做者提供的测试[14],其性能表如今必定

的数据量如下是炸裂级别的。然而,另外一项由Acunu的Andy Twigg在商用SSD上作的测试代表,当数据量超过1M并朝着1B的级别发展时,性能会剧烈降低[15]。因此对于真正对数据规模有要求的后端项目来讲,

LevelDB可能不是最好的选择。

  但其实这不是什么大问题,由于对于我来讲LevelDB最好的部分不在于他的性能而在于它的架构。看看源代码中各个部分的组织方式以后,你就会理解什么叫纯粹的美。全部东西都那么清楚,简洁,合理。接

触LevelDB的源码并用他作模型是一个绝佳的写出好代码的机会。

剩下那些落选的K-V数据库怎么办?

  事实上我没选他们不表明我会把他们彻底抛掉。我可能偶尔会用到他们架构中的一些元素。可是他们不会像选中的那三个数据库同样对个人项目产生很大的影响。

引用

[1] http://blog.knuthaugen.no/2010/03/a-brief-history-of-nosql.html
[2] http://en.wikipedia.org/wiki/Dbm
[3] http://en.wikipedia.org/wiki/Systemantics
[4] http://en.wikipedia.org/wiki/Berkeley_DB#Origin
[5] http://www.aosabook.org/en/bdb.html
[6] http://docs.oracle.com/cd/E17076_02/html/programmer_reference/intro.html
[7] http://fallabs.com/qdbm/
[8] http://research.google.com/people/jeff/
[9] http://research.google.com/pubs/SanjayGhemawat.html
[10] http://google-opensource.blogspot.com/2011/07/leveldb-fast-persistent-key-value-store.html
[11] http://www.w3.org/TR/IndexedDB/
[12] http://www.igvita.com/2012/02/06/sstable-and-log-structured-storage-leveldb/
[13] http://www.acunu.com/2/post/2011/04/log-file-systems-and-ssds-made-for-each-other.html
[14] http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html
[15] http://www.acunu.com/2/post/2011/08/benchmarking-leveldb.html
[16] http://blog.creapptives.com/post/8330476086/leveldb-vs-kyoto-cabinet-my-findings
[17] http://highscalability.com/blog/2011/8/10/leveldb-fast-and-lightweight-keyvalue-database-from-the-auth.html
[18] http://stackoverflow.com/questions/13054852/kyoto-cabinet-berkeley-db-hash-table-size-limitations
[19] https://groups.google.com/forum/#!topic/tokyocabinet-users/Bzp4fLbmcDw/discussion
[20] http://stackoverflow.com/questions/1051847/why-does-tokyo-tyrant-slow-down-exponentially-even-after-adjusting-bnum
[21] https://groups.google.com/forum/#!topic/tokyocabinet-users/1E06DFQM8mI/discussion
[22] http://www.eecs.harvard.edu/margo/
[23] http://www.cse.yorku.ca/~oz/
[24] http://fallabs.com/mikio/profile.html

相关文章
相关标签/搜索