我谈一点个人的见解吧。
成都创新互联长期为成百上千客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为同仁企业提供专业的成都网站设计、做网站，同仁网站改版等技术服务。拥有十载丰富建站经验和众多成功案例,为您定制开发。
记得之前看过一篇帖子，讲的是可能我们所说的非关系型数据库是我们翻译错了。年代久远，找不到原贴了，但是大概说的是非关系型数据库的名字叫Not Only Sql，我们简化过来就叫NoSql，所以看着就像是非关系型数据库，然后我们再顾名思义，就是数据之间没有关系的数据库，这个理解我不赞同。
如果从名字上来看，我觉得可以叫做不仅仅是关系型的数据库，更为恰当，当然，我们也不能否认，这类数据库确实在数据关联之间更为自由，约束条件更少，（甚至没有），但是这并不能阻挡它的发展，以“键值对”为基础的NoSql在性能上可以说是碾压对手，大家都知道NoSql不需要经过Sql层的解析的，相比关系型数据库数据之间的高耦合性，这让它具有更高的平行扩展性，当然这方面你需要去看一下相关的知识，高耦合低聚合等等概念需要理解一下。
大概就是我的理解了吧，关系型数据库就不用说了吧，我们常常用到，现在的主流数据库我们也都在接触，大到Oracle，小到Sqlite，相信你也比较熟悉，这些数据库都是支持事务和相当复杂的查询的，往往我们一条查询语句可以上百行（一子句一行）甚至上千行，这些都是NoSql做不到的，（注意我说的是一条查询语句），事务这个概念我也不多提了，这个网上就太多了，如果涉及到高并发之类的，可以多线程+事务，效率更高一些。
最后再补两句，好像现在的NoSql数据库的发展趋势很微妙，描述在往一些关系型数据库的基础模型延伸。
nosql适合存储非结构化数据吗
基本含义NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨
物联网时代的大数据策略
互联网时代，PC、Pad、智能手机等设备无处不在，数以亿计的用户通过微博、微信、SNS、博客等途径产生大量的自媒体数据，电商、新闻类网站、搜索引擎每时每刻都在记录着丰富的用户行为信息，海量的数据促进了云计算，分布式技术的发展，而这些技术反过来不仅推动了Web和移动互联网的革新，也推动了物联网的飞速前进。现在，我们正逐渐迈入物联网时代，实现万物互联的愿景，如果说之前人是信息生产的主体，那么或许不久的将来设备将成为主角，它们将源源不断地产生与人相关的衣食住行信息，这些信息会通过云计算、数据挖掘等技术实现价值的升华从而为用户提供更优质、贴心的服务。那么物联网时代会产生什么样的数据，应该采用什么样的大数据策略呢？
THINKstrategies 的总经理 Jeff Kaplan 在自己的博文《 当物联网遇见大数据 》中写道：
“你不能使用现在的策略，因为可以被捕获、管理并利用的数据将更加多样化，同时用例也会更加丰富。附加到各种设备和对象上的传感器会产生各种类型的数据。这些数据将会用于各种响应式的、主动的或者 创造性的目的 。IT部门的任务就是与业务部门一起工作，完全理解物联网方面的用例，然后寻找满足业务需求的技术。特别是，IT部门必须识别出最优的分析平台和工具，让业务用户能够获取到需要的数据，分析数据的含义并快速地做出响应。”
Gartner公司的副总裁、著名分析师 Joe Skorupa 认为：
“分布在世界各地的物联网设备将产生大量的输入数据，将所有的数据传送到一个位置进行处理无论从技术上还是从经济上都是无法实现的。最近的趋势——将应用程序集中起来以便于降低成本并增强安全性——并不适合物联网。组织必须将数据集中到多个分布式的小型数据中心中，在此对数据进行初步的处理并发送到一个中心站点进行额外的处理。数据中心管理员需要在这些区域部署更加具有前瞻性的容量以满足业务发展的需要。”
Patrick McFadin则在自己的博文《 物联网：数据都去了哪里？ 》中阐述了一个具体的数据策略解决方案。他认为整个过程可以分为三个阶段：产生数据并通过Internet传递、中央系统收集并组织数据、持续的数据分析与使用。
第一阶段需要决定数据创建的标准以及如何通过网络进行传递。Patrick McFadin认为可以通过HTTP、MQTT和CoAP三种常用的标准协议传递数据。HTTP通用程度高，但是它的头中包含大量冗余信息，不太适合带宽比较低的场景。MQTT基于发布/订阅模型，新的设备或者服务能够非常容易地连到中央系统上消费消息。另外，它在消息大小上比HTTP更轻量，但是缺点是不包含加密标准。CoAP适合于低功耗、低带宽的场景，与MQTT的订阅模式相比它更侧重于一对一的连接。
第二阶段则需要根据设备、网络以及功耗的限制决定是实时地收集数据还是在某个时间批量收集，同时还需要决定如何存储数据。如果是实时收集，那么必须要考虑数据库的写入速度，这对于传统的数据库而言可能是一个挑战，但是像 Cassandra 这样的NoSQL数据库却能够轻松应对。
一旦完成了数据的收集与存储，接下来就是分析了，这才是整个过程最核心的部分。此时需要考虑需要何时使用分析结果，是否需要立即或近乎实时的分析，还是仅仅需要对历史数据进行处理。越来越多的人在使用Apache Spark分析大数据，使用Spark Streaming满足近乎实时的要求，如果将这些技术与Cassandra这样的NoSQL数据库结合在一起使用，那么开发者就能够处理并分析大规模、快速移动的数据集。
那么是不是所有的物联网厂商都需要自己去构建相关的数据解决方案呢？也不尽然，在云计算的时代大可以利用云服务提供商的资源，以降低相关的成本，对小公司或初创公司更是如此。
Mike Kavis最近在自己的博文《 物联网将彻底改变你的大数据策略 》中阐述了自己的方案，他认为：
“在物联网时代，面对PB级的数据，企业将难以以一己之力完成基础设施的建设。物联网所产生的大量数据不仅会驱动现在的数据中心发生根本性的变化，同时也会驱动相关企业采用新的大数据策略。由于缺乏相关技能以及持续增长的数据对基础设施采购的需求，企业将逐步放弃DIY模式，转而使用PaaS和托管的解决方案，借助于数据库即服务（例如Amazon的Redshift、Hortonworks和Cloudera的企业级Hadoop）、托管的大数据服务（例如Treasure Data）以及矩阵式的数据中心服务（例如GoGrid）实现自己的物联网数据分析方案。
总之，物联网的价值在于数据。企业对数据的分析工作启动地越快，挖掘出的业务价值就越多。而云服务提供商的目的就是通过加大相关的投入，消除数据收集、管理的风险以及复杂性，让客户能够专注于分析。”
以上是小编为大家分享的关于物联网时代的大数据策略的相关内容，更多信息可以关注环球青藤分享更多干货
什么是NoSQL数据库？从名称“非SQL”或“非关系型”衍生而来，这些数据库不使用类似SQL的查询语言，通常称为结构化存储。这些数据库自1960年就已经存在，但是直到现在一些大公司（例如Google和Facebook）开始使用它们时，这些数据库才流行起来。该数据库最明显的优势是摆脱了一组固定的列、连接和类似SQL的查询语言的限制。有时，NoSQL这个名称也可能表示“不仅仅SQL”，来确保它们可能支持SQL。 NoSQL数据库使用诸如键值、宽列、图形或文档之类的数据结构，并且可以如JSON之类的不同格式存储。
用于输出指定的值：
s:property value="%{@cn.csdn.hr.domain.User@Name}"/br/
s:property value="@cn.csdn.hr.domain.User@Name"/Br/!-- 以上两种方法都可以 --
s:property value="%{@cn.csdn.hr.domain.User@study()}"/
常见的理解及分析
目前流行的、对CAP理论解释的情形是从同一数据在网络环境中的多个副本出发的。为了保证数据不会丢失，在企业级的数据管理方案中，一般必须考虑数据的冗余存储问题，而这应该是通过在网络上的其他独立物理存储节点上保留另一份、或多份数据副本来实现的（如附图所示）。因为在同一个存储节点上的数据冗余明显不能解决单点故障问题，这与通过多节点集群来提供更好的计算可用性的道理是相同的。
附图 CAP理论示意图
其实，不用做严格的证明也可以想见，如附图的情况，数据在节点A、B、C上保留了三份，如果对节点A上的数据进行了修改，然后再让客户端通过网络对该数据进行读取。那么，客户端的读取操作什么时候返回呢？
有这样两种情况：一种情况是要求节点A、B、C的三份数据完全一致后返回。也就是说，这时从任何一个网络节点读取的数据都是一样的，这就是所谓的强一致性读。很明显，这时数据读取的Latency要高一些（因为要等数据在网络中的复制），同时A、B、C三个节点中任何一个宕机，都会导致数据不可用。也就是说，要保证强一致性，网络中的副本越多，数据的可用性就越差；
另一种情况是，允许读操作立即返回，容忍B节点的读取与A节点的读取不一致的情况发生。这样一来，可用性显然得到了提高，网络中的副本也可以多一些，唯一得不到保证的是数据一致性。当然，对写操作同样也有多个节点一致性的情况，在此不再赘述。
可以看出，上述对CAP理论的解释主要是从网络上多个节点之间的读写一致性出发考虑问题的。而这一点，对于关系型数据库意味着什么呢？当然主要是指通常所说的Standby（关于分布式事务，涉及到更多考虑，随后讨论）情况。对此，在实践中我们大多已经采取了弱一致性的异步延时同步方案，以提高可用性。这种情况并不存在关系型数据库为保证C、A而放弃P的情况；而对海量数据管理的需求，关系型数据库扩展过程中所遇到的性能瓶颈，似乎也并不是CAP理论中所描述的那种原因造成的。那么，上述流行的说法中所描述的关系型数据库为保证C、A而牺牲P到底是在指什么呢？
因此，如果根据现有的大多数资料对CAP理论的如上解释，即只将其当作分布式系统中多个数据副本之间的读写一致性问题的通用理论对待，那么就可以得出结论：CAP既适用于NoSQL数据库，也适用于关系型数据库。它是NoSQL数据库、关系型数据库，乃至一切分布式系统在设计数据多个副本之间读写一致性问题时需要遵循的共同原则。
更深入的探究：两种重要的分布式场景
在本文中我们要说的重点与核心是：关于对CAP理论中一致性C的理解，除了上述数据副本之间的读写一致性以外，分布式环境中还有两种非常重要的场景，如果不对它们进行认识与讨论，就永远无法全面地理解CAP，当然也就无法根据CAP做出正确的解释。但可惜的是，目前为止却很少有人提及这两种场景：那就是事务与关联。
先来看看分布式环境中的事务场景。我们知道，在关系型数据库的事务操作遵循ACID原则，其中的一致性C，主要是指一个事务中相关联的数据在事务操作结束后是一致的。所谓ACID原则，是指在写入/异动资料的过程中，为保证交易正确可靠所必须具备的四个特性：即原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）和持久性（Durability）。
例如银行的一个存款交易事务，将导致交易流水表增加一条记录。同时，必须导致账户表余额发生变化，这两个操作必须是一个事务中全部完成，保证相关数据的一致性。而前文解释的CAP理论中的C是指对一个数据多个备份的读写一致性。表面上看，这两者不是一回事，但实际上，却是本质基本相同的事物：数据请求会等待多个相关数据操作全部完成才返回。对分布式系统来讲，这就是我们通常所说的分布式事务问题。
众所周知，分布式事务一般采用两阶段提交策略来实现，这是一个非常耗时的复杂过程，会严重影响系统效率，在实践中我们尽量避免使用它。在实践过程中，如果我们为了扩展数据容量将数据分布式存储，而事务的要求又完全不能降低。那么，系统的可用性一定会大大降低，在现实中我们一般都采用对这些数据不分散存储的策略。
当然，我们也可以说，最常使用的关系型数据库，因为这个原因，扩展性（分区可容忍性P）受到了限制，这是完全符合CAP理论的。但同时我们应该意识到，这对NoSQL数据库也是一样的。如果NoSQL数据库也要求严格的分布式事务功能，情况并不会比关系型数据库好多少。只是在NoSQL的设计中，我们往往会弱化甚至去除事务的功能，该问题才表现得不那么明显而已。
因此，在扩展性问题上，如果要说关系型数据库是为了保证C、A而牺牲P，在尽量避免分布式事务这一点上来看，应该是正确的。也就是说：关系型数据库应该具有强大的事务功能，如果分区扩展，可用性就会降低；而NoSQL数据库干脆弱化甚至去除了事务功能，因此，分区的可扩展性就大大增加了。
再来看看分布式环境中的关联场景。初看起来，关系型数据库中常用的多表关联操作与CAP理论就更加不沾边了。但仔细考虑，也可以用它来解释数据库分区扩展对关联所带来的影响。对一个数据库来讲，采用了分区扩展策略来扩充容量，数据分散存储了，很显然多表关联的性能就会下降，因为我们必须在网络上进行大量的数据迁移操作，这与CAP理论中数据副本之间的同步操作本质上也是相同的。
因此，如果要保证系统的高可用性，需要同时实现强大的多表关系操作的关系型数据库在分区可扩展性上就遇到了极大的限制（即使是那些采用了各种优秀解决方案的MPP架构的关系型数据库，如TeraData，Netezza等，其水平可扩展性也是远远不如NoSQL数据库的），而NoSQL数据库则干脆在设计上弱化甚至去除了多表关联操作。那么，从这一点上来理解“NoSQL数据库是为了保证A与P，而牺牲C”的说法，也是可以讲得通的。当然，我们应该理解，关联问题在很多情况下不是并行处理的优点所在，这在很大程度上与Amdahl定律相符合。
所以，从事务与关联的角度来关系型数据库的分区可扩展性为什么受限的原因是最为清楚的。而NoSQL数据库也正是因为弱化，甚至去除了像事务与关联（全面地讲，其实还有索引等特性）等在分布式环境中会严重影响系统可用性的功能，才获得了更好的水平可扩展性。
那么，如果将事务与关联也纳入CAP理论中一致性C的范畴的话，问题就很清楚了：关于“关系型数据库为了保证一致性C与可用性A，而不得不牺牲分区可容忍性P”的说法便是正确的了。但关于“NoSQL选择了C与P，或者A与P”的说法则是错误的，所有的NoSQL数据库在设计策略的大方向上都是选择了A与P（虽然对同一数据多个副本的读写一致性问题的设计各有不同），从来没有完全选择C与P的情况存在。
结论
现在看来，如果理解CAP理论只是指多个数据副本之间读写一致性的问题，那么它对关系型数据库与NoSQL数据库来讲是完全一样的，它只是运行在分布式环境中的数据管理设施在设计读写一致性问题时需要遵循的一个原则而已，却并不是NoSQL数据库具有优秀的水平可扩展性的真正原因。而如果将CAP理论中的一致性C理解为读写一致性、事务与关联操作的综合，则可以认为关系型数据库选择了C与A，而NoSQL数据库则全都是选择了A与P，但并没有选择C与P的情况存在。这才是用CAP理论来支持NoSQL数据库设计正确认识。
其实，这种认识正好与被广泛认同的NoSQL的另一个理论基础相吻合，即与ACID对着干的BASE（基本可用性、软状态与最终一致性）。因为BASE的含义正好是指“NoSQL数据库设计可以通过牺牲一定的数据一致性和容错性来换取高性能的保持甚至提高”，即NoSQL数据库都应该是牺牲C来换取P，而不是牺牲A。可用性A正好是所有NoSQL数据库都普遍追求的特性。
