|
让我们先从一个简单的问题开始：什么是NoSQL和SQL之间的真正差异？在我看来，NoSQL和SQL所提供的不同的访问模式导致非常不同的可伸缩性和性能。 NoSQL的元素，只允许在一个狭窄的预定义的访问模式下访问数据。例如，DHT（分布式哈希表）是通过哈希表的API访问;给出确切的键值（key），则返回响应的值（value）。其他NoSQL数据服务的数据访问模式同样是狭隘的和明确的，因此可伸缩性和性能结构是可预测和可靠的 。
在SQL中，访问模式事前未知，基于表建模，假设作出的访问模式，这些假设转换成预定义的优化（方式），如定义索引 。SQL是一种通用的语言，它允许以各种方式访问数据。程序员对SQL语句的执行控制能力也是有限的;大多数情况下，数据库引擎优化SQL语句的执行 。换言之，在SQL中，数据模型强制定义数据的工作方式-强调建立数据的完整性、简洁性、数据标准化和抽象，这对所有大型复杂应用极为重要。 为何选用NoSQLNoSQL方法相对SQL数据库具有巨大优势，因为它允许扩展大规模应用到新的水平 。新的数据服务基于真正可扩展的结构和架构，可构建为云模式，可构建为分布式，对开发人员很有吸引力。不需要DBA，无需复杂的SQL查询，且快速。万岁，人民的自由！
问题不小- 一个好的程序员自由选择数据模型，使用熟悉的工具写程序或开发应用，减少对他人的依赖，测试和代码优化，无需而猜测或依靠黑盒子（DB）。是的，它的测试系统响应缓慢，但后面会有人调整DB来解决这个问题... ...这些都是NoSQL运动的主要优势。 为什么不...NoSQL方法也有一些缺点。这些都是在开发阶段不可见的，但在系统、架构及操作阶段是高度可见的。
1. 在系统层次，数据模型为键值。没有能设计单一的、定义良好的数据模型的熟练专家，无论采用何种技术，都有其缺点。数据模型可能遭受数据对象重复的折磨（非规范化模型）。由于不同的开发者采用不同的对象模型且映射到持久模型时可能产生此类现象 。在系统层面上，人们还必须了解所选择的数据服务的局限性，与其大小、每秒的操作次数，以及并发模型等无关。
2. 在结构层次，两个主要问题是接口和互操作性。NoSQL的数据服务的接口有待规范。即使是DHT，这是一个简单的接口，仍然没有标准的语义，其中包括事务、非阻塞API等。每个DHT的服务使用其自己的一套接口。另一个大问题是不同的数据结构，如DHT和二叉树，只是作为一个例子，共享数据对象。所有这些服务中，指针没有内在的语义。事实上，这些服务中，处理互操作性是开发者的职责，这一点很很重要，尤其是当需要数据被多个服务访问时 。一个简单的例子：后台工作由Java实现，Web服务类工作由PHP实现，数据可以被轻易地从两个域访问数据吗？显然，人们可以使用Web服务作为前端数据访问层，但是，事情变得更复杂，并降低了业务敏捷性，灵活性和性能，同时增加了开发工作量。 3. 转向操作领域。在这里，依据我的经验，最大的困难在于，理所当然地，在云或一组固定的服务器环境下，操作环境需要一套工具，不仅可扩展性好，而且还要可管理并且稳定。当出现错误时，它不应该需要通过整个环境链和上溯到开发者层次来诊断问题。事实上，这正是运营经理的噩梦 。你有没有试过让开发人员诊断为什么支付系统不能正常工作，而他在一间酒吧喝啤酒？我确信该开发者岁月中将被他对工作的奉献精神留下深刻的印象，但这是一种来打动别人的相当昂贵的方式 ? 操作需要系统化和自包含。目前市场上可用的的NoSQL服务，这是不容易实现的，即使在诸如亚马逊的管理环境 。 所以，怎样才能获得的NoSQL方法的主要优点，同时保持SQL方法的优势呢？
SQL和NoSQL结合使用NoSQL的基础架构实现SQL数据库是一个很好的解决方案。一个SQL数据库是可扩展、易管理，云就绪、高度可用的，完全建立在NoSQL的基础结构上，但仍然提供SQL数据库的所有优势，如互操作性，定义良好的语义以及更多。
这种混合结构将不如NoSQL的服务快，但足以满足需要更强可扩展性和自然云行为的80％的市场需求。 这种解决办法还允许很容易地迁移现有的应用到云环境，从而保护相关组织在这些应用上所付出的巨大的投资。 在我看来，构建于NoSQL基础之上的SQL数据库，可以为那些在其成长期间期望灵活、高效的客户提供最高的价值。 |
|
|
