Comments
yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Expo on Google News

2008 West
DIAMOND SPONSOR:
Data Direct
SOA, WOA and Cloud Computing: The New Frontier for Data Services
PLATINUM SPONSORS:
Red Hat
The Opening of Virtualization
GOLD SPONSORS:
Appsense
User Environment Management – The Third Layer of the Desktop
Cordys
Cloud Computing for Business Agility
EMC
CMIS: A Multi-Vendor Proposal for a Service-Based Content Management Interoperability Standard
Freedom OSS
Practical SOA” Max Yankelevich
Intel
Architecting an Enterprise Service Router (ESR) – A Cost-Effective Way to Scale SOA Across the Enterprise
Sensedia
Return on Assests: Bringing Visibility to your SOA Strategy
Symantec
Managing Hybrid Endpoint Environments
VMWare
Game-Changing Technology for Enterprise Clouds and Applications
Click For 2008 West
Event Webcasts

2008 West
PLATINUM SPONSORS:
Appcelerator
Get ‘Rich’ Quick: Rapid Prototyping for RIA with ZERO Server Code
Keynote Systems
Designing for and Managing Performance in the New Frontier of Rich Internet Applications
GOLD SPONSORS:
ICEsoft
How Can AJAX Improve Homeland Security?
Isomorphic
Beyond Widgets: What a RIA Platform Should Offer
Oracle
REAs: Rich Enterprise Applications
Click For 2008 Event Webcasts
SYS-CON.TV
Top Links You Must Click On


Migrating Your Database to the Cloud? | @CloudExpo #API #Cloud
Companies are migrating infrastructure to the cloud in order to achieve advantages & agility they need to remain competitive

Migrating Your Database to the Cloud? Look Beyond MySQL

Companies are migrating infrastructure to the cloud in order to achieve advantages and agility that they need to remain competitive. However, they may have difficulty achieving one extremely important benefit of cloud computing as they attempt to run their MySQL databases in the cloud - scalability in true utility fashion. Similar to the power utilities we are all familiar with, this entails the ability to get what you need, when you need it and pay for only what you use, even during peak demand.

Why switch to the cloud if databases like MySQL limit scalability and performance? It's very simple: the advantages of shedding the headaches of managing one's own machines and reducing operating and capital expenditures are still too great to ignore. However, organizations are in many cases shortchanging themselves by focusing narrowly on these financial and operational benefits, not realizing that the right cloud database will dramatically increase flexibility and agility.

People far too often assume that "going to the cloud" is synonymous with "having the ability to migrate to a scale-out database." In reality, one does not necessarily follow the other. Adding more confusion, many companies are migrating to the cloud to use Aurora, which provides marginally more write/read scale than RDS MySQL, but still imposes a write performance ceiling.

This lack of ability to achieve true utility will be particularly acute for applications with OLTP (online transaction processing) workloads that are both high in volume and need to maintain data integrity through ACID compliance. These characteristics are shared by most applications that serve e-commerce, ad tech, gaming, social and IoT functions, and the inability of MySQL to meet their demands in utility fashion is largely attributed to one fact: it is architected for "single node" deployment.

The single-node conundrum: when "cloud" doesn't equate to "scale out"
MySQL databases are often the initial solution of choice for OLTP applications because of their ability to maintain ACID compliance. Though MySQL databases are commonly deployed in the cloud, they also run on a single server, and don't allow you to "scale out" by adding server nodes like most cloud applications. Eventually, this lack of ability to scale by adding nodes means that organizations running MySQL in the cloud will be hamstrung by the same performance problems that existed before they made the migration from the data center.

Scaling comes in many flavors, and some taste pretty bad
If the company in question is an e-commerce provider, for example, it is likely to experience dramatic seasonal changes in demands on the database that coincide with major shopping holidays, which requires flexibility. If the company is a rising star in a data-intensive industry like digital healthcare, it may find that its need for rapid scaling of capacity is the most important consideration.

If they're using a single-node solution like MySQL or Aurora, a primary method of increasing capacity, once they've scaled to the upper limit of the server they're using, will be to "scale up" by moving the database to a more powerful server. This method - which is neither rapid, nor flexible - will set you back a ridiculous amount of money for large, expensive hardware that can achieve the maximum level of performance that might be required. Inevitably, this capacity will lie unacceptably dormant for some period of time, which means you will be stuck paying for unused capacity for off-peak traffic periods (i.e., most of the time). This is an unnecessary waste of money and resources, one that the cloud is supposed to help companies circumnavigate.

For many companies, this is only the start of the problems associated with scaling their database. Even the largest server will impose a capacity ceiling, and once that is reached, they often resort to alternate methods for scaling performance, such as creating additional read slaves, master/master configurations and then finally sharding. These, however, are problematic - they either:

  • Don't add write scale (read slaves)
  • Have conflict management issues (master/master)
  • Don't provide ACID transactional guarantees (sharding)

In short, in seeking to extend write scale beyond the limits of MySQL on the largest available server, painstaking programming and a highly undesirable level of complexity and fragility are often added to the application. Instead of a streamlined application, you wind up with a makeshift patchwork that requires a lot of effort to keep afloat.

