一般情况下，使用可以快速查询的存储方式。如果你的集合很大，你可能需要一些基于 Lucene 的东西，比如 ElasticSearch。如果您是 SQL 专家并且您最喜欢的数据库支持它，那么全文索引可能会起到作用。对于像 5000 个文档这样的小文件，即使是 Linux 的 LocateDb+grep 或 OSX 的聚光灯也足够了。

重要的一点是能够快速验证有关数据内容的假设 - 有多少文档包含 X 和 Y，是否有任何文档包含 W 但不包含 V，等等。

这将在整个集合级别以及分析您的主题集群时都很有用。最后，一些 GNU 工具或 SQL 掌握也可以帮助您更有效地分析您的文档集（n-gram 计数/排名、搭配、索引等）

编辑：这意味着，由于上述原因并考虑到您的集合大小，好的旧纯文本（在文件系统或数据库中）可能比任何“花哨”格式更有效。

假设一个论坛帖子平均有 2000 个字符，或多或少相当于一页文本，如果文本是 ASCII，则所需的总内存为 10MB。即使文本是用亚洲语言编码的 Unicode，也需要 40MB。

这对于现代计算机来说太少了，所以一个简单的文本格式是最好的，因为它可以以最快的方式解析，并一次加载到 RAM 中。

假设您打算使用 Python 库来分析数据，因为您正在使用 Scrapy 来收集数据。

如果这是真的，那么存储考虑的一个因素就是与其他 Python 库的兼容性。当然，纯文本与任何东西都兼容。但是，例如 Pandas 有许多 IO 工具，可以简化从某些格式读取的过程。如果您打算scikit-learn用于建模，那么 Pandas 仍然可以为您读取数据，如果您随后将其从 DataFrame 转换为 Numpy 数组作为中间步骤。

这些工具允许您阅读 CSV 和 JSON，还可以阅读 HDF5 ......特别是，我会提请您注意对 msgpack 的实验性支持，这似乎是JSON 的二进制版本。二进制在这里意味着存储的文件会更小，因此读写速度更快。一个有点类似的替代方案是BSON，它有一个 Python 实现——不涉及 Pandas 或 Numpy。

仅当您打算为存储的文本提供至少一些格式时，考虑这些格式才有意义，例如将帖子标题与帖子内容分开存储，或将所有帖子按顺序存储在一个线程中，或存储时间戳......如果你根本考虑过 JSON，那么我想这就是您的意图。如果您只想存储纯文本内容，请使用纯文本。

我认为在存储文本数据时必须非常小心。如果它们是用户评论，那么出于安全考虑，最好在存储之前以某种格式对其进行编码。然后可以定义一个 protobuf 对象来解析编码。

根据查询模式和可接受的数据检索延迟，应确定 DB。只是一个建议，如果想法是在一段时间内为每个用户存储评论，请考虑 HBase 或 Cassandra。它们针对时间范围查询进行了优化。

推荐阅读：http: //info.mapr.com/rs/mapr/images/Time_Series_Databases.pdf