5 Steps for Migrating Relational Databases to Next-Gen Architectures

Editor's Notes

• #3: My name is… I’m joined by Tim Tadeo, a Solutions Architect with NuoDB. I’ll start by introducing the Elastic SQL database and why and how you should be thinking differently about databases as you move to a modern architecture. Tim will then do a live demonstration showing how to evaluate key aspects of an Elastic SQL database. I’ll wrap up with a pointer to resources available for you to conduct your own evaluation. At the end of the presentation we’ll be taking live questions from the audience. At any time during the webinar you can enter your questions using the Question box on the right side of your screen and we’ll address them at the end. We are also recording today’s webinar and will share the replay link with you should you wish to revisit it or share it with your colleagues. With that, let’s get started by exploring the database landscape
• #37: NuoDB has been built from the ground up to be an operational database that scales-out for cloud deployments. NuoDB appears as a single, logical, SQL database to the application, allowing developers to focus on building great applications, versus dealing with scale-out complexities. Under the hood, NuoDB has a peer-to-peer, two-layer, distributed architecture that can be deployed across multiple data centers and is optimized for in-memory speeds, continuous availability, and elastic scale-out. The transaction layer  consists of in-memory process nodes called transaction engines (TE). Transaction engines handle requests from applications, cache data for fast access, and coordinate transactions with other process nodes in both the transaction and storage layers. As an application makes requests of NuoDB, the transaction engines will naturally build in-memory caches with affinity for that application’s data, allowing NuoDB to maintain high performance.   The storage layer consists of process nodes called storage managers (SM). The storage manager ensures durability of data by writing it to disk, manages data on disk, handles requests from transaction engines (TEs), and sends asynchronous messages to other SMs to commit data to disk and to maintain copies of data in memory. These process nodes provide ACID-guarantees, data redundancy, and data persistence.   Within both layers, NuoDB can elastically scale out (and back) without any interruption to application service, simply by adding and removing TEs and SMs. This means developers can design applications to access a single logical database and not worry about handling scale out complexity related to dynamic operational workloads.  Database operators can scale out the database to accommodate dynamic workloads and not worry about adverse consequences to the application. The result is that developers and operations can focus on truly maximizing performance of both the application and the database.
• #40: If you’d like to learn more about NuoDB and try it for yourself, you can check out our recorded demo, or download our community edition or evaluation guide from our website. At this point we’ll move into Q&A…