论文部分内容阅读
键值是一种基本的数据保存形式或数据结构，我们所熟知的NoSQL数据库采用的就是这种数据结构。它非常简单，由键和值对组成，键在数据集中具有唯一性。如果曾经关注过基于对象的存储（或文件系统），那么这些操作对你来说应该非常熟悉。实际上，对象存储使用同样的操作，比如亚马逊的S3、OpenStack的Swift、Caringo及其他对象存储。这些文件系统方案存在已有几年，所以它们根本不是全新的。
那么，为何键值存储会是眼下的一个热门话题呢？理由很浅显：它很简单，同时有一些新技术让键值存储更容易，可能更适用于比之前所用的速度更快的存储。
实际上，键值存储不仅能成为基于对象的存储和文件系统的后端部分，还成为许多文件系统的后端部分，包括传统上使用块存储的文件系统。目前，希捷已经研发出了一款基于键值的、使用以太网接口的硬盘驱动器，这也表明键值存储是一个值得关注的发展方向。
支持键值存储的驱动器
希捷Kinetic驱动器（Kinetic Drive）在键值存储方面做出了大胆的探索。在Kinetic驱动器中，希捷去除了传统硬盘驱动器的SAS或SATA接口，换成两个以太网接口和简单的处理器。另外，在电源连接方面也有变化，不过Kinetic驱动器的外观尺寸与普通SAS驱动器一样。
把SAS接口换成以太网接口的好处在于，它摈弃了应用程序与驱动器本身之间的所有中间层。这个中间层涉及所有的POSIX函数调用、文件系统、卷管理器、驱动程序，以及含有RAID控制器、高速缓存和SAS控制器等部件的存储服务器。
就Kinetic驱动器而言，应用程序与开发人员开发的、取代文件系统的类库进行通信，随后类库使用TCP/IP，直接与Kinetic驱动器进行通信。这大大缩短了应用程序和实际存储之间的所有输入输出延迟。
但它只有以太网接口，我们该如何使用Kinetic驱动器？希捷将Kinetic驱动器变成了一种键值对存储设备，用户可以通过几门编程语言，包括Java、C 和Python，访问该接口。这种接口有几个简单的客户端API：Put、Get、Delete，这些函数是不是很熟悉？Kinetic驱动器还有另外几个命令可以帮助开发人员，包括getNext、getPrevious、getMetadata、getKeyrange。这种驱动器还有管理员API，那样就能管理和监控驱动器。
虽然希捷不愿详细讨论该驱动器里面到底有什么玄机，但基本上就是一个简单的键值数据库，可能还有某个简单的操作系统。深入探究的话，发现Kinetic驱动器可以从事空间映射工作，包括需要执行的任何垃圾收集工作。驱动器存储的键范围在1字节到4 KiB之间，存储的值范围则在0字节到1 MiB之间。
开发人员可以通过驱动器的开源编程库编写或改动文件系统，以便将这种驱动器用作存储后端。另外，还可以编写相当简单的输入输出库，那样应用程序就能与驱动器之间直接进行输入输出操作。
目前的Kinetic驱动器有两个千兆以太网接口。希捷提供的性能数字表明，顺序读取和写入速度约为50 MB/s，随机写入速度也约为50 MB/s，不过随机读取速度比传统驱动器慢1.2倍。所以，性能与普通SAS驱动器大致相当。
有一些文件系统支持使用Kinetic驱动器作为后端。比如，Swiftstack就有支持Kinetic的Swift版本。它面向可能用于数据归档的速度较慢、成本较低的存储场景。
键值存储的局限
有了键就很容易查询对应值、删除键值对，或者更换键值对中的值。开发人员可以编写程序检索所请求数据、写入数据，或者擦除数据。但存储数据还需要元数据。有好多方法可以进行元数据操作，包括存储文件到键的映射，作为Kinetic驱动器或可能单独数据库中数据的一部分。开发人员将所有函数和操作编写到输入输出库。
这听起来很容易，但必须重新编写应用程序的输入输出部分，才能使用Kinetic驱动器提供的输入输出库。键值存储其实与POSIX并不兼容，所以这意味着存储接口要么是新的，要么需要编写库层，以便适应POSIX输入输出函数调用。
使用键值存储有难度，一个简单的例子是POSIX输入输出函数让你可以查找到文件中的特定部位（偏移），但没有对应的键值函数让你可以将文件指针移到文件中的指定位置。也就是说，你无法查找到文件中的特定部位，然后执行某种输入输出操作。这是表明使用键值存储方面有问题的一个例子而已。办法是要么针对特定的输入输出库重新编写应用程序，要么编写与POSIX兼容（或足够相近）的库，可以与键值存储进行联系。
另一个办法是编写输入输出库，以便它有一个中间文件系统来执行查找及键值存储无法提供的其他操作。访问、打开或创建文件后，与POSIX兼容的文件系统就执行应用程序所要求的全部操作，该文件系统用作中间文件系统。随后在某个时候，中间文件系统中的数据被“清空”或拷贝到键值存储。确保键值存储中的数据与中间文件系统相一致，就需要一些认真的设计和编码工作。这不是最容易的解决办法，不过为非POSIX输入输出库和与POSIX兼容的库起到了桥梁的作用。
不只是适用于归档存储
键值存储最擅长的领域是归档存储。这类应用程序不可能直接与归档存储进行联系，因而不大需要与POSIX兼容或重新编写应用程序。其本质是只需要将数据“放入”归档，然后需要时从归档“获取”数据的工具。“放入”和“获取”这两种操作非常适合于键值存储。
如前所述，创建使用键值存储的与POSIX兼容的系统并非易事，因为将所有POSIX输入输出函数映射到键值存储的简单函数有难度。然而，这并不意味着不可能。克服这个难题的一个办法就是对现有的面向对象的文件系统进行改动，以适应键值存储。Ceph就是这方面的一个典例。
Ceph可以让存储在客户端面前呈现为面向对象的文件系统、块存储或文件。Ceph里面支持所有这三种存储类型的文件系统基于对象。Ceph v0.80（Firefly）支持键值OSD（对象存储设备）。所以，绝对可以创建不只是归档的存储解决方案，它也不一定只有归档存储的有限性能。其他改动后可使用键值存储的性能良好的文件系统，还有Lustre和GlusterFS。对键值存储来说，性能不是一个限制因素。
键值存储正迅速成为一项流行的存储技术，特别是在大容量、低性能的存储领域受到特别关注。但键值存储并不局限于归档或低性能存储。恰恰相反，它可以用于性能更高的存储，Ceph就是个佐证。
希捷的Kinetic可以使用类似REST的命令（比如get、put和delete）来寻址，这表明你可以用键值存储实现什么、它有多简单。简单的开源库让你随后可以开发输入输出库，那样应用程序就能执行与驱动器之间的输入输出操作。Swift等一些对象存储解决方案早已进行了移植，可以使用Kinetic驱动器。Ceph还演示了可使用Kinetic驱动器的一个版本。Lustre和Gluster等其他基于对象的存储系统在理论上同样可以使用这项技术。
鉴于此，请密切关注键值存储，它可能会出现在你身边的文件系统中。
那么，为何键值存储会是眼下的一个热门话题呢？理由很浅显：它很简单，同时有一些新技术让键值存储更容易，可能更适用于比之前所用的速度更快的存储。
实际上，键值存储不仅能成为基于对象的存储和文件系统的后端部分，还成为许多文件系统的后端部分，包括传统上使用块存储的文件系统。目前，希捷已经研发出了一款基于键值的、使用以太网接口的硬盘驱动器，这也表明键值存储是一个值得关注的发展方向。
支持键值存储的驱动器
希捷Kinetic驱动器（Kinetic Drive）在键值存储方面做出了大胆的探索。在Kinetic驱动器中，希捷去除了传统硬盘驱动器的SAS或SATA接口，换成两个以太网接口和简单的处理器。另外，在电源连接方面也有变化，不过Kinetic驱动器的外观尺寸与普通SAS驱动器一样。
把SAS接口换成以太网接口的好处在于，它摈弃了应用程序与驱动器本身之间的所有中间层。这个中间层涉及所有的POSIX函数调用、文件系统、卷管理器、驱动程序，以及含有RAID控制器、高速缓存和SAS控制器等部件的存储服务器。
就Kinetic驱动器而言，应用程序与开发人员开发的、取代文件系统的类库进行通信，随后类库使用TCP/IP，直接与Kinetic驱动器进行通信。这大大缩短了应用程序和实际存储之间的所有输入输出延迟。
但它只有以太网接口，我们该如何使用Kinetic驱动器？希捷将Kinetic驱动器变成了一种键值对存储设备，用户可以通过几门编程语言，包括Java、C 和Python，访问该接口。这种接口有几个简单的客户端API：Put、Get、Delete，这些函数是不是很熟悉？Kinetic驱动器还有另外几个命令可以帮助开发人员，包括getNext、getPrevious、getMetadata、getKeyrange。这种驱动器还有管理员API，那样就能管理和监控驱动器。
虽然希捷不愿详细讨论该驱动器里面到底有什么玄机，但基本上就是一个简单的键值数据库，可能还有某个简单的操作系统。深入探究的话，发现Kinetic驱动器可以从事空间映射工作，包括需要执行的任何垃圾收集工作。驱动器存储的键范围在1字节到4 KiB之间，存储的值范围则在0字节到1 MiB之间。
开发人员可以通过驱动器的开源编程库编写或改动文件系统，以便将这种驱动器用作存储后端。另外，还可以编写相当简单的输入输出库，那样应用程序就能与驱动器之间直接进行输入输出操作。
目前的Kinetic驱动器有两个千兆以太网接口。希捷提供的性能数字表明，顺序读取和写入速度约为50 MB/s，随机写入速度也约为50 MB/s，不过随机读取速度比传统驱动器慢1.2倍。所以，性能与普通SAS驱动器大致相当。
有一些文件系统支持使用Kinetic驱动器作为后端。比如，Swiftstack就有支持Kinetic的Swift版本。它面向可能用于数据归档的速度较慢、成本较低的存储场景。
键值存储的局限
有了键就很容易查询对应值、删除键值对，或者更换键值对中的值。开发人员可以编写程序检索所请求数据、写入数据，或者擦除数据。但存储数据还需要元数据。有好多方法可以进行元数据操作，包括存储文件到键的映射，作为Kinetic驱动器或可能单独数据库中数据的一部分。开发人员将所有函数和操作编写到输入输出库。
这听起来很容易，但必须重新编写应用程序的输入输出部分，才能使用Kinetic驱动器提供的输入输出库。键值存储其实与POSIX并不兼容，所以这意味着存储接口要么是新的，要么需要编写库层，以便适应POSIX输入输出函数调用。
使用键值存储有难度，一个简单的例子是POSIX输入输出函数让你可以查找到文件中的特定部位（偏移），但没有对应的键值函数让你可以将文件指针移到文件中的指定位置。也就是说，你无法查找到文件中的特定部位，然后执行某种输入输出操作。这是表明使用键值存储方面有问题的一个例子而已。办法是要么针对特定的输入输出库重新编写应用程序，要么编写与POSIX兼容（或足够相近）的库，可以与键值存储进行联系。
另一个办法是编写输入输出库，以便它有一个中间文件系统来执行查找及键值存储无法提供的其他操作。访问、打开或创建文件后，与POSIX兼容的文件系统就执行应用程序所要求的全部操作，该文件系统用作中间文件系统。随后在某个时候，中间文件系统中的数据被“清空”或拷贝到键值存储。确保键值存储中的数据与中间文件系统相一致，就需要一些认真的设计和编码工作。这不是最容易的解决办法，不过为非POSIX输入输出库和与POSIX兼容的库起到了桥梁的作用。
不只是适用于归档存储
键值存储最擅长的领域是归档存储。这类应用程序不可能直接与归档存储进行联系，因而不大需要与POSIX兼容或重新编写应用程序。其本质是只需要将数据“放入”归档，然后需要时从归档“获取”数据的工具。“放入”和“获取”这两种操作非常适合于键值存储。
如前所述，创建使用键值存储的与POSIX兼容的系统并非易事，因为将所有POSIX输入输出函数映射到键值存储的简单函数有难度。然而，这并不意味着不可能。克服这个难题的一个办法就是对现有的面向对象的文件系统进行改动，以适应键值存储。Ceph就是这方面的一个典例。
Ceph可以让存储在客户端面前呈现为面向对象的文件系统、块存储或文件。Ceph里面支持所有这三种存储类型的文件系统基于对象。Ceph v0.80（Firefly）支持键值OSD（对象存储设备）。所以，绝对可以创建不只是归档的存储解决方案，它也不一定只有归档存储的有限性能。其他改动后可使用键值存储的性能良好的文件系统，还有Lustre和GlusterFS。对键值存储来说，性能不是一个限制因素。
键值存储正迅速成为一项流行的存储技术，特别是在大容量、低性能的存储领域受到特别关注。但键值存储并不局限于归档或低性能存储。恰恰相反，它可以用于性能更高的存储，Ceph就是个佐证。
希捷的Kinetic可以使用类似REST的命令（比如get、put和delete）来寻址，这表明你可以用键值存储实现什么、它有多简单。简单的开源库让你随后可以开发输入输出库，那样应用程序就能执行与驱动器之间的输入输出操作。Swift等一些对象存储解决方案早已进行了移植，可以使用Kinetic驱动器。Ceph还演示了可使用Kinetic驱动器的一个版本。Lustre和Gluster等其他基于对象的存储系统在理论上同样可以使用这项技术。
鉴于此，请密切关注键值存储，它可能会出现在你身边的文件系统中。