了解KeyValue嵌入式数据存储与文件系统 [英] Understanding KeyValue embedded datastore vs FileSystem

问题描述

关于文件系统的使用，我有一个基本问题我想使用嵌入式的KeyValue存储库，该存储库非常注重写操作.(持续)说我的值是a)10千b)1百万并且读取次数和更新次数相等

I have a basic question with regards to FileSystem usage I want to use a embedded KeyValue store, which is very write oriented. (persistent) Say my value size is a) 10 K b) 1 M and read and updates are equal in number

我不能简单地创建包含该值的文件，并且其中的名称充当键.

Cant I simply create files containing the value and there name acting as keys.

与使用LevelValue或RocksDB的KeyValue存储一样快.

Wont it as fast as using a KeyValue store as LevelDB or RocksDB.

有人可以帮我理解吗?

推荐答案

原则上可以，文件系统可以用作键值存储.仅当您查看各个用例和实现中的限制时，这些差异才会出现.

In principle, yes, a filesystem can be used as a key-value store. The differences only come in when you look at individual use cases and limitations in the implementations.

这里没有过多讨论，有些事情可能会大不相同:

Without going into too much details here, there are some things likely to be very different:

• 文件系统将数据分成固定大小的块.两个文件通常不能占据同一块的一部分.常见的块大小为4-16 KiB；您可以计算出10 KiB示例将导致多少开销.键/值存储往往会考虑较小的数据段.
• 文件系统中的目录索引通常无法按排序顺序有效地遍历文件名/键.您可以有效地查找特定键，但是如果不读取几乎所有目录条目就无法检索范围.一些键/值存储库(包括LevelDB)支持高效的有序迭代.
• 某些键/值存储库(包括LevelDB)是可交易的.这意味着您可以将多个更新捆绑在一起，LevelDB将确保所有这些更新都能通过，或者没有一个通过.这对于防止数据不一致非常重要.文件系统很难实施，尤其是涉及多个文件时.
• 键/值存储区通常尝试使数据在磁盘上保持连续(这样就可以以较少的查找次数来检索数据)，而现代文件系统则故意不跨文件执行此操作.在读取许多记录时，这可能会严重影响性能.不过，这在固态磁盘上不是问题.
• 尽管某些文件系统确实提供了压缩功能，但是它们通常是按文件或按块的.据我所知，LevelDB压缩了整个记录块，有可能产生更好的压缩效果(尽管它们将压缩策略偏向于性能而不是压缩效率).

这篇关于了解KeyValue嵌入式数据存储与文件系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！