技术开发 频道

挑战关系型遇阻:NoSQL扩展的隐性成本

        【IT168 专稿】当今的应用庞大,成千上万的用户上传数据,在短期内数据存储量就会大幅增加。因此对于数据架构师而言,可扩展性成为重点关注的问题也就不足为奇了。

  对于Google和Facebook等全球互联网公司,NoSQL这种高度可扩展的非关系型数据存储的使用偶尔会超过关系型数据库技术。事实上,这些应用已经成为这种新型数据库模式优越性的非常好的广告,也得到了应用程序架构师的广泛关注。

  取代传统PB级规模的关系型数据库是极具诱惑的。只有在性能受到威胁的情况下,人们才会考虑修改PB级数据。但是近年来,关系型数据库技术已经出现了挑战。在权衡NoSQL的结构和可扩展性的优势以及关系型数据库易于管理的优点后,许多公司,特别是一些ISV,仍然把关系型数据库作为他们业务的最好选择。

  非关系的权衡

  IT业在对NoSQL产品产生兴奋的同时,也产生怀疑。评论者指出,采用非关系型数据库可能是不明智的,这依赖于你所需要的应用。并非所有的非关系型数据库都一样,需要做出权衡。

  ·数据完整性-非关系型数据库为了实现高性能,尽管是对大规模的数据,也要对数据的正确性做出让步。传统的数据写入规则是不严谨的,很有可能产生数据丢失或覆盖。因此,非关系型的最好应用是那些对数据完整性要求不高的应用,例如社交媒体的应用。任何要求数据绝对完整的应用则需要关系型数据库,而不是NoSQL。

  ·灵活的索引-关系型数据库有利于用户从各个角度查询数据,联接和索引是关系型数据库的强项。为实现高速和规模,NoSQL技术依赖于数据需要以何种方式进行浏览;替代数据视图是非常困难甚至是不可能实现的。

  ·交互数据更新-许多NoSQL解决方案是为了批量更新和快速读取数据,他们没有对应用所需要的细粒度的更新和快速补救进行优化。

  ·并发保证-当很多人访问数据库的时候,确保何时及何种方式将更新后的数据显示给并发用户是很重要的。NoSQL一般不对更新提供保证。

  ISV的困境

  对于许多公司来说,使用关系型的还是非关系型的决定是相当明显的。不幸的是,对于ISV来说,决定有一点困难。社交媒体适合使用NoSQL,但对于绝大多数ISV来说并不适合。然而,扩展仍是最优先的事情。正如大部分呢ISV的应用程序要出售给整个客户系统的数百个企业和小客户,数据量会变得很大。

  因此,ISV发现自己在其中:即需要数据的完整性和灵活性,还为大规模的扩展寻求简单的解决方案。损失数据完整性的小风险看起来是个很小的代价。但没有选择,“多租户”NoSQL看起来更强大。

  ISV的独特之处在于,他们所建立的最终被成千上万用户使用的应用程序。不像Facebook,Facebook的目的是让任何用户与其他各地用户进行交互,ISV的应用程序在公司内部使用,使得A不再需要从B处读写数据。因此,任何给定对象的应用,其数据的大小将永远不会达到NoSQL所显示出来的优势的级别。

  为什么隔离数据?

  ISV可以避免孤立客户数据扩展的挑战,这远不是唯一的有利于该架构的原因。除了技术问题,还有很多原因表明为什么多用户数据库架构的NoSQL对ISV来说是不可取的。

  ·安全-并不是所有的组织都愿意或能够接受让其数据存储在共享库中。事实上,很多企业找到了规避泄露竞争性数据风险的解决办法,使其成为交易获胜的卖点。

  ·管理-行业规则限制组织对数据存储的选择。许多规则规定了数据存放的物理位置和潜在的安全漏洞的问题。对于被迫遵守这些法律的组织,NoSQL解决方案不足以使其满意。

  ·定制-ISV比任何人都了解:公司将会找到优化软件解决方案的办法,以更好的满足特定的业务或工作流。如果因为您的数据库架构使得解决方案难以灵活定制,就既无法升值,也无法让人安心使用。

  两全其美

  当然,从管理的角度看,每个客户的应用程序捆绑在一个独立的关系数据库中使人望而生畏。管理多个数据库是一项艰巨的任务。ISV不会得益于为客户指派DBA,小客户也没有专门的DBA。

  由于现代关系数据库技术的进步,数据库的管理不会感到痛苦。现在的RDMBS市场提供了自我管理和自我调节功能,可以帮助缓解这些挑战并提供保证,ISV可以为客户提供他们所需要的数据库架构。自我管理和自我调整提供给ISV两全其美的办法:无论是扩展、管理还是数据的可靠性,都采取折中的解决方案。

  对于ISV,数据隔离和数据完整性是主要卖点。选择一家领先的关系型数据库系统弥补ISV应用模型的不足,企业就不会以损失未来收入为代价扩展应用。

1
相关文章