我的问题是关于系统设计（而不是解决技术障碍），但它仍然非常具体。

我目前有一个应用程序在文本文件中存储大量数据。该应用程序的上下文如下：

• 数据自然地被分成块（这使得文件很方便）
• 解析速度非常快（我记得单线程基准大约为 400M 行/秒 – 行数相当少，但我觉得很难相信任何 DB 可以实现这一点）
• 存储之后，后续处理也很简单：各块按顺序处理，或彼此独立处理。数据永远不会被修改。

因此使用文件的优点是：

• 不依赖服务器软件和客户端库
• 使用命令行工具轻松存档、检查、恢复、修复、处理
• 数据写入很简单（不涉及网络或断开的连接、数据库服务器版本、维护停机时间等）
• 一切都比使用数据库更快，而且控制起来也更容易。您无需管理服务器选项、客户端选项、TCP 选项、数据包大小和磁盘性能对性能的影响，只需关心读/写大小和连续磁盘速度。

使用实际数据库的优点似乎不值得权衡：

• 损坏保护：在此应用程序中，我并不真正关心某个文件的一小部分是否损坏；丢失几行没什么大不了的，而且由于文本格式的冗余（使用分隔符和行尾），一行坏文本不会损坏文件的其余部分。至于整个文件损坏（我在其他情况下见过这种情况），我从未见过它们发生在现代服务器文件系统上，而我在相同的文件系统上见过无法恢复的数据库损坏（去想象吧）
• 轻松获取任何数据：这同样不适用于此，因为处理的性质非常流畅，并且自然分成块；不需要缓存或随机访问
• 并发性/可扩展性：由于写入的流式特性，这从未被需要过（所有内容最终都会出现在几个前端服务器上，这些服务器只是将传入的数据排队等待写入）

我是否忽略了使用实际数据库的关键优势？除了 MariaDB（据我所知，它是存储和检索结构化数据最快的系统）之外，还有其他我应该考虑的系统吗？