Archive for the ‘cloud database’ Category

SkySQL Raises $4 Million in Series A Round Funding

Апрель 19th, 2012

I am very pleased to say that earlier today, SkySQL announced it has raised $4 Million in Series A Round Funding.

Let me post the main part of the press release here:

SAN JOSE – April 18, 2012 – SkySQL, the first choice in affordable database solutions for the MySQL® and MariaDB® databases in the enterprise and the cloud, today announces that the company has raised $4 million in Series A funding from a number of investors, including OnCorps, an elite peer-based community of veteran technology investors and advisors committed to bringing better, cost-disruptive technologies into the mainstream. Also funding the round are European investors including Finnish Industry Investment Ltd., Spintop Ventures and Open Ocean Capital.

SkySQL will primarily use the investment to fund growth in its new product development, including adding critical positions. This is the company’s most recent move in expanding beyond a MySQL and MariaDB services-only company into a fully-fledged database products and services provider. SkySQL made its debut in October 2010 and has been funded to date with seed money from OnCorps, as well as Open Ocean Capital. Today, SkySQL is currently operating in 13 countries.

“The SkySQL strategy aligns well with OnCorps’s technology leadership vision,” said Bob Suh of OnCorps. “SkySQL will capitalize on the growing database and cloud services market. We are delighted and look forward to working with the SkySQL team to contribute to their continued success.”

“This investment will let us focus on ramping up development and efforts behind both enterprise and cloud database products that address a very real need in the marketplace,” said Ulf Sandberg, chief executive officer of SkySQL. “We also plan to build on our existing MySQL and MariaDB services offering, which offers customers unrivaled support, consulting and training.”

You can read the full press release here:

http://www.skysql.com/news-and-events/press-releases/skysql-raises-4-million-series-round

Very exciting times! :)

 


PlanetMySQL Voting: Vote UP / Vote DOWN
 

Posted in cloud, cloud database, Finnish Industry Investment Ltd., InnoDB, maria, MariaDB, mysql, OnCorp, OnCorps, Open Ocean Capital, SkySQL, skysql cloud, skysql investment, skysql series A funding, Spintop Ventures

Комментарии отключены

 

Walking on Cloud 9

Декабрь 15th, 2011

As the saying goes, we at Severalnines have been walking on several clouds this year, 9 to be precise!


Today, we are proud to say that we are on walking on Cloud 9!


And in the spirit of celebration, we would like to announce our:



Top 9 Clouds of the Year 2011 for Severalnines



Cloud 1 – releasing ClusterControl™ - our first commercial product in April!


ClusterControl™ is our flagship product. It enables developers and database administrators to Deploy, Manage, Monitor and Scale their clustered database platforms, free from the complexity and learning curves associated with database clusters. Read more ...



Cloud 2 – releasing ClusterControl™ for MySQL Replication


Designed to address issues and needs of MySQL users relying on MySQL Replication, ClusterControl™ for MySQL Replication offers a complete set of tools to assist developers and administrators of all skill levels to deploy, manage, monitor and scale their replicated MySQL databases. Read more ...



Cloud 3 - releasing ClusterControl™ for MySQL Galera together with Codership

ClusterControl™ for MySQL Galera enables customers to Deploy, Manage, Monitor and Scale a clustered MySQL database platform based on Galera Replication. MySQL Galera is a synchronous multi-master cluster for MySQL/InnoDB, and allows applications to read and write from any MySQL Server.

Developers and DBAs now have access to all of the features of Severalnines' flagship product ClusterControl™ specifically adapted to MySQL Galera. Read more ...


Cloud 4 – reaching over 7,000 installations via the Severalnines Configurator


The Severalnines Configurator allows you to generate a production class configuration for a clustered MySQL configuration. It also generates a deployment package that automates the deployment of the complete database setup. Topologies can be based on MySQL Replication, MySQL Cluster or MySQL Galera.


We have a great user base and in order to facilitate communication within our user community, we set up our Severalnines Customer Services platform with forums, online support, etc. both for paying customers as well as users. Check it out and join the conversation!



Cloud 5 – our Customers


At Severalnines, our goal is to reduce database costs, ease deployment, simplify management and increase DBA and developer productivity.


