Couchbase作为缓存和缓存失效

Question

我在考虑将Couchbase用作缓存层。我意识到Couchbase提供的许多优点，例如简单的可扩展性。但更让我感兴趣的是couchbase的丰富文档模型，与memcached的简单键值模型相比。

我的RDBMS是SQL Server，我们使用NHibernate。查询和数据库已经非常优化，我认为缓存是进一步扩展的最佳选择。

我的项目是实现一个简单的实体之间的关系模型（比RDBMS中的简单得多）来处理失效。当应用程序使实体失效（从缓存中删除）时，所有依赖实体也可以被删除。定义实体之间依赖关系的逻辑将由专用组件在应用程序级别处理。将有10或12个不同的实体（我不想缓存我的所有应用程序域）。

我的文档模型在Couchbase应该是这样的：

• 键（一个应用程序生成的），键的格式取决于实体类型
• 散列键（有一个统一的唯一密钥翻过所有实体）
• 实体
• 依赖 - 当主实体被删除，必须删除的实体的哈希键列表

所以我的问题是：

• 失效时，我们需要解析依赖关系图（异步）。用大约500k实体查找特定密钥是否快速？
• 关于整体想法的任何反馈？

维护实体之间的依赖关系可能非常简单，并且可能不是什么大问题。

皮埃尔

Answer 1

我使用Couchbase 2.2生产为持久性高速缓存层，并用它真的很开心（运行约2M文档）。我的应用程序变得非常快（1毫秒）。你的想法是有效的，我没有看到使用Couchbase作为实体存储失效的问题。它是一种成熟和非常稳定的产品。

你在你的实体设计中是正确的。你可以有一个主要的json文档，其中包含对其他子文档的引用列表。因此，在删除主文档之前，您将首先删除所有的孩子。

另外，不确定它是否适用于您的情况，您可以利用Couchbase的能力来过期文件。当你插入键/值（json doc）时，如果你知道它的话，你可以指定TTL（生存时间）。这样您就不需要从Couchbase中显式删除实体。

删除操作本身速度很快（您可以将其作为异步操作运行），并且在Couchbase集群中具有500K文档，它非常小。你应该看到1毫秒以下的操作。

但是，考虑在一个群集中至少有3个Couchbase节点，以便您可以在任何给定时间点关闭一个节点，而不会影响存储在群集中的数据。见Sizing a Couchbase Server 2.0 cluster

一些额外的资源：

• 10 things developers should know about Couchbase
• Top 10 things an Ops/Sys admin must know about Couchbase
• App Development with Documents, their Schemas and Relationships
• Couchbase Models

Answer 2

这里是我的想法：

无效时，我们需要解析依赖关系图（异步） 。用大约 500k实体查找特定密钥是否很快？

你在找RDBMS或CB中的密钥吗？如果在CB中，您将需要使用视图/索引;现在，视图是基于磁盘的，但按照排序顺序存储，因此它们不会比SQL索引慢。并行访问将比串行访问更快。它将是您的操作中的慢点，虽然如果你使用CB。

继续这个想法，我已经成功地使用CB来存储和导航其中有500k +节点的分层数据结构。 CB性能良好，但如果需要的话，确实需要几秒钟才能完成整个索引（如果我需要执行批量更新操作，我会这样做）。

关于整体想法的任何反馈？

这个想法是健全的。事实上，当我在Couchbase集群上运行它时，我看到了10倍于分层查询的SQL性能。我还发现，在进行索引查找时，单个couchbase实例的性能优于多个实例 - 我不知道这是为什么（2实例cb索引比我的SQL设置快5倍）。为了进一步加快速度，可以将查询并置到cb索引。