0

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

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

操作:同时从文件中获取行(100 - 400 行查询),添加行(也是 100 - 400 行),导出不是关键 - 可以安排

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

4

2 回答 2

0

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

于 2012-12-29T13:24:55.440 回答
0

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 的速度提供。

于 2012-12-29T13:31:00.870 回答