But rather than us telling you why we think we are great, we wanted to provide documented case studies on how our innovative products are helping customers meet and exceed business goals for their database operations. See what our customers have to say about us.



Cloud 6 – introducing Severalnines DataCloud™


Severalnines DataCloud™ enables DBaaS for public, private and hybrid clouds. It extends the advantages of cloud computing to the database infrastructure layer by enabling on-demand access, automated management, managed availability and elasticity of MySQL databases. This reduces cost and the complexities of deploying and managing databases. Read more ...



Cloud 7 – launching the first ever 100% European DbaaS with City Network


On November 23rd, Severalnines and our partner City Network announced the first fully European Database as a Service (DBaaS) solution - in beta form. The City Cloud Database Service is based and operated in the European Union - offering European customers full compliance with EU Directive on Data Protection 95/46/EC and a safe haven from the reaches of the US Patriot Act and making it the first ever offering of its kind. Read more ...



Cloud 8 – being talked about at the European Commission – Severalnines in the News


Following our announcement of the City Cloud Database Service, the press took over and 20+ original articles later, we discovered that we were even being talked about at European Commission conferences. Which shows to prove that politicians do read the papers (or are well briefed by colleagues who do) and that we had hit the right spot with our announcement. Find out more and see all the press coverage in our News Center.



Cloud 9 – winning the EuroCloud Sweden & Europe Awards 2011 for Best Startup!!!


We did it! After winning the EuroCloud Award for Sweden, we won the EuroCloud Europe Award for Best Startup last week in Paris at a prestigious ceremony on the Seine. We attended the ceremony together with our friends from City Network and needless to say that we had a great night! The Awards have been widely covered by the European press in multiple languages – visit our News Center for all the details.


All in all, it's been a great year for us and we have all of you to thank for that!


So here is a BIG 'thank you' from everyone at Severalnines to all our customers, partners, friends and supporters out there.


Have a great year-end and and an even better start to the year 2012 - see you there!


Please do reach out to us with your feedback on Facebook, LinkedIn, XING or directly via these contact details for fruitful and interactive discussions on this latest release. For 'instant' communication, feel free to follow us on Twitter !

About Severalnines

Severalnines provides automation and management software for easily usable, highly available and auto-scalable cloud database platforms. ClusterControl™, the company’s flagship product, used by developers and administrators of all skill levels, addresses the full deploy-manage-monitor-scale cycle. Severalnines has enabled over 7,000 deployments to date via its popular online configurator for clustered MySQL databases.

To see who is using Severalnines today, please visit our references page.


PlanetMySQL Voting: Vote UP / Vote DOWN
 

Posted in cloud computing, cloud database, mysql, MySQL Cluster, MySQL Replication

Комментарии отключены

 

Lack of Business Visibility Cripples Traditional SQL DaaS, Drives NewSQL

Сентябрь 23rd, 2011
More and more public cloud companies are moving to managed cloud services to improve their value-add (price premium) and the stickiness of their solution. However, the shift to a database as a service (DaaS) severely reduces the DBAs visibility into the business, thus limiting the ability to hand tune the database to the requirements of the application and the database. The solution is a cloud database that eliminates the hand-tuning of the database, thereby enabling the DBA to be equally effective even with limited visibility into the business and application needs. It is these unique needs, particularly for SQL databases, that is fueling the NewSQL movement.

DBAs traditionally have insight into the company, enabling them to hand tune the database in a collaborative basis with the development team, such as:

1. Performance Trade-offs/Tuning: The database is partitioned and tuned to address business requirements, maximizing performance of certain critical processes, while slowing less critical processes.

2. System Maintenance Planning: You need to shut down the database to do an application/database upgrade, repartition, etc. but you may need to coordinate with the development team, and the schedule may change up until the last moment.

3. Application Evolution: The database must be designed and tuned to accommodate the planned changes in the application.

4. Consulting with Application Developers: Since the database partitioning and performance are hand-tuned, the DBA must collaborate closely with the application development team on design, development and deployment.

5. Partitioning Requirements: When partitioning (or repartitioning) your database you’ll need to partition the data to suit application requirements avoiding things like cross partition joins, range scans, aggregates, etc., which can cause tremendous performance penalties if not implemented correctly.

