具体解释NoSQL数据库使用实例

一、NoSQL基础知识

1．关于NoSQL

在“NoSQL”一词。实际上是一个叫Racker的同事创造的，当约翰埃文斯埃里克要组织一次活动来讨论开源的分布式数据库。

这个名称和概念都由此而来。

有些人反对NoSQL术语，由于它听起来像我们定义自己是什么．在一定程度，但长期仍然是有价值的。由于当一个关系数据库是唯一的工具，你知道，每个问题，看起来像一个大拇指。

NoSQL是让人们知道有其它选择哪里。但我们并不反对关系数据库，由于当这确实是工作的最佳工具.

一个与NoSQL名称真正关注的是，它是一个非常大的帐篷。有非常不同的设计空间。假设这不是在讨论清楚的，它在各种产品混乱的结果。因此，我要建议沿着三个轴的思考非常多数据库选项：可扩展性，数据和查询模型和持久性的设计。

前所未有的数据量正推动企业关注传统的关系数据库技术。已服务了30多年良好替代品。总的来说。这些替代品已被称作“NoSQL数据库。”

最根本的问题是关系数据库不能处理非常多现代的工作量。有三个详细的问题：扩大向像Digg新闻评论站点的（3TB绿色徽章）或Facebook的（50TB收件箱中的搜索）或EBay（总体2PB），

每server性能和严格的架构设计。

备注：（Digg概念源自美国Digg公司。它全然是依靠真实的网民的自己力量。站点上全部内容都是由网民自己公布，而且内容的位置也是由网民自己来决定。当内容的顶数，评论等达到一定的数字。这些内容就有可能从众多的信息中脱颖而出。

）

我近期写了邮件给卡桑德拉，关于非关系型数据库的资源。我们承诺后，还有其它非关系型数据库在工作，我们称之为“NoSQL运动。”

2.一个简单的NoSQL实例

我选择了一些作为样例NoSQL数据库。这不是一个详尽的清单，但讨论的概念是对于衡量其它人也至关重要。

可伸缩性

缩放读取与复制easy，当我们对在这方面缩放时。我们的意思写了缩放到多台机器自己主动分区的数据。我们呼吁制度不健全。这样的“分布式数据库。

”这当中包含Cassandra，HBase。Riak，Scalaris，Voldemort，等等。

假设你写卷或数据容量超过一台机器可处理。那么这些是你的唯一选择，假设你不想手动分区管理。

有两件事情看在分布式数据库：1）支持多种数据中心和2）可以加入新的机器现场集群的应用程序的透明。

二、NoSQL数据库使用

1． NoSQL数据和查询模型

非分布式NoSQL数据库包含CouchDB。MongoDB，Neo4j，Redis。和Tokyo Cabinet。

这些能够作为分布式系统持久层; MongoDB提供有限的共享支持，做了单独的歇息室为CouchDB项目。和Tokyo Cabinet可作为Voldemort存储引擎使用。

数据和查询模型

在NoSQL里有非常多不同的数据模型和数据库的查询API.

一些重点：

该columnfamily模型Cassandra共享和HBase的是由谷歌的Bigtable文件。第2节描写叙述的启示。 （Cassandra下降，历史版本号，并加入超级列。）在这两个系统，你必须像你行和列习以为常，但稀疏行：每一行能够有很多或尽可能少列的须要。以及列不必须预定义。

键/值模型是最简单和最easy实现的，但效率低，仅仅有当你在查询或更新的值的一部分感兴趣。这也是难以运行的分布式圈顶更复杂的结构/价值。

文档数据库基本上是下一阶段重点/值。同意嵌套的值与每一个键关联。

文件数据库支持查询的效率比每次返回了整个BLOB更简单。

Neo4J有一个真正独特的数据模型，对象存储在图和节点和边的关系。

对于查询适合这个模型（比如。分层数据），它们能够是1000倍速度比替代品。

Scalaris是独特的。提供跨多个键分布式事务。 （讨论与贸易之间的一致性和可用性权衡超出了这个职位的范围，但还有一个方面就是要牢记在评价分布式系统。）

持久性设计

通过持续的设计我的意思是，“怎样在内部存储的数据？” 持久性模型告诉我们非常多这些数据库可以善于什么样的工作量.

在内存数据库是很。很快的（Redis达到每秒超过100,000操作一台计算机上），但不能与数据集的工作，超出可用的RAM。耐久性（保留数据。即使server崩溃或断电）也将是一个问题的数据量，能够预期损失之间的冲（复制数据到磁盘）可能很大。

Scalaris，其它内存数据库，我们的名单上。意向处理与复制耐久性问题，但因为它不支持多个数据中心的数据将仍然easy受到停电的事情一样。

Memtables和SSTables缓存在内存中写入（1“memtable”）后。以书面追加仅仅承诺为耐久性日志。

当写够已被接受的memtable排序并写入到磁盘上的全部一次作为“sstable。

”这提供近内存中的表现，由于没有涉及要求。同一时候避免了纯粹的耐久性问题，在内存的方法。 （这是具体描写叙述在第5.3和先前提及的5.4 Bigtable的文件，以及在该日志结构合并树。

）

B-树已被用于从数据库中实际上是时间的起点。

索引他们提供强大的支持。但表现欠佳的旋转盘（这仍然是迄今为止最具有成本效益，由于多）要求读或写什么工作。

一个有趣的变体是CouchDB的追加，仅仅有B -树，它避免了管理费用的目的在限制CouchDB一写一时间成本.

结论

该NoSQL运动在2009年爆炸地为越来越多的企业全力对付大量数据。在Rackspace云高兴地发挥了NoSQL运动的早期作用。并继续投入资源，Cassandra像NoSQL支持事件。

本文借鉴http://database.51cto.com/art/201004/192283.htm