Putting a component between your users and your database may not be the first thing that people think of when they start to encounter database performance issues. So, in this article I’d like to discuss three reasons why a transparent proxy-based data distribution solution provides a very good answer to database scalability problems. Read More
AWS Webinar: How to Scale RDS and MySQL on EC2 – Many Instances Working Together as One | September 24, 2014, 1:00pm EST
Webinar: How to Scale RDS and MySQL on EC2: Many Instances Working Together as One
– Keep ACID and RDS Services with No Changes to App Code
Do you want to scale Amazon RDS and MySQL on EC2 and cut computing costs? Do you want the scale, availability and performance of a distributed database while keeping ACID and RDS services?
Of course you do!
In this post, we will introduce several query examples that demonstrate optimization potential in a distributed environment, based on real-life cases.
Before diving into query execution path optimization, if you are unfamiliar with the term or simply need a refresher, be sure to check out my two previous posts on the topic. Learn key definitions in Part 1: An Overview, and gain insights in Part 2: Examples, whilst preparing your mind for query execution path optimization, all the while.
Distributed databases are a hot topic. They’ve been written about for decades, but only recently have they been commercially available. Scale out performance, continuous availability, and geo-distribution of data are some of the highlight benefits they provide. If you want humongous web scale capabilities to handle unlimited numbers of concurrent users and transactions — and manipulate massive data volumes — you want a distributed database.
But the way data is distributed across your distributed database makes a big difference to how successful the database will actually be in delivering these great benefits. If it’s done badly — or in a way that is not tuned to your application’s requirements — your distributed database will not perform so well.
This post examines the difference between typical “black-box” data distribution approaches and ScaleBase’s transparent approach. We will delve into various techniques and solutions that are used as well as examine the integral role developers and DBAs play in strategic data distribution.
The open source database market is going gangbusters. Never has there been a time when more database choices were available. In this blog posting, I want to quickly look at some market statistics. There are some surprising findings.
A distributed relational database can do wonders for the scalability of your application. Unfortunately, there are a number of challenges that tend to accompany this modern solution.
The short presentation identifies the issues that many of us working with distributed databases know all too well.
Looking at each challenge individually, you will learn how to identify these common nuisances in a distributed database environment.
The first post in this series, Query Execution Paths in a Distributed Relational Database Environment: Part 1, I briefly discussed the different ways one could go about executing an SQL statement.
Sticking with the concepts described in that post, I would now like to delve a bit deeper into the various execution paths, using specific examples to understand and analyze the collection and processing phases of queries.
Today, I’d like to discuss read/write (r/w) splitting – use cases and benefits.
Read/write splitting is a special kind of data distribution, and it offers a slightly different approach to a number of database scalability issues. Essentially, the r/w splitting process takes place in a simple cluster where multiple copies of the entire database are utilized for query execution (instead of distributing portions – or shards – of data).
So, let’s take a look at some typical uses cases and some specific issues you need to take into account.
Your business is taking off and success feels good! Users are flocking to your app. Your game is going viral. Website traffic is exploding. Your hard work is paying off. Congratulations!!
Business growth creates more users, more transactions, and more data and can strain your database beyond its capacity. But your database must keep up with the rise in transactions and concurrent workloads. What can you do? A short-sighted solution is to buy bigger hardware and scale up. But this only provides a temporary fix. A long-term solution is to scale out your database. That is, transition from a single instance database to a distributed database.
But how can you scale out an existing database without downtime and without any application or service interruptions?
That’s what I want to discuss today.
Subscribe to Blog
- September 2014
- August 2014
- July 2014
- June 2014
- May 2014
- April 2014
- March 2014
- February 2014
- January 2014
- November 2013
- October 2013
- September 2013
- August 2013
- July 2013
- June 2013
- May 2013
- April 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- January 2011
- December 2010
- October 2010
- August 2010
- July 2010