Welcome!

Big Data Journal Authors: Roger Strukhoff, Elizabeth White, Trevor Parsons, Andreas Grabner, Pat Romanski

Related Topics: Cloud Expo, Java, SOA & WOA, Virtualization, Big Data Journal, SDN Journal

Cloud Expo: Article

Can We Finally Find the Database Holy Grail? | Part 3

With the advent of Durable Distributed Cache architectures organizations can build global systems with transactional semantics

In my first post in this three part series I talked about the need for distributed transactional databases that scale-out horizontally across commodity machines, as compared to traditional transactional databases that employ a "scale-up" design.  Simply adding more machines is a quicker, cheaper and more flexible way of increasing database capacity than forklift upgrades to giant steam-belching servers. It also brings the promise of continuous availability and of geo-distributed operation.

The second post in this series provided an overview of the three historical approaches to designing distributed transactional database systems, namely: 1. Shared Disk Designs (e.g., ORACLE RAC); 2. Shared Nothing Designs (e.g. the Facebook MySQL implementation); and 3) Synchronous Commit Designs (e.g. GOOGLE F1).  All of them have some advantages over traditional client-server database systems, but they each have serious limitations in relation to cost, complexity, dependencies on specialized infrastructure, and workload-specific performance trade-offs. I noted that we are very excited about a recent innovation in distributed database design, introduced by NuoDB's technical founder Jim Starkey.  We call the concept Durable Distributed Cache (DDC), and I want to spend a little time in this third and final post talking about what it is, with a high-level overview of how it works.

Memory-Centric vs. Storage-Centric
The first insight Jim had was that all general-purpose relational databases to-date have been architected around a storage-centric assumption, and that this is a fundamental problem when it comes to scaling out.  In effect, database systems have been fancy file systems that arrange for concurrent read/write access to disk-based files such that users do not trample on each other.  The Durable Distributed Cache architecture inverts that idea, imagining the database as a set of in-memory container objects that can overflow to disk if necessary, and can be retained in backing stores for durability purposes.  Memory-Centric vs. Storage-Centric may sound like splitting hairs, but it turns out that it is really significant.  The reasons are best described by example.

Suppose you have a single, logical DDC database running on 50 servers (which is absolutely feasible to do with an ACID transactional DDC-based database).  And suppose that at some moment server 23 needs object #17.  In this case, server 23 might determine that object #17 is instantiated in memory on seven other servers.  It simply requests the object from the most responsive server.  Note that as the object was in memory, the operation involved no disk IO - it was a remote memory fetch, which is orders of magnitude faster than going to disk.

You might ask about the case in which object #17 does not exist in memory elsewhere.  In the Durable Distributed Cache architecture this is handled by certain servers "faking" that they have all the objects in memory.  In practice, of course, they are maintaining backing stores on disk, SSD or whatever they choose (in the NuoDB implementation they can use arbitrary Key/Value stores such as Amazon S3 or Hadoop HDFS).  As it relates to supplying objects, these "backing store servers" behave exactly like the other servers except they can't guarantee the same response times.

So all servers in the DDC architecture can request objects and supply objects.  They are peers in that sense (and in all other senses).  Some servers have a subset of the objects at any given time, and can therefore only supply a subset of the database to other servers.  Other servers have all the objects and can supply any of them, but will be slower to supply objects that are not resident in memory.

Let's call the servers with a subset of the objects Transaction Engines (TEs), and the other servers Storage Managers (SMs).  TEs are pure in memory servers that do not need to use disks.  They are autonomous and can unilaterally load and eject objects from memory according to their needs.  Unlike TEs, SMs can't just drop objects on the floor when they are finished with them; instead they must ensure they are safely placed in durable storage.

For readers familiar with caching architectures, you might have already recognized that these TEs are in effect a distributed DRAM cache, and the SMs are specialized TEs that ensure durability.  Hence the name Durable Distributed Cache.

Resilience to Failure
It turns out that any object state that is present on a TE is either already committed to the disk (i.e. safe on one or more SMs) or part of an uncommitted transaction that will simply fail at application level if the object goes away. This means that the database has the interesting property of being resilient to the loss of TEs.  You can shut a TE down or just unplug it and the system does not lose data.  It will lose throughput capacity of course, and any partial transactions on the TE will be reported to the application as failed transactions.  But transactional applications are designed to handle transaction failure. If you reissue the transaction at the application level it will be assigned to a different TE and will proceed to completion.  So the DDC architecture is resilient to the loss of TEs.

