存储一次写入多次读取

Question

我有一百万个数字的列表。每次用户提交输入时，我都需要将输入与列表进行匹配。

因此，列表将具有一次写入多次读取（WORM）特性？

为这些数据实施存储的最佳方法是什么？

我在想几个选择：

1. SQL数据库，但是它适用于WORM（更新：使用VARCHAR字段类型而不是INT）
2. 包含列表的一个文件
3. 像/ 1/2/3/4/5/6/7/8/9/0这样的目录结构（但这个会占用太多空间）
4. 铲斗系统，如/ 12345/67890 /

您怎么看？

更新：该应用程序将是一个Web应用程序。

Answer 1

要回答这个问题，你需要考虑两件事：

您是尝试最小化存储空间，还是尝试最小化处理时间。

将数据存储在内存中将为您提供最快的处理时间，特别是如果您可以以内存空间为代价优化最常见操作（在本例中为查找）的数据结构。对于持久性，您可以将数据存储到平面文件，并在启动期间读取数据。

SQL数据库非常适合存储和读取关系数据。例如，存储名称，地址和订单可以被标准化并有效地存储。是否有一个平面的数字列表有意义存储在关系数据库中？对于每次访问，您将有很多与查找数据相关的开销。构建查询，构建查询计划，执行查询计划等。由于数据是一个平面列表，您将无法创建有效的索引（您的索引基本上是您要存储的值，这意味着您会对每次数据访问进行表扫描。）

使用目录结构可能有效，但随后您的应用程序不再可移植。

如果我正在编写应用程序，我会在启动期间从文件加载数据并将其存储在哈希表（提供常量查找）的内存中，或者编写一个简单的索引文件访问器类来存储数据。搜索优化顺序（最坏情况是平面文件）。

Answer 2

也许您对The Pi Searcher如何做到感兴趣。他们有2亿个数字可以搜索，并发布了关于他们的索引搜索如何工作的描述。

Answer 3

如果你担心速度并且不想关心文件系统存储，那么SQL可能是你最好的选择。您可以优化表索引，但也会为项目添加另一个外部依赖项。

编辑：似乎MySQL有一个ARCHIVE Storage Engine：

  

MySQL支持带有ARCHIVE存储引擎的5.0版以来的动态压缩。 Archive是一次写入，多次读取的存储引擎，专为历史数据而设计。它将数据压缩高达90％。它不支持索引。在版本5.1中，归档引擎可以与分区一起使用。

Answer 4

我会考虑两个选项：

1. 序列化 - 当您的应用程序可以接受查找列表的内存占用时，并且应用程序是持久的（守护程序或服务器应用程序），然后创建它并将其存储为二进制文件，在应用程序启动时读取二进制文件。上行 - 快速查找。缺点 - 内存占用，应用程序初始化时间。
2. SQL存储 - 当查找适合基于索引的查找时，您不希望将整个列表保存在内存中。上行 - 缩短初始化时间，减少内存占用。缺点 - 需要DBMS（额外的应用程序依赖，设计专业知识），速度快，但不如在记忆中保存整个列表快

Answer 5

如果您担心篡改，请购买可写DVD（如果您可以找到仍然带有它们的商店，请购买CD），在其上写下列表，然后将其放入只有DVD的服务器中驱动器（不是DVD刻录机/刻录机）。这样，列表就无法修改。另一种选择是购买一个带有“写保护”开关的USB记忆棒，但它们很难获得，而且安全性不如CD / DVD那么好。

接下来，将每个数字写入该磁盘上的文件，每行一个条目。当您需要匹配数字时，只需打开文件，读取每一行并在找到匹配项时停止。使用当今的计算机速度和RAM数量（以及文件系统缓存），这对于每日一次的访问模式来说应该足够快。

Answer 6

鉴于1M数字对于今天的计算机而言并不是一个庞大的数字，为什么不只是做一些可行的最简单的事情。只需将数字存储在文本文件中，然后在应用程序启动时将它们读入哈希集。在我的计算机上，从文本文件中读取1M个数字需要不到一秒钟，之后我每秒可以进行大约13M的查找。