Comments on: scale-out vs scale-up http://oracle2mysql.wordpress.com/2007/08/22/12/ yet another MySQL DBA blog Thu, 10 Sep 2009 22:56:30 +0000 http://wordpress.com/ hourly 1 By: Архитектура Wikimedia | Всё интересное http://oracle2mysql.wordpress.com/2007/08/22/12/#comment-269 Архитектура Wikimedia | Всё интересное Tue, 12 Aug 2008 11:57:32 +0000 http://oracle2mysql.wordpress.com/2007/08/22/12/#comment-269 [...] scale-out vs scale-up из блога “Oracle to MySQL” [...] [...] scale-out vs scale-up из блога “Oracle to MySQL” [...]

]]> By: Архитектура Wikimedia | Insight IT http://oracle2mysql.wordpress.com/2007/08/22/12/#comment-266 Архитектура Wikimedia | Insight IT Fri, 28 Mar 2008 12:33:04 +0000 http://oracle2mysql.wordpress.com/2007/08/22/12/#comment-266 [...] scale-out vs scale-up из блога “Oracle to MySQL” [...] [...] scale-out vs scale-up из блога “Oracle to MySQL” [...]

]]> By: Sebastian Wallroth http://oracle2mysql.wordpress.com/2007/08/22/12/#comment-94 Sebastian Wallroth Sun, 28 Oct 2007 23:39:50 +0000 http://oracle2mysql.wordpress.com/2007/08/22/12/#comment-94 Thank you for your article. I'm in research for scaling-up or -out. As a side effect I translated yoúr article into German: http://habacht.blogspot.com/2007/10/scale-out-vs-scale-up-skalierung-durch.html Thank you for your article. I’m in research for scaling-up or -out. As a side effect I translated yoúr article into German: http://habacht.blogspot.com/2007/10/scale-out-vs-scale-up-skalierung-durch.html

]]> By: Sean Bannister http://oracle2mysql.wordpress.com/2007/08/22/12/#comment-58 Sean Bannister Fri, 28 Sep 2007 07:23:50 +0000 http://oracle2mysql.wordpress.com/2007/08/22/12/#comment-58 Thanks for the great article that was really useful, im currently researching different ways to shard. Thanks for the great article that was really useful, im currently researching different ways to shard.

]]> By: ben http://oracle2mysql.wordpress.com/2007/08/22/12/#comment-13 ben Thu, 23 Aug 2007 17:14:27 +0000 http://oracle2mysql.wordpress.com/2007/08/22/12/#comment-13 Thanks for the corrections and clarifications! I was writing from memory and not checking my facts - I knew disk-based NDB was coming soon, but didn't realize how soon (to "production", that is - I guess it's already here)! Thanks for the corrections and clarifications! I was writing from memory and not checking my facts – I knew disk-based NDB was coming soon, but didn’t realize how soon (to “production”, that is – I guess it’s already here)!

]]> By: Matthew Montgomery http://oracle2mysql.wordpress.com/2007/08/22/12/#comment-11 Matthew Montgomery Thu, 23 Aug 2007 04:24:57 +0000 http://oracle2mysql.wordpress.com/2007/08/22/12/#comment-11 I must correct you on one point... Disk based columns for NDB (MySQL Cluster) tables is available in 5.1. See: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-disk-data.html NDB Engine gives you the ability to scale-out while preserving a single logical image of your data without having to code sharding into your application. It also provides high availability with synchronous replication, sub-second failover and automatic recovery. I must correct you on one point… Disk based columns for NDB (MySQL Cluster) tables is available in 5.1.

See: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-disk-data.html

NDB Engine gives you the ability to scale-out while preserving a single logical image of your data without having to code sharding into your application. It also provides high availability with synchronous replication, sub-second failover and automatic recovery.

]]> By: Keith Murphy http://oracle2mysql.wordpress.com/2007/08/22/12/#comment-10 Keith Murphy Thu, 23 Aug 2007 01:26:10 +0000 http://oracle2mysql.wordpress.com/2007/08/22/12/#comment-10 So, a couple of points. One..MySQL 5.0 has totally in-memory clustering using the NDB engine. With MySQL 5.1, on the other hand, you only have to keep indexes in memory. Actually data can be kept on disk. Why would you do this? Well, primarily reliability. If you have multiple SQL and data nodes and it is properly configured you can have any server go down and the cluster keeps running. In theory it will allow you to scale your app as needed. That is more theoretical at this point from what I have seen, but I am sure this will continue to improve. I am having this discussion right now about scale-out vs. scale-up. Yes, scale out is cheap(er) because higher-end hardware is more expensive. But, more servers require more people to maintain them (sys admins) and more dba's to work on them. So, it gets murky as to which is better. It has been proven over and over that MySQL can scale-out. Not as much info is available about scale-up. I haven't read the postings you reference, but I will. The info I have heard is that MySQL under Linux will handle around 64 gigs of RAM and around 8 cores without to much loss due to inefficiency. That is actually a pretty hefty machine....one that could replace quite a few smaller servers. Another argument aside from the reduced admin cost is that some applications simply don't shard so well. There is a great deal of complexity in some applications that make this prohibitive. I hope to benchmark some of this down the road. I will certainly blog about it if I get the chance. So, a couple of points. One..MySQL 5.0 has totally in-memory clustering using the NDB engine. With MySQL 5.1, on the other hand, you only have to keep indexes in memory. Actually data can be kept on disk.

Why would you do this? Well, primarily reliability. If you have multiple SQL and data nodes and it is properly configured you can have any server go down and the cluster keeps running.

In theory it will allow you to scale your app as needed. That is more theoretical at this point from what I have seen, but I am sure this will continue to improve.

I am having this discussion right now about scale-out vs. scale-up. Yes, scale out is cheap(er) because higher-end hardware is more expensive. But, more servers require more people to maintain them (sys admins) and more dba’s to work on them. So, it gets murky as to which is better.

It has been proven over and over that MySQL can scale-out. Not as much info is available about scale-up. I haven’t read the postings you reference, but I will. The info I have heard is that MySQL under Linux will handle around 64 gigs of RAM and around 8 cores without to much loss due to inefficiency. That is actually a pretty hefty machine….one that could replace quite a few smaller servers.

Another argument aside from the reduced admin cost is that some applications simply don’t shard so well. There is a great deal of complexity in some applications that make this prohibitive.

I hope to benchmark some of this down the road. I will certainly blog about it if I get the chance.

]]>