大型网站:XML vs MySQL

7
对于像社交网络(比如Facebook)这样的非常大的网站,您推荐哪种方法来存储用户帐户?
1)每种功能类型的单个XML文件,位于用户目录上: basicinfo.xml,comments.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 /

我认为通过文件路径查找用户的评论比在大型数据库中查找要快。
此外,如果每个功能在表格中拆分,则每个用户配置文件将多次查找以显示评论、照片、基本信息等。
2)我听说MySQL在写入时会全局锁定。这是真的吗?如果是,我宁愿锁定单个文件而不是所有文件。
3)MySQL是否在群集之间“共享”?我的意思是,如果1个磁盘已满,它会在另一个磁盘上“继续”吗?还是我作为程序员必须自己管理并在另一个磁盘上创建新数据库? (请注意,我使用Linux)
使用XML文件大致相同也可以,但是更容易在磁盘之间分割,因为结构按帐户ID而不是按特征拆分。
4)请注意,我不会在comments.xml上存储每个注释。我只在每个XML标记中记录它们的属性,并且消息在单独的文本文件commentid.txt中。由于每个XML都不应太大,因此不应该出现内存/时间问题。
至于解析整个XML的问题,也许我应该考虑使用XMLReader / Writer而不是SimpleXML / DOM?或者,它会大大降低性能?
谢谢!

不考虑像CouchDB这样的文档数据库,或者像Sedna这样的现有XML数据库,是否有理由呢?这比专有的XML解决方案更有意义。 - Elle H
2
"我听说..", "我认为..." 你的观点没有很好的基础 - 你需要开始自己找出答案。是的,原始文件访问速度更快 - 但提供了没有可用机制来管理并发的方式。关系型数据库管理系统是几乎在30年前消灭了分层文件式(“导航”)数据库的工具。你是否也考虑过COBOL或汇编语言相对于PHP的优点? - symcbean
3个回答

10

Facebook使用MySQL

话虽如此,以下是详细版本:

我一直认为XML是数据传输技术,而不是数据存储技术,但并非所有人都同意。XML并没有被设计成使用关系型数据存储。XML最初的目的是提供一种标准的方法,在系统与系统之间传输数据,而不给予访问源系统的权限。

既然你正在谈论一个大型应用程序,我强烈建议您使用MySQL(或其他RDBMS),随着数据集的不断增长,XML将变得越来越慢,除非您始终在内存中保持新鲜副本,并且只在服务重启时读取XML文件。

据报道,当你不断地将XML发送到数据库中,并从数据库中检索XML时,使用XML数据库的效率更高。理由是,当XML是唯一的传输语法用于将事物输入和输出数据库时,为什么要将所有内容都通过SQL抽象层和所有那些关系表、外键等来压缩呢?这基本上是将解析层从应用程序中移除,并将其带入数据引擎-那里它可能会比SQL替代方案更快速、更高效。可能。


我认为不再是这样了:http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf [PDF]。 - Daniel Vassallo
1
@Daniel,他们将Cassandra与MySQL结合使用:http://www.facebook.com/note.php?note_id=24413138919 无论如何,不使用XML。 - shamittomar

5
取决于您的网站性质。一方面,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存储在关系型数据库中的支持也越来越广泛。你会因重复造轮子而陷入困境...

此外,通过将数据存储在关系型数据库中,可以实现规范化,这将强制执行参照完整性,而XML永远无法做到这一点...

2) "全局锁定"并没有任何上下文范围。在写入时,我所知道的数据库都不会全局锁定;大多数为了保留并发性,在指定时会支持各种程度的锁定(表/行等,各厂商之间有所不同),而不是默认情况。

3) 没有数据库、数据或实际用户-关注聚集是明显的过早优化。

4) 如果在将参照完整性写入某些能够在应用程序关闭后保留的持久化介质之前,系统崩溃了,那么数据就会变得无用。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接