What about SMs?  Recall that you can have as many SMs as you like.  They are effectively just TEs that secretly stash away the objects in some durable store.  And, unless you configure it not to, each SM might as well store all the objects. Disks are cheap, which means that you have as many redundant copies of the whole database as you want.  In consequence, the DDC architecture is not only resilient to the loss of TEs, but also to the loss of SMs.

In fact, as long as you have at least one TE and one SM running, you still have a running database.  Resilience to failure is one of the longstanding but unfulfilled promises of distributed transactional databases.  The DDC architecture addresses this directly.

Elastic Scale-out and Scale-in
What happens if I add a server to a DDC database?  Think of the TE layer as a cache.  If the new TE is given work to do, it will start asking for objects and doing the assigned work.  It will also start serving objects to other TEs that need them.  In fact, the new TE is a true peer of the other TEs.  Furthermore, if you were to shut down all of the other TEs, the database would still be running, and the new TE would be the only server doing transactional work.

SMs, being specialized TEs, can also be added and shut down dynamically.  If you add an "empty" (or stale) SM to a running database, it will cycle through the list of objects and load them into its durable store, fetching them from the most responsive place as is usual.  Once it has all the objects, it will raise its hand and take part as a peer to the other SMs.  And, just as with the new TE described above, you can delete all other SMs once you have added the new SM.  The system will keep running without missing a beat or losing any data.

So the bottom line is that the DDC architecture delivers capacity on demand.  You can elastically scale-out the number of TEs and SMs and scale them back in again according to workload requirements.  Capacity on demand is a second promise of distributed databases that is delivered by the DDC architecture.

Geo-Distribution
The astute reader will no doubt be wondering about the hardest part of this distributed database problem -- namely that we are talking about distributed transactional databases.  Transactions, specifically ACID transactions, are an enormously simplifying abstraction that allows application programmers to build their applications with very clean, high-level and well-defined data guarantees.  If I store my data in an ACID transactional database, I know it will isolate my program from other programs, maintain data consistency, avoid partial failure of state changes and guarantee that stored data will still be there at a later date, irrespective of external factors.  Application programs are vastly simpler when they can trust an ACID compliant database to look after their data, whatever the weather.

The DDC architecture adopts a model of append-only updates.  Traditionally, an update to a record in a database overwrites that record, and a deletion of a record removes the record.  That may sound obvious, but there is another way, invented by Jim Starkey about 25 years ago.  The idea is to create and maintain versions of everything.  In this model, you never do a destructive update or destructive delete.  You only ever create new versions of records, and in the case of a delete, the new version is a record version that notes the record is no longer extant.  This model is called MVCC (multi-version concurrency control), and it has a number of well-known benefits, even in scale-up databases.  MVCC has even greater benefits in distributed database architectures, including DDC.

We don't have the space here to cover MVCC in detail, but it is worth noting that one of the things it does is to allow a DBMS to manage read/write concurrency without the use of traditional locks.  For example, readers don't block writers and writers do not block readers.  It also has some exotic features, including that if you wanted to you could theoretically maintain a full history of the entire database.  But as it relates to DDC and the Distributed Transactional Database challenge, there is something very neat about MVCC.  DDC leverages a distributed variety of MVCC in concert with DDC's distributed object semantics that allows almost all the inter-server communications to be asynchronous.

The implications of DDC being asynchronous are very far-reaching.  In general, it allows much higher utilization of system resources (cores, networks, disks, etc.) than synchronous models can.  But specifically, it allows the system to be fairly insensitive to network latencies, and to the location of the servers relative to each other.  Or to put it a different way, it means you can start up your next TE or SM in a remote datacenter and connect it to the running database.  Or you can start up half of the database servers in your datacenter and the other half on a public cloud.

Modern applications are distributed.  Users of a particular web site are usually spread across the globe.  Mobile applications are geo-distributed by nature.  Internet of Things (IoT) applications are connecting gazillions of consumer devices that could be anywhere at any time.  None of these applications are well served by a single big database server in a single location, or even a cluster of smaller database servers in a single location.  What they need is a single database running on a group of database servers in multiple datacenters (or cloud regions).  That can give them higher performance, datacenter failover and the potential to manage issues of data privacy and sovereignty.

The third historical promise of Distributed Transactional Database systems is Geo-Distribution.  Along with the other major promises (Resilience to Failure and Elastic Scalability), Geo-Distribution has heretofore been an unattainable dream.  The DDC architecture, with its memory-centric distributed object model and its asynchronous inter-server protocols, finally delivers on this capability.

In Summary
This short series of posts has sought to provide a quick overview of distributed database designs, with some high level commentary on the advantages and disadvantages of the various approaches.  There has been great historical success with Shared Disk, Shared Nothing and Synchronous Commit models.  We see the advanced technology companies delivering some of the most scalable systems in the world using these distributed database technologies.  But to date, distributed databases have never really delivered anything close to their full promise.  They have also been inaccessible to people and organizations that lack the development and financial resources of GOOGLE or Facebook.

