Lib.rs

rust-catalog

一种“文件支持”的映射，它以 O(n) 的时间复杂度将键和值插入到文件中，并使用二分搜索和文件定位在 O(log-n) 时间内获取值。目前，它只支持插入和获取实现 Display 和 FromStr 特性的（即可以转换为字符串并从字符串解析回的）可哈希键和值。

有关更多信息，请参阅模块文档。

用法

请注意，这是一个 实验，因此请自行承担风险使用！

将以下内容添加到您的 Cargo.toml...

catalog = "0.1.2"

有关精确用法，请参阅详细示例。

lib.rs:

标准库中的 HashMap 和 BTreeMap 在插入和获取数据方面提供了非常好的性能，但它们是内存杀手。如果“数据”变得很大——比如说，一兆（10¹²），那么我们将遇到麻烦，因为我们那时将需要几GB的RAM来保存数据。

此外，一旦程序退出，所有“辛苦挣来的”数据都会被释放，我们不得不重新插入它们。 HashFile 解决了这个问题。它使用 BTreeMap 存储键和值。因此，直到达到定义的容量，它提供的性能与 btree-map 相同。然而，一旦（以及每次）达到容量，它就会将数据 刷新 到文件中（必要参数可以在其方法中定义）。

因此，在任何给定时刻，这个玩意儿消耗内存的上限由其 容量 决定。这使我们能够很好地控制空间/时间权衡。但是，刷新将需要 O(2ⁿ) 的时间，这取决于处理器的速度和 I/O 速度，因为它会利用迭代器即时处理。

在完成最后的手动刷新后，文件可以存储、移动，并且由于它使用二分查找，当需要时可以在O(log-n)的时间内获取值（取决于驱动器的搜索速度）。例如，平均搜索时间为约0.3毫秒，包含万亿个值的文件需要大约40次搜索（在最坏情况下），这相当于12毫秒。

这种“搜索和搜索”已经在数据库中被使用了。但是，如果你只是想要一个有数以万计行和仅两列（键和值）的表，那么这个系统就是一个不必要的复杂性。

请查看HashFile类型以获取更多信息。