关系数据库和十样事物不能混为一谈

  次阅读 作者:智能小宝 来源:互联网 2016-01-28 13:18 我要评论(0)

关系数据库管理系统仍然稳居业界主导之地位。然而即使大家是彻头彻尾的甲骨文粉儿、为老式RAC中的PL/SQL架构所深深吸引,也请稳下心神、保持冷静。时代不同了,如今我们需要在着手执行任务之前认真考量,而绝不能仅凭个人好恶来选择解决方案。本文列出了十件事,是大家在使用关系数据库的时候一定要避免的。

我是位NoSQL用户,同时在大数据方面也广有涉猎。这种技能组合相当应景,正如大家所看到,如今数据库技术人员讨论最多的可能就是“数据增长失控”这个话题。

正所谓“积习难改”,关系数据库管理系统仍然稳居业界主导之地位。然而即使大家是彻头彻尾的甲骨文粉儿、为老式RAC中的PL/SQL架构所深深吸引,也请稳下心神、保持冷静。时代不同了,如今我们需要在着手执行任务之前认真考量,而绝不能仅凭个人好恶来选择解决方案。

1. 搜索: 即使是最敬业的甲骨文专家也会尽量避免使用OracleText组件。尽管甲骨文公司斥资将其纳入自家数据库产品,但其实际表现相当乏善可陈。相反,我们会看到很多用户还在使用like及or等命令实现复杂的查询工作。由此引发的结果自然是使用者抱怨满载、实际性能羸弱不堪——而且甲骨文公司所设定的数据获取方式本身也令人极为恼火。当然,甲骨文并不是惟一一家在搜索功能方面有所欠缺的厂商。除他们之外,大多数其它RDBMS产品也没能实现真正的搜索扩展。

在Hibernate Search、ApacheSolr或者Autonomy的帮助下,我们能够获得更好的检索性能表现。别犹豫,让它们成为大家全文本搜索工作中的有力助手吧。

2. 推荐:我用过大量ATG及其它商用类产品,这项功能绝对是我见到最令人无法忍受的东西。产品会追踪使用者的大量日常信息,并尝试推荐用户可能需要的其它产品。凡是我工作过的地方,一般都会出于可扩展性方面的考虑而把一切推荐功能第一时间关闭掉。

大家不妨设想社交网络的运行情况。如果我希望某位用户能够购买他(她)的朋友以及朋友的朋友所选购的袜子,这种跨越式关系会让RDBMS非常被动。要实现这一诉求,我们需要采用自连接表格与多查询层。这很像是Neo4j等图形类数据库中的两行代码。虽然大家可以通过对社交网络架构的预扁平化及数据临时调整达成目标,但这也会令关系数据库失去其实时性。

3. 频繁交易:大家可能会以为交易系统是RDBMS的长项所在,因为数据多少都会蕴含一些交易属性,不是吗?错。我甚至怀疑第一个将频繁交易通过NoSQL实现的操作者就是NoSQL开发团队中的一员。频繁交易活动中,低延迟是最关键也最宝贵的因素。没错,如果大家跳出固有思路,也能在RDBMS中获得较低的延迟效果——但我还是提醒各位,关系数据库在设计上并不适合这类任务。

甲骨文公司试图通过收购TimesTen来解决这一难题,后者一直在努力将内存数据库与RDBMS相结合——然而上车就算加了翅膀也不会变成飞机,我们只能把这看作一定程度上的小小改善。相反,我们倒是发现很多频繁交易操作者自发选择Riak等键-值方案甚至是更为复杂的Gemfire。

4. 产品目录:这一条看上去似乎平淡无奇,但我曾在之前的文章中谈到,我个人工作中最可怕的SQL查询噩梦之一正是产品数据映射工作。当时我正为一家移动电话制造商工作。手机这东西大家都知道,同一个型号“XYZ”有可能代表着多款机型,而且这些机型在不同的市场中还被赋予了不同的“昵称”。甚至同一款机型也会使用多种差异化组件。要想对这类复杂而模糊的“类”进行扁平化处理简直难于登天,因此在处理此类工作时,以Neo4j为代表的图形类数据库就成了上上之眩