6. Moving Processes to the Application Layer: Single server databases can handle joins, range scans, aggregates and the like internally. However, when you partition the database these functions are typically moved to the application layer. The application must add the logic to accomplish these things. It must also add the routing code to point to the correct partitions. As a result, an application written to a single server API does not work in a multi-server configuration.

When moving from a self-managed database—either in the cloud or on premise—to a DaaS, the “DBA-in-the-cloud” doesn’t have that visibility into the business requirements, performance requirements, development schedule, and more. This lack of visibility turns the already challenging task of hand-tuning the database into a near impossibility using traditional databases.

A real world example: You are the DBA-in-the-cloud. Your customer has been running on a single server, but they need to now scale-out across multiple database nodes to accommodate growth. How do you split the data? You don’t know which queries have higher performance priority. You don’t know the development plan for new version of the application. You don’t know when it is convenient to shut down the application to implement the partitioning. You need to inform the application developers how they should implement their routing code to send database requests to the right nodes. You need to inform the application developers that they need to handle joins, range scans and aggregates at the application level, since the database can no longer handle those.

DBAs have enough of a challenge scaling and maintaining databases when they have full visibility into the business. To address these challenges without that level of visibility is unrealistic. I refer to this problem as the “Blind DBA” challenge, because the DaaS DBA has a serious lack of visibility into the requirements and inner workings of the company.

ScaleDB is a NewSQL database uniquely designed to handle the Blind DBA challenge inherent in DaaS implementations. ScaleDB is based on a shared-disk architecture that scales in a manner that is invisible to the application. It eliminates the need to push functions (joins, range scans, aggregates) up to the application layer. It eliminates the need to coordinate your application and database design to work around partitions, because there are no partitions. It eliminates the performance tradeoffs in partitioning design, you get consistent performance across the database. It eliminates scheduling and coordinating application shut-down to repartition, because it doesn’t use partitions. In short, with ScaleDB the DBA needn’t have any visibility into the business to deliver optimal database performance via a single API. This is what makes ScaleDB an ideal solution for cloud companies implementing the database as a managed service or DaaS.


PlanetMySQL Voting: Vote UP / Vote DOWN
 

Posted in cloud, cloud database, clustered database, DaaS, database, database virtualization, elastic, elastic database, High Availability, newsql

Комментарии отключены

 

MySQL Clusters on Amazon EC2 — verified AMIs

Август 23rd, 2011
We regularly receive questions from our user community with regards to which AMIs to use when deploying database clusters on Amazon EC2.

As part of our ongoing development work on the Severalnines Configurator and ClusterControl, we have recently done some testing on deploying MySQL Cluster on EC2 using Severalnines on three different AMIs. We thought we should share the results of these tests, hence the reason for this week's blog!

If you would like to test such a deployment yourself, feel free to use the parameters and guidelines below to do so. You can also check out these new videos to see Severalnines technology in action prior to getting started with your testing.

These are the three AMIs that we have tested the deployment on so as to have a good representative mix:

* RightImage_CentOS_5.4_x64_v5.5.9
* Amazon QuickStart AMI: amzn-ami-2011.02.1.x86_64-ebs
* Canonical AMI: ubuntu-maverick-5g-64bit

Of course, it would be great to hear from you on how your testing went and on what AMIs you are currently using yourself. Feel free to share your feedback with us on Facebook, Twitter, LinkedIn or leave a comment on this blog.

Here are the parameters that you can use to test your MySQL Cluster deployment using the Severalnines Configurator.

In all cases, the Internal IP was used as the Hostname in the Configurator and the following was used for all tests:

* Instance type: m1.larg
* Number of instances: 5 (1 for ClusterControl), 2 for data nodes, 2 for MySQL servers and management servers.

RightImage_CentOS_5.4_x64_v5.5.9 (ami-0f42a966)

* Cloud Provider [Configurator]: Amazon EC2
* OS user [Configurator]: root
* Operating System [Configurator]: Redhat/Fedora/Centos/Oracle
* Data directories [Configurator]: /mnt/data/mysqlcluster for data nodes and management servers and /mnt/data/mysql (for the mysql servers) both RPM and tar.gz installation was tested using 'deploy.sh'

