Couchbase作为缓存和缓存失效

Pie*_*sso 5 memcached caching couchbase

我正在考虑使用Couchbase作为缓存层.我知道Couchbase提供的许多优点,比如简单的可扩展性.但更令我感兴趣的是couchbase的丰富文档模型,与memcached的简单键值相比.

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

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

我在Couchbase中的文档模型如下所示:

  • 密钥(应用程序生成的密钥),密钥的格式取决于实体类型
  • 哈希密钥(在所有实体中具有统一的唯一密钥)
  • 实体
  • 依赖关系 - 删除主实体时必须删除的实体的散列键列表

所以我的问题是:

  • 在失效时,我们需要解析依赖关系图(异步).是否可以快速查找大约500k实体的特定密钥?
  • 关于一般想法的任何反馈?

维护实体之间的依赖关系可以非常简单,并且可能不是一个大问题.

皮埃尔

use*_*575 5

我在生产中使用Couchbase 2.2作为持久缓存层并且非常满意(运行大约2M文档).我的应用程序变得非常快(1毫秒).您的想法是有效的,我认为使用Couchbase作为无效的实体存储没有任何问题.它是一种成熟且非常稳定的产品.

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

此外,不确定它是否适用于您的情况,您可以利用Couchbase的能力使文档过期.当您插入键/值(json doc)时,如果您事先知道它,则可以指定TTL(生存时间).这样您就不需要从Couchbase中明确删除实体.

删除操作本身很快(您可以将其作为异步操作运行)并且在Couchbase集群中具有500K文档,它的尺寸非常小.您应该看到不到1毫秒的操作.

但是考虑在一个集群中至少有3个Couchbase节点,这样您就可以在任何给定的时间点关闭一个节点,而不会影响存储在集群中的数据.请参阅调整Couchbase Server 2.0群集的大小

一些额外的资源: