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


NoSQLer:关系型数据库永远难办的10件事




发布时间: 2012-11-21 10:37:37  
    我是一个NoSQLer,一个搞大数据的家伙。这是一个很好的巧合,因为你可能已经听说,数据增长在失控。

  旧习难改。关系型数据库管理系统(RDBMS)仍然居于主导地位。但是,即使你是一个Oracle的铁杆爱好者,RAC与PL/SQL的忠实信徒,执行以下任务,使用你心爱的技术之前,需要三思而后行:

  1、搜索:即使是最敬业的Oracle店铺也不倾向于使用Oracle Text的,甲骨文为其数据库收购这个扩展,但似乎并没有非常积极的发展。相反,你会看到很多人使用复杂的查询,沉重得像运营商。这些结果是粗糙的,能力是薄弱的 - 获取这些数据,Oracle的方式需要的过程是艰难的。除了甲骨文,许多其他的RDBMS产品并没有真正的搜索扩展。

  使用像Hibernate Search,Apache Solr,甚至Autonomy。这样做可以有更好的拟合指数的性能,以及全文搜索的能力。

NoSQLer:关系型数据库永远难办的10件事

  2、推荐:这是我曾经使用过的ATG Comerce及其他商业产品最糟糕的一部分。它们捕获大量的用户数据,从它们试图提出建议的用户中。在我曾经的工作,推荐的功能几乎总是关闭的,因为可扩展性的原因。

  考虑到社交网络。如果我想推荐给你袜子,因为你的朋友或朋友的朋友买了袜子,RDBMS变得很糟糕。我们谈论的自连接的表和多层次的查询。这简直是图形数据库像Neo4j的两行代码。围绕RDBMS您可以通过平坦的社交网络和打零工操作的数据来解决,但你将会失去它的实时性。

  3、高频交易(HFT,High-frequency trading):你可能会认为,交易系统会喜欢RDBMS,因为数据至少是部分事务性的,对不对?这是错误的。在某些情况下,高频交易商是采用和创建NoSQL方法中的第一人。在HFT以低时延为王。当然,如果你陷入了严重的泥泞,你可以在你的RDBMS实现低延迟,但它确实没有为HFT而设计。

  甲骨文试图通过收购TimesTen回答这个问题,后者试图将一个内存数据库和一个RDBMS相结合,但如果你为卡车配上一只鹅,你没有可能得到一架飞机。相反,我们看到HFT人群使用key-value存储如Riak,或更复杂的解决方案如GemFire等。

  4、产品编目:这不是你听说过的令人兴奋的东西,SQL查询的最大噩梦之一,是我为映射产品数据而写过的。当时我与一家移动电话制造商合作,这是为呼叫手机(Callphone) - 除了“标准XYZ”可能意味着几个不同的实际电话,其中任意一个在不同的市场有不同的名称。同样的模式可能有完全不同的组件。管理这些“类”的设备没有扁平化得非常好。这种场景下,可以使用一个图形数据库正是非常之需,如Neo4j。

  我曾在一家化工企业遇到一个非常类似的问题。我们做了一些非常愚蠢的字符串映射,这是很费力的。如果我们保持这些产品信息在图形数据库中,那将是非常容易映射的。即使像CouchBase 2.0或MongoDB这样的文档数据库也可以做得更好。

  5、用户/用户组和ACL:在一定程度上,LDAP是NoSQL数据库的前身。 LDAP被设计于用户、组和ACL,它可以像手套一样适合这类问题。可悲的是,很多人都以LDAP为废弃品,当技术更新,并且有公司以它做了一些可怕的荒诞的事情。一些企业也建立这样一个官僚机构,许多开发人员只好欺骗性地创建数据库表。这违背了集中的用户访问控制的目的。 “用户”和“角色”表应该从任何企业环境走开。

    6、日志分析:如果你需要一个很好的示范,为小的服务器集群启用Hadoop或RHQ/JBossON的日志分析功能。设置日志级别和日志采集到ERROR之外的任何其他事情。做更复杂的东西,生活将是很糟糕的。有些非结构化数据的分析,这正是Hadoop MapReduce的拿手好戏。如果主要的监控工具RDBMS特定的,那是非常不幸的 - 它们真的不需要交易,并且低延迟是最重要的。

  7、媒体库:用来存储您的元数据可能很好(虽然文档数据库像Couchbase 2.0或MongoDB可能会更好),但毕竟这些年来在RDBMS中的BLOB是很痛苦的。你最好使用某种类型的分布式存储或集群文件系统,为您的图像 和其他二进制文件。可悲的是,许多CMS引擎仍然把一切都推到一个RDBMS。

NoSQLer:关系型数据库永远难办的10件事

  8、电子邮件:我知道这第一手资料。运行一个试图整合电子邮件和RDBMS的项目之后,我发现很多人已经知道的:电子邮件真的是适度的元数据的非结构化数据,元数据最好是以另一种方式存储。我们尽可能地优化了 RDBMS,为BLOB做疯狂的事情,以及做更多的事情。最终,电子邮件,元数据,搜索和内容,没有的,这使它们的关系代数,你真的不需要在这里交易。文件系统是好的,元数据文件中的数据库会更好。

  9、分类广告:一个高规模,大量进出的用户,大多是简短明确的内容。 Craigslist使用文档数据库MongoDB。有搜索,有元数据,有简短明确的内容。最终一致性不够好。对于这些类型的文件,一个数据库可以做的最好的事情,是走出自己的方式。

  10、时间序列/预测( Time-series/forecasting):这是这10个中最普遍的一个,但它有多种形式,从商品到金融工程师,从太阳黑子到天气。围绕时间的问题在关系数据库中是传说中的东西。当然,这已经完成,并且可以肯定的是,经过多年的黑客攻击,在过去的十年左右,我们有时间领域和功能,是远远不够的,大多数RDBMS实现远不足胜任。这就是说,如果时间是你的主题,那么MapReduce友好的列式存储像Cassandra可能是一个更好的解决方案。 Datastax已专门定制它的Cassandra分布支持时间序列数据。

  你可以使用RDBMS做这些吗?当然 - 我有,人们也继续。然而,它是一个不错的选择吗?不尽然。我预料守旧的人不同意,但传统本身并不是坚持使用旧的做事方式的很好的理由。

    本文来源:IT专家网

 

    相关文章推荐:NoSQL等于没有安全?大数据安全隐患分析

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

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