Canonical AMI: ubuntu-maverick-5g-64bit (ami-ac41b7c5)

* Cloud Provider [Configurator]: Amazon EC2
* OS user [Configurator]: ubuntu
* Operating System [Configurator]: Ubuntu/Debian
* DataMemory [Configurator]: 512MB
Set it down in the Configurator - yes, it is tiny, but the default disk in this AMI is tiny, so you should add a 20GB EBS Volume if you want to test with the default suggested DataMemory
* Data directories [Configurator]: default suggested ones.
* Installation was tested using 'deploy.sh'

Amazon QuickStart AMI: amzn-ami-2011.02.1.x86_64-ebs (ami-8e1fece7)

* Cloud Provider [Configurator]: Amazon EC2
* OS user [Configurator]: ec2-user
* Operating System [Configurator]: Redhat/Fedora/Centos/Oracle
* DataMemory [Configurator]: 512MB
Set it down in the Confgurator. Yes, it is tiny, but the default disk in this AMI is tiny, so you should add a 20GB EBS Volume if you want to test with the default suggested DataMemory.
* Data directories [Configurator]: default suggested ones.
* .tar.gz installation using 'deploy.sh' no problems.
* RPM installation - dependency problems with libmysqlclient.so.16 vs libmysqlclient.so.14.
This can be fixed by editing the mysqlcluster-71-rpm/cluster/scripts/install/install-rpm.sh before running 'deploy.sh':
Change this, in the function named install_rpm_cmonmysql() :
MySQL-Cluster-gpl-shared-compat-${version}-1.${rhel}.${arch}.rpm
to
MySQL-Cluster-gpl-shared-${version}-1.${rhel}.${arch}.rpm
Now you can run ./deploy.sh

Finally, do not forget to set the EC2 Keypair in the Configurator and upload it to the ClusterControl server before running deploy.sh.

You should now be up and running with your MySQL Cluster on EC2; if you have any questions or comments, please do let us know. We welcome your feedback on Facebook, Twitter, LinkedIn or directly on this blog.

For more information on AMIs: http://aws.amazon.com/amis/
For more information on EC2: http://aws.amazon.com/ec2/

PlanetMySQL Voting: Vote UP / Vote DOWN
 

Posted in Amazon EC2, AMI, cloud database, MySQL Cluster, Ubuntu

Комментарии отключены

 

MySQL Clusters on Amazon EC2 — verified AMIs

Август 23rd, 2011
We regularly receive questions from our user community with regards to which AMIs to use when deploying database clusters on Amazon EC2.

As part of our ongoing development work on the Severalnines Configurator and ClusterControl, we have recently done some testing on deploying MySQL Cluster on EC2 using Severalnines on three different AMIs. We thought we should share the results of these tests, hence the reason for this week's blog!

If you would like to test such a deployment yourself, feel free to use the parameters and guidelines below to do so. You can also check out these new videos to see Severalnines technology in action prior to getting started with your testing.

These are the three AMIs that we have tested the deployment on so as to have a good representative mix:

* RightImage_CentOS_5.4_x64_v5.5.9
* Amazon QuickStart AMI: amzn-ami-2011.02.1.x86_64-ebs
* Canonical AMI: ubuntu-maverick-5g-64bit

Of course, it would be great to hear from you on how your testing went and on what AMIs you are currently using yourself. Feel free to share your feedback with us on Facebook, Twitter, LinkedIn or leave a comment on this blog.

Here are the parameters that you can use to test your MySQL Cluster deployment using the Severalnines Configurator.

In all cases, the Internal IP was used as the Hostname in the Configurator and the following was used for all tests:

* Instance type: m1.larg
* Number of instances: 5 (1 for ClusterControl), 2 for data nodes, 2 for MySQL servers and management servers.

RightImage_CentOS_5.4_x64_v5.5.9 (ami-0f42a966)

* Cloud Provider [Configurator]: Amazon EC2
* OS user [Configurator]: root
* Operating System [Configurator]: Redhat/Fedora/Centos/Oracle
* Data directories [Configurator]: /mnt/data/mysqlcluster for data nodes and management servers and /mnt/data/mysql (for the mysql servers) both RPM and tar.gz installation was tested using 'deploy.sh'

