sql - 大型文本文件的集中存储

Question

系统应该做什么：存储/管理集中的大型（100 - 400 mb）文本文件

存储内容：文本文件中的行，对于某些文件，行必须是唯一的，有关文件的元数据（文件名、注释、上次更新等）也必须存储在文件中的位置（对于不同的应用程序，同一文件上的位置可能不同）

操作：同时从文件中获取行（100 - 400 行查询），添加行（也是 100 - 400 行），导出不是关键 - 可以安排

那么使用 SQL DBMS 的存储 - 太慢了，我想，也许是 noSQL 解决方案？

Answer 1

NoSQL：Cassandra 是一种选择（我猜您可以逐行或多行存储它），Voldemort 还不错，您甚至可以使用 MongoDB，但不确定它是否符合“大文件”要求。

Answer 2

400 MiB 将完全从每个非荒谬数据库服务器上的缓存中提供。就目前而言，数据库的选择并不重要，任何数据库都可以快速交付（尽管有不同类型的“快速”，这取决于您的需求）。

如果您真的非常渴望原始速度，则可以使用类似redis. 同样，400 MiB 对此毫无挑战。

SQL 可能会稍微慢一些（但不是那么慢），但具有灵活的巨大优势。灵活性、通用性和“内置编程语言”的存在并不是免费的，但它们应该不会产生太糟糕的影响，因为从缓冲区缓存返回数据的任何一种方式都或多或少地以 RAM 的速度工作。

如果您以后需要一个不同的数据库，SQL 将允许您使用一些命令来完成，或者如果您想要其他一些您没有计划的东西，SQL 会做。无法保证使用简单的键值存储来做不同的事情是可行的。

就个人而言，我不会担心这种相当“小”的数据集的性能。真的，每一种数据库都可以很好地发挥作用，不用担心。当您的数据集大小达到几十 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毫秒。这对于建立连接、向服务器发送请求和接收应答要多 3 到 4 个数量级。与此相比，担心查询需要 517 微秒还是 519 微秒似乎很荒谬。如果中间有1-2个路由器，它会变得更加明显。
带宽也是如此。理论上，您可以在 1 Gibit/s 的链路上推动大约 119 MiB/s，假设最大大小的帧并假设没有 ACK 并假设绝对没有其他流量，并且数据包丢失为零。RAM 可以毫无问题地以每秒数十 GiB 的速度提供。