http://akf-consulting.com/techblog/2008/05/22/splitting-databases-for-scale/ Technical and Leadership Thoughts Thu, 20 Nov 2008 20:59:14 +0000 http://wordpress.org/?v=2.0.2 http://akf-consulting.com/techblog/2008/05/22/splitting-databases-for-scale/#comment-98 Mon, 30 Jun 2008 19:00:46 +0000 http://akf-consulting.com/techblog/2008/05/22/splitting-databases-for-scale/#comment-98 [...] 5) Scaling through third parties: If you’re a hyper-growth SaaS site, you don’t want to be locked into a vendor for your future business viability; rather you want to make sure that the scalability of your site is a core competency and that it’s built into your architecture. Define how your platform scales through your efforts, not through the systems that a third-party vendor provides. [...] […] 5) Scaling through third parties: If you’re a hyper-growth SaaS site, you don’t want to be locked into a vendor for your future business viability; rather you want to make sure that the scalability of your site is a core competency and that it’s built into your architecture. Define how your platform scales through your efforts, not through the systems that a third-party vendor provides. […]

]]> http://akf-consulting.com/techblog/2008/05/22/splitting-databases-for-scale/#comment-77 Mon, 09 Jun 2008 17:23:57 +0000 http://akf-consulting.com/techblog/2008/05/22/splitting-databases-for-scale/#comment-77 [...] Every vendor has a quick fix for your scale issues. If you are a hyper growth SaaS site, however, you do not want to be locked into a vendor for your future business viability; rather you want to make sure that the scalability of your site is a core competency and that it is built into your architecture. See our articles on database scalability and platform scalability. This is not to say that after you design your system to scale horizontally that you will not rely upon some technology to help you; rather, once you define how you can horizontally scale you want to be able to use any of a number of different commodity systems to meet your needs. As an example, most popular databases provide for the technology of log shipping to keep read or standby databases in synch with the primary. Per our discussion in technology agnostic design, define how your platform scales through your efforts, not through the systems that a 3d party vendor or opensource software company provides. If you say we use ACME database clusters to scale our database we would argue you have the wrong solution. If, on the other hand you say we split our databases into read and write systems and further split them by customer id you are attacking the problem appropriately. [...] […] Every vendor has a quick fix for your scale issues. If you are a hyper growth SaaS site, however, you do not want to be locked into a vendor for your future business viability; rather you want to make sure that the scalability of your site is a core competency and that it is built into your architecture. See our articles on database scalability and platform scalability. This is not to say that after you design your system to scale horizontally that you will not rely upon some technology to help you; rather, once you define how you can horizontally scale you want to be able to use any of a number of different commodity systems to meet your needs. As an example, most popular databases provide for the technology of log shipping to keep read or standby databases in synch with the primary. Per our discussion in technology agnostic design, define how your platform scales through your efforts, not through the systems that a 3d party vendor or opensource software company provides. If you say we use ACME database clusters to scale our database we would argue you have the wrong solution. If, on the other hand you say we split our databases into read and write systems and further split them by customer id you are attacking the problem appropriately. […]

]]> http://akf-consulting.com/techblog/2008/05/22/splitting-databases-for-scale/#comment-66 Fri, 30 May 2008 23:03:48 +0000 http://akf-consulting.com/techblog/2008/05/22/splitting-databases-for-scale/#comment-66 [...] « Splitting Databases for Scale [...] […] « Splitting Databases for Scale […]

]]>