关系型数据库只是各种数据存储方式中的一种。根据实际情况不同，键 / 值存储方式可能是更合适的选择。如果数据主要通过一个主键进行访问，那么键 / 值存储方式可能比关系型数据库更适合此类场景。那么，什么是键 / 值存储？听上去和传统的散列非常接近——实际上，这本就是相同的东西。
键 / 值存储方式相比成熟而复杂的 RDBMS 要简单得多，这也是该方面出现大量实现并相互竞争的原因。这里我们体验了 Tokyo Cabient，以及一个不同键 / 值存储方式的统一接口：Moneta。
Tokyo Cabinet 是一个 C 语言编写的类库，实现了一个非常高效，并节省空间的键 / 值存储：
数据存储在一个简单的文件中，每条记录为一个键 / 值对。每个键和值是一系列字节，长度可变，它们都支持两种形式：二进制数据和字符串。这里没有数据表或数据类型等概念。记录通过散列表或定长的数组进行组织。
除了对Ruby 的支持之外，也有面向Perl，Java 和Lua 的API。
Tokyo Tyrant 还提供了用于并行和远程连接的服务器，使 Tokyo Cabinet 能够跨多台机器使用。您可以从 Ilya Grigorik 的介绍文章中了解到 Tokyo Cabinet 的更多示例和信息。
假设您已经决定要采用键 / 值存储方式，但是还没有确定要使用哪种具体实现，则不妨尝试一下Moneta 。它和Rack 之于Web 服务器的作用类似，“希望能够为各种键/ 值存储方式提供统一的接口”。如 Yehuda Katz 所述，“那些希望利用键 / 值存储优势的类库（例如 Rails 和 Merb 的缓存支持）可以在后端使用 Moneta”。
Moneta 创造性地支持文件、memcache、内存、文件系统中的 xattrs、DataMapper，以及之前提过的 Tokyo Cabinet（通过 rufus-tokyo 进行支持，这是个“基于 ruby-ffi 的 Tokyo Cabient 和 Tokyo Tyrant 接口”）等多种存储方式。
您可以从 Yehuda 的 blog 中得到有关Moneta 的更多信息，或访问其 github repository 。
查看英文原文： Moneta: An Interface to Key-Value Stores like Tokyo Cabinet, Memcache
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论