关系数据库难办十件事.docxVIP

关系数据库难办的十件事nosql关系数据库key-value列式数据库图结构数据库最近一段时间，准备认真关注并学习一下NOSQL，会陆续摘录一些资料到博客中。对于RDBMS来说，在搜索、推荐、高频交易、产品编目、用户/用户组和ACL 、日志分析、媒体库、电子邮件、分类广告和时间排序与预测等方面或多或少存在一定的局限性。1. 搜索即使是最敬业的甲骨文专家也会尽量避免使用Oracle Text组件。尽管甲骨文公司斥资将其纳入自家数据库产品，但其实际表现相当乏善可陈。同时，很多用户还在使用like及or等命令实现复杂的查询工作，由此引发的结果自然是使用者抱怨满载、实际性能羸弱不堪。当然，甲骨文并不是惟一一家在搜索功能方面有所欠缺的厂商。在Hibernate Search、Apache Solr或者Autonomy的帮助下，我们能够获得更好的检索性能表现。别犹豫，让它们成为大家全文本搜索工作中的有力助手吧。2. 推荐产品会追踪使用者的大量日常信息，并尝试推荐用户可能需要的其它产品。大家不妨设想社交网络的运行情况，如果希望某位用户能够购买他（她）的朋友以及朋友的朋友所选购的袜子，这种跨越式关系会让RDBMS非常被动。要实现这一诉求，需要采用自连接表格与多查询层。这很像是Neo4j等图形类数据库中的两行代码。虽然大家可以通过对社交网络架构的预扁平化及数据临时调整达成目标，但这也会令关系数据库失去其实时性。3. 频繁交易大家可能会以为交易系统是RDBMS的长项所在，因为数据多少都会蕴含一些交易属性。频繁交易活动中，低延迟是最关键也最宝贵的因素。没错，如果大家跳出固有思路，也能在RDBMS中获得较低的延迟效果——但还是提醒各位，关系数据库在设计上并不适合这类任务。甲骨文公司试图通过收购TimesTen来解决这一难题，后者一直在努力将内存数据库与RDBMS相结合——然而上车就算加了翅膀也不会变成飞机，我们只能把这看作一定程度上的小小改善。相反，我们倒是发现很多频繁交易操作者自发选择Riak等键-值方案甚至是更为复杂的Gemfire。4. 产品目录手机这东西大家都知道，同一个型号“XYZ”有可能代表着多款机型，而且这些机型在不同的市场中还被赋予了不同的“昵称”。甚至同一款机型也会使用多种差异化组件。要想对这类复杂而模糊的“类”进行扁平化处理简直难于登天，因此在处理此类工作时，以Neo4j为代表的图形类数据库就成了上上之选，甚至像CouchBase 2.0或者MongoDB这样的文件数据库都比关系数据库表现得更好。5. 用户/群组与ACL在某种角度来看，LDAP其实就是最原始的NoSQL数据库。LDAP专门为用户、群组及ACL所设计，能够恰到好处地满足此类需求。遗憾的是，很多人都出于误解而将其作为新技术的衍生品，企业也试图用它来处理某些荒谬甚至可怕的任务。还有不少公司用它建立起一套官僚意味浓厚的管理机制，许多开发人员为了免受影响只能被迫通过篡改数据库表格来维护日常工作流程。这显然有违集中式用户访问控制的初衷。6. 日志分析如果大家还不清楚这方面问题的危害，不妨打开Hadoop或者小型集群服务器版本RHQ/JBossON中的日志分析功能，设定日志级别、让日志捕捉除错误之外的其它信息。执行过程越复杂、我们的工作状态也就越混乱。可以看到，像日志信息这样多少带有些非结构化特性的数据，正是MapReduce公司的Hadoop以及像PIG这样的语言所擅长的领域。然而我们遗憾地看到目前各类主流监控工具仍然在以RDBMS为主要对象——关系数据库根本不需要这么多分析及汇总工作，低延迟才是其最大卖点及首要诉求。7. 媒体资源库虽然保存元数据的效果还算可以（其实Couchbase 2.0或者MongoDB在这方面表现更好），不过RDBMS中的BLOB在经过了多年的演变后仍然很不给力。大家最好为自己的图像及其它二进制文件选择某种类型的分布式存储方案或集群文件系统。尽管表现令人失望，许多CMS引擎仍然会把一切存储任务都推给RDBMS，这也是大家需要注意的一点。8. 电子邮件电子邮件实际是一种具备适度非结构化特性的元数据，而关系数据库并不擅长存储这类资料。电子邮件管理工作涉及到元数据、搜索以及内容，这些东西之间并没有明显的关联代数可供参考，而且与交易扯不上关系。关系数据库本身的文件系统没有问题，只是文件类数据库在处理元数据时表现更出色。9. 分类广告广告是一种规模庞大的信息集合，海量用户查询及发布这类数据，其内容短小却极具吸引力。Craigslist这家知名广告网站使用的正是文件类数据库MongoDB，它擅长搜索、打理元数据、非常适合广告的固有特性，连信息一致性也有足够的保障。面对几乎等于是为广告量身打造的文件类数据库，RDBMS最好的选择就是绕道而行。10. 时间排序/预报