http://akfpartners.com/techblog/2008/05/22/splitting-databases-for-scale/ Technical and Leadership Thoughts Wed, 10 Mar 2010 16:54:54 +0000 http://wordpress.org/?v=2.9.2 hourly 1 http://akfpartners.com/techblog/2008/05/22/splitting-databases-for-scale/comment-page-1/#comment-540 Using Vendor Features to Scale | AKF Partners Blog Fri, 01 Jan 2010 19:43:37 +0000 http://akf-consulting.com/techblog/2008/05/22/splitting-databases-for-scale/#comment-540 [...] these concerns resonate with you, check out our database scalability cube post for ideas on how to design a scaling strategy that you can own, is relatively simple, and is vendor [...] [...] these concerns resonate with you, check out our database scalability cube post for ideas on how to design a scaling strategy that you can own, is relatively simple, and is vendor [...]

]]> http://akfpartners.com/techblog/2008/05/22/splitting-databases-for-scale/comment-page-1/#comment-462 Newsletter - Trends | AKF Partners Blog Tue, 27 Oct 2009 16:56:20 +0000 http://akf-consulting.com/techblog/2008/05/22/splitting-databases-for-scale/#comment-462 [...] While relational database management systems (RDBMS) are scalable as we have described in many of our posts, we also know that it can be intimidating for some technology [...] [...] While relational database management systems (RDBMS) are scalable as we have described in many of our posts, we also know that it can be intimidating for some technology [...]

]]> http://akfpartners.com/techblog/2008/05/22/splitting-databases-for-scale/comment-page-1/#comment-390 Scaling & Availability Anti-patterns | AKF Partners Blog Thu, 13 Aug 2009 23:56:51 +0000 http://akf-consulting.com/techblog/2008/05/22/splitting-databases-for-scale/#comment-390 [...] enough you will need the ability to split your database on at least one axis as described in the AKF Scale Cube. Planning on Moore’s law to save you is planning to [...] [...] enough you will need the ability to split your database on at least one axis as described in the AKF Scale Cube. Planning on Moore’s law to save you is planning to [...]

]]> http://akfpartners.com/techblog/2008/05/22/splitting-databases-for-scale/comment-page-1/#comment-321 Tuning versus Scaling | AKF Partners Blog Wed, 01 Jul 2009 16:57:00 +0000 http://akf-consulting.com/techblog/2008/05/22/splitting-databases-for-scale/#comment-321 [...] involves architectural effort in redesign of the underlying fundamentals of your system such as adding replicated read databases or splitting databases along data boundaries while tuning is just “spring cleaning” of your [...] [...] involves architectural effort in redesign of the underlying fundamentals of your system such as adding replicated read databases or splitting databases along data boundaries while tuning is just “spring cleaning” of your [...]

]]> http://akfpartners.com/techblog/2008/05/22/splitting-databases-for-scale/comment-page-1/#comment-296 The Problem With Food and Technology | AKF Partners Blog Mon, 01 Jun 2009 15:05:32 +0000 http://akf-consulting.com/techblog/2008/05/22/splitting-databases-for-scale/#comment-296 [...] for its original purpose, a load balancer as a load balancer and a database as a database. Use an X, Y, or Z axis split to scale your database, don’t rely on a vendor for scale. Following this principle will 1) allow you to remain [...] [...] for its original purpose, a load balancer as a load balancer and a database as a database. Use an X, Y, or Z axis split to scale your database, don’t rely on a vendor for scale. Following this principle will 1) allow you to remain [...]

]]> http://akfpartners.com/techblog/2008/05/22/splitting-databases-for-scale/comment-page-1/#comment-96 10 of the Biggest Platform Development Mistakes - GigaOM Mon, 30 Jun 2008 19:00:46 +0000 http://akf-consulting.com/techblog/2008/05/22/splitting-databases-for-scale/#comment-96 [...] 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://akfpartners.com/techblog/2008/05/22/splitting-databases-for-scale/comment-page-1/#comment-95 Abbott, Keeven &#038 Fisher Consulting Mon, 09 Jun 2008 17:23:57 +0000 http://akf-consulting.com/techblog/2008/05/22/splitting-databases-for-scale/#comment-95 [...] 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://akfpartners.com/techblog/2008/05/22/splitting-databases-for-scale/comment-page-1/#comment-94 Abbott, Keeven &#038 Fisher Consulting Fri, 30 May 2008 23:03:48 +0000 http://akf-consulting.com/techblog/2008/05/22/splitting-databases-for-scale/#comment-94 [...] « Splitting Databases for Scale [...] [...] « Splitting Databases for Scale [...]

]]>