我是一个NoSQLer，一个搞大数据的家伙。这是一个很好的巧合，因为你可能已经听说，数据增长在失控。

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

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

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

　　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为废弃品，当技术更新，并且有公司以它做了一些可怕的荒诞的事情。一些企业也建立这样一个官僚机构，许多开发人员只好欺骗性地创建数据库表。这违背了集中的用户访问控制的目的。 “用户”和“角色”表应该从任何企业环境走开。