想要明白什么是key/value数据库

为什么80%的码农都做不了架构师？>>>   

想要明白什么是key/value数据库，就必须了解哈希表（Hash Table）这种数据结构。
比如，Berkley DB就是典型的key/value数据库。

以下内容对哈希表进行了很形象的描述：
========================================
Google搜索到的头条：散列表（也叫哈希表），是根据关键码值直接进行访问的数据结构，也就是说，它通过把关键码值映射到表中一个位置来访问记录，以加快查找的速度。
这个映射函数叫做散列函数，存放记录的数组叫做散列表。

这个解释其实太含糊，想要整明白哈希表，那就得明白哈希表到底有什么样的优势。
数据结构中，有个时间算法复杂度O(n)的概念来衡量某种算法在时间效率上的优劣。
哈希表的理想算法复杂度为O(1)，也就是说利用哈希表查找某个值，系统所使用的时间在理想情况下为定值，这就是它的优势。
那么哈希表是如何做到这一点的呢？

我们定义一个很大的有序数组，想要得到位于该数组第n个位置的值，它的算法复杂度为O(1)。
哈希表利用哈希函数将需要存储的内容的关键值转换为这个有序数组中的某个值，在被存储内容和有序数组之间建立了映射关系。
这样，下次我们对这个值进行查找时只要使用同一个哈希函数对关键值进行转换，找到这个数组值 就可以了。

如果还没有明白是怎么回事的话，那我们来举个例子。假设我们要做个存储结构，需要存储下来三国中的人物，以及他们的详细信息。
我们用他们的名字来作为存储 的关键值，例如：刘备，曹操，孙权，关羽，张飞……等等。
这个时候我们如果想用一般的方法来查找这些英雄豪杰，需要遍历整个存储空间，如果这些英雄豪杰一 共有n个，那么这时候的时间算法复杂度为O(n)。
显然如果n值很大，每次想要找到某个英雄就需要比较长的时间。

此时我们先定义一个大的有序结构数组HashValue[m]，用来存放各位英雄豪杰的信息。
然后编写一个哈希函数ChangeToHashValue (name)，函数的具体内容就不细说了，反正这个函数会将这些做为关键值的名字转换为HashValue[m]中的某个下标值x。
然后可以将英雄的信息 放进HashValue[x]中去。这样，可以将所有英雄的信息存储起来。当查询的时候再使用哈希函数ChangeToHashValue(name)得到这个下标值，这样就很容易得到了这个英雄的信息。

例如：ChangeToHashValue(刘备)为10，那么就将刘备存储到HashValue [10]里面。
当查询的时候再次使用ChangeToHashValue(刘备)得到10，这个时候我们就可以很容易找到刘备的所有信息。
在实际应用中如果我们想把所有的英雄豪杰都存储进系统时，需要定义m>n。
就是数组的大小要大于需要存储的信息量，所以说哈希表是一个以空间换取时间的数据结构。

这个时候问题来了，出现了这种情况ChangeToHashValue(关羽)和ChangeToHashValue(张飞)得到的值是一样的，都 是250，我们岂不是在存储过程中会遇到麻烦，怎么安排他们二位的地方呢（总不能让二位打一架，谁赢了谁呆在那吧），这就需要一个解决冲突的方法。
当遇到这种情况时我们可以这样处理，先存储好了关羽，当张飞进入系统时会发现关羽已经是250了，那咱就加一位，251得了，这不就解决了。
我们查找张飞的时候也 是，一看250不是张飞，那就加个1，就找到了。
这时还存在一个问题，直接用ChangeToHashValue(赵云)为251，张飞已经早早占了他的地方，那就再加1存到252呗。
呵呵，这时我们会发现，当哈希函数冲突发生的机率很高时，可能会有一群英雄豪杰在250这个值后面扎堆排队。
要命的是查找的时候，时间算法复杂度早已不是O(1)了（所以我们说理想情况下哈希表的时间算法复杂度为O(1)）。

这就是说哈希函数的编写是哈希表的一个关键问题，会涉及到一个存储值在哈希表中的统计分布。
如果哈希函数已经定义好了，冲突的解决就成为了改变系统性能的关键因素。
其实还有很多种方法来解决冲突情况下的存储和查找问题，不一定非要线性向后排队，如果有好的哈希表冲突的解决方法也能很大程度上提高系统的效率。

转载于:https://my.oschina.net/fir01/blog/163888