With the advent of DDC architectures, it is now possible for any organization to build global systems with transactional semantics, on-demand capacity and the ability to run for 10 years without missing a beat.  The big promises of Distributed Transactional Databases are Elastic Scalability and Geo-Distribution.  We're very excited that due to Jim Starkey's Durable Distributed Cache, those capabilities are finally being delivered to the industry.

More Stories By Barry Morris

Barry Morris is CEO & Co-Founder of NuoDB, Inc. An accomplished software CEO with over 25 years of industry experience in the USA and Europe, running private and public companies ranging in scale from early startup phase to 1,000+ employees, he loves to build companies around industry-changing paradigm-shifts in technology. Morris was previously CEO of StreamBase and Iona Technologies.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Cloud Expo Breaking News
File sync and share. Endpoint protection. Both are massive opportunities for today’s enterprise thanks to their business benefits and widespread user appeal. But one size does not fit all, especially user-adopted consumer technologies. Organizations must apply the right enterprise-ready tool for the job in order to properly manage and protect endpoint data. In his session at 14th Cloud Expo, Michael Bachman, Senior Enterprise Systems Architect at Code42, he will discuss how the synergy of an enterprise platform – where sync/share and endpoint protection converge – delivers incredible value for the business.
Simply defined the SDDC promises that you’ll be able to treat “all” of your IT infrastructure as if it’s completely malleable. That there are no restrictions to how you can use and assign everything from border controls to VM size as long as you stay within the technical capabilities of the devices. The promise is great, but the reality is still a dream for the majority of enterprises. In his session at 14th Cloud Expo, Mark Thiele, EVP, Data Center Tech, at SUPERNAP, will cover where and how a business might benefit from SDDC and also why they should or shouldn’t attempt to adopt today.
Today, developers and business units are leading the charge to cloud computing. The primary driver: faster access to computing resources by using the cloud's automated infrastructure provisioning. However, fast access to infrastructure exposes the next friction point: creating, delivering, and operating applications much faster. In his session at 14th Cloud Expo, Bernard Golden, VP of Strategy at ActiveState, will discuss why solving the next friction point is critical for true cloud computing success and how developers and business units can leverage service catalogs, frameworks, and DevOps to achieve the true goal of IT: delivering increased business value through applications.
APIs came about to help companies create and manage their digital ecosystem, enabling them not only to reach more customers through more devices, but also create a large supporting ecosystem of developers and partners. While Facebook, Twitter and Netflix were the early adopters of APIs, large enterprises have been quick to embrace the concept of APIs and have been leveraging APIs as a connective tissue that powers all interactions between their customers, partners and employees. As enterprises embrace APIs, some very specific Enterprise API Adoption patterns and best practices have started emerging. In his session at 14th Cloud Expo, Sachin Agarwal, VP of Product Marketing and Strategy at SOA Software, will talk about the most common enterprise API patterns and will discuss how enterprises can successfully launch an API program.
MapDB is an Apache-licensed open source database specifically designed for Java developers. The library uses the standard Java Collections API, making it totally natural for Java developers to use and adopt, while scaling database size from GBs to TBs. MapDB is very fast and supports an agile approach to data, allowing developers to construct flexible schemas to exactly match application needs and tune performance, durability and caching for specific requirements.
The social media expansion has shown just how people are eager to share their experiences with the rest of the world. Cloud technology is the perfect platform to satisfy this need given its great flexibility and readiness. At Cynny, we aim to revolutionize how people share and organize their digital life through a brand new cloud service, starting from infrastructure to the users’ interface. A revolution that began from inventing and designing our very own infrastructure: we have created the first server network powered solely by ARM CPU. The microservers have “organism-like” features, differentiating them from any of the current technologies. Benefits include low consumption of energy, making Cynny the ecologically friendly alternative for storage as well as cheaper infrastructure, lower running costs, etc.
Next-Gen Cloud. Whatever you call it, there’s a higher calling for cloud computing that requires providers to change their spots and move from a commodity mindset to a premium one. Businesses can no longer maintain the status quo that today’s service providers offer. Yes, the continuity, speed, mobility, data access and connectivity are staples of the cloud and always will be. But cloud providers that plan to not only exist tomorrow – but to lead – know that security must be the top priority for the cloud and are delivering it now. In his session at 14th Cloud Expo, Kurt Hagerman, Chief Information Security Officer at FireHost, will detail why and how you can have both infrastructure performance and enterprise-grade security – and what tomorrow's cloud provider will look like.
Web conferencing in a public cloud has the same risks as any other cloud service. If you have ever had concerns over the types of data being shared in your employees’ web conferences, such as IP, financials or customer data, then it’s time to look at web conferencing in a private cloud. In her session at 14th Cloud Expo, Courtney Behrens, Senior Marketing Manager at Brother International, will discuss how issues that had previously been out of your control, like performance, advanced administration and compliance, can now be put back behind your firewall.
More and more enterprises today are doing business by opening up their data and applications through APIs. Though forward-thinking and strategic, exposing APIs also increases the surface area for potential attack by hackers. To benefit from APIs while staying secure, enterprises and security architects need to continue to develop a deep understanding about API security and how it differs from traditional web application security or mobile application security. In his session at 14th Cloud Expo, Sachin Agarwal, VP of Product Marketing and Strategy at SOA Software, will walk you through the various aspects of how an API could be potentially exploited. He will discuss the necessary best practices to secure your data and enterprise applications while continue continuing to support your business’s digital initiatives.
The revolution that happened in the server universe over the past 15 years has resulted in an eco-system that is more open, more democratically innovative and produced better results in technically challenging dimensions like scale. The underpinnings of the revolution were common hardware, standards based APIs (ex. POSIX) and a strict adherence to layering and isolation between applications, daemons and kernel drivers/modules which allowed multiple types of development happen in parallel without hindering others. Put simply, today's server model is built on a consistent x86 platform with few surprises in its core components. A kernel abstracts away the platform, so that applications and daemons are decoupled from the hardware. In contrast, networking equipment is still stuck in the mainframe era. Today, networking equipment is a single appliance, including hardware, OS, applications and user interface come as a monolithic entity from a single vendor. Switching between different vendor'...
Cloud backup and recovery services are critical to safeguarding an organization’s data and ensuring business continuity when technical failures and outages occur. With so many choices, how do you find the right provider for your specific needs? In his session at 14th Cloud Expo, Daniel Jacobson, Technology Manager at BUMI, will outline the key factors including backup configurations, proactive monitoring, data restoration, disaster recovery drills, security, compliance and data center resources. Aside from the technical considerations, the secret sauce in identifying the best vendor is the level of focus, expertise and specialization of their engineering team and support group, and how they monitor your day-to-day backups, provide recommendations, and guide you through restores when necessary.
Cloud scalability and performance should be at the heart of every successful Internet venture. The infrastructure needs to be resilient, flexible, and fast – it’s best not to get caught thinking about architecture until the middle of an emergency, when it's too late. In his interactive, no-holds-barred session at 14th Cloud Expo, Phil Jackson, Development Community Advocate for SoftLayer, will dive into how to design and build-out the right cloud infrastructure.
You use an agile process; your goal is to make your organization more agile. What about your data infrastructure? The truth is, today’s databases are anything but agile – they are effectively static repositories that are cumbersome to work with, difficult to change, and cannot keep pace with application demands. Performance suffers as a result, and it takes far longer than it should to deliver on new features and capabilities needed to make your organization competitive. As your application and business needs change, data repositories and structures get outmoded rapidly, resulting in increased work for application developers and slow performance for end users. Further, as data sizes grow into the Big Data realm, this problem is exacerbated and becomes even more difficult to address. A seemingly simple schema change can take hours (or more) to perform, and as requirements evolve the disconnect between existing data structures and actual needs diverge.
SYS-CON Events announced today that SherWeb, a long-time leading provider of cloud services and Microsoft's 2013 World Hosting Partner of the Year, will exhibit at SYS-CON's 14th International Cloud Expo®, which will take place on June 10–12, 2014, at the Javits Center in New York City, New York. A worldwide hosted services leader ranking in the prestigious North American Deloitte Technology Fast 500TM, and Microsoft's 2013 World Hosting Partner of the Year, SherWeb provides competitive cloud solutions to businesses and partners around the world. Founded in 1998, SherWeb is a privately owned company headquartered in Quebec, Canada. Its service portfolio includes Microsoft Exchange, SharePoint, Lync, Dynamics CRM and more.
The world of cloud and application development is not just for the hardened developer these days. In their session at 14th Cloud Expo, Phil Jackson, Development Community Advocate for SoftLayer, and Harold Hannon, Sr. Software Architect at SoftLayer, will pull back the curtain of the architecture of a fun demo application purpose-built for the cloud. They will focus on demonstrating how they leveraged compute, storage, messaging, and other cloud elements hosted at SoftLayer to lower the effort and difficulty of putting together a useful application. This will be an active demonstration and review of simple command-line tools and resources, so don’t be afraid if you are not a seasoned developer.