我有一个关于FileSystem使用的基本问题我想使用一个嵌入式KeyValue存储，它非常面向写。（persistent）说我的值大小是a） 10 Kb） 1米读取和更新的数量相等
我不能简单地创建包含值和作为键的名称的文件。
就像使用LevelDB或RocksDB这样的KeyValue存储一样快。
有人能帮我理解吗。
原则上，是的，文件系统可以用作键值存储。只有当您查看各个用例和实现中的限制时，差异才会显现出来。
在这里不谈太多细节，有些事情可能会大不相同：
- 文件系统将数据拆分为固定大小的块。两个文件通常不能占用同一块的一部分。常见的块大小为4-16 KiB；你可以计算出你的10 KiB例子会导致多少开销。密钥/值存储往往会考虑较小大小的数据
- 文件系统中的目录索引通常无法按排序顺序有效地迭代文件名/键。您可以有效地查找特定的键，但如果不读取几乎所有的目录条目，就无法检索范围。一些密钥/值存储，包括LevelDB，支持高效的有序迭代
- 包括LevelDB在内的一些键/值存储是事务性的。这意味着你可以将几个更新捆绑在一起，LevelDB将确保所有这些更新都能通过，或者没有一个能通过。这对于防止数据不一致非常重要。文件系统使其更难实现，尤其是当涉及多个文件时
- 键/值存储通常试图在磁盘上保持数据的连续性（因此可以用较少的查找来检索数据），而现代文件系统故意不在文件之间这样做。在读取许多记录时，这可能会严重影响性能。不过，这在固态磁盘上不是问题
- 虽然有些文件系统确实提供了压缩功能，但它们通常是按文件或按块的。据我所见，LevelDB压缩了整个记录块，可能会产生更好的压缩效果（尽管他们的压缩策略偏向于性能而非压缩效率）
让我们在2022年尝试使用Linux和现代文件系统构建Minimal NoSQL DB服务器，只是为了好玩，而不是为了严肃的环境。
不要在生产中尝试------------------------------------------------------------------------------------------
用于读写的POSIX文件Api，
用于本机用户帐户和组权限管理的POSIX ACL。
POSIX文件名作为密钥（（根数据库文件夹）/（表名文件夹）/[分区文件夹]/（64位密钥））。根据数据库和表，我们可以使用POSIX ACL定义读/写权限。（64位密钥）是在计算函数中生成的。
安装BTRFS/OpenZFS/F2fs作为文件系统，以提供压缩（Lz4/zstd）和加密（fscrypt）作为本机支持。F2fs更适合于实现LSM，许多nosqldb在其低级别架构中都使用了LSM。
元数据由文件系统处理，所以不需要实现它
根据在计算函数或数据库过程中编写的业务登录中实现的读写模式，使用Linux和/或文件系统来配置页面、文件或磁盘块缓存。
使用RAID和sshfs进行远程复制，以创建主/从高可用性和/或备份
用于编写逻辑的计算函数或数据库过程可以是NodeJS文件或Go二进制文件或其他任何文件，以及向数据库读取和写入内容的标准http://tcp/ws服务器模块。