|
|
你需要知道的关于NoSQL数据库的10件事
By Guy Harrison , Translated By Jametong
关系数据模型已经流行了几十年了,但是一种新型的数据库(即NoSQL)正在吸引各大企业的关注.下面是对其优势与劣势的一个简单总结.
在过去的1/4世纪中,关系型数据库(RDBMS)一直是数据库管理系统的主导模型.但是,今天,非关系型,”云,”或者”NoSQL”数据库正以数据库管理系统的替代模型而获得认知.在本文中,我们将考察这些非关系型NoSQL数据库的10个关键因素:最重要的5个优势以及5个挑战.
可以通过此链接下载本文的PDF格式.
NoSQL的5个优势
1. 弹性扩展
多年来,数据库管理员一直依赖于向上扩展(scale up)－随着数据库负载的增加购买更大的数据库服务器―而不是向外扩展－随着负载的增加将数据库分不到多个不同的主机上.然而,随着每秒事务数与可用性需求的提高,以及数据库往云或虚拟环境的迁移,向外扩展到廉价硬件的经济优势越来越难以抵挡.
RDBMS或许比较难以在廉价的集群上进行向外扩展,但是,NoSQL数据库的新品从设计之初就是为了利用新节点的优势进行透明扩展,他们通常在设计时就考虑使用低成本的廉价硬件.
2. 大数据量
在过去10年,与每秒事务数的增长超出了认知一样,存储的数据的规模也出现了极大的增长.O’Reilly明智的称此为”数据的工业革命.”RDBMS的容量也在增长以匹配这些数据的增长,但是,与每秒事务数一样,单个RDBMS可有效管理的数据规模限制让部分企业越来越难以忍受.今天,大规模数据量可以交由NoSQL系统来处理,比如Hadoop,超过目前最大的RDBMS可以管理的数据规模.
3. 再见了,DBA(回头见,DBA?)
这些年,虽然RDBMS的提供商宣称推出了很多的可管理性方面的改进,高端的RDBMS系统还是只能交由昂贵的、高度受训的DBA来进行维护.高端RDBMS系统从设计到安装以及后续的调优，都需要DBA们深度介入.
从理论上，通常，NoSQL数据库的最初的设计目标就是更少的管理介入:自动修复、数据分布以及更简单的数据模型，从而更少的管理与调优需求.实际上，关于DBA将死的谣言很可能被略微放大了.对于任何关键的数据存储,总是需要有人来关心它的性能以及可用性.
4. 经济性
NoSQL数据库通常使用廉价服务器集群来管理暴增的数据与事务规模,而RDBMS倾向于依赖昂贵的专有服务器与存储系统.其结果是,NoSQL数据库的每GB数据或每秒事务数的成本要远远低于RDBMS,使得你可以以更低的价格来存储与处理更多的数据.
5. 灵活的数据模型
在大量的生产环境数据库中,变更管理是一个非常棘手的问题.哪怕是对数据模型的很小的变更,在RDBMS中也需要进行小心的管理,甚至还需要停机或降低服务级别.
在数据模型的限制这一点上，NoSQL数据库要宽松的多，或者完全不存在. NoSQL的键值存储(Key value Store)与文档数据库(Document Database)允许应用在一个数据单元中存入它想要的任何结构.即使是定义更加严格的基于BigTable的NoSQL数据库,通常也允许创建新的字段而不致带来麻烦.
其结果是,应用的变更与数据库结构的变更不需要绑定在一个变更单元中进行管理.理论上,这可以提高应用的迭代速度,然而,显然,如果应用无法管理数据的完整性,它将带来不良的副作用.
NoSQL的5个挑战
NoSQL数据库的可能性空间引发了大量的关注,但是,在它们成为企业级应用的主流之前,还有大量的障碍有待克服.下面是几个主要的挑战.
1. 成熟度
RDBMS已经存在了很长一段时间. NoSQL的支持者认为它们的年纪是它们过时的象征,但是,对于大部分CIO(首席信息官)来讲,RDBMS的成熟度是可以让人放心的.通常,RDBMS系统都很稳定,功能也很丰富.相比而言,大部分NoSQL的替代品都还处于前-生产环境阶段,还有大量的关键特性有待实现.
生活在科技前沿对于大部分开发人员来讲,是令人兴奋的,但是,企业在实施时必须非常谨慎.
2. [...]
1. Jonathan Ellis 做的关于Cassandra 0.6以及0.7版本的新功能
a. 新增了对Compaction的优先级控制.
-XX:+UseThreadPriorities \
-XX:ThreadPriorityPolicy=42 \
-Dcassandra.compaction.priority=1 \
b. 对Hinted Handoff的手工控制.
0.6.0: send hints to natural replicas
0.6.0: fix row-level concurrency bottleneck
0.6.2: option to disable entirely
0.6.3: remove hourly scan
0.6.4: lower priority
0.6.5: paging of large hinted rows
0.7.0: large rows
c. 在0.6.4上调整了SEDA的流控制(Flow Control),将Message Deserializer的步骤去掉了(这在我们这边的测试中,成为了系统的写性能瓶颈)
d. 在0.7版本中,大大提供了Cassandra的Read Performance(这一点,我非常期待)
State of Cassandra, August 2010
View more presentations from jbellis.
2. Benjamin Black做的关于Cassandra的运维与故障诊断介绍.
故障诊断部分的介绍,我认为写的非常好, 对于做其他类似的问题的诊断也有部分效果.
a. 如何调整Cassandra的Ring分布, 这个问题也是困扰我已久的问题, 内部也有兄弟问过我这个问题, [...]
为什么Flowdock从Cassandra迁移到MongoDB
by Otto Hilska @mutru Translated by Jametong
Flowdock是一个基于Web的团队通讯工具.所有的软件开发人员都应该使用它进行沟通,而不是使用Campfires、Skype Chats或IRC等工具.因为它可以更好的的支持他们的真实工作流.
上周,我们对Flowdock的数据库服务做了一次切换,聪从Cassandra迁移到了另一种NoSQL工具-MongoDB.由于我们的技术选择已经引起了大家的部分兴趣,我将在此向公众说明下我们的决策理由.
我们的部分客户一定对下面这个图片记忆犹新:
从一定程度上讲,我们遭遇到了Cassandra的稳定性问题.所有的节点都陷入无线无限循环(infinite loop),运行垃圾回收工作(GC, Garbage Collection)并尝试压缩数据文件-并偶尔导致集群瘫痪.除了对集群进行重启并经常性的手工对节点做压缩工作以让其稳定一会外,我们无计可施.其他人也报告过类似的问题.在前面几周的时间里,我们的Cassandra节点总是会吃掉给他分配的所有资源,而导致Flowdock运行缓慢.
由于我们刀口嗜血式的数据库选择(James注: 这是我不认同的地方,可能对于一些Startup的公司来讲,这是一种不得已的选择.),这已经不是我们第一次遇到此类问题了.从Cassandra 0.4升级到0.5的时候,我们被迫关闭了整个集群,仅仅是为了将所有的数据刷新到磁盘上(虽然,我们已经按照文档进行了手工刷新的操作).这个操作导致我们丢失了几分钟的讨论内容,以及我们手工创建的索引出现严重的不一致,以致于需要做完全的重建.我想,我们最后离开办公室的时间已经是凌晨4点了.
从我们最初选择Cassandra到现在,NoSQL社区已经出现了很大的变化.MongoDB已经发生了很大的改变,最近新增的自动分片(auto-sharding)与副本集(replica set)使得它可以作为Cassandra的有力的替代品.因此,我们决定试试MongoDB.
写从Cassandra往MongoDB的数据迁移的脚本耗费我一天的时间.在一周左右的时间内,我们已经可以完全在MongoDB上运行Flowdock了.在生产环境部署MongoDB之前,内部测试持续进行了好几个星期.
目前,我们已经完成这个调整,
1. 智能(多键)索引. 手工维护的索引令人生厌,MongoDB可以自动帮我们维护所需的索引.例如,我们的消息包含标签(tag),例如下面这个格式的document:
{ content: “Write a blog post about #mongodb.”,
workspace: ‘myflow’,
tags: ["mongodb", "todo", "@Otto"] }
这样,如果仅检索自己的任务,Flowdock的后台只需要做下面这个查询:
db.messages.find({
workspace: ‘myflow’,
tags: { $all: ["todo", "@Otto"] }
})
2. 查询.无论数据模型多么简单,每当需要执行一个查询的时候,你都不需要提前规划此事.在MongoDB中,你可以直接在控制台定制复杂的查询,这一点非常类似于SQL数据库.它会据此执行一次顺序扫描,这比在客户端手工处理上百万的记录要更快捷也更便利.
3. Map-Reduce. 这是分析人员的利器啊.MongoDB的Map-Reduce功能支持虽然不是非常完美,但它起码很易用.
4. GridFS让我们的文件存储操作变得非常容易.它的存储能力可以随着我们的MongoDB集群的扩展一起增长.
我们也遭遇到部分轻微的限制:
1. 我们发现了一个JSON解析的bug,不过我们在10分钟内就解决了此bug.
2. BSON的Document键中不支持点(dot).通常,这或许不是个问题,但是我们必须在数据迁移中解决此问题.
3. Document有4MB的大小限制.这对于我们的数据模型来讲不是问题,由于MongoDB对在位的原子更新(atomic in-place updates)有非常好的支持,所以,你需要关注,Document不要超过4MB的限制.
4. 增加新的节点没有在Cassandra中那么容易.然而,Cassandra在新增节点的负载均衡上有它自己的问题.
到目前为止,它的运行还非常平稳.开发人员与数据库管理员的工作也因此减轻了很多.
Cassandra vs HBase
By Vaibhav Puranik Translated By Jametong
我们是一家广告网络公司.我们需要存储展示与点击信息.我们在为我们的新项目评估多个不同的大批量数据(或nosql,或任何你喜欢的称呼)系统.过去8个月中,我们一直在一个测试产品上使用HBase,并且满意它的表现,但是,最近Cassandra的风头很高,因此,我们决定对它做个测试.我认为,从某些角度讲,Cassandra团队的推广做的很不错.你将发现,在Santa Monica，哪怕是非技术人员(诸如风险投资商、CEO以及产品经理)也会相互推荐使用Cassandra.
Cassandra给人的第一印象很好.它们的首页看上去比HBase更加专业也更加友好.安装并运行它也很简单.这个网站的文档很丰富.说实在话,安装并让其工作只花费了我5分钟的时间.
真正的挑战是理解Cassandra的数据模型,并尝试在我们的使用场景中实现它.我们很清楚如何在HBase中实现它,因为我们对HBase有相当不错的使用经验.虽然Cassandra也是从BigTable出继承了同样的数据模型,Cassandra与HBase之间还是有一些根本性的不同的.我试图用表格整理了两个系统之间的差异,如下:
Cassandra
HBase
缺少类似于表的概念.所有的文档都告诉你,有多个Keyspace的情况不常见.这意味着你必须在一个集群中共享同一个key space.另外,新增keyspace需要重启集群才能生效.
存在表相关的概念.每个表都有它自己的key space. 这一点对我们来说很重要.添加/删除表都很容易,跟在RDBMS中一样.
使用字符串的Key.通常使用uuid作为Key.如果希望你的数据按照时间排序,可以使用TimeUUID.
使用二进制Key.通常将三个不同的项目组合在一起来构建一个Key.这意味着你可以搜索一个给定表中的多个键.
即使使用TimeUUID,也不会发生热点问题,因为Cassandra会对客户端请求做负载均衡.
如果Key的第一部分是时间或者序列数,就会发生热点问题.所有新的Key都会被插入同一个区域,一直到此区域被塞满(因而导致出现热点问题).
支持列排序
不支持列排序
超列(Super Column)概念使得你可以设计非常灵活也非常复杂的表结构.
不支持超列.不过可以设计一个类似与超列的结构,不过列名称与值都是二进制的.
没有便捷的方法来自增长一个列的值.实际上,最终一致性的不同特性使得更新/写入一条记录并在更新后立即读出非常困难.必须确保使用R+W>N来实现强一致性.
由于设计上就是一致性.提供了一个非常便捷的方法来自增计数器.非常适合做数据汇总.
刚开始支持Map Reduce接口.还需要有一个hadoop集群来运行它.需要将数据从Cassandra集群迁移到Hadoop集群.不适合对大型数据运行map reduce任务.
对Map Reduce的支持是原生的.HBase构建在Hadoop集群上.数据不需要做迁移.
如果不需要Hadoop的话,维护相对简单.
由于包含多个诸如Zookeeperr、Hadoop以及HBase本身的可活动组件，维护相对复杂.
到目前为止,还没有本地化的Java Api支持.没有Java文档.虽然是使用Java编写的,你还是必须用Thrift接口来与集群进行通讯.
有友好的本地Java API.比Cassandra更像是Java系统.由于我们的应用是基于Java的,这一点对我们很重要.
没有主节点,因此也没有单点故障.
虽然在概念上有一个主节点服务,HBase本身对它的依赖并不严重.即使在主节点宕机的情况下,HBase集群仍然可以正常提供数据服务.Hadoop的Namenode是一个单点故障.
在按照这种方式比较过数据模型与相关特性后,对我们来讲,HBase是明显的优胜者.我的看法是,如果你确实需要一致性,HBase是一个明显的选择.更进一步,本地化的Map Reduce支持、表概念以及可修改而且不用重启集群的简单的表结构是你不可忽略的加分项.HBase是一个更加成熟的平台.当人们说Twitter、Facebook在使用Cassandra时,他们忘记了这些公司同时也在使用HBase.实际上,Facebook最近雇用了一个HBase的代码提交者(Commiter),这清楚地表明Facebook对HBase的兴趣.
总之,我们全力支持HBase!!
以下内容摘自Eric Evans在OSCON上的ppt (Hands On Cassandra)
1. 设置Java的Heap Size.
# Arguments to pass to the JVM
JVM_OPTS=” \
…
-Xmx1G \
…
2. 设置memtable flush的策略.
# 达到的数据量大小(这个与memtable大小的设置一致).
memtable_throughput_in_mb: 64
# 包含的对象数量(单位:百万)
memtable_operations_in_millions: 0.3
# 经过的时间长度
memtable_flush_after_mins: 60
3. 缓存设置策略
keyspaces:
- name: Twissandra
…
column_families:
- name: User
keys_cached: 100 ## 缓存的Key的数量
preload_row_cache: true ##是否预载行缓存
rows_cached: 1000 ##行缓存的键的数量.
…
4. 磁盘访问策略.
# [...]
|
|
最近评论