开发/数据库
软件与服务//
看NoSQL数据库选型
　　Darrell Burgan：“我是专业信息系统架构师，擅长将云扩展产品和业务需求结合起来。在这个行业，我已经工作26年了。和很多老兵一样，我见证了很多技术趋势起起落落，但有一点是永恒不变的，那就是最快、最灵活地满足业务目标。
　　我猜测很多人在尝试接触NoSQL行业时会遇到困惑。让人眼花缭乱的产品、加上各种各样新奇的理念，经常会使那些只希望使用正确技术来完成特定工作的架构师更加迷惑。我当然能够理解, 因为这就是曾经的我所走过的路, 在这一路上我得到很多宝贵经验。
　　在这篇文章中，我希望和你们分享这些经验，并给出一些实用建议,如果以前有人给我这些建议,那我将少走很多弯路，现在让我们开始吧。
　　为什么要使用NoSQL？
　　如果因为它可能会是新趋势，或是因为你看到其他人正在使用它，亦或因为它是闪亮的新玩具，你才会考虑使用它，那么请马上停止。事实上，如果你并不打算解决一个关系数据库。那被称为关系数据库的古老技术才是你真正的朋友。因为它不会丢失你的数据、不会崩溃，就其所做的事情而言，它的表现已经足够完美。而且对于商务应用程序而言，许多人将它作为最直接的、持久的基础。就像家庭SUV，它并不迷人，却轻而易举就可以把你带到你想去的地方,并允许你存放各种各样的东西。
　　因此，这是我的第一条建议：
　　你只能在确实需要NoSQL数据库的时候使用它。
　　我很认真负责地说。
　　四个关键的问题
　　鉴于以上建议，你怎样知道你是不是真的需要它?在我的经验中, NoSQL最典型和突出的需求包括下列几点：
　　•我已经购买了世界上最快的机器，但我的数据库服务器仍然不堪重负, 那么,现在该做什么?
　　•我怎样才能够在另一个大陆上建立新的数据中心，并以某种方式实现与大洋彼岸的数据同步?
　　•我需要为数据分析提供大量的只读半结构化数据，并且极其不适合关系模型。我应该将它存储在哪里?
　　•我有一个十分奇异的的数据类型并且不适合关系模型。我该怎么做?
　　你可以沿着这些线路，想象许多类似的问题。但这个样本已经可以识别出NoSQL产品试图解决的各种关键问题：
　　本地规模的问题。“对于一台服务器来说，我的交易量太大，并且需要可以扩展的数据库”
　　大数据的问题。“对于单个服务器来说,我的数据量太大,而且需要跨多个服务器运行”
　　全球数据的问题。 “我不得不扩大规模以至于超出了单个数据中心,并且需要支持全球云的数据库”
　　数据的多样性问题。“我的数据需求有分歧，并且一个放之四海而皆准的方法已不再起作用。”
　　根据我的经验，没有一个NoSQL的产品很完美地解决了所有这些问题，尽管很多公司宣称他们可以做到。因此，你应该根据实际问题来选择适合的NoSQL产品，不要浪费时间去担心其它。如果你仔细想想这些，或许迫使你考虑NoSQL的商务问题将不再是其基本问题之一。
　　需要注意的是，这些问题都与成本没有任何关系。我猜测你或许认为转移到NoSQL可以节省成本，但事实是，从总数上计算你可能会花费更多。当然，在短期内你需要增加开发人员再培训的费用成本，等等。我故意省略了NoSQL的财务方面的任何讨论，因为我认为使用它的原因是基于技术的必要性，没有任何形式的成本节约或者收入加速。
　　还要注意的是，除了数据多样性的问题，所有的这些问题直接意味着需要某种分布式持久类型的系统。
　　CAP定理
　　如果我们不了解基本的上限定理，我们很难更近一步。我相信你已经听过 Eric Brewer提出的基本定理。当然，这个定理周围存在着很大的恐惧、不确定性和怀疑。让我们尽量将它变得简单一些：
　　其基本思路是，对于任何分布式数据系统来说，这里共有三种基本保障制度，在任何时刻你最多只能包括其中两个：
　　一致性：数据系统保证使用线程进行数据更新的一致性。例如隔离级别、事务等。
　　可用性：数据系统可以排除中断和故障，从而确保该系统连续运行。例如无单点故障等等。
　　分区兼容性：数据系统保证它可以兼容网络分区，而不会发生错误或数据丢失。例如现存网络中断等。
　　在这三种基本保障制度中，每一个数据系统将实现至少一个并争取实现两个。但在有人发明了时间机器之前(如果他们这样做了，我当然想跟那个人讨论一下)，其物理上并不可能保证实现所有三个。因此,CAP定理为任何持久性系统定义了关键的权衡，同时理解一个持久化系统如何与CAP定理相关联，这应该是你在评估任何持久性系统时的第一目标。
关键词：NoSQL ,CAP ,数据库,大数据
责任编辑：李荣欣
All Rights Reserved, Copyright , .cn渝ICP证B2-号 如有意见请与我们联系 powered by 天极内容管理平台CMS4i
京公网安备84号当前访客身份：游客 [
go,just do it
目前还没有任何评论
今日访问：0
昨日访问：9
本周访问：27
本月访问：108
所有访问：1612
对cap定理的理解
发表于1年前( 00:45)&&
阅读（80）&|&评论（）
0人收藏此文章,
CAP定理是设计分布式系统的基础。
CAP定理指出分布式系统不能同时满足以下三个点：
1.一致性（Consistent）
2.可用性（Availability）
3.分区容忍性（Partition Tolerance）
这三点对于设计分布式的web services是非常重要的。
这里先说一下这三点的含义，要理解它们的含义，首先需要知道CAP定理提出时是针对分布式的web services系统，这样一个系统是由N多节点构成，为了便于说明，我们假定系统只有两个节点{N1,N2}。
一致性是说在节点上的操作是原子性的，对一个节点上的数据的修改，在所有节点上同步，这期间不能有其他操作。比如一个在N1上的write操作，必须是原子性的，也即在N1写完并同时同步到N2上，这整个过程是原子性的，在这个写的过程中不能有读的操作，否则可能读到不一致的结果(例如N1修改完数据但N2还未同步）。
可用性是指节点一旦接受到请求（比如web request)，必须给予 回应。回应的内容可以是成功取到的数据或者失败消息。比如N1接到一个请求，必须返回一个请求结果或者失败结果，如果不给予任何回应，就违背了可用性。
分区容忍性是指允许节点间丢失任何消息。节点间的通信会发送消息，这些消息在网络中可能会丢失，这是客观存在的。比如N1和N2在一个局域网里相互发送消息，不管使用什么协议（tcp,udp等），两者之间都可能丢失消息包，理论上最坏情况会丢掉所有的包。
所以CAP定理是说，分布式系统在有消息丢失的网络节点间不可能同时保证操作的原子性以及对请求必定给予回应这一特性。例如满足原子性不能满足可用性的情况：在N1上写数据，N2需要同步数据，假设N1和N2之间的消息全部丢失（最坏的情况），此时N2上的数据不一致，要保证这个写操作的原子性，需要等到N2上的数据同步完成，此时其他操作都不能进行，节点接受的请求不能给予回应，系统满足不了可用性。
1)">1)">1" ng-class="{current:{{currentPage==page}}}" ng-repeat="page in pages"><li class='page' ng-if="(endIndex<li class='page next' ng-if="(currentPage
相关文章阅读第三方登录：}