Of the three scaling techniques mentioned, read (only) slaves are the most common technique for scaling out capacity once the upward limit of a single-node implementation has been reached. In fact, Amazon RDS provides 15 "read replicas" very simply via their AWS Console. However, as Marc Staimer of Dragonslayer Consulting pointed out in "Why Traditional SQL Databases Fail to Scale Effectively," while read-only slaves require nominal setup and maintenance, they "cannot overcome the bottleneck of the master SQL database, especially for write-intensive applications." Which brings us to a consideration that is of paramount importance - the ability to scale in both reads and writes.

Scaling reads isn't enough, but sharding isn't the answer
Scaling along the read axis can be helpful, but services that handle OLTP loads will eventually hit a wall if writes cannot be scaled in addition to reads. There is no shortage of services out there, like Amazon's Aurora, that do a good job scaling reads in the cloud, but don't scale writes without building complicated and expensive solutions (giving you the "patchwork" application described above).

Many cloud providers, including AWS Aurora, do not support sharding, a method commonly used to yield scalability in both reads and writes. And, even when sharding is supported, it is difficult, costly to implement and fragile while in use. It can be problematic with workloads that require full data integrity, due to the difficulty of maintaining ACID compliance without making comprehensive changes to the application layer (once again leading to undesirable complexity and fragility). Ultimately, those who employ this method wind up exchanging one set of problems for another potentially more serious set.

Suffice it to say, most companies moving to the cloud do not anticipate having to resort to sharding, yet many will find themselves in that exact predicament due to ever-increasing transactional demands. These kinds of barriers are exactly the ones that companies aim to overcome when they set out with a cloud database migration project.

OLTP cloud database needs scale-out performance with ACID compliance
Many companies don't realize that their most common database hiccups often stem from their efforts to jerry-rig them to do things they weren't designed to do, not because the databases themselves are fundamentally inferior. MySQL wasn't designed to scale out (horizontally), and rather than performing unnatural feats in order to make it do so, organizations should instead look to solutions that are architected for this type of scaling.

The NewSQL era has made it possible to scale out by adding nodes, while maintaining linear performance. And, for companies with transactional applications - such as those in e-commerce, gaming, social, IoT and ad tech - they will be able to maintain ACID compliance the whole time.

There may be initial advantages to platforms like MySQL for small operations, but IT decision-makers should have their eyes on the exit route if their companies project any kind of serious growth. Playing catch-up with databases is nobody's idea of a good time, and is an untenable business practice when an organization's applications rely on OLTP. A database that can massively scale horizontally to increase or decrease capacity according to dramatic seasonal swings in traffic, or scale to very large total capacities, may not be deemed necessary by a fledgling service or company with fairly nominal requirements. However, if a company sees rapid success in the near future, such capabilities are likely to become a necessity - and what management team is worth their salt if they don't plan for success?

Many are in fact acknowledging that moving up from MySQL and its kin to the next tier of database is a necessary stage to prevent slowdowns and failures for businesses with high-growth services. This new reality is certainly evidenced in the popularity of Aurora. But again, companies must keep in mind that Aurora, despite its improvements over MySQL, is a single node with old school scale techniques solution, and thus presents limitations. The best way database companies can serve these kinds of organizations is to offer a drop-in replacement for MySQL that delivers the linear scalability that enables you to fully leverage the flexibility of the cloud.

About Mike Azevedo
Mike Azevedo is CEO of Clustrix, provider of the first scale-out relational database designed to meet the needs of large, fast-growing e-commerce sites and other big Web- and cloud-based applications. He has more than 25 years of experience in scale-out analytic applications, grid computing, storage infrastructure, security, and retail, and has led top sales divisions at Platform Computing, ParAccel and PostX Corporation.

Mike holds a Bachelor of Science degree in business administration/ management from Chico State University

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

Enterprise Open Source Magazine Latest Stories . . .
Learn how to solve the problem of keeping files in sync between multiple Docker containers. In his session at 16th Cloud Expo, Aaron Brongersma, Senior Infrastructure Engineer at Modulus, discussed using rsync, GlusterFS, EBS and Bit Torrent Sync. He broke down the tools that are need...
Kubernetes is a new and revolutionary open-sourced system for managing containers across multiple hosts in a cluster. Ansible is a simple IT automation tool for just about any requirement for reproducible environments. In his session at @DevOpsSummit at 18th Cloud Expo, Patrick Galbrai...
It is ironic, but perhaps not unexpected, that many organizations who want the benefits of using an Agile approach to deliver software use a waterfall approach to adopting Agile practices: they form plans, they set milestones, and they measure progress by how many teams they have engag...
For better or worse, DevOps has gone mainstream. All doubt was removed when IBM and HP threw up their respective DevOps microsites. Where are we on the hype cycle? It's hard to say for sure but there's a feeling we're heading for the "Peak of Inflated Expectations." What does this mean...
Widespread fragmentation is stalling the growth of the IIoT and making it difficult for partners to work together. The number of software platforms, apps, hardware and connectivity standards is creating paralysis among businesses that are afraid of being locked into a solution. EdgeX...
DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one lo...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)sys-con.com!

Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021




SYS-CON Featured Whitepapers
ADS BY GOOGLE