调查显示超过50%DBA开始学习使用NoSQL（转自csdn）

有多少数据库工程师们开始对NoSQL感兴趣了呢？

日前，在CSDN举行的一项针对DBA对NoSQL的态度调查中，已有超过50%的数据库工程师已经开始关注并学习使用NoSQL。（本次数据样本搜集761份）

NoSQL需解决与关系型数据库融合的问题

从这些数据库工程师们对待NoSQl的态度上，我们了解到，他们对于NoSQL目前持有有三种态度：

1、关系型数据库日落西山

2、NoSQL难堪大任

3、NoSQL与关系型数据的融合

对相当多的DBA而言，NoSQL已经达到了快被“神”化的境界——他们的理由是，NoSQL是一个完美的架构，既解决了扩展的问题，又解决了可靠性的问题，同时还可以不受关系型数据库的约束（费用大大降低）。

但事实果真如此吗？

实际上，作为一个存储数据的核心组件，企业在处理问题时，考虑更多的是在对数据进行人工订正维护的时候是否方便操作，在需要抽取其中某部分数据到线 下给开发/测试部门使用的时候是否方便，最重要的是，当他整个崩溃之后我们可以怎么恢复？当企业面对这些问题的时候，是否有合适便利的手段来避免或者解决 呢？

确实，理念很完美，架构很完美，但目前的NoSQL产品的实现是不是真的也如此完美呢？恐怕没有哪个产品敢拍着自己的胸脯说他们的产品不会崩溃，就 像没有厂商向我们保证他们的硬件在达到标称的使用寿命之前不会损坏一样。既然存在整个崩溃的可能，那就必须考虑如何应对。我们不能只是考虑这个听上去完美 的分布式系统在某个节点崩溃之后可以很好的”自愈”，不能只考虑当目前整个集群资源达到瓶颈之后仅仅只需要在线增加一个节点就可以”自我完成负载/数据重 分布”。我们还需要考虑他的整体可靠性，还需要考虑更为恶劣的环境更为残酷的场景下，他是否还能生存，此外，成本问题也是一个必须要考虑的，有的 NoSQL解决方案需要的是三倍的冗余，可想而知，光是服务器或存储的成本就绝对不是一个小数目。

关系型数据库在刚开始产生的时候，同样面临了各种各样的问题，同样受到过大量的质疑。但是，通过不断的完善和适应，关系型数据库不论在灾难恢复方面 还是在可操作性和可维护性方面都做了大量的工作。当然，在这么多年的市场需求下，也培养出了大量的专业技术人员。但NoSQL发展到现在，才经历了很短的 时间，缺少在恶劣环境下的磨炼，缺少复杂环境下的检验。在这种情况下，没有谁敢轻易决定将一个公司最为核心的资本上轻易从关系型数据库中迁移出来。

此外，NoSQl的技术人才短缺在也是一个麻烦的问题，这几年，关于NoSQL技术人才的招募一直是技术人才市场上的热门，不少企业甚至不惜重金在 人才市场上招人，但是最后能成功招募到靠谱的人的企业可以说是屈指可数，可以在这个领域是严重缺乏有丰富经验的人才。其实也不难理解，国内目前真正成熟的 NoSQL应用，除了能用十根手指就能数清的那几家大型互联网公司外，还有谁呢？

话又说回来，其实NoSQL的出现并非为了替代非关系型数据库，只是希望在一些关系型数据库已经无法满足或者在某个特定需求下去解决问题，所以目前 来看，NoSQL产品有非常鲜明的特点，各个产品的技术也还在不断完善发展中，其将成为特定场景下的数据读写解决方案的补充，因此其短期内也恐难以成为数 据管理上的Leader，而关系型数据库经过了多年的发展，已经成为了成熟的商业产品。