Canonical AMI: ubuntu-maverick-5g-64bit (ami-ac41b7c5)

* Cloud Provider [Configurator]: Amazon EC2
* OS user [Configurator]: ubuntu
* Operating System [Configurator]: Ubuntu/Debian
* DataMemory [Configurator]: 512MB
Set it down in the Configurator - yes, it is tiny, but the default disk in this AMI is tiny, so you should add a 20GB EBS Volume if you want to test with the default suggested DataMemory
* Data directories [Configurator]: default suggested ones.
* Installation was tested using 'deploy.sh'

Amazon QuickStart AMI: amzn-ami-2011.02.1.x86_64-ebs (ami-8e1fece7)

* Cloud Provider [Configurator]: Amazon EC2
* OS user [Configurator]: ec2-user
* Operating System [Configurator]: Redhat/Fedora/Centos/Oracle
* DataMemory [Configurator]: 512MB
Set it down in the Confgurator. Yes, it is tiny, but the default disk in this AMI is tiny, so you should add a 20GB EBS Volume if you want to test with the default suggested DataMemory.
* Data directories [Configurator]: default suggested ones.
* .tar.gz installation using 'deploy.sh' no problems.
* RPM installation - dependency problems with libmysqlclient.so.16 vs libmysqlclient.so.14.
This can be fixed by editing the mysqlcluster-71-rpm/cluster/scripts/install/install-rpm.sh before running 'deploy.sh':
Change this, in the function named install_rpm_cmonmysql() :
MySQL-Cluster-gpl-shared-compat-${version}-1.${rhel}.${arch}.rpm
to
MySQL-Cluster-gpl-shared-${version}-1.${rhel}.${arch}.rpm
Now you can run ./deploy.sh

Finally, do not forget to set the EC2 Keypair in the Configurator and upload it to the ClusterControl server before running deploy.sh.

You should now be up and running with your MySQL Cluster on EC2; if you have any questions or comments, please do let us know. We welcome your feedback on Facebook, Twitter, LinkedIn or directly on this blog.

For more information on AMIs: http://aws.amazon.com/amis/
For more information on EC2: http://aws.amazon.com/ec2/

PlanetMySQL Voting: Vote UP / Vote DOWN
 

Posted in Amazon EC2, cloud database, MySQL Cluster, Ubuntu

Комментарии отключены

 

Do you need an elastic database?

Август 16th, 2011
Not every company or application needs an elastic database. Some applications can get by just fine on a single database server, rendering database elasticity moot from their perspective. To make this determination, simply ask yourself:

1. Will I need more than a single database server?
Look at your current load and your projected growth and ask yourself whether it will exceed the capacity of a single server. If it doesn’t now, nor will it in the future, then you don’t need an elastic database.

2. Will my load fluctuate sufficiently to warrant the investment in elasticity?
If your database requirements won’t experience fluctuations in demand—e.g. daily, weekly, monthly, seasonal changes in the number of servers required—then elasticity isn’t important. For example, if you have a social networking application that requires 2 database nodes 24x7, but peaks at 10 nodes for 2 hours a night, then elasticity is important. If your database has a steady load that requires 3 database nodes and that load doesn’t change, then elasticity isn’t important.

3. Will my database load grow with time?
I your database load will grow with time, then you need to evaluate the growth pattern and ask yourself whether you can handle this expansion manually, or if you simply want to rely on an elastic database to grow seamlessly.

If your answer to these three questions is no, then you don’t really need an elastic database. Now there are certainly other reasons to consider ScaleDB (e.g. high-availability, eliminate partitioning/sharding, eliminate master-slave issues, etc.) but elasticity may not be one of them.

PlanetMySQL Voting: Vote UP / Vote DOWN
 

Posted in Amazon database, cloud database, elastic database, mysql

Комментарии отключены

 

Do you need an elastic database?

Август 16th, 2011
Not every company or application needs an elastic database. Some applications can get by just fine on a single database server, rendering database elasticity moot from their perspective. To make this determination, simply ask yourself:

1. Will I need more than a single database server?
Look at your current load and your projected growth and ask yourself whether it will exceed the capacity of a single server. If it doesn’t now, nor will it in the future, then you don’t need an elastic database.

