XML vs MySQL for Large Sites

nano1

New Member
For a very large site such as a Social Network (say Facebook), which method would you recommend for user accounts storage?1) Single XML files for each type of features, on the user's directory: basicinfo.xml, comments.xml, photos.xml, ...2) MySQL, although not sure how to organize on this. Maybe separated tables for each feature? E.g. a tables for Comments, where columns are id,from,message,time?I know XML is not designed for storage, and PHP (this is the language I use) must read the entire XML file and store in memory before it is used.But, here are the reasons why I prefer XML (but I may be wrong, please tell me if you disagree with any):1) If I have user accounts' paths organized in this way\[quote\] User ID 2342:
/users/00/00/00/00/00/00/00/23/42/\[/quote\]I think it's faster to find the Comments of a user by file path than seeking in a large database.
Also, if each feature is split in tables, each user profile will seek more than once, to display comments, photos, basic info, etc.2) I heard MySQL is globaly locked when writing on it. Is this true? If yes, I rather to lock a single file than everything.3) Is MySQL "shared" between the cluster? I mean, if 1 disk gets full, will it "continue" on another? Or do I, as the programmer, have to manage it myself and create new databases on another disk? (note, I use Linux)
It is ok that it is about the same by using XML files, but it is easier to split between disks, because structure is split by account IDs, not by feature as it would be in a database.4) Note that I don't store each comment on the comments.xml. I just note their attributes in each XML tag, and the messages are in separated text files commentid.txt. Once each XML should not be much large, there should not be problems with memory/time.As for the problem of parsing entire XML, maybe I should think on using XMLReader/Writer instead of SimpleXML/DOM? Or, will it decrease performance allot?Thank you!
 
Back
Top