NoSQL产品的优势在于扩展性、灵活和海量数据处理上，而传统的关系型数据库的优势在于：通用、成熟度高，运维成本低，使用成本低等方面。而他们 之间也不是替代的关系，而是互补的关系，可以预见的是，在未来相当长的一段时间内，关系型数据库还将是企业用户的首选数据库处理和存储方案，但是在海量数 据处理和数据仓库上，NoSQL的优势无疑更加明显。

NoSQL——Which is your best choice？

Cassandra

在此次调查中，作为目前最受开发者关注的NoSQL解决方案，Cassandra得到了开发者64.7%，也就是近2/3的人支持度，这也是在意料之中的事。

Cassandra最初由Facebook开发，以Amazon专有的完全分布式的Dynamo为基础，并结合了Google BigTable基于列族（Column Family）的数据模型。其在实现了BigTable的数据模型的同时，使用了基于Amazon的Dynamo的系统架构来存储数据。

Cassandra的优点在于你可以根据具体情况来选择一个最佳的折衷，来满足特定操作的需求。在实际操作中，Cassandra也更适合于实时事务处理和提供交互型数据。

尽管在2010年Cassandra成为了Apache的顶级项目，但Cassandra也并非绝无弱点，虽然其数据库速度更快，但或许它仍然处于 实验期，在去年年中时，Twitter曾宣布将不再使用Cassandra数据库系统储存数据，并将被改做用于Twitter实时分析产品的技术研发。

此外，Cassandra来源自Facebook，但是在Facebook内部Cassandra目前只用在inbox search产品上，容量大约有100-200T。且Inbox Search在Facebook的基础架构中也并非核心应用。并且还传出不少rumors说facebook已经放弃Cassandra。2010年，著 名的社交新闻网站Digg工程副总裁约翰·奎恩（John Quinn）辞职，据说也与Cassandra的运行状况并不能令用户满意有关。

MongoDB

    关于MongoDB的一些优劣势分析， 实际上，MongoDB最大的优势无疑于能够快速部署，这也和应用有关，和关系型数据库相比，它的部署时间仅为它的1/5；此外，replication 模式(replica sets)也是MongoDB的一大特性，完善的Java API无疑也是企业级开发人员所关注的特性。另一个最强大的理由在于，10gen已经打算给MongoDB继续投入资金。

    但MongoDB的劣势也相对突出，首先是业界关于成熟的MongoDB大型应用方案还很少，Facebook和Twitter等互联网企业都未采用 MongoDB，其可靠性到底如何还有待实践检验。此外，和以往的存储相比，数据的关系性操作不再存在，这也是开发人员不得不考虑的一个问题。

CouchDB

CouchDB或许是一个选择，但是当CouchDB项目自己不再认为是NoSQL的一分子，CouchDB在NoSQL发展的前景无疑蒙上了一层阴影。

CouchDB的核心开发人员Mikeal Rogers曾表示，对于CouchDB而言，今后将专注于支持离线数据和应用。

也许CouchDB在服务器端应用的表现上不如MongoDB，和Cassandra、Redis、Tokyo Cabinet、Riak等又差异很大，但它对移动平台的良好支持、为JavaScript. Web开发提供的极大便利、本身可以作为Web应用宿主以及作为云计算平台组件的大构想，都非常有特色。

结语：实际上，单独对NoSQL进行比较是没什么意义的，和关系型数据库相比，毕竟NoSQL才刚起步几年，目前很难看到真正成熟的企业应用，即便是Google或者Facebook，也在不断地对自己的技术路线进行修正。

我们在此也并非强调谁才是数据库工程师最佳的选择，对他们而言，必须清楚一个产品可能存在的风险和缺陷，并且清楚如何做能避免这些 风险和缺陷，同时还要让自己有能力避免这些风险和缺陷。找到适合自己企业的技术，用最合理的方式进行解决，不管是关系型还是非关系型，这才是最完美的海量 数据解决方案。

2_110121030814_1.jpg

30908_1.jpg

842_1.jpg

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24485833/viewspace-684483/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24485833/viewspace-684483/