巨大的阵列答案

【问题标题】：Gigantic arrays巨大的阵列
【发布时间】：2011-05-01 10:24:59
【问题描述】：

我打算将巨大的数组存储到序列化文件中并从中读取，以便在其中显示数据。这个想法是拥有一个简单的、面向文档的文件系统数据库。谁能告诉我这是否是性能问题？它会很慢还是很快？

值得吗，文件系统总是真的更快？

【问题讨论】：

需要更多信息。文件系统并不总是（或大多数情况下）比使用 SQL 或 NoSQL 数据库快。这完全取决于您的用例。所以如果你能弄清楚你的确切使用要求是什么，你就能弄清楚哪个是正确的......
定义“巨大”！成千上万的条目，数万，数百万，更大？多维数组？处理大型数组时，序列化/反序列化很慢，因此能够读取数组的一部分可能会更好。
What are some good, fast persistant storage options for key->value data? 的可能重复项
我更倾向于做一个var_export（加载开销比unserialize少）。
“巨大”对您意味着什么？ 1 MB、1 GB、1 TB？你有多少文件？数千？百万？所有告诉您使用真实数据库或键值存储的人可能都是正确的，但是当您走极端时，细节很重要。

标签： php

【解决方案1】：

相当大，一个包含 +- 5,000 个条目的多维数组。

【讨论】：

【解决方案2】：

我认为您可以在没有很多性能问题的情况下实现这一点，只要您的数组不会永远（取消）序列化并且您能够有效地查找文件。顺便说一句，您打算如何查找要读取的文件？

值得吗，文件系统总是真的更快？

不，这种方法并不总是更快，事实上，使用某种数据库或缓存可能会获得更好的性能。

【讨论】：

【解决方案3】：

使用“合适的”数据库会更好——这就是它们的设计目的。如果您的数据确实是面向文档的格式，请考虑CouchDB。

【讨论】：

【解决方案4】：

它会非常慢。序列化和反序列化总是需要读取和处理整个数组，即使你只需要一小部分。

因此，您最好使用数据库（如 MySQL）。或者，如果您只需要访问键/值，请使用 APC/memcached。

【讨论】：

但这不是文件系统数据库的工作方式……它使用目录和文件来组织数据，而不是数组或其他复杂的数据结构。所以不需要序列化/反序列化（好吧，无论如何都高于你对MySQL / etc的需要）......我并不是说它是正确的实现，但对于某些用例（大量稀疏数据，需要从shell 脚本等）它可能有意义（现在，这些很少而且相差甚远）。但这绝不是“非常慢”...
@ircmaxell：OP 谈到了将大型数组序列化到文件系统。这当然没有意义。他没有提及目录和文件。
哎呀。我一定已经跳过了……否则我仍然认为评论是有效的（除了那一行）。但我同意，没有理由自己将复杂的数据结构存储在序列化文件中，除非你很懒......