New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Just a few points to note:
Scaling vertically is very easy and affordable to people living outside South Asia - you get upto 32 GB RAM in many cloud / VPS / Dedicated providers with 4-5 HDDs(each 500G - 1T ), Network storage and what not.
Scaling horizontally is a totally different ball game to scaling vertically. You need to redesign your application from the ground up - for scaling horizontally - will explain soon.
If it is a huge application (or will become in the future) with many fields, lots of inter-related data, then you can even choose to separate fields between DB's - relational data goes into MySQL, documents go into plain filesystem or document store DB's or key-value DB's - simply store pointers to the documents in relational columns. Use the correct tool for the correct need.
MySQL is really mature - you can partition, shard, replicate(master slave), cluster (connected groups of mysql servers) and a lot more. Mysql 5.6.4 onwards has a in-built InnoDB FTS engine, and there are various plugins to MySQL which allow document storage, graph / network data too. All free and opensource.
Partitioning in MySQL is pretty superb. You can ask MySQL to break up the DB in one file per table and each such table into multiple files - one per partition. Now I don't know whether you can place these partitions on different physical disks (I think not yet) but then there is sharding . You can design you app itself to pick up from different MySQL servers based on some column like user_id. You can make, say 10 logical parts to your user_id space, and each logical part goes to a separate physical MySQL server - For example, if you say for users table
user_id auto_increment=10, start =0then it will only ever have user_id's 0,10,20,30 and so on. The next server you sayuser_id auto_increment=10, start =1then it will only ever have user_id's 1,11,21,31 and so on. Thus you go upto 9,19,29,39, etc with start=9.In this way, you if think your app will really scale, you can even start with
user_id auto_increment=100, start=0- this means you can add 100 physical MySQL servers :-)I don't think you need more than that.
MongoDB is a document store - use it only if you have document storage-retrieval needs and that too, there is no rule that says you should use only one of MySQL or MongoDB, use both, or any more also, if it pleases you :-)
Basically spend time architecting your app - and just remember MySQL is a good solid friend, if you look close and hard enough.
Good luck!
EDIT:
Don't let anyone tell you that InnoDB is slow. Those days are long gone. If you give somewhat decent RAM to InnoDB (not even all that it nominally demands based on howto's and mysqlperformanceblog tips) it rips and flies and what not :-) The reason I am suggesting to stick with MySQL is that there is no dearth of support and tips on the internet for MySQL. I am personally not sure how much great free support (in terms of google-fu) there is for the noSQL DB's if you are stuck with some performance issue.
Have you taken a look at TokuDb?
www.tokutek.com/products/tokudb-for-mysql/