互联网公司常用的基本集中在以下几种,每种只举一个比较常见或者应用比较成功的例子吧。
1. In-Memory KV Store : Redis
in memory key-value store,同时提供了更加丰富的数据结构和运算的能力,成功用法是替代memcached,通过checkpoint和commit log提供了快速的宕机恢复,同时支持replication提供读可扩展和高可用。
2. Disk-Based KV Store: Leveldb
真正基于磁盘的key-value storage, 模型单一简单,数据量不受限于内存大小,数据落盘高可靠,Google的几位大神出品的精品,LSM模型天然写优化,顺序写盘的方式对于新硬件ssd再适合不过了,不足是仅提供了一个库,需要自己封装server端。
3. Document Store: Mongodb
分布式nosql,具备了区别mysql的最大亮点:可扩展性。mongodb 最新引人的莫过于提供了sql接口,是目前nosql里最像mysql的,只是没有ACID的特性,发展很快,支持了索引等特性,上手容易,对于数据量远超内存限制的场景来说,还需要慎重。
4. Column Table Store: HBase
这个富二代似乎不用赘述了,最大的优势是开源,对于普通的scan和基于行的get等基本查询,性能完全不是问题,只是只提供裸的api,易用性上是短板,可扩展性方面是最强的,其次坐上了Hadoop的快车,社区发展很快,各种基于其上的开源产品不少,来解决诸如join、聚集运算等复杂查询。
HBase与传统关系数据库的区别?答:主要体现在以下几个方面:1.数据类型。关系数据库采用关系模型,具有丰富的数据类型和储存方式。HBase则采用了更加简单的数据模型,它把数据储存为未经解释的字符串,用户可以把不同格式的结构化数据和非结构化数据都序列化成字符串保存到HBase中,用户需要自己编写程序把字符串解析成不同的数据类型。
2.数据 *** 作。关系数据库中包含了丰富的 *** 作,如插入、删除、更新、查询等,其中会涉及复杂的多表连接,通常是借助多个表之间的主外键关联来实现的。HBase *** 作则不存在复杂的表与表之间的关系,只有简单的插入、查询、删除、清空等,因为HBase在设计上就避免了复杂的表与表之间的关系,通常只采用单表的主键查询,所以它无法实现像关系数据库中那样的表与表之间的连接 *** 作。
3.存储模式。关系数据库是基于行模式存储的,元祖或行会被连续地存储在磁盘页中。在读取数据时,需要顺序扫描每个元组,然后从中筛选出查询所需要的属性。如果每个元组只有少量属性的值对于查询是有用的,那么基于行模式存储就会浪费许多磁盘空间和内存带宽。HBase是基于列存储的,每个列族都由几个文件保存,不同列族的文件是分离的,它的优点是:可以降低I/O开销,支持大量并发用户查询,因为仅需要处理可以回答这些查询的列,而不是处理与查询无关的大量数据行;同一个列族中的数据会被一起进行压缩,由于同一列族内的数据相似度较高,因此可以获得较高的数据压缩比。
4.数据索引。关系数据库通常可以针对不同列构建复杂的多个索引,以提高数据访问性能。与关系数据库不同的是,HBase只有一个索引——行键,通过巧妙的设计,HBase中所有访问方法,或者通过行键访问,或者通过行键扫描,从而使整个系统不会慢下来。由于HBase位于Hadoop框架之上,因此可以使用Hadoop MapReduce来快速、高效地生成索引表。
6.数据维护。在关系数据库中,更新 *** 作会用最新的当前值去替换记录中原来的旧值,旧值被覆盖后就不会存在。而在HBase中执行更新 *** 作时,并不会删除数据旧的版本,而是生成一个新的版本,旧有的版本仍旧保留。
7.可伸缩性。关系数据库很难实现横向扩展,纵向扩展的空间也比较有限。相反,HBase和BigTable这些分布式数据库就是为了实现灵活的水平扩展而开发的,因此能够轻易地通过在集群中增加或者减少硬件数量来实现性能的伸缩。
但是,相对于关系数据库来说,HBase也有自身的局限性,如HBase不支持事务,因此无法实现跨行的原子性。
注:本来也想来问这个问题,然后复制一下的。结果找不到,只好自己手打了,麻烦复制拿去用的同学点下赞呗。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)