大型网站的 XML 与 MySQL

Posted 2023-02-24

【中文标题】大型网站的 XML 与 MySQL

【英文标题】：XML vs MySQL for Large Sites

【发布时间】：2011-04-10 13:45:23

【问题描述】：

对于非常大的网站，例如社交网络（例如 Facebook），您会推荐哪种方法来存储用户帐户？

1) 用户目录中每种功能类型的单个 XML 文件：basicinfo.xml、cmets.xml、photos.xml、...

2) mysql，虽然不知道如何组织这个。也许每个功能的单独表格？例如。用于评论的表格，其中列是 id,from,message,time?

我知道 XML 不是为存储而设计的，php（这是我使用的语言）在使用之前必须读取整个 XML 文件并存储在内存中。

但是，这里是我喜欢 XML 的原因（但我可能错了，如果你不同意，请告诉我）：

1) 如果我有以这种方式组织的用户帐户路径

用户 ID 2342： /users/00/00/00/00/00/00/00/23/42/

我认为通过文件路径查找用户的评论比在大型数据库中查找要快。 此外，如果将每个特征拆分为表格，则每个用户配置文件将多次搜索，以显示 cmets、照片、基本信息等。

2) 我听说 MySQL 在写入时被全局锁定。这是真的？如果是，我宁愿锁定单个文件而不是所有内容。

3) MySQL 是否在集群之间“共享”？我的意思是，如果 1 个磁盘已满，它会在另一个磁盘上“继续”吗？还是我作为程序员必须自己管理它并在另一个磁盘上创建新数据库？ （注意，我使用 Linux） 使用 XML 文件大致相同是可以的，但在磁盘之间拆分更容易，因为结构是按帐户 ID 拆分的，而不是像在数据库中那样按功能拆分。

4) 请注意，我不会将每条评论都存储在 cmets.xml 中。我只是在每个 XML 标记中记下它们的属性，并且消息位于单独的文本文件 commentid.txt 中。一旦每个 XML 不应该太大，内存/时间就不应该有问题。

至于解析整个XML的问题，也许我应该考虑使用XMLReader/Writer而不是SimpleXML/DOM？或者，它会降低性能分配吗？

谢谢！

【问题讨论】：

是否有理由不考虑 CouchDB 等文档数据库？还是现有的 XML 数据库，例如 Sedna？这比专有的 XML 解决方案更有意义。

"我听说..", "我认为..." 您的意见没有根据 - 您需要开始自己找出答案。是的，原始文件访问速度更快——但没有提供用于管理并发的可用机制。关系数据库管理系统是 30 年前几乎消灭了基于分层文件（“导航”）数据库的工具。您是否也在考虑 COBOL 或汇编语言优于 PHP 的优点？

【参考方案1】：

Facebook uses MySQL.

话虽如此。这是长版：

我总是说 XML 是一种数据传输技术，而不是一种数据存储技术，但并不是所有人都同意。 XML 不是为使用关系数据存储而设计的。最初引入 XML 是为了提供一种在系统之间传输数据的标准方式，而无需访问原始系统。

由于您谈论的是大型应用程序，我强烈建议您使用 MySQL（或其他 RDBMS），随着数据集的增长和增长，XML 将越来越慢除非您始终保持新副本在内存中，仅在服务重新启动时读取 XML 文件。

据报道，当您不断地将 XML 发送到数据库中并从数据库中检索 XML 时，使用 XML 数据库在转换成本方面更有效。基本原理是，当 XML 是唯一用于进出数据库的传输语法时，为什么要通过 SQL 抽象层以及所有那些关系表、外键等来压缩所有内容？它基本上从应用程序中取出一个解析层并将其带入数据引擎 - 它可能会比 SQL 替代方案更快、更有效地工作。大概吧。

【讨论】：

我不再相信：cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf [PDF]。

@Daniel，他们将 Casandra 与 MySQL 结合使用：facebook.com/note.php?note_id=24413138919 不管怎样，不使用 XML。

【参考方案2】：

很大程度上取决于您网站的性质。一方面，XML 方法让您可以免费使用诸如“SELECT * FROM $table where $table.id=$id”类型的查询。另一方面...

对于一个非常大的站点，在最坏的情况下，数据文件最终也会变得非常大。如果它是任何类型的社区网站，任何帐户都可能很容易发生这种情况 去任何论坛，在其社区中拥有真实数量的老派成员，你会发现几张海报，上面写着 10K 帖子......这意味着您会希望 SQL 风格的结果集使用内存高效模型实现，而不是速度高效模型。对于最终用户来说，1 秒与 1.1 秒的响应时间并不是什么大问题。但对您而言，1K 的同时请求绝对是 1.5K 或更好。

还有一个方面是，如果您主要读取数据，那么对于大型数据集和基于 DOM 的实现来说，XML 可能有点粗糙。但是如果你写了很多东西，事情就会变得更糟。数据缓存仍然是可能的，但为这些文件事务提供类似 ACID 的保证需要您编写自己的数据库软件。

还有存储要求等，这意味着您可能需要一种分布式方法来存储数据。这类设置在数据库世界中比较容易理解，它们带来了很多有趣的问题（比如如果单个磁盘出现故障，你会怎么做？，你怎么知道在哪个磁盘上找到数据？以及如何实现高效缓存？）这基本上相当于再次从头开始编写自己的小型数据库软件。

因此，对于一个非常大的网站，我认为性能的硬技术要求在内存和一定的可靠性方面成本不会太大，并且不需要同时重新发明 21 个***，这意味着您的方法行不通那好吧。我认为它更适合小型只读网站，您可以在这些网站上进行试验和寻找替代路线，在那里您可以轻松进行更改并将其推广到整个网站。

【参考方案3】：

IME：使用单个 XML 文件进行持久性的内部应用程序无法供单个用户使用...

1) 您的建议是带有管理器应用程序的 XML 文件系统...有 XML 数据库，并且 XML 越来越多地支持在 RDBMS 中存储 XML。您正在考虑重新发明***...

除了将数据存储在 RDBMS 中所产生的规范化之外，这将强制执行 XML 永远不会做的引用完整性......

2) “全局锁定”没有任何上下文范围。写的时候没有数据库我知道全局锁；大多数支持程度的锁定（表/行/等，因供应商而异），以便在定向时保持并发性 - 不是默认情况下。

3) 没有数据库、数据或实际用户——关注集群绝对是过早的优化。

4) 如果系统崩溃而没有将引用完整性写入某种持久性，这种持久性将在应用程序关闭后继续存在，那么数据将毫无用处。