实现高性能分布式文件系统/数据库

我需要实现尽可能最快的方式来将密钥/值对存储在Linux上的分布式系统中。数据库记录很小，平均为256字节。我打算使用open（），write（）和read（）系统调用，并直接在文件中的某个偏移量处编写键值对。我可以省略fdatasync（）系统调用，因为我将使用带有电池的SSD磁盘，所以如果发生意外的系统关闭，我不必担心ACID兼容性问题。 Linux已经提供了磁盘缓存实现，所以在已经加载到内存中的扇区上不会发生读/写操作。这（我认为）将是存储数据的最快方式，比任何其他缓存数据库引擎（例如GT.M或Intersystem的Globals）要快得多。如果我有2个数据服务器（1个本地服务器和1个远程服务器），那么这个数据服务器就可以使用NFS来挂载另一个Linux服务器的文件系统，，我会发出2 open（），2 write（）和2 close（）调用。如果远程服务器上的事务失败，我会将其标记为“不同步”，并在远程服务器恢复时再次复制正确的文件。实现高性能分布式文件系统/数据库

您如何看待这种方法？它会很快吗？我可以在UDP上使用NFS，这样我就可以避免TCP Stack的开销。

优势列表到目前为止是这样的：

Linux磁盘高速缓存中重用
的几行代码
高性能

我会用C语言来编写此要找到在文件中的记录我将保留一个指向物理位置的指针。

来源

2012-01-10 Nulik

等等，你为什么需要写这个？这是为了一个班级什么的？ – chrisaycock 2012-01-10 17:59:01

不，它适用于Web应用程序 – Nulik 2012-01-10 18:03:00

您是否考虑将GDBM用作基本库？ – 2012-01-10 20:33:30

您可能会看到一个真正的分布式文件系统，而不是使用NFS，正如您所指出的那样，它仍然提供单点故障和不复制。

最初由CMU开发的Andrew File System（AFS）可能是您的解决方案。这是一个商业产品，但你可能会检查出在Linux（和其他系统）上工作的OpenAFS。

虽然警告：AFS有学习曲线。

来源

2012-01-10 17:59:25

想到一些建议。

是否需要为每个事务打开（）/ write（）/ close（）？ open（）的系统调用开销尤其可能不是微不足道的
您可以使用mmap（）而不是显式write（）s吗？
如果您为每个事务执行2个write（）调用（1个本地，1个NFS），那么看起来像任何类型的网络问题（延迟，丢弃的数据包等）都有可能使您的应用程序如果您正在等待NFS write（）调用成功，那么会发出尖锐的停顿。如果你不在等待，例如通过从一个单独的线程执行NFS写入，你的复杂性将迅速增长（我不认为“几行代码”将保持真实。）

一般情况下，我建议你真正证明自己，可用的工具不要选择重新发明这个特定的车轮前，满足您的性能需求。

来源

2012-01-10 18:12:26

谢谢！是的，我可能省略open（）close（）并且只发出write（）read（），但我不确定你用mmap（）替换write（）的含义，你能解释一下吗？ – Nulik 2012-01-10 18:25:13

我同意，在这里需要一点复杂性来暂停远程服务器，然后再重新同步它。 – Nulik 2012-01-10 18:26:30

好吧，我了解了mmap，但我想我必须使用write（）/ read（），因为它需要内存，而且我的应用程序中将使用2MB页面，而不是标准4K。 – Nulik 2012-01-10 18:52:20

实现高性能分布式文件系统/数据库

回答

相关问题