2. Will my load fluctuate sufficiently to warrant the investment in elasticity?
If your database requirements won’t experience fluctuations in demand—e.g. daily, weekly, monthly, seasonal changes in the number of servers required—then elasticity isn’t important. For example, if you have a social networking application that requires 2 database nodes 24x7, but peaks at 10 nodes for 2 hours a night, then elasticity is important. If your database has a steady load that requires 3 database nodes and that load doesn’t change, then elasticity isn’t important.

3. Will my database load grow with time?
I your database load will grow with time, then you need to evaluate the growth pattern and ask yourself whether you can handle this expansion manually, or if you simply want to rely on an elastic database to grow seamlessly.

If your answer to these three questions is no, then you don’t really need an elastic database. Now there are certainly other reasons to consider ScaleDB (e.g. high-availability, eliminate partitioning/sharding, eliminate master-slave issues, etc.) but elasticity may not be one of them.

PlanetMySQL Voting: Vote UP / Vote DOWN
 

Posted in Amazon database, cloud database, elastic database, mysql

Комментарии отключены

 

Cloud Elasticity & Databases

Август 4th, 2011
The primary reasons people are moving to the public cloud are: (1) replace capital expenses with operating expenses (pay as you go); (2) use shared resources for processes like back-up, maintenance, networking (shared expenses); (3) use shared infrastructure that enables you to pay only for those resources you actually use, instead of consuming your maximum load resources at all times (pay-per-use). The first thing you’ll notice is that all 3 cloud benefits have their basis in finances or the cloud business model.

We will focus in on #3 above: Pay-Per-Use. The old school model was to build your compute infrastructure for the maximum load today, plus growth over the life-cycle of the equipment, plus some buffer so the systems don’t get overloaded from spikes in usage. The net result is that your average usage might run 10% of the potential for the infrastructure you mortgaged your home to buy. In other words, you were paying 10X more than you would pay if you only paid by usage. In reality, you might pay half as much to run on the cloud, with the balance of the savings going to the cloud company in the form of profits. This works and it is a win-win for both you and the public cloud.

To achieve this Pay-Per-Use ideal, and the compelling financial advantages it enables, the infrastructure must scale elastically. You must be able to add compute power seamlessly and on the fly, without shut-down. How important is this elasticity? Amazon named their service “EC2” for “Elastic Cloud Computing”. Elastic is the first word, I would say it is pretty important. Besides, if the cloud weren’t elastic, you would simply be paying for the same computer costs, plus the public cloud company’s markup for expenses and profit.

So how elastic are public clouds? The entire cloud stack is elastic, except for one piece, the SQL database. Cloud companies recognized that the SQL database was the Achilles heel of cloud elasticity. To address this problem, they created NoSQL, which delivers database-like capabilities, but removes the things that make a SQL database inelastic; namely SQL, ACID-compliance, data consistency, transactions, etc.

NewSQL appears to be the response from the database vendors, who believe that there is a market for SQL databases that provide cloud elasticity. Not all NewSQL solutions address elasticity, but a few of us do. In my next blog post, I’ll address whether or not database elasticity is important…hint: it depends upon your needs.


PlanetMySQL Voting: Vote UP / Vote DOWN
 

Posted in Amazon database, cloud, cloud database, elastic, mysql, newsql

Комментарии отключены

 

Cloud Elasticity & Databases

Август 4th, 2011
The primary reasons people are moving to the public cloud are: (1) replace capital expenses with operating expenses (pay as you go); (2) use shared resources for processes like back-up, maintenance, networking (shared expenses); (3) use shared infrastructure that enables you to pay only for those resources you actually use, instead of consuming your maximum load resources at all times (pay-per-use). The first thing you’ll notice is that all 3 cloud benefits have their basis in finances or the cloud business model.

We will focus in on #3 above: Pay-Per-Use. The old school model was to build your compute infrastructure for the maximum load today, plus growth over the life-cycle of the equipment, plus some buffer so the systems don’t get overloaded from spikes in usage. The net result is that your average usage might run 10% of the potential for the infrastructure you mortgaged your home to buy. In other words, you were paying 10X more than you would pay if you only paid by usage. In reality, you might pay half as much to run on the cloud, with the balance of the savings going to the cloud company in the form of profits. This works and it is a win-win for both you and the public cloud.

