对此，前Google工程师，Milo（本地商店搜索引擎）创始人Ted Dziuba最近发表标题惊人的博客“I Can't Wait for NoSQL to Die”，对NoSQL的适用范围进行了分析。他认为，
成都创新互联是专业的金堂县网站建设公司，金堂县接单;提供成都做网站、成都网站制作,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行金堂县网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
NoSQL也会带来一连串的新问题，并不会成为主流，无法取代关系型数据库。
他的理由是：Cassandra等NoSQL数据库在使用上并不方便，比如，修改column family定义时就需要重启。而且NoSQL更适合Google那样的规模，而一般的互联网公司都不是Google，早早地去考虑Google那样的规模的可扩展性，纯粹是浪费时间，存在巨大的商业风险。
他还透露，即使在Google，AdWords这样的关键产品也是基于MySQL实现的。
他在文中最后表示，NoSQL当然死不了，但是
它最终会被边缘化，就像Rails被NoSQL边缘化一样
Dziuba的文章因为言辞激烈，在社区里引起了强烈反应。
SQL数据库阵营赞同者大有人在。craigslist工程师、著名的MySQL专家Jeremy Zawodny表示，在读此文的时候，不时会心一笑。他说，
NoSQL运动只是软件不断进化进程中的正常现象
。关系型数据库也会继续发展，MySQL社区不断推出的XtraDB或InnoDB插件, PBXT, Drizzle都是证据。各种技术竞争的结果是，我们获得了更多解决问题的选择。
drizzle项目开发者Eric Day也表示，NoSQL有很多值得学习的，但是目前大部分实际项目的最佳选择还是关系型数据库。
NoSQL阵营当然不会坐视不理，Cassandra项目组的Eric Evans表示，Dziuba提到Cassandra修改column family定义的问题其实很容易解决。而且，NoSQL并不是要取代MySQL，事实上Twitter仍然在用MySQL。如果关系型数据库能够承担负荷，那就用好了；如果不行，请考虑NoSQL。
而德国知名博客Code Monkeyism则嘲笑Dziuba看起来并没有用MySQL做过真实项目，因为MySQL如果没有memcache，基本上无法应付网站项目。他认为，NoSQL将使SQL数据库边缘化，而且一个重要理由恰恰是可以节省DBA的开销。
digg的前任首席架构师现在也在创业的Joe Stump说，自己现在的创业项目就是用NoSQL，而且列举了一系列问题挑战SQL阵营。
基本含义NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。NoSQLNoSQL数据库的四大分类键值(Key-Value)存储数据库这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。但是如果DBA只对部分值进行查询或更新的时候，Key/value就显得效率低下了。[3] 举例如：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.列存储数据库。这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如：Cassandra, HBase, Riak.文档型数据库文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可 以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB，已经开源。图形(Graph)数据库图形结构的数据库同其他行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语言(SQL)，因此进行数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。[2] 如：Neo4J, InfoGrid, Infinite Graph.因此，我们总结NoSQL数据库在以下的这几种情况下比较适用：1、数据模型比较简单；2、需要灵活性更强的IT系统；3、对数据库性能要求较高；4、不需要高度的数据一致性；5、对于给定key，比较容易映射复杂值的环境。
大数据时代下,DBA该何去何从
数据库管理员（DBA）的职能已扩展到数据管理、基础架构管理以及工作负载和SLA管理上。作为大数据战略的一部分，DBA的角色又是如何变化的呢？
数据管理
* 为成为数据管理专家而努力。虽然SQL数据库可以扩展以处理大数据，但数据库并不是最优解决方案。DBA正在预算方面做努力，在预算范围内，以最低的成本满足SLA。
* 出现数据ops概念。数据管理和数据治理。数据操作是团队的一部分，在收集和创建数据时共享目标、协作工作。使用自动化来挤压延迟、采取最合适的敏捷方案以提高提高效率。
* 管理、治理和软件交付。维护数据库模型和模式。在大数据中，从定义明确的转换到应用程序和工程师之间的协同工作，一切都是具有探索性的。
* 虽然开发人员认为不需要数据管理，但为了后续的分析数据，DBA们仍需要进行数据管理。
* DBA从管理数据库转变为跨多个系统的数据工程师。他们关注的是数据如何从一个数据库转移到另一个数据库、数据的消耗、数据的调整以及数据流程的管理，对于数据自动分配和执行来说这些都至关重要。
* DBA已经不再是单单只关注像SQLServer和Oracle这样的个人产品，而是必须要处理好企业大数据实施方案的执行问题。
基础架构和平台
DBA的角色已经被推到第一线上。对IT栈的演变负责。基础设施和平台的认定范围变的更大。
*这是一个不容忽视的大挑战，应用程序所使用的数据库技术不再归于DBA的控制范围内。迁移到云上的比重越大，DBA的控制范围就越小。数据越来越多，同时也在不断推出新的数据库。管理数据基础设施、提出大数据的解决喝整合方案、掌握如何归档和处理灾难恢复的技能。AWS似乎将云中的数据库选项绑定到了DBA上。DBA仍然需要在备份、灾难恢复和海量存储上多费心思。值得在备份和存储方面进行更具战略性的思考。
DBA比以往更重要，因此他们也需要学习：如何有效地集成存储在RDBMS系统中的遗留数据，同时大数据技术也是必不可少的。
* 由于大数据改变了数据架构，DBA的存在可能需要不是立竿见影的，但确实是实实在在的。新技术为数据管理提供了新的契机，使DBA和数据模式打开了一个新时代。
* 事实上，没有数据模式和Hadoop的NoSQL平台，以及支持它的一系列工具，会越来越多地部署在企业中。现在开发人员在数据本身的设计上有更多的影响力。
* 这在扩大DBA的专业范围上起到了推动作用：必须学习NoSQL系统的机制和操作；掌握管理Hadoop集群的能力；实施“无需存储数据存储数据”的方法。
* 而且，NoSQL的灵活性是以数据完整性为代价，这种模型的难度更高。目前，许多公司的网络应用程序的数据完整性已经给灵活性让位了。
* DBA必须适应设计和开发的风格变化。DBA也需要运行几个关系系统，并且认真学习NoSQL技术，对指导公司做出的部署负责。将来可能会划分出几种类型的DBA：局限于技术的；传统的管理员；努力学习并适应管理大数据的新技术和工具的。
* DBA始终是整个软件开发流程的一部分。在目前的环境中，更是需要所有的DBA都参与到整个开发过程中，尤其是规划、范围界定和原型设计部分。DBA能为企业提供有关数据基础设施功能、所需变更成本、潜在性能影响以及总体容量规划等项目的具体信息。
*鉴于对数据的使用要求，更多特定数据平台范围之外的技术正被用于实施解决方案。DBA不仅仅要专注于SQL、DDL等，还要掌握JavaScript、Java、.NET等技术。DBA会越来越精通应用容器化和系统容器化（Docker、Rkt、Linux容器等）。DBA压力会越来越大，一旦与其他角色联系到一起，数据及其管理都是穿插着多条生命线，因此需要掌握的技术就不断增加。
成功采用大数据策略的企业，早已经把DBA转变为新型数据基础管理员，包括NoSQL数据库和Hadoop在内。与开发数据管理逻辑的数据开发人员、处理和准备数据的数据科学家以及业务线上的数据分析人员相结合，DBA是操作大数据战略的重要部分。现在，DBA依赖于更智能的工具，这些工具可以管理并报告各种数据库和技术框架的数据基础架构和流程。
工作负载和SLA
* 工作结构消失了。有类型更为广泛的问题需要解决。要实现混合的环境在流和批处理中交付新的工作负载，同时又能跟得上变化。
* 现在，有许多不在数据库中管理数据，而是将数据组织成超级管理数据的数据生态系统一部分的做法。了解通信、链接的速度、安全性以及如何将来源汇集在一起。
* 比起以往，现在有更多的技术管理。理解并管理一个数据仓库的技术方法有10到20种。为了能给问题选择出正确的技术，便于管理，规模较大的企业正在考虑将搜索、NoSQL、Hadoop和GPU技术标准化。
* 从一个拥有数据库领域知识的系统管理员，到现在需要掌握处理数据集成、非结构化数据、自然语言处理、文档存储和统计。工具集可以能够简化工作。关系数据库不会有大的进展，但大数据存储会有新变化。
1. 大数据时代，DBA的角色发生了重大变化。在很长一段时间里，DBA仅仅只是一个系统管理员。他们的确有SQL知识、知道该如何优化SQL，以及对构建数据库的理解，但他们并没有主动参与到数据库系统里数据的特定用途上。
2. 大数据DBA对数据和非关系数据模型的应用程序有更深入的了解，并且必须具备执行数据集成的知识，这些数据集超出了用于商业智能（BI）应用的传统提取——转换——加载过程（ETL）。
NoSQL，指的是非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的
SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。
NoSQL(NoSQL
= Not Only SQL
)，意即“不仅仅是SQL”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数
据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。
从这一新兴技术中选择一款正确的NoSQL数据库是非常具有挑战性的。比一下网建议在选择时考虑以下因素：
并发控制
并
发控制指的是当多个用户同时更新运行时，用于保护数据库完整性的各种技术。并发机制不正确可能导致脏读、幻读和不可重复读等此类问题。并发控制的目的是保
证一个用户的工作不会对另一个用户的工作产生不合理的影响。在某些情况下，这些措施保证了当用户和其他用户一起操作时，所得的结果和她单独操作时的结果是
一样的。在另一些情况下，这表示用户的工作按预定的方式受其他用户的影响。
封锁
就是事务T在对某个数据对象（例如表、记录等）操作之前，先向系统发出请求，对其加锁。加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其它的事务不能更新此数据对象。
封锁是一次只允许一个用户读取或修改的一种机制，是实现并发控制的一个非常重要的技术。
MVCC
Multi-Version Concurrency Control多版本并发控制，维持一个数据的多个版本使读写操作没有冲突。MVCC优化了数据库并发系统，使系统在有大量并发用户时得到最高的性能，并且可以不用关闭服务器就直接进行热备份。
ACID
指
数据库事务正确执行的四个基本要素的缩写。包含：原子性(Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久
性（Durability）。一个支持事务（Transaction）的数据库系统，必需要具有这四种特性，否则在事务过程（Transaction
processing）当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。
None
一些系统不提供原子性。
镜像
数据库镜像是DBMS根据DBA的要求，自动把整个数据库或其中的关键数据复制到另一个磁盘上，每当主数据库更新时，DBMS会自动把更新后的数据复制过去，即DBMS自动保证镜像数据与主数据的一致性。
镜像分为同步和异步。
数据存储
指的是数据的物理特性怎样被存储在数据库中。
磁盘 数据被存储在硬盘驱动器里；
GFS或谷歌文件系统是一个由谷歌开发的专有的分布式文件系统；
Hadoop是Apache软件框架，免费许可下支持数据密集型分布式应用程序；
RAM随机存储器；
插件 可以添加外部插件；
Amazon S3通过Web服务接口提供存储；
BDB：BDB
全称是 “Berkeley DB”，它是MySQL具有事务能力的表类型，由Sleepycat
Software开发。BDB表类型提供了MySQL用户长久期盼的功能，即事务控制能力。在任何RDBMS中，事务控制能力都是一种极其重要和宝贵的功
能。事务控制能力使得我们能够确保一组命令确实已经全部执行成功，或者确保当任何一个命令出现错误时所有命令的执行结果均被退回。
实现语言
实现语言会影响数据库的发展速度。典型的NoSQL数据库是用低级语言如C / C + +编写的。另一方面，那些更高层次的语言如Java，使自定义更容易。
实现语言有：C, C++, Erlang, Java, Python
特性
考虑下列哪一个特点对你的数据库是最重要的：
持久性
可用性
一致性
分区容忍性
证书类型
下面这些许可证是一个不同的开放源码许可的形式：
GPL：通用公共许可证
BSD：伯克利软件分发
MPL：Mozilla公共许可证
EPL：Eclipse公共许可证
IDPL：最初的开发者的公共许可证
LGPL：较宽松通用公共许可证
存储类型
存储类型是NoSQL数据库最大的不同，是决定使用哪款数据库的一个首要指标。
关键字：支持get、put和删除操作
按列存储：相对于传统的按行存储，数据集成容易多了
面向文件系统：存储像是JSON或XML这样的结构化文件，很容易就能从面向对象软件中获取数据。
1、数据bai存储方式不同。
关系型和非关系型数据库的主要差异是数据存储的方式。关系型数据天然就是表格式的，因此存储在数据表的行和列中。数据表可以彼此关联协作存储，也很容易提取数据。
与其相反，非关系型数据不适合存储在数据表的行和列中，而是大块组合在一起。非关系型数据通常存储在数据集中，就像文档、键值对或者图结构。你的数据及其特性是选择数据存储和提取方式的首要影响因素。
2、扩展方式不同。
SQL和NoSQL数据库最大的差别可能是在扩展方式上，要支持日益增长的需求当然要扩展。
要支持更多并发量，SQL数据库是纵向扩展，也就是说提高处理能力，使用速度更快速的计算机，这样处理相同的数据集就更快了。
因为数据存储在关系表中，操作的性能瓶颈可能涉及很多个表，这都需要通过提高计算机性能来客服。虽然SQL数据库有很大扩展空间，但最终肯定会达到纵向扩展的上限。而NoSQL数据库是横向扩展的。
而非关系型数据存储天然就是分布式的，NoSQL数据库的扩展可以通过给资源池添加更多普通的数据库服务器(节点)来分担负载。
3、对事务性的支持不同。
如果数据操作需要高事务性或者复杂数据查询需要控制执行计划，那么传统的SQL数据库从性能和稳定性方面考虑是你的最佳选择。SQL数据库支持对事务原子性细粒度控制，并且易于回滚事务。
虽然NoSQL数据库也可以使用事务操作，但稳定性方面没法和关系型数据库比较，所以它们真正闪亮的价值是在操作的扩展性和大数据量处理方面。
传统数据库仍旧会有一席之地，至于NewSQL的优势又是什么，简单和大家说说：
首先关于“中间件+关系数据库分库分表”算不算NewSQL分布式数据库问题，国外有篇论文pavlo-newsql-sigmodrec，如果根据该文中的分类，Spanner、TiDB、OB算是第一种新架构型，Sharding-Sphere、Mycat、DRDS等中间件方案算是第二种（文中还有第三种云数据库，本文暂不详细介绍）。
基于中间件（包括SDK和Proxy两种形式）+传统关系数据库（分库分表）模式是不是分布式架构？我觉得是的，因为存储确实也分布式了，也能实现横向扩展。但是不是“伪”分布式数据库？从架构先进性来看，这么说也有一定道理。
“伪”主要体现在中间件层与底层DB重复的SQL解析与执行计划生成、存储引擎基于B+Tree等，这在分布式数据库架构中实际上冗余低效的。为了避免引起真伪分布式数据库的口水战，本文中NewSQL数据库特指这种新架构NewSQL数据库。
NewSQL数据库相比中间件+分库分表的先进在哪儿？画一个简单的架构对比图：
传统数据库面向磁盘设计，基于内存的存储管理及并发控制，不如NewSQL数据库那般高效利用；
中间件模式SQL解析、执行计划优化等在中间件与数据库中重复工作，效率相比较低；
NewSQL数据库的分布式事务相比于XA进行了优化，性能更高；
新架构NewSQL数据库存储设计即为基于paxos（或Raft）协议的多副本，相比于传统数据库主从模式（半同步转异步后也存在丢数问题），在实现了真正的高可用、高可靠（RTO30s，RPO=0）；
NewSQL数据库天生支持数据分片，数据的迁移、扩容都是自动化的，大大减轻了DBA的工作，同时对应用透明，无需在SQL指定分库分表键。
