10种不可以使用关系数据库的场景

如何根据业务选择不同的技术架构，这是一个方向战略性问题，我在论支付宝与12306的业务类型可比性是从OO分析方式进行论证，但是更多时候我们很多人基本都是从关系数据库的设计开始项目的第一步，这篇文章：
10件不可以使用关系数据库的场景：10 things never to do with a relational database | Application Development - InfoWorld也许能够对普通人起到方向提醒作用。

大意翻译如下：
1.搜索: 即使Oralce商店自己也不使用Oracle Text, 但是你会看到很多人使用复杂的like之类查询语句，这是非常丑陋的，兼容性相当差，Oracle数据库获得数据的过程是艰难的，除了Oralce以外，其他数据库几乎没有真正的搜索扩展。推荐使用类似Hibernate Search, Apache Solr, or even Autonomy.能有更好地性能。

2. 推荐: 这是很多电子商务产品最丑陋的地方，他们获取关于用户的许多数据，然后试图进行推荐。考虑一个社交网络场景下，如果你的朋友买了袜子，我也推荐袜子给你，这是从RDBMS中获得的数据，我们会使用Join表等SQL语句多层次查询，这在Neo4J之类图库中只需要两行即可。你可以在社交系统中使用关系数据库，但是会失去天然的实时性。


3. 高频交易:我们大多数人都认为交易系统必须RDBMS，因为它能保证事务性，对吗？错了. 高频交易者往往是采用NoSQL的第一批人，对于HFT低延迟为王(低延迟意味快速响应，特别是大访问量情况下快速完成用户交易)，当然，你可以进行高难度篮球投篮，你也能使用关系数据库完成低延迟，但是关系数据库真的不是为这个目标设计的。.

Oracle试图否定上面的结论，他通过购买TimesTen, 试图将基于内存数据库和RDBMS结合, 但是你会捡了芝麻丢了西瓜，我们看到HFT大部分使用key-value存储，泪如Riak，甚至更复杂如Gemfire.

4. 商品分类编目: 使用SQL来映射商品不是一件令人愉快的事情，当我为一家移动电话商家服务，商品是手机，除了标准模型以外还有几种不同性质的手机，在不同市场下都不同的名称，同样的模型可以有完全不同的部件。管理这些扁平化数据很方便的工具我比较喜欢图库类如：Neo4j.

在一个化工企业我还有类似的经验，我们对产品进行了非常吃力愚蠢的字符串映射，但是将产品信息保存在图库中就非常简单方便，即使使用文本数据库如CouchBase 2.0 or MongoDB也还可以。

5. 用户/用户组和权限ACL: 在某个程度上讲， LDAP是最原始的NoSQL数据库，LDAP是为用户权限设计的。可惜当技术发展LDAP成为过去时，开发人员只好使用创建数据表的方式来欺骗蒙混过关。在企业软件中，User表和Role表方式不能再这样走下去了。

6. 日志分析: Hadoop 或是和小型集群的 RHQ/JBossON 是一个好的选择，将除了错误以外日志截获到这两个系统中，做一件很复杂的事情，生活将变得更糟糕(苦逼程序员有时可能是自找的)，非结构化数据正是 MapReduce强项，可以使用PIG之类方便操作，但是主流系统监控工具大部分是基于RDBMS，实际上日志分析真的不需要事务，低延迟才是第一追求。

7. 媒体库: 使用关系数据库存储元数据也许还可以(其实最好还是使用文本数据库Couchbase 2.0 or MongoDB), 但是BLOBs类型数据已经维持痛苦经历很长时间，你最好使用分布式存储或集群式的文件系统来保存图片和其他二进制数据，很不幸，很多CMS内容管理系统工程师还是将它们保存到RDBMS.

8. Email: 电子邮件是带有元数据的现代非结构化数据，我们尽可能优化 RDBMS，使用 BLOBs字段做很疯狂的事情， email是关于元数据 搜索 内容，这其中没有任何关系代数，也不需要事务，文件系统就很好，而元数据可以保存在文本数据库。

9. 分类广告: 一个高伸缩 大批用户展示，短小内容，使用文本数据库MongoDB. 最终一致性足够了。

10. 时间系列time-series 有关预测等(大数据分析): 这是最普遍的10个，但它有多种形式，从商品到金融工程师和太阳黑子的天气。有关时间方面的应用对于关系数据库只是一个传说。如果时间是你主要关心的业务核心，那么使用MapReduce-friendly列族比如Cassandra 也许是一个好的解决方案，Datastax 已经针对Cassandra 发布了其时间系列的数据。