对于一个非常大的网站,例如社交网络(比如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？或者,它会降低性能吗？
谢谢!
话虽如此.这是长版本:
我总是说XML是一种数据传输技术,而不是数据存储技术,但不是每个人都同意.XML不是设计用于关系数据存储区.首先引入XML是为了提供一种从系统到系统传输数据的标准方法,无需访问原始系统.
既然你在谈论一个大型应用程序,我强烈建议你使用MySQL(或其他RDBMS),随着数据集的增长和增长,XML将越来越慢,除非你总是在内存中保留一个新的副本并且只读取服务重启时的XML文件.
据报道,当您经常将XML发送到数据库并从数据库中检索XML时,使用XML数据库在转换成本方面更有效.理由是,当XML是用于进出数据库的唯一传输语法时,为什么要通过一层SQL抽象和所有那些关系表,外键等来挤压所有内容？它基本上从应用程序中取出一个解析层并将其带入数据引擎 - 它可能比SQL替代方案更快,更有效地工作.大概.
在很大程度上取决于您网站的性质.一方面,XML方法让你对事物的免费通行证,如"SELECT*FROM $表,其中$ table.id = $ ID"类型的查询.另一方面...
对于一个非常大的站点,在最坏的情况下,数据文件也会变得非常大.如果是任何类型的社区网站,这可能很容易发生任何帐户去任何一个论坛,在社区保守派成员的真实数量,你会发现一对夫妇的海报有说10K的帖子...这意味着您希望使用内存高效模型而不是速度效率模型实现SQL样式结果集.对于最终用户来说,1s对1.1s的响应时间并不是那么多; 但对你而言,1K的同步请求肯定是1.5K或更好.
再有就是方面,如果你大多是读取数据的XML可能是罚款,如果有些粗糙的大数据集和基于DOM实现.但如果你写的很多,情况会变得更糟.数据高速缓存仍然是可能的,但是给ACID像这些文件交易担保要求你几乎写自己的数据库软件.
然后有存储要求等,这意味着您可能需要一种分布式方法来存储您的数据.这些类型的设置都比较充分的了解数据库中的世界,他们带来了很多与他们有趣的问题表(就像你会怎么做,如果单个磁盘发生故障？你怎么知道什么磁盘找到数据你怎么实现高效的缓存？)基本上等于从头重新编写自己的迷你数据库软件.
因此,对于一个非常大的站点,我认为性能的硬技术要求在内存和一定可靠性方面并没有太大的成本,并且不需要同时重新发明21个轮子意味着你的方法不能很好地工作.我认为它更适合于那些您可以负担得起并尝试替代路线的小型只读站点,您可以轻松地进行更改并在整个站点中进行更改.