大型网站的XML与MySQL之比较

Facebook uses MySQL .

话虽如此。下面是长版:

我总是说XML是一种数据传输技术,不是一种数据存储技术,但并不是所有人都同意。XML不是设计用来使用关系数据存储的。XML的引入首先是为了提供一种标准的方式来从一个系统到另一个系统传输数据,而不提供对原始系统的访问。

除非您总是在内存中保留一个新的副本,并且只在服务重新启动时读取XML文件。

很大程度上取决于网站的性质。一方面,XML方法让您可以自由地从$table where传递SELECT*之类的内容$表格id=$id类型查询。另一方面。。。

对于一个非常大的站点,在最坏的情况下,数据文件也会变得非常大。如果这是任何一种社区网站,这可能很容易发生,任何帐户去任何论坛与一个真实的老警卫成员在其社区,你会发现一对夫妇的海报说,10万个职位。。。这意味着您将希望SQL样式的结果集是使用内存高效的模型实现的,而不是使用速度高效的模型。对于最终用户来说,1s和1.1s的响应时间并不是什么大不了的事情;但是对于您来说,1K的同时请求和1.5K或更好的响应时间绝对是大不了的。

还有一个方面,如果您主要是阅读数据,那么对于大型数据集和基于DOM的实现来说,XML可能还不错,尽管有些粗糙。但如果你写得太多,事情会变得更糟。数据缓存仍然是可能的,但要对这些文件事务提供类似ACID的保证,您几乎需要编写自己的数据库软件。

还有存储需求等,这意味着您可能需要一种分布式方法来存储数据。这类设置在数据库世界中是比较容易理解的,它们带来了许多有趣的问题(比如,如果一个磁盘出现故障,您该怎么办?,如何知道在哪个磁盘上查找数据,以及如何实现高效缓存?)这实际上相当于再次从头开始编写自己的迷你数据库软件。

因此,对于一个非常大的网站,我认为严格的性能技术要求在内存和一定的可靠性方面没有太大的成本,而且不需要同时重新发明21个轮子,这意味着你的方法不会工作得那么好。我认为它更适合于小型的只读站点,在这些站点中,您可以负担得起试验和寻找替代路线的费用,在这些站点中,您可以轻松地进行更改并在整个站点上进行部署。

1) 您的建议是,带有管理器应用程序的XML文件系统。。。有XML数据库,而且XML数据库已经越来越支持在RDBMS中存储XML。你想重新发明轮子。。。

2) “全局锁定”没有任何上下文范围。我知道在编写时没有全局锁的数据库;大多数数据库支持锁的程度(表/行/等,不同供应商不同),以便在定向到时保留并发性—而不是默认情况下。

3) 如果没有数据库、数据或实际用户,那么关注集群无疑是过早的优化。

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