当前位置: 首页 > 业界动态 > 技术评论 > 本文


NoSQL七大真相令开发者无法接受




发布时间: 2012-10-26 9:06:47  
    NoSQL风行之后,其提供更快数据存储速度让人们倍感兴奋和陶醉。如今NoSQL的蜜月期已经结束,热情散去之后,我们需要以冷静的目光审视那些难以接受的真相。

  请不要误会。我们目前仍然在不断地尝试创建一个简单的数据存储机制,也仍然在挖掘MongoDB、CouchDB、Cassandra、 Riak和其他NoSQL数据库的深层次价值。我们仍然在规划将最重要的数据存储在NoSQL数据库中,因为它们正在日益强大,越来越经得起考验。

  不过,我们也开始察觉到了一些问题,NoSQL似乎没有我们想像中的那么完美,它们甚至经常令人感到恼火。明智的开发者明白这一切只是刚刚开始。他们没有扔掉SQL操作手册,也没有中断与他们曾经信任的SQL数据库供应商之间的联系。他们将NoSQL理解为“Not Only SQL”。

  以下是NoSQL目前面临问题的列表,这些问题或大或小,我们这样做的目的是向公众展现实际的情况并澄清事实。只有坦然面对这些问题,才能够更好地理解NoSQL的优势与不足。

  真相1:一致性困扰

  人们对SQL系统的一个不满意地方是,在两个表单间执行一个连接(JOIN)所需的计算成本。其理念是在一个,即唯一的一个地方存储数据。如果你保存一个客户名单,将他们的住址保存在一张表单上,在其他的每一张表单上使用客户的ID。当你拖动数据时,JOIN将所有ID与住址连接在一起,让所有的数据保持一致性。

  问题是JOIN非常昂贵,一些DBA(数据库管理员)使用极为复杂的JOIN命令,它们能让最好的硬件也会变成垃圾。NoSQL开发者是这么解决JOIN不足的:让我们将客户的地址像其他所有的东西一样都存储在相同的表单上。NoSQL的做法是存储与每个人配对的键值。在需要时,你可以检索到它们。

  不幸的是,希望让自己的表单保持一致的人们仍然需要JOIN。一旦开始存储客户的地址,你需要经常将这些地址的多个拷贝保存在每张表单中。你拥有多个拷贝,并且需要同时升级它们。如果你没有这么做,那么NoSQL将不会帮你进行交易。

  真相2:交易复杂性

  如果说你能够习惯没有JOIN的表单,因为你希望获得更高的速度。这种取舍还是可以接受的。有时候,SQL的数据库管理员就是出于这种原因才使用非规范化表单的。问题是NoSQL难以保持各种条目的一致性。很多时候,没有一个交易可以确保能同时对多个表单做出调整。出于这种原因,你只有依靠你自己,一个崩溃将会导致表单变得前后矛盾。

  最早的NoSQL部署无视这些交易。除非没有设定一致性,否则它们将提供保持一致性的数据列表。换句话说,他们追求的是最低价值的数据。在这种情下,错误不会导致任何重大差异。

  真相3:灵活性怪圈

  许多NoSQL程序员喜欢吹嘘他们的代码如何简洁,工作机制运行的速度有多快,等等。当任务像NoSQL那样简单时,通常他们的说法是对的,但是当问题复杂之后,情况就改变了。

  我们应该考虑到JOIN的挑战。一旦NoSQL程序员开始在他们自己的逻辑中加入自己的JOIN命令,他们就会开始尝试更为有效地做这项工作。 SQL数据库开发者花了数十年的时间开发巧妙的引擎,以便让JOIN命令尽可能地高效化。一个SQL数据库开发者告诉我,他正在尝试让自己的代码与硬盘转速同步。这样一来,他就能够仅在磁头处于正确位置时请求数据。这看起来有些极端,但是SQL数据库开发者为此已经努力了十余年的时间。

  毫无疑问,程序员们已经绞尽脑汁组织他们的SQL查询,以利用所有的潜在优势。其中的过程可能很艰辛,但是当程序员找到了解决办法,这些数据库就能够真正焕发出活力。

  真相4:访问模式过多

  在理论上,SQL被认为是一种标准的语言。如果你在一个数据库中使用SQL,你应该能够在另外一个兼容版本中执行相同的查询。这一说法可能仅对一些简单的查询有效,但是每个DBA都清楚,他们需要花上数年时间才能掌握不同版本数据库的SQL的特点。关键词被重新定义,在一个版本中正常运行的查询,在另一个版本中可能就无法正常运行。

  NoSQL更为神秘莫测,它们就如同通天塔一样。从一开始,NoSQL开发者就在竭尽全力地想要设计出最佳语言,但是他们的设想有着很大的差别。起初实验效果还是不错的,但是当你尝试在工具间切换时情况就变了。CouchDB查询被表述为用于映射与约简的JavaScript功能。 Cassandra早期版本使用了一个原始而低级的API(应用编程接口),即Thrift。新版本推出了CQL,一种与SQL类似的查询语言,它必须要被服务器所解析和理解。每一个的设计原理都不尽相同。

  真相5:纲要灵活性存在问题

  NoSQL的一个重要理念是不需要纲要。换句话说,程序员不需要提前决定表单中的每一个行需要使用哪个列。一个条目可能有20个相关的字符串,另一个可能有12个整数类型,另一个可能完全是空白。程序员能够在他们需要存储时随时做出决定。他们不需要获得DBA的许可,他们也不需要填写所有的文档,以增加一个新的列。

  这些自由听起来非常具有诱惑力,并且能够加快开发速度。但是对于需要三个开发团队的数据库来说,这真的是一个好主意吗?对于可能持续六个月以上时间的数据库来说,它们是否可行?

  换句话说,开发者可能希望利用这些自由将老的Pair(对)加入到数据库中。但是,在四名开发者已经选择了他们自己的键后,你希望成为了第五名开发者吗?我们可以想象一下“birthday”(生日)的多种表达方式。在添加用户生日进入条目中时,每名开发者都会选择他们自己的表示方式。一个开发团队几乎可能会想到所有的表示形式,例如“bday”、“b-day”和“birthday”。NoSQL架构并不支持限制这一问题,因为这意味着要重新设计纲要。它们不希望对个性化的开发者加以限制。

  真相6:没有附加功能

  你不希望把所有的数据存储在所有的行中。你希望得到单选索引的总数。SQL用户能够通过SUM操作执行一个查询,然后向你反馈一个数字。 NoSQL用户则将所有的数据反馈至他们那里,然后自己进行添加。添加并不是问题,因为在任何机器上增加数字都需要花上相同的时间。但是数据反馈却非常慢。反馈所有数据所需要的带宽也非常的昂贵。

  NoSQL数据库中几乎没有附加功能。除了存储和检索数据外,如果你想做任何事情,你可能需要自己动手。在许多案例中,通过完整的数据复制,你可以在不同的机器上做这些事情。真正的问题是,它对在保留有数据的机器上进行计算有帮助,因为可以省去数据反馈的时间,但是对于你来说却是非常的困难。

  MongoDB提供的映射与约简查询架构可以让你通过任意的JavaScript架构来简化数据。在拥有数据的机器间分发计算方面,Hadoop是一个强大的机制。它是一个快速演进的架构,可以为创建复杂的分析快速提供改良的工具。这听起来非常酷,但是Hadoop技术本身却非常新。尽管Hadoop与NoSQL之间的差别正在消失,但是在技术上,Hadoop是一个与NoSQL完全不同的东西。

  真相7:工具太少

  你能够在服务器上部署NoSQL并运行它们。当然,你也能够编写你自己自定义代码以读写数据。但是如果你希望做更多的事,那它们会怎么样呢?如果你想购买一个报告套件,一个绘图套件或是下载一些用于创建图表的开源工具,它们又会怎么样呢?

  很不幸,大多数工具都是针对SQL数据库编写的。如果你想生成报告,创建图表,或是利用NoSQL堆栈中的数据做一些事情,你需要重新进行编写。目前已经有了用于处理来自甲骨文数据库、微软SQL Server、MySQL和Postgres等SQL数据库中数据的标准工具。你的数据是NoSQL类型的吗?目前工具制造商们正在努力解决这些问题。

  目前有20多个不同的NoSQL选择,这些选择都拥有自己的理念和处理数据的方式。对于工具制造商而言,他们难以支持SQL的特点和不一致性。然而与之相比,为NoSQL解决方案制造相关工具则更为困难。

  当然,这一问题会慢慢消灭。开发者们已经意识到了NoSQL的优势,他们将修改自己的工具,以适合这些新的系统,不过这要花上些时间。或许他们会针对MongoDB开发出一些工具,但是这对于使用Cassandra的用户而言没有丝毫的帮助。在这种情况下,标准就显得尤为重要,但是在这一方面,NoSQL并不擅长。

    本文来源:IT专家网

 

    相关文章推荐:第三方调查报告:近半数人认可Hadoop和NoSQL技术

分享到:
阅读:1276次
推荐阅读:

版权所有 © 2011-2016 南京云创大数据科技股份有限公司(股票代码:835305), 保留一切权利。(苏ICP备11060547号-1)  
云创大数据-领先的云存储、大数据、云计算产品供应商