[摘录] 关系数据库难办的十件事

最近一段时间，准备认真关注并学习一下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. 时间排序/预报
这一点在本文的十大排行中最具普遍性，但其具体表现形式却多种多样，从商品到数据分析再到太阳黑子预测都包含在内。关系数据库在时间排序问题方面的表现一直饱受争议。当然，现在情况已经大大改善；而且经过过去十几年的努力，RDBMS在与时间有关的处理效率及功能方面已经摆脱了严重缺陷的尴尬境地、取得了令人瞩目的进步。然而如果大家把时间类任务作为主要处理对象，那么像Cassandra这样能够与MapReduce列簇产品家族良好对接的方案无疑更为理想。Datastax公司已经明显指出，其Cassandra发行版将支持时间排序数据；其它一些供应商也纷纷在产品中推出类似功能。

对于NOSQL来说，目前其产品主要有四大类：
1.key-value存储
Examples：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB
典型应用场景：内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等等
数据模型：Key 指向 Value 的键值对，通常用hash table来实现
强项：查找速度快
弱项：数据无结构化，通常只被当作字符串或者二进制数据

2.列式数据库
Examples：Cassandra, HBase, Riak
典型应用场景：分布式的文件系统
数据模型：以列簇式存储，将同一列数据存在一起
强项：查找速度快，可扩展性强，更容易进行分布式扩展
弱项：功能相对局限

3.文档型数据库
Examples：CouchDB, MongoDb
典型应用场景：Web应用（与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容）
数据模型：Key-Value对应的键值对，Value为结构化数据
强项：数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义表结构
弱项：查询性能不高，而且缺乏统一的查询语法

4.图结构数据库
Examples：Neo4J, InfoGrid, Infinite Graph
典型应用场景：社交网络，推荐系统等。专注于构建关系图谱
数据模型：图结构
强项：利用图结构相关算法。比如最短路径寻址，N度关系查找等
弱项：很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案。