2020年Key-value存储简介资料.doc

Key-value存储简介具备高可靠性及可扩展性的海量数据存储对互联网公司来说是一个巨大的挑战,传统的数据库往往很难满足该需求,并且很多时候对于特定的系统绝大部分的检索都是基于主键的的查询,在这种情况下使用关系型数据库将使得效率低下,并且扩展也将成为未来很大的难题。在这样的情况下,使用Key-value存储将会是一个很好的选择。它被广泛应用于缓存,搜索引擎等等领域。        根据以上的描述,一个好的key-value存储需要满足哪些条件呢?l Availability可用性l Scalability可扩展性l Failover故障恢复l Performance高性能简单来说,就是数据不能丢失,服务不能中断,能对故障进行感知并能自动恢复,读写性能极高。文件存储这一部分比较大,以后会另开主题写单文件还是多文件不少nosql的产品采用的是单文件存储的,数据量大以后肯定会遇到性能瓶颈,这一点无需多说,我想强调的是,采用多文件存储数据优点还是非常多的,不过也需要注意,操作系统对于能够打开的文件数目是由限制的,貌似Linux仿佛是1024(待确认),OnlyAppend为了支持更快的写操作,数据文件的写操作只支持append,这个就不多说了,相信大部分的海量存储设计都是这样的。因此,更新操作等价于写操作,不过在写的时候第一步判断写到树的哪个位置时肯定会定位到树已有的节点上,这样能够使得这次写失效或者直接覆盖。这样存在一个问题,就是对于失效的数据(比如更新过的数据)如何处理,比较好的办法是启动独立线程定时或手动进行清理,请注意,这是一个非常巨大的过程,它将耗光你的CPU和I/O,因为要进行频繁计算和数据迁移。数据结构BTree家族这一数据结构被广泛的运用于数据库索引,如Mssql的B+tree,oracle的B-tree,熟悉索引的朋友一定很清楚,+tree,能够参见下图:它是一个多路搜索树,数据存储在叶子节点上,非叶子节点作为叶子节点的索引,加速数据的查找,而叶子节点是一个有序的链表,每次搜索都会到达叶子节点才会结束,插入新数据可能会引起节点的分裂。在本篇文章中,你需要知道,上层的节点成为IN(InternalNode),它持有其它节点的引用,叶子节点的上层是(BottomInternalNode),而叶子节点则是存储数据的节点。  图片来自:这部分是纯粹的数据结构,就不多说了,如果想深入了解的话能够看看这篇论文《TheUbiquitousB-Tree》设计要点Partition因为系统要具备高扩展性,因此,增加删除机器是频繁的操作,如何将数据均匀分散到集群中呢?比较常用的办法是hash取模的办法,但是这样一来,增加机器的瞬间,按照之前的hash取模方式,数据无法读取,这意味着需要对数据进行迁移,等待机器预热,这是很不好的办法。当前比较公认的解决办法就是一致性哈希(consistenthashing)首先按照机器的hash进行顺时针分布,如图,当前有5台机器,如果有一个读写请求,那么hash该key值得的一个hash值,定位到环上,如果没有定位到具体的机器,那么按照顺时针查找,找到的第一个机器就是目标节点。如果需要新增机器,增加过程为,首先hash新机器得到其位置,加入新机器F,这时访问策略不变,那么按照之前的策略,如果hash到C-F之间的数据就无法找到