To achieve this Pay-Per-Use ideal, and the compelling financial advantages it enables, the infrastructure must scale elastically. You must be able to add compute power seamlessly and on the fly, without shut-down. How important is this elasticity? Amazon named their service “EC2” for “Elastic Cloud Computing”. Elastic is the first word, I would say it is pretty important. Besides, if the cloud weren’t elastic, you would simply be paying for the same computer costs, plus the public cloud company’s markup for expenses and profit.

So how elastic are public clouds? The entire cloud stack is elastic, except for one piece, the SQL database. Cloud companies recognized that the SQL database was the Achilles heel of cloud elasticity. To address this problem, they created NoSQL, which delivers database-like capabilities, but removes the things that make a SQL database inelastic; namely SQL, ACID-compliance, data consistency, transactions, etc.

NewSQL appears to be the response from the database vendors, who believe that there is a market for SQL databases that provide cloud elasticity. Not all NewSQL solutions address elasticity, but a few of us do. In my next blog post, I’ll address whether or not database elasticity is important…hint: it depends upon your needs.


PlanetMySQL Voting: Vote UP / Vote DOWN
 

Posted in Amazon database, cloud, cloud database, elastic, mysql, newsql

Комментарии отключены

 

ScaleDB: Shared-Disk / Shared-Nothing Hybrid

Июль 25th, 2011
The primary database architectures—shared-disk and shared-nothing—each have their advantages. Shared-disk has functional advantages such as high-availability, elasticity, ease of set-up and maintenance, eliminates partitioning/sharding, eliminates master-slave, etc. The shared-nothing advantages are better performance and lower costs. What if you could offer a database that is a hybrid of the two; one that offers the advantages of both. This sounds too good to be true, but it is fact what ScaleDB has done.

The underlying architecture is shared-disk, but in many situations it can operate like shared-nothing. You see the problems with shared-disk arise from the messaging necessary to (a) ship data among nodes and storage; and (b) synchronize the nodes in the cluster. The trick is to move the messaging outside of the transaction so it doesn’t impact performance. The way to achieve that is to exploit locality. Let me explain.

When using a shared-disk database, if your application or load balancer just randomly sprays the database requests to any node in the cluster, all of the nodes end up sharing all of the data. This involves a lot of data shipping between nodes and messaging to keep track of which node has what data and what they have done to it. This is at the core of the challenge for companies like ours to build shared-disk databases…it ain’t easy. There are many things you can do to optimize performance in such a scenario like local caching, shared cache (we use CAS, Oracle uses CacheFusion), etc. However, the bottom line is that even with these optimizations, random distribution of database requests results in suboptimal database performance for some scenarios.

Once you have solved the worst case scenario of random database requests, you can start optimizing for the intelligent routing of database requests. By this I mean that either the application or the load balancer sends specific database requests to specific nodes in the cluster. Intelligent database request routing results in something we in the shared-database world call locality. The database nodes are able to operate on local data while only updating the rest of the cluster asynchronously. In this scenario, the database nodes, which are still using a shared-disk architecture, operate much more independently, like shared-nothing. As a result, data shipping and messaging are almost completely eliminated, resulting in performance comparable to shared-nothing, while still maintaining the advantages of shared-disk.

The trick is for the database to recognize on-the-fly when the separate nodes can and cannot operate in this independent fashion. This is complicated by the fact that the database must recognize and adapt to locality which can evolve as database usage changes, nodes are added or removed, etc. This is one aspect of the secret sauce that is built into ScaleDB.

Note: Now that we’ve built a shared-disk database that can recognize locality and respond by acting (and performing) like a shared-nothing database, how do we achieve locality? There are many ways to achieve locality. It can be built into the application, or you can rely on a SQL-aware routing/caching solution like those available from Netscaler and Scalarc that handle this for you.


PlanetMySQL Voting: Vote UP / Vote DOWN
 

Posted in cloud database, newsql, performance, scaledb, shared-disk, shared-nothing

Комментарии отключены

 
« Older Entries