后来我供职于一家化工企业时也遇到过类似的问题。当时我们选择的字符映射方案非常愚蠢、极耗人力。而在把产品信息转移到图形类数据库中后,映射工作就变得简单易行了。甚至像CouchBase2.0或者MongoDB这样的文件数据库都比关系数据库表现得更好。

5. 用户/群组与ACL:在某种角度来看,LDAP其实就是最原始的NoSQL数据库。LDAP专门为用户、群组及ACL所设计,能够恰到好处地满足此类需求。遗憾的是,很多人都出于误解而将其作为新技术的衍生品,企业也试图用它来处理某些荒谬甚至可怕的任务。还有不少公司用它建立起一套官僚意味浓厚的管理机制,许多开发人员为了免受影响只能被迫通过篡改数据库表格来维护日常工作流程。这显然有违集中式用户访问控制的初衷。我认为,“用户”与“角色”等表格在任何企业环境下都毫无必要,应当早日摒弃。

6. 日志分析:如果大家还不清楚这方面问题的危害,不妨打开Hadoop或者小型集群服务器版本RHQ/JBossON中的日志分析功能,设定日志级别、让日志捕捉除错误之外的其它信息。执行过程越复杂、我们的工作状态也就越混乱。可以看到,像日志信息这样多少带有些非结构化特性的数据,正是MapReduce公司的Hadoop以及像PIG这样的语言所擅长的领域。然而我们遗憾地看到目前各类主流监控工具仍然在以RDBMS为主要对象——关系数据库根本不需要这么多分析及汇总工作,低延迟才是其最大卖点及首要诉求。

7. 媒体资源库: 虽然保存元数据的效果还算可以(其实Couchbase2.0或者MongoDB在这方面表现更好),不过RDBMS中的BLOB在经过了多年的演变后仍然很不给力。大家最好为自己的图像及其它二进制文件选择某种类型的分布式存储方案或集群文件系统。尽管表现令人失望,许多CMS引擎仍然会把一切存储任务都推给RDBMS,这也是大家需要注意的一点。

8.电子邮件:我知道,这一点几乎已经成为共识。在项目完成、着手将电子邮件整理到RDBMS当中时,我发现很多人已经明白:电子邮件实际是一种具备适度非结构化特性的元数据,而关系数据库并不擅长存储这类资料。我们已经尽可能对RDBMS进行了优化,最大程度修整BLOB等相关组件。然而电子邮件管理工作涉及到元数据、搜索以及内容,这些东西之间并没有明显的关联代数可供参考,而且与交易扯不上关系。关系数据库本身的文件系统没有问题,只是文件类数据库在处理元数据时表现更出色。

本站文章信息来源于网络以及网友投稿,本站只负责对文章进行整理、排版、编辑,是出于传递更多信息之目的,并不意味着赞同其观点或证实其内容的真实性。如果您有什么意见或建议,请联系QQ28-1688-302!

人工智能实验室
相关文章相关文章
  • 无人驾驶汽车如何改变城市生活?听听他们怎么说

    无人驾驶汽车如何改变城市生活?听听他们怎么说

  • 未来两年人工智能要怎么走?看这篇就够了

    未来两年人工智能要怎么走?看这篇就够了

  • 英国研发“杀生”机器人 通过生命体获取能量

    英国研发“杀生”机器人 通过生命体获取能量

  • 韩春雨称已能重复实验结果 近期将有消息公布

    韩春雨称已能重复实验结果 近期将有消息公布

网友点评网友点评
阅读推荐阅读推荐

据国外媒体报道,在过去两年内,聊天机器人(chatbot)、人工智能以及机器学习的研发和采用取得了巨大进展。许多初创公司正利用人工智能和...

霍金 视觉中国 图 英国著名物理学家霍金(Stephen Hawking)再次就人工智能(AI)发声,他认为:对于人类来说,强大AI的出现可能是最美妙的...

文|郑娟娟 今年,人工智能(AI) 60岁了。在AI60岁的时候,笔者想要介绍一下AI100,一个刚刚2岁的研究项目,但它的预设寿命是100年,甚至更长...

AlphaGo与李世石的人机大战,为大众迅速普及了人工智能的概念。 但对谷歌而言,除了下围棋,现在的人工智能进展到哪一步了?未来,人工智能...