对于非常大的网站，例如社交网络（比如Facebook），您会推荐哪种方法用于存储用户帐户？
1）用户目录中每种功能类型的单个XML文件： basicinfo.xml，comments.xml，photos.xml，...
2）MySQL，虽然不知道如何组织这个。每个功能可能分开的表格？例如。注释表，其中列是 id，from，message，time ？
我知道XML不是为存储而设计的，PHP（这是我使用的语言）必须读取整个XML文件并在使用之前存储在内存中。
但是，这就是我更喜欢XML的原因（但我可能错了，如果你不同意，请告诉我）：
1）如果我以这种方式组织了用户帐户的路径
用户ID 2342：
/用户/ 00/00/00/00/00/00/00/23/42 /
我认为通过文件路径查找用户的评论比在大型数据库中查找更快 此外，如果每个功能都分成表格，每个用户配置文件将不止一次，以显示评论，照片，基本信息等。
2）我听说MySQL在写上时被全局锁定。这是真的？如果是的话，我宁愿锁定一个文件而不是一切。
3）MySQL是否在群集之间“共享”？我的意思是，如果1个磁盘已满，它会在另一个磁盘上“继续”吗？或者，作为程序员，我是否必须自己管理并在另一个磁盘上创建新数据库？ （注意，我使用Linux）
可以通过使用XML文件大致相同，但在磁盘之间拆分更容易，因为结构按帐户ID分割，而不是像在数据库中那样按功能分割。
4）请注意，我不会将每条评论存储在 comments.xml 上。我只是在每个XML标记中记下它们的属性，并且消息在分隔的文本文件 commentid.txt 中。一旦每个XML不应该太大，就不应该有内存/时间问题。
至于解析整个XML的问题，也许我应该考虑使用XMLReader / Writer而不是SimpleXML / DOM？或者，它会降低性能吗？
谢谢！
答案 0 :(得分：8)
话虽如此。这是长版：
我总是说XML是一种数据传输技术，而不是数据存储技术，但不是每个人都同意。 XML不是设计用于关系数据存储区。首先引入XML是为了提供一种从系统到系统传输数据的标准方法，无需访问原始系统。
由于您正在讨论大型应用程序，我强烈建议您使用MySQL（或其他RDBMS），随着数据集的增长和增长，XML将越来越慢，越来越慢除非您始终保留新的副本在内存中，只在服务重启时读取XML文件。
据报道，当您经常将XML发送到数据库并从数据库中检索XML时，使用XML数据库在转换成本方面更有效。理由是，当XML是用于进出数据库的唯一传输语法时，为什么要通过一层SQL抽象和所有那些关系表，外键等来挤压所有内容？它基本上从应用程序中取出一个解析层并将其带入数据引擎 - 它可能比SQL替代方案更快，更有效地工作。可能。
答案 1 :(得分：5)
在很大程度上取决于您网站的性质。一方面，XML方法为您提供了诸如“SELECT * FROM $ table where $ table.id = $ id”类型查询之类的内容的免费传递。另一方面......
对于一个非常大的网站，在最坏的情况下，数据文件也会变得非常大。如果它是任何类型的社区网站，这可能很容易发生任何帐户去任何论坛与社区中真正数量的守卫成员，你会发现几个海报说有10K帖...这意味着您希望使用内存高效模型而不是速度效率模型实现SQL样式结果集。对于最终用户来说，1s对1.1s的响应时间并不是那么多;但对你而言，1K的同步请求肯定是1.5K或更好。
然后有一个方面，如果你主要是阅读数据，那么对于大型数据集和基于DOM的实现而言，XML可能会很好。但如果你写的很多，情况会变得更糟。缓存数据仍然是可能的，但是对这些文件事务提供类似ACID的保证要求您几乎编写自己的数据库软件。
然后存在存储要求等，这意味着您可能需要一种分布式方法来存储数据。这些设置在数据库世界中相对比较容易理解，并且它们会给表带来很多有趣的问题（比如如果单个磁盘出现故障你会怎么做？）你怎么知道在什么磁盘上找到数据以及如何实现高效的缓存？）本质上相当于从头开始编写自己的迷你数据库软件。
因此，对于一个非常大的网站，我认为性能的硬技术要求在内存和一定可靠性方面没有太大的成本，并且不需要同时重新发明21个轮子意味着你的方法不起作用那很好。我认为它更适合于那些您可以负担得起并尝试替代路线的小型只读网站，您可以轻松地进行更改并在整个网站上进行更改。
答案 2 :(得分：3)
IME：使用单个XML文件进行持久化的内部应用程序无法由单个用户使用......
1）你的建议是带有管理器应用程序的XML文件系统......有XML数据库和XML，越来越多的人支持在RDBMS中存储XML。你正在重新发明轮子......
除了将数据存储在RDBMS中之外的规范化，这将强制执行XML永远不会做的引用完整性......
2）“全局锁定”没有任何上下文范围。编写时没有数据库我知道全局锁;大多数支持锁定程度（表/行/等，因供应商而异），以便在指向时保留并发性 - 不是默认情况下。
3）没有数据库，数据或实际用户 - 关注群集肯定是过早的优化。
4）如果系统崩溃而没有将参照完整性写入某种持久性，这种持久性将在应用程序关闭后继续存在，那么数据将毫无用处。