一、Nosql基础知识

1．关于Nosql

在“Nosql”一词，实际上是一个叫Racker的同事创造的，当约翰埃文斯埃里克要组织一次活动来讨论开源的分布式数据库。这个名称和概念都由此而来。

有些人反对Nosql术语，因为它听起来像我们定义自己是什么．在一定程度，但长期仍然是有价值的，因为当一个关系数据库是唯一的工具，你知道，每一个问题，看起来像一个大拇指。 Nosql是让人们知道有其他选择哪里。但我们并不反对关系数据库，因为当这确实是工作的最佳工具.

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

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

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

每服务器性能和严格的架构设计。

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

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

2.一个简单的Nosql实例

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

可伸缩性

缩放读取与复制容易，当我们对在这方面缩放时，我们的意思写了缩放到多台机器自动分区的数据。我们呼吁制度不健全，这种“分布式数据库。”这其中包括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下降，历史版本，并添加超级列。）在这两个系统，你必须像你行和列习以为常，但稀疏行：每一行可以有许多或尽可能少列的需要，以及列不必须提前定义。

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

文档数据库基本上是下一阶段重点/值，允许嵌套的值与每个键关联。文件数据库支持查询的效率比每次返回了整个BLOB更简单。

Neo4J有一个真正独特的数据模型，对象存储在图和节点和边的关系。对于查询适合这个模型（例如，分层数据），它们可以是1000倍速度比替代品。

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

持久性设计

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

在内存数据库是非常，非常快的（Redis达到每秒超过100,000操作一台计算机上），但不能与数据集的工作，超出可用的RAM。耐久性（保留数据，即使服务器崩溃或断电）也将是一个问题的数据量，可以预期损失之间的冲（复制数据到磁盘）可能非常大。 Scalaris，其他内存数据库，我们的名单上，意向处理与复制耐久性问题，但由于它不支持多个数据中心的数据将仍然容易受到停电的事情一样。

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