共计 2599 个字符，预计需要花费 7 分钟才能阅读完成。
本篇内容介绍了“分布式缓存能不能被用作 NoSQL 数据库”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
分布式缓存能被用作 NoSQL 数据库吗
InfoQ：你能否就分布式缓存解决方案与 NoSQL 数据库做个对比?
Greg Luck：分布式缓存通常会把数据放在内存里，用于降低延时。NoSQL 数据库是没有 R 的 DBMS(即没有关系的数据库管理系统)，一般也缺乏对事务和其他高级特性的支持。对于不支持关系的系统，表关系的关联是 SQL 里最麻烦的部分，这也正是 NoSQL 这个名字的起源。
其中一种 NoSQL 数据库是键值存储。典型的例子包括 Dynamo、Oracle NoSQL Database 和 Redis。缓存也是键值存储，因此说这两者是相关的。很多缓存实现能被配置为可持久化的，之所以很多时候不那么做，是因为缓存是要提升性能而不是做持久化。而 NoSQL 数据库则与此相反，它是用来做持久化的。
持久化缓存也可当作键值 NoSQL 数据库来使用。NoSQL 也提到了 Big Data，通常是指比能放进一个单独的 RDBMS 节点的量要大的数据，一般从几 TB 到几 PB。
分布式缓存通常用于降低事务性数据的延时，这些数据开始时并不大，但慢慢就会往 Big Data 这个方向发展。由于缓存将数据保存在内存里，这提高了存储的成本，而且需要限制数据的大小。如果依赖于堆存储，每个服务器节点可能只有可怜的 2GB。如果依赖于分布式缓存，Ehcache 还提供了堆外存储，每台服务器可以存储几百 GB 数据，可以用作 TB 级别的缓存。
持久化、分布式的缓存可以适用于一些 NoSQL 的场景。NoSQL 数据库也可以应对一些缓存的场景，只是延时稍高而已。
InfoQ：从架构角度来看，分布式缓存和 NoSQL 数据库有什么相似之处吗?
Greg：它们都想提供优于 RDBMS 的 TPS 和可扩展性。为此，它们都在功能上做了简化，抛开了那些麻烦的问题，比如表关联、存储过程和 ACID 事务。
虽然 Java 缓存领域里有 JSR 107，它为 Spring 和 Java EE 程序员提供了一套标准的缓存 API，但是比起标准化接口，它们都更倾向于使用私有接口。
它们都采用对客户端透明的方式对数据进行分区，做向外扩展。非 Java 产品向上扩展做得也很好。拥有 Terracotta BigMemory，我们在 Java 平台上的向上扩展方面也做得很特别。最后，两者都可以部署在常见的硬件和操作系统上，这让它们都能理想地运行于云端。
InfoQ：架构上这两项技术又有何不同呢?
Greg：NoSQL 和 RDBMS 通常使用的是磁盘。磁盘是机械设备，延时很厉害，因为寻道时间是磁头移动到正确的磁道的时间，读写时间依赖于磁盘的 RPM。NoSQL 尝试优化磁盘的使用，例如，仅仅在磁头当前位置追加日志，偶尔才刷新到磁盘上。相反，缓存主要都把数据放内存里。
NoSQL 和 RDBMS 的客户端很薄(想想 Thrift 或 JDBC)，只是在网络中传输数据，而像 Ehcache 这样的缓存使用进程内存储和远程存储，因此常用请求在本地就能被成功处理。在分布式缓存上下文中，每个应用程序服务器的进程内存储中都会缓存热点数据，增加服务器数量并不会增加网络或后端的负载。
RDBMS 专注于成为通用的 SOR(System of Record)。NoSQ 希望成为某类特定数据类型的 SOR，比如键值对、文档、稀疏表 (宽表) 或图。缓存着眼于性能，一般会与 RDBMS 或 NoSQL 数据库结合使用，数据类型就是 SOR。往往缓存中会存储 Web 服务调用的结果，业务对象的计算结果，这个结果可能需要成百 SOR 调用才能得到。
像 Ehcache 这样的缓存部分运行在应用程序的操作系统进程里，部分运行在网络那头自己机器的进程里。但也不是全部分布式缓存都这样：memcache 就是一个例子，所有的数据都跨网络存储。
InfoQ：哪类应用程序最适合这种方式?
Greg：这还得从先前的问题说起，要将分布式缓存用于你现有的应用程序，通常只需要很小的工作量，而 NoSQL 则需要做很多事，还有大的架构变更。
因此适用分布式缓存的第一类应用程序是现有系统，特别是有以下需要的：
由于使用量或负载激增而需要向外扩展
为达到 SLA 而需要有更低的延时
为了将大型机这样的昂贵基础设施的使用减到最低
减少 Web 服务调用而带来的费用
应对极端负载高峰(比如黑色星期五一样的促销)
分布式缓存能被用作 NoSQL 数据库吗
InfoQ：这种方式有什么局限么?
Greg：缓存，置于内存之中，在大小上有制约，它们的技术局限受限于有多少内存给它们使用(下面还会具体展开说明)。
缓存，就算它提供持久化功能，也未必算的上作为 SOR 的上选。缓存故意回避了备份到磁盘和从中还原的复杂功能，尽管也有简单的。RDMBS 在过去 30 年里开发了丰富的备份、还原、迁移、报表和 ETL 特性。而 NoSQL 则介于两者之间。
缓存提供了改变数据与访问数据的编程 API。NoSQL 和 RDBMS 则提供了工具，可以执行脚本化语言(比如 SQL、UnSQL 和 Thrift)。
但关键一点是要记住缓存并不想成为你的 SOR。它能轻松地与你的 RDBMS 和睦相处，为此它并不需要 RDBMS 所有用的复杂功能。
InfoQ：以后分布式缓存解决方案、NoSQL 数据库和传统 RDBMS 互相协同工作，你有何看法?
Greg：速度大幅快于 RDBMS，依赖于部署拓扑的 NoSQL，还有数据访问模式，分布式缓存可以位于这三者之间的任意位置。那些需要更低延时的人可以将缓存作为 NoSQL 的一个补充，就像现在对待 RDBMS 那样。
稍有不同的是，在你想将 RDBMS 扩展到多个节点时，经常会难于扩展，或者影响编程契约，或者受制于 CAP 做出权衡; 而使用 NoSQL，就算只使用一个节点，你也可以简单地将其视为多节点安装。如果是向上扩展就没有这些问题。在 RDBMS 中，添加缓存是为了避免向外扩展会遇到的麻烦。通常缓存能解决系统的容量问题，你不用费太多力气。因此当需要向外扩展时，加入缓存吧。
对于 NoSQL 而言，内建了向外扩展的能力，在需要低延时的时候使用缓存吧。
“分布式缓存能不能被用作 NoSQL 数据库”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注丸趣 TV 网站，丸趣 TV 小编将为大家输出更多高质量的实用文章！
