Couchbase作为缓存和缓存失效

Question

5

我正在考虑使用Couchbase作为缓存层。我知道Couchbase提供的许多优势，比如易于扩展性。但更让我感兴趣的是Couchbase的丰富文档模型，与Memcached的简单键值模型相比。

我的关系型数据库管理系统是SQL Server，我们使用NHibernate。查询和数据库已经相当优化了，我认为缓存是进一步扩展的最佳选择。

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

我的Couchbase文档模型如下：

- 键（应用程序生成的键），键的格式取决于实体类型 - 散列键（为了获得统一的唯一键） - 实体 - 依赖项 - 要在删除主要实体时删除的实体的散列键列表

所以我的问题是：

- 在失效时，我们需要解决依赖关系图（异步）。查找大约500k个实体的特定键是否快速？ - 对于这个想法有什么反馈？

维护实体之间的依赖关系可能会变得非常简单，而且可能并不是一个很大的问题。

Pierre

- Pierre Murasso

你需要执行多少次“失效”操作？你是指总共500K个实体还是每次失效500K个实体？ - theMayer

2个回答

1

以下是我的想法：

在无效化时，我们需要解决依赖关系图（异步）。寻找大约500k个实体的特定键是否快速？

您是在RDBMS还是CB中寻找键？如果在CB中，则需要使用视图/索引；现在，视图是基于磁盘的，但按排序顺序存储，因此它们不比SQL索引慢。并行访问它们比串行访问更快。但是，如果使用CB，这将是操作中的缓慢点。

继续这个想法，我成功地使用CB存储和导航具有500k +节点的分层数据结构。CB表现良好，但如果需要执行大规模更新操作，则需要几秒钟才能输出整个索引。

对于这个想法有任何反馈吗？

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

- theMayer

是的，我将在CB中查找密钥，无论是当我从缓存中检索单个实体时，还是当我查找依赖项时。在第一种情况下，在第二种情况下，它是一个实体列表。 - Pierre Murasso

那么我的建议是创建一个索引，该索引以parentId作为键进行发射; 然后您可以在一个查找中搜索给定父级的所有子级。 - theMayer

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- user1697575 · Accepted Answer

我在生产中使用Couchbase 2.2作为持久化缓存层，非常满意（运行约2M个文档）。我的应用程序变得非常快（1毫秒）。您的想法是正确的，我认为使用Couchbase作为实体存储来进行失效验证没有任何问题。它是一个成熟而且非常稳定的产品。

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

此外，不确定是否适用于您的情况，您可以利用Couchbase过期文档的能力。当您插入键/值（JSON文档）时，如果您事先知道，则可以指定TTL（存活时间）。这样，您就不需要明确地从Couchbase中删除实体。

删除操作本身很快（可以将其作为异步操作运行），并且在Couchbase集群中拥有500K个文档，它的大小确实很小。您应该看到在1毫秒以下的get操作。

但请考虑在一个集群中最少有3个Couchbase节点，这样您就可以在任何给定时间关闭一个节点，而不会影响存储在集群中的数据。请参见Sizing a Couchbase Server 2.0 cluster 一些其他资源：