您当前的位置: 之前说到博客长草的问题，想了想除了很忙特别忙非常忙各种瞎忙忙你妹啊外，主要还是不知道写什么好——到这家公司的两年中从JS到领域驱动到缓存服务器从前端到后端各种折腾，有些东西虽然有所心得，不过既然前人已多有总结，我也懒得多说了；还有些东西神功未成，不敢献丑人前。索性还是尝试着翻译试试吧。
本书（NoSQL Distilled）厚度适中，上下两部分统共500来页，而且以基本的知识点为主——更重要的是貌似还没人翻译的样子，故而拿来试水一番。推荐有能力的话还是购买原版吧，也算对大牛写书的一种支持。
实际进行翻译了才觉得前人所提“信、达、雅”三点实在是强人所难，单单一个标题试着死活不落窠臼翻译为《NoSQL精粹》都绞尽脑汁，最终在发稿前放弃挣扎。谬误在所难免，具体以原文为准，欢迎留言斧正。
关于翻译进度，计划大致上二到三周一章，把第一部分（关于NoSQL中的各种概念）译完即止。如果想知道第二部分 穿山甲 说了什么，请购买原书。个人觉第一部分大致上可以算精华中的精华，第二部分有兴趣的人请支持正版吧。
说起来前几天发现我这么冷清的博客都被自动采集了，看来以后要不时加点宣传才行。您看到的这篇文章来自难以名状之博客(www.cnblogs.com/Nyarlathotep/)
以下正文：
NoSQL精粹——一窥愈加丰富的持久化方案的世界（NoSQL Distilled）
序言
在我们长达二十年左右的企业信息系统开发的历程中，我们经历过开发语言、架构、平台以及开发过程方面的不断变化。不过二十年的时间中时移世易，我们仍用关系型数据库存储数据。虽然关系型数据库的王者地位并非无法撼动——有些挑战者已经在特定的领域获得了成功，但整体来说，对于架构师而言如何进行数据存储意味着选择何种关系型数据库进行存储。
在数据存储领域保持稳定是非常必要的。对于一个机构而言其数据将比程序的寿命长的多（至少大家都这么说——虽然也有大量多年前写就的程序仍然被使用着）。所以选择一种大家能良好理解、支持从多种应用程序平台上操作的、稳定的数据存储方案是非常有价值的。
但时至今日，新的挑战者在NoSQL的旗帜下对关系型数据库的无可动摇的地位发起了挑战。这挑战者诞生于为处理大数据所带来的搭建大规模普通市售服务器（commodity server）硬件集群的方案这种根本性变化所产生的需求之中。对NoSQL的需求也导致了长期以来对关系型数据库难以在程序代码中被使用的顾虑浮出水面。
“NoSQL”的定义其实是含混不清的。大致上NoSQL代表了类似Cassandra、Mongo、Neo4J或Riak这样的非关系型数据库。这些非关系型数据库通常没有数据架构，在集群中运行，并且能牺牲事务一致性以换取其他有用的特性。NoSQL的拥护者们声称通过采用NoSQL他们能搭建性能更强、扩展性更高、更容易开发的系统。
NoSQL浪潮是否敲响了关系型数据库的第一声丧钟？抑或仅仅只是又一位关系型数据库王者地位的觊觎者？我们的回答是：“都不是”。关系型数据库是一种将长期存在的强力工具，但我们也见识到人们在从根本上改变将关系型数据库等价于数据库这种认知。我们的观点是一个有着愈加丰富的持久化方案的世界正迎面而来——在这个新世界中企业，甚至单个程序，将采用多样的数据管理方案。为了配合这个新世界的来临，架构师们将需要了解这些技术，并能从中选择合适的技术以迎合特定的需求。我们本没有预料到的是，写这本书其实并没有花费我们太多的时间与精力。
本书寻求给予读者足够的知识以判断NoSQL数据库是否值得在未来的项目中得到应用。项目之间本身就千差万别，我们也无法通过简单的决策树来选取数据存储方案。相对的，本书将尝试给予读者充足的NoSQL方面的的背景知识，以支持读者不用在网络中四处搜罗就作出选择。本书将短小精干，以方便读者能迅速概览全书。本书并不直接针对各个项目的选择作出定论，但必定有助于读者减少需要考虑的要素以及明确问题点。
为什么NoSQL数据库受到瞩目？
我们发现，通常人们考虑采用关系型数据库是基于以下两个原因：
程序产出效率。 大量的开发精力被投入到了建立关系型数据库中的数据结构与内存中的数据结构的映射上。某些NoSQL数据库或许能提供更适合程序需求的数据模型，以简化数据交互过程，并带来做的更少，错的更少，变更更快的潜在收益。
大数据。 许多机构发觉捕捉并以更快的速度处理更多数据是很有价值的。这些机构发现采用关系型数据库在处理海量数据方面代价高昂，甚至无法承担重任。究其原因，关系型数据库被设计为单机运行，但通常采用集群环境以处理大数据或承担大运算负荷更为经济。许多NoSQL数据库从骨子里就为集群环境而生，故而它们更适合处理大数据的场景。
本书结构
本书分为两大部分。第一部分专注于读者需要知悉的关于NoSQL数据库是否适合您的需求以及各种NoSQL数据库之间有何差别的核心概念。第二部分更多涉及在系统中采用NoSQL数据库的相关知识。
第一章将开宗明义，解释为何NoSQL以野火燎原之势兴起——大数据处理的需求导致了大型系统中集群由纵向扩展转为通过集群横向扩展的变革。这种需求解释了大量NoSQL数据库的数据模型的一个重要特性——直接存储各种各样由一组相互之间紧密联系、作为一个单元被访问的数据结构。本书中我们将称呼这种结构为一个聚合（aggregate）。
第二章描述了聚合如何通过NoSQL领域主要数据模型中的以下三种得到明确体现：键值对型（key-value） 、 文档型（document） 以及 列簇型（column family） 数据库。聚合作为大部分程序中自然的交互单元（unit of interaction），还带来了改善程序在集群中运行的能力、简化了数据访问相关代码的编写的好处。第三章转而讲述了聚合的缺点——难以处理不同聚合之间的实体的关系。这种缺点自然而然地将我们导向图形数据库，一种无法归类为面向聚合的NoSQL数据模型。我们也将关注NoSQL数据库无模式的特性——一种多少提高了灵活性，但并没有您刚开始时想象中灵活的功能。
鉴于本书覆盖了NoSQL的数据模型方面问题，本书将进而讲述分布式：第四章讲述了数据库如何将数据分布在集群中运行。数据将被拆解为一个个的切片（sharding ）以及复制（replication），复制功能要么实现为主从（master-slave）模式，要么实现为点对点（peer-to-peer）模式。在讲述完分布式模式后，本书进而讲述一致性问题。相对于关系型数据库，NoSQL数据库由集群友好的理念出发，提供了更多样的一致性选项。故而第五章描述了数据读取与修改时一致性（consistency ）的规则发生了什么变化，仲裁机制（quorum）的作用，以及为何甚至持久性也能在某种程度上进行折中。如果你已听说过NoSQL的一些方面，那么很有可能也听说过CAP理论；“CAP理论”节解释了什么是CAP理论以及此理论如何与NoSQL数据库相适应。
虽然上述章节主要关注于理论上数据如何分布式存储的同时保持一致性，接下来的两个章节讲述了一系列将理论联系进实际的工具。第六章描述了版本标记（version stamps），版本标记被用于数据的变更跟踪以及探知不一致性。第七章概要介绍了map reduce（映射——规约），map reduce是一种适用于集群的，故而适合NoSQL系统的分布式计算方式。
讲述完这些概念后，本书将转而通过以前述四大类数据结构中代表性的数据库为例子，描述如何实际使用：第八章采用Riak作为键值对类型数据库的例子，第九章以MongoDB为例介绍文档型数据库，第十章选取Cassandra来探究列簇型数据库，最后第十一章将推出Neo4J以一探图形数据库。我们要强调下，这些章节并非全面详尽的教程——有太多细节是本书无暇顾及的，留待大家自行尝试。本书所举的例子也不暗示推荐使用这些数据库。您将看到操作这些种类的数据库需要编写什么样的代码，以在使用这些类型的数据库时能大致上有相关的观念。
一个关于NoSQL数据库的常见观点认为由于其没有架构（schema），在程序生命周期中改变数据的结构并没有多少难点。本书并不赞同此观点——一个无架构的数据库仍然需要在改变数据架构时修改其所具有的隐式数据结构（implicit schema），所以第十二章介绍了对于显示架构与隐式架构的数据库，如何进行数据迁移。
以上所有章节应当能让读者明确NoSQL不是一种数据库，也不能代替关系型数据库。第十三章中将展望即使在一个应用程序中也有多种数据存储方案共存的多姿多彩的未来。接着第十四章超越了本书所涉及的范畴，简要介绍了本书没有涉及到的多姿多彩的存储世界中其他技术方案。
了解了全部这些知识后，读者将最终需要为选用何种数据存储技术作出自己的选择，所以本书最后一章（第十五章，选择适合你的数据库）提供了一些有助于您作出选择的建议。在本书的观点中，主要需要考虑以下两大要素——寻求一种其数据存储模型与您的应用程序非常相配的有生产力的编程模式，以及确保您能获得所需求的数据访问性能与弹性。由于当前NoSQL仍为新生事物，我们或许无一定之规以供遵循，并且您需要在您需求的范畴内测试您的选择。
本书仅仅是对NoSQL世界的简要概览——我们故意限制了本书的长度。我们选择介绍了我们认为最关键的知识——所以读者您不必为此做出判断。如果您深入研究这些技术，您将需要比本书所涉及到的范畴更进一步，不过我们期望本书为您提供了一个好的起点。
需要指出的是，NoSQL是计算机产业中一个变化迅速的领域。增加新功能，推出新数据库，每年重点都在发生着变化。纵然具体的技术变化着，我们也相信理解概念是非常有价值的，故而本书对关注于概念作出了大量努力。我们相当确信本书的大部分论述将保持长期正确，不过必定不会所有论述能长期有效。
本书目标读者
本书的目标读者为正在为了新项目，或由于现有项目遇到瓶颈而考虑采用某些类型的NoSQL数据库的人。
我们的目标是给予读者足够的信息以判断是否NoSQL数据库能切合您的需求，以及如果决定采用NoSQL数据库，需要对何种工具进行深入了解。我们假设的主要目标读者为架构师或技术领头人，但我们认为本书对希望对这个新领域能有一定了解的管理岗位的人员也能有所助益。我们还认为如果您是希望了解NoSQL技术的开发者，本书将是一个好的起点。
对于具体的数据库，本书没有涉及编程或部署方面的细节——这些细节留待专门的书籍阐明。我们也坚持只对具体的数据库进行简要的介绍以限制本书的页数。这是本我们认为能在航班上阅读的书：本书不能回答您提出的方方面面的问题，但能引导您提出值得疑问的问题。
如果您已经深入了解NoSQL世界，本书也许不能为您带来更多知识。不过当您需要向别人阐述您所学到的内容时，本书也许能有所助益。理解NoSQL涉及到的相关问题是非常重要的——尤其在您说服其他人在项目中采用NoSQL数据库时。
本书用到的数据库
在本书中，我们遵循了基于其数据模型的NoSQL数据库的主流类别。下图为四种主要数据模型类别以及其代表性的几种数据库的表格。这并不是一个详尽的列表——图中只列出了常见的几种数据库。在本书写作时，您能在 http://nosql-database.org/以及http://nosql.mypopescu.com/kb/nosql获得详尽的列表。对于每种类型，相关章节中采用的数据库用斜体标出。
我们期望能为每一类别选取最具代表性的数据库。当本书讲述具体的例子时，绝大部分论点也能应用于整个类别的数据库——即使是某些非常特殊且难以简单归类的产品。我们将对键值对、文档、列簇以及图数据库各选择一个代表；当时机恰当时，我们也将提到能满足您特殊需求的其他产品。
这种基于数据模型的分类有效，但简单粗暴。不同数据模型，比如键值对与文档数据库，之间的分界线，经常比较模糊。许多数据库不存粹属于某个类别；如OrientDB宣称自己为文档/图数据库。
感谢
BLABLABLA，有兴趣的请参见原书。