我正在考虑使用Couchbase作为缓存层。我知道Couchbase提供的许多优点，比如简单的可扩展性。但更令我感兴趣的是couchbase的丰富文档模型，与memcached的简单键值相比。
我的RDBMS是SQL Server，我们使用NHibernate。查询和数据库已经非常优化，我认为缓存是进一步扩展的最佳选择。
我的项目是在实体之间实现一个简单的关系模型（比RDBMS中的简单得多），以处理失效。当应用程序使实体无效（从缓存中删除）时，也可以删除所有依赖实体。定义实体之间的依赖关系的逻辑将由专用组件在应用程序级别处理。将有10或12个不同的实体（我不想缓存我的所有应用程序域）。
我在Couchbase中的文档模型如下所示：
所以我的问题是：
维护实体之间的依赖关系可以非常简单，也可能不是一个大问题。
皮尔
答案 0 :(得分：5)
我在生产中使用Couchbase 2.2作为持久缓存层并且非常满意（运行大约2M文档）。我的应用程序变得非常快（1毫秒）。您的想法是有效的，我认为使用Couchbase作为无效的实体存储没有任何问题。它是一种成熟且非常稳定的产品。
您的实体设计是正确的。您可以拥有一个主json文档，其中包含对其他子文档的引用列表。因此，在删除主文档之前，您将首先删除所有孩子。
另外，不确定它是否适用于您的情况，您可以利用Couchbase的能力使文档过期。当您插入键/值（json doc）时，如果您事先知道它，则可以指定TTL（生存时间）。这样您就不需要从Couchbase中明确删除实体。
删除操作本身很快（您可以将其作为异步操作运行）并且在Couchbase群集中具有500K文档，它的尺寸非常小。你应该看到1毫秒以下的操作。
但考虑在一个群集中至少有3个Couchbase节点，这样您就可以在任何给定的时间点关闭一个节点，而不会影响群集中存储的数据。见Sizing a Couchbase Server 2.0 cluster
一些额外的资源：
答案 1 :(得分：1)
以下是我的想法：
在失效时，我们需要解析依赖关系图 （异步）。是否可以快速查找周围的特定键 500k实体？
您是在寻找RDBMS或CB中的密钥吗？如果在CB中，则需要使用视图/索引;现在，视图是基于磁盘的，但是按排序顺序存储，因此它们不比SQL索引慢。并行访问它们比串行访问更快。如果您使用CB，它将成为您操作的慢点。
继续这个想法，我已成功使用CB来存储和导航其中包含500k +节点的分层数据结构。 CB运行良好，但如果我需要，它会花几秒钟吐出整个索引（如果我需要进行批量更新操作，我会这样做。）
关于一般想法的任何反馈？
这个想法很合理。实际上，当我在Couchbase集群上运行SQL时，我看到SQL的性能是分层查询的10倍。我还发现在执行索引查找时，单个couchbase实例的性能优于多个实例 - 我不知道为什么会这样（2实例cb索引比我的SQL设置快5倍）。为了进一步加快速度，您可以将查询分配到cb索引。