了解 KeyValue 嵌入式数据存储与文件系统答案

【问题标题】：Understanding KeyValue embedded datastore vs FileSystem了解 KeyValue 嵌入式数据存储与文件系统
【发布时间】：2014-09-07 23:05:38
【问题描述】：

我有一个关于文件系统使用的基本问题我想使用一个非常面向写入的嵌入式 KeyValue 存储。（持久）说我的价值大小是一）10K b) 1 百万并且读取和更新的数量相等

我不能简单地创建包含值和名称作为键的文件。

不希望它像 LevelDB 或 RocksDB 那样使用 KeyValue 存储。

谁能帮我理解一下。

【问题讨论】：

【解决方案1】：

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

这里不赘述，有些事情可能会有很大不同：

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

【讨论】：

这个答案+1。 k/v 数据库存储数据更紧凑，并有一个额外的缓存层。因此，您可以期待更快的性能（以及可能对您的应用程序有用的附加功能）。此外，如果您创建许多文件，某些文件系统也无法很好地扩展。
为了完整起见，在任何健全的操作系统上，文件系统数据也会被缓存。
所以你能建议一下，如果值大小很大（比如 5 MB），并且模式是查看、更新、存储；使用 kv 存储是有意义的。还说创建 500 K 文件会对文件系统产生不良影响
@RajeshGaur 具有这种大小，文件系统和 KV 存储之间可能不会有显着差异。一个包含 500 K 文件的目录在典型的文件系统上可能工作得很好，但是当您实际直接使用文件系统的这些部分时，它可能会变得笨拙。出于这个原因，我个人可能更喜欢 KV 商店。 LevelDB 似乎是为这些数据量而设计的，但如果您要依赖它，在半现实条件下进行一些测试可能是个好主意。 :)