系统应该做什么：存储/管理集中的大型（100 - 400 mb）文本文件
存储什么：来自文本文件的行，对于某些文件行必须是唯一的，关于文件的元数据（文件名，注释，最后更新等）也必须存储在文件中的位置（在同一文件上可能是不同的位置，用于不同的应用）
操作：并发从文件获取行（查询时为100 - 400行），添加行（也是100 - 400行），导出并不重要 - 可以安排
那么使用SQL DBMS的存储 - 太慢了，我想，也许是一个noSQL解决方案？
答案 0 :(得分：0)
NoSQL：Cassandra是一个选项（你可以逐行存储它或者我猜的线组），Voldemort也不错，你甚至可以使用MongoDB但不确定它是否适合“大文件”要求。
答案 1 :(得分：0)
每个非荒谬的数据库服务器上的缓存将完全提供400 MiB。就目前而言，数据库的选择并不重要，任何数据库都能快速交付（尽管存在不同类型的“快速”，这取决于您的需求）。
如果你真的非常渴望原始速度，你可以选择像redis这样的东西。再次，400 MiB对此没有挑战。
SQL可能会稍慢（但不是 ），但具有灵活性的巨大优势。灵活性，通用性以及“内置编程语言”的存在并不是免费的，但它们不应该产生太大的影响，因为从缓冲区缓存中返回数据的方式或多或少都会以RAM的速度运行。 / p>
如果你以后想到你需要一个不同的数据库，SQL会让你用一些命令来做，或者如果你想要一些你没有计划过的东西，SQL就可以做到。无法保证使用简单的键值存储来做一些不同的事情。
就个人而言，我不担心这些相当“小”的数据集的性能。真的，每种DB都能很好地服务，不用担心。当您的数据集大小为几十GB时，再来一次。
如果你100％确定你肯定永远不会需要一个完整的SQL数据库系统提供的额外功能，那么请使用NoSQL来减少几微秒。否则，只要坚持下去就是安全的一面。
修改
详细说来，考虑到现在“一个较低级”的桌面有超过2 GiB（通常相当于4 GiB），而典型的“没什么大不了”的服务器有32 GiB这样的东西。在这种情况下，400 MiB是没有的。服务器上的典型网络上行链路（除非您愿意支付额外费用）为100 mibit / s。
400 MiB文本文件可能有大约一百万行。归结为“典型SQL服务器”的6-7个内存访问，以及2个内存访问加上计算“典型NoSQL服务器”的哈希所需的时间。也就是说，给出或者采取几十个周期，在任何一种情况下都是相同的 - 在相对慢的系统上大约半微米秒。
在第一次执行查询时添加几十微秒，因为如果使用SQL，必须对其进行解析，验证和优化。
如果幸运的话，网络延迟大约是2到3 b 秒。这比建立连接，向服务器发送请求以及接收答案要多3到4个数量级。与此相比，担心查询是否需要517或519微秒似乎是荒谬的。如果中间有1-2个路由器，它就会变得更加明显 带宽也是如此。理论上，您可以在1 Gibit / s链路上推送大约119 MiB / s，假设帧数最大且假设没有ACK，并且假设没有其他流量，并且丢包率为零。 RAM每秒可以提供几十GiB而不会出现问题。