KV存储系统

现在的KV存储系统都是分布式的,首先介绍Zookeeper——针对大型分布式系统的高可靠的协调系统。

开发分布式系统是件很困难的事情,其中的困难主要体现在分布式系统的“部分失败”。“部分失败”是指信息在网络的两个节点之间传送时候,如果网络出了故障,发送者无法知道接收者是否收到了这个信息,而且这种故障的原因很复杂,接收者可能在出现网络错误之前已经收到了信息,也可能没有收到,又或接收者的进程死掉了。

Zookeeper就是解决分布式系统“部分失败”的框架,当分布式系统碰到部分失败时候,可以正确的处理此类的问题,让分布式系统能正常的运行。zookeeper的实际运用场景:

  1. 集群中有服务器挂掉时,能检测到并将其从列表中删除,并能报告给管理员;当master挂掉时,会根据”选举领导者算法”选出新的健康的master;
  2. 分布式锁机制,保证集群中数据的一致性;
  3. 配置管理,快速地配置集群;
  4. 任务均衡等。

memcached

许多Web应用都将数据保存到RDBMS中,应用服务器从中读取数据并在浏览器中显示。 但随着数据量的增大、访问的集中,就会出现RDBMS的负担加重、数据库响应恶化、 网站显示延迟等重大影响。memcached是高性能的分布式内存缓存服务器。 一般的使用目的是,通过缓存数据库查询结果,减少数据库访问次数,以提高动态Web应用的速度、 提高可扩展性。

特点是:协议简单、基于libevent的事件处理、内置内存存储方式、memcached不互相通信的分布式。

由于数据仅存在于内存中,因此重启memcached、重启操作系统会导致全部数据消失。 另外,内容容量达到指定值之后,就基于LRU(Least Recently Used)算法自动删除不使用的缓存。 memcached本身是为缓存而设计的服务器,因此并没有过多考虑数据的永久性问题。 各个memcached不会互相通信以共享信息,分布策略由客户端实现。

HBase

HBase是Apache Hadoop中的一个子项目,Hbase依托于Hadoop的HDFS作为最基本存储基础单元,通过使用hadoop的DFS工具可以看到这些数据存储文件夹的结构,还可以通过Map/Reduce的框架(算法)对HBase进行操作(Hive更常用),如图所示:

HBase在产品中还包含了Jetty,在HBase启动时采用嵌入式的方式来启动Jetty,因此可以通过web界面对HBase进行管理和查看当前运行的一些状态,非常轻巧。

HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库。所谓非结构化数据存储就是说HBase是基于列的而不是基于行的模式。HBase是介于Map Entry(key & value)和DB Row之间的一种数据存储方式。就点有点类似于Memcache,但不仅仅是简单的一个key对应一个 value,你很可能需要存储多个属性的数据结构,但没有传统数据库表中那么多的关联关系,这就是所谓的松散数据。

一个数据行拥有一个可选择的键和任意数量的列。表是疏松的存储的,因此用户可以给行定义各种不同的列,对于这样的功能在大项目中非常实用,可以简化设计和升级的成本。

Tair

tair是淘宝自己开发的一个分布式 key/value存储引擎。tair分为持久化和非持久化两种使用方式,非持久化的tair可以看成是一个分布式缓存;持久化的tair将数据存放于磁盘中,为了解决磁盘损坏导致数据丢失,tair可以配置数据的备份数目,tair自动将一份数据的不同备份放到不同的主机上,当有主机发生异常,无法正常提供服务的时候,其于的备份会继续提供服务。tair是加强版的memcached,提供了数据长期保存的策略。

tair作为一个分布式系统,是由一个中心控制节点和一系列的服务节点组成。我们称中心控制节点为config server,服务节点是data server。config server负责管理所有的data server,维护data server的状态信息。data server对外提供各种数据服务,并以心跳的形式将自身状况汇报给config server。config server是控制点,而且是单点,目前采用一主一备的形式来保证其可靠性。所有的 data server 地位都是等价的,tair支持自定义的备份数。

tair的分布采用的是一致性哈希算法,对于所有的key,分到Q个桶中,桶是负载均衡和数据迁移的基本单位。config server根据一定的策略把每个桶指派到不同的data server上,因为数据按照key做hash算法,所以可以认为每个桶中的数据基本是平衡的。保证了桶分布的均衡性,就保证了数据分布的均衡性。

Redis是一个key-value存储系统。和Memcached类似,它支持存储的value类型相对更多,包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash(哈希类型)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作,而且这些操作都是原子性的。在此基础上,redis支持各种不同方式的排序。

与memcached一样,为了保证效率,数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件(RDB和AOF两种方式),并且在此基础上实现了master-slave(主从)同步。Redis数据库

KV系统对比:Redis/HBase/Tair比较

时间: 2024-10-16 15:51:40

KV存储系统的相关文章

Key/Value存储系统etcd的特性

etcd 是一个高可用的Key/Value存储系统,和其他KV存储系统不同的是,它的灵感来自于 ZooKeeper 和 Doozer,主要用于分享配置和服务发现.利用 etcd 的特性,应用程序可以在集群中共享信息.配置或作服务发现,etcd 会在集群的各个节点中复制这些数据并保证这些数据始终正确. 它的主要优点是: 简单:支持 curl 方式的用户 API (HTTP+JSON) 安全:可选 SSL 客户端证书认证 快速:单实例可达每秒 1000 次写操作 可靠:使用Raft强一致性算法实现分

HDFS跨外部存储系统的多层级存储

前言 目前大数据和云计算是当下讨论非常火热的2个词,笔者也非常相信在未来的时间内,以Hadoop系统生态圈为代表的大数据工具,将会被更多的企业所使用.在一些更大规模的公司,已经将大数据与云联系在了一起了,举个例子,我们将数据存储在HDFS内,然后在定期同步到云上,相当于云端存储的数据是一个back store.这样做的一个好处是防止本地集群的数据遭到意外的破坏或丢失,至少在云端我们还有备份.或者有另外的一些做法是,我们通过一层适配操作,将用户写入集群的数据直接就写到了远端的云上,但是对于用户而言

谈谈KV存储集群的设计要点

版权声明:本文由廖念波原创文章,转载请注明出处: 文章原文链接:https://www.qcloud.com/community/article/150 来源:腾云阁 https://www.qcloud.com/community Key-value存储系统,是非常普遍的需求,几乎每个在线的互联网后台服务都需要KV存储,我们团队在KV存储方面,经历过几个时期,我自己深感要做好不容易. 这里扯远一点,展开说一下: 第一个时期,很早期的时候,我们的数据存储在mysql表里,按照用户账号简单的分库分

深入leveldb-初步认识leveldb

文章参考http://blog.chinaunix.net/uid-26575352-id-3245476.html 1. leveldb简介 leveldb是google两位工程师实现的单机版k-v存储系统,具有以下几个特点 1. key和value都是任意的字节数组,支持内存和持久化存储 2. 数据都是按照key排序 3. 用户可以重写排序函数 4. 包含基本的数据操作接口,Put(key,value),Get(key),Delete(key) 5. 多操作可以当成一次原子操作 6. 用户可

开源大数据处理系统/工具大全

本文一共分为上下两部分.我们将针对大数据开源工具不同的用处来进行分类,并且附上了官网和部分下载链接,希望能给做大数据的朋友做个参考.下面是第一部分. 查询引擎 一.Phoenix 贡献者::Salesforce 简介:这是一个Java中间层,可以让开发者在Apache HBase上执行SQL查询.Phoenix完全使用Java编写,代码位于GitHub上,并且提供了一个客户端可嵌入的JDBC驱动. Phoenix查询引擎会将SQL查询转换为一个或多个HBase scan,并编排执行以生成标准的J

分布式系统领域有哪些经典论文

0 个回答 默认排序 知乎用户 机器学习 话题的优秀回答者 901 人赞同了该回答 谢邀!五一快乐!分布式系统在互联网时代,尤其是大数据时代到来之后,成为了每个程序员的必备技能之一.分布式系统从上个世纪80年代就开始有了不少出色的研究和论文,我在这里只列举最近15年范围以内我觉得有重大影响意义的15篇论文(15 within 15).1. The Google File System: 这是分布式文件系统领域划时代意义的论文,文中的多副本机制.控制流与数据流隔离和追加写模式等概念几乎成为了分布式

LOSF 海量小文件问题综述

1.LOSF问题概述 在互联网(尤其是移动互联网).物联网.云计算.大数据等高速发展的大背景下,数据呈现爆炸式地增长.根据IDC的预测,到2020年产生的数据量 将达到40ZB,而之前2011年6月的预测是35ZB.然而,社会化网络.移动通信.网络视频音频.电子商务.传感器网络.科学实验等各种应用产生的数 据,不仅存储容量巨大,而且还具有数据类型繁多.数据大小变化大.流动快等显著特点,往往能够产生千万级.亿级甚至十亿.百亿级的海量小文件,而且更多地 是海量大小文件混合存储.由于在元数据管理.访问

微信与朋友圈后台架构

微信朋友圈技术之道:三个人的后台团队与每日十亿的发布量 视屏讲解 概述 截止到2015年7月,微信每月活跃用户约5.49亿,朋友圈每天的发表量(包括赞和评论)超过10亿,浏览量超过100亿.得益于4G网络的发展,以上数据仍有很快的增长,而且相对于PC互联网时代,移动互联网时代的峰值要来得更加凶猛.比如,2015年元月的流量到了平时的2倍,而峰值则达到了平时峰值的2倍,相当于平时正常流量的5倍,这对整个系统的考验是很残酷的.本次分享将简单介绍微信后台团队的开发模式.微信朋友圈的架构以及在性能上的一

第一幕数据分片与路由

---恢复内容开始--- 一.数据分片相关: 数据分片:系统水平扩展.数据分片存的各个机器上 数据复制:保证数据的高可用性,保证读操作的效率,客服端从多个备份数据中选择物理距离较近的读取,提高单次读取效率 数据路由:分片后找到某条记录的存储位置 缺点:数据一致性 二.数据分片和路由的抽象模型 二级映射: 1.key - partation:数据分到数据分片,1对多:一个分片包涵多条数据 2.partation--machine:数据分片到物理机中,1对多:一个物理机包涵多个分片 路由:获得某条记