我们必须存储约 300 万种产品的基本信息。目前这些信息是一个 180 mb 的 CSV 文件，每季度更新一次。
每天大约会有 30,000 次查询，但这些查询只是非常简单的键值存储。我们只需要查找产品 ID 并显示其余信息（它们都将在一条记录中）。
这是用于网络的，因此快速的性能至关重要。
即使我们真的不需要关系数据库，我们是否应该使用 MySQL？我们是否应该每季度生成 300 万个静态 html 文件？我们是否应该将每件产品的一行 CSV 存储在 Amazon S3 或 Rackspace Cloud Files 之类的东西上？最好的方法是什么？
答案1
由于 MySQL 受到广泛支持，而且这确实是一件非常简单的事情，所以我建议使用它。除非服务器至少有几 GB 的内存，否则我建议坚持使用 MySQL，而不是使用内存系统。
一旦你开始将数据放入数据库，无论是 MySQL 还是其他数据库，你很可能会发现它会有更多用途。现在你只谈论键值对，但与产品相关的其他数据必须存储在某个地方。如果不在数据库中，我无法想象数据存储会非常高效。
不管你做什么，不要创建这三百万个文件。我们已经看到，由于文件数量太多而引发的问题已经引发了许多问题。
答案2
您可以使用专用的 Key-Value 类型的 NoSQL 数据库优化完成这类任务。看看：
- Redis-- Redis 是一个开源的高级键值存储。它通常被称为数据结构服务器，因为键可以包含字符串、哈希、列表、集合和有序集合。
- 缓存数据库——MemcacheDB 是一个专为持久性设计的分布式键值存储系统。
- 其他（其中一个列表可在此处找到：http://nosql-database.org/）
当然，你可以使用 MySQL 或任何其他关系数据库，但解决方案特别为键值类型的数据而设计的应该更好（否则首先设计它们的意义何在，除了可能事实上它将是一个小得多（就 RAM 和 HDD 而言）的解决方案）。
答案3
现在来谈谈完全不同的事情：
鉴于：
- 180MB/3M 产品 = 平均 62 字节/产品。
- 每天 30,000 次查询 = 每秒 0.34 次查询
- 每季度更新 = 本质上是静态数据
开箱即用的解决方案：
将每个产品转储为 TXT 资源记录并将其存储在 DNS 中，例如：
$origin products.example.com.
product_1_name IN TXT "product 1 description"
product_2_name IN TXT "product 2 description"
...
product_3000000_name IN TXT "product 3000000 description"
好处：
- 极其可靠和值得信赖（您每天都依赖它）
- 几乎可以在任何平台上构建
- 几乎每种语言都以某种形式支持 DNS 查询
- 开源和商业服务器支持不同类型的后端数据库
- 可以轻松复制（只需指定多个名称服务器）
- 处理原子更新，即使在十几台服务器之间进行复制
- 可以进行加密签名以确保数据完整性
- 可以处理更高数量级的每秒查询速率（每秒 10,000 个查询第二可以通过商品硬件轻松处理）
这可能是一个坏主意的原因如下：
- 您需要搜索数据（DNS 纯粹是键/值查找）
- 您需要隐藏数据（DNS没有保密性）
答案4
您可以使用 Berkeley 数据库，它确实可以完成此类工作，即使它自 Perl5 诞生以来就不流行。Berkeley 仅支持键值对，您可以将整个数据库绑定到哈希并以此方式访问它。
书架上有许多较旧的 Perl 参考资料，其中详细介绍了如何使用 Berkeley，或者尝试一下BerkeleyDB CPAN 模块的 Perldoc。我通常避免使用 Berkeley DB（尽管我的雇主有许多古老的代码，其中 Berkeley DB 占据突出地位，而且一些 DB 和你的一样大），因为当你的数据变得更加复杂时，这就不好玩了。