You are here

Welcome to the NuoDB Blog

  • From time to time, I get down deep inside the NuoSQL compiler and give it a good hard shake. That's generally good for the compiler, but it can make comparing the new compiler to the old compiler's results an exercise in wading through a sea of small differences, some consequential, some not. Computers are much better at that than I am, so I would like to use a diff tool that's extremely configurable. PHP has array-udiff, and Python has difflib, but I wanted a tool written in Java, and I also wanted to learn more about how diff works. I develop dynamic programming algorithms building

  • In our latest patch, v2.0.2, the focus remained on fortifying our 2.0 release. In this short development cycle there were nearly 100 feature improvements and fixes. I'll call out a few of them here, but leave it to you to go download this latest release and see for yourself.

    For starters, I should note that 2.0.2 continued with the optimization of our deployment for geo-distributed environments. A significant mention here is the progress made on defense, adding greater resilience to both network errors and high-latency network links.

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

    In my first post of 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

  • A truly distributed DBMS with ACID transactional guarantees could address the key pain points in modern database management.

    In Part One of this three part series, I talked about distributed transactional databases being the Holy Grail of database systems. Among other things, the promise of such systems is to provide on-demand capacity, continuous availability and geographically distributed operation. But the historical approaches to building distributed transactional databases

  • Recently, Dan wrote a great piece on testing network failures with NuoDB's support for geo-distribution. If you haven't read it, then go do that right now. It's cool, and it illustrates pretty clearly how you can tune the rules for durability based on awareness of regions .

    We've made our tools region-aware: you can define where your database is running and what the criteria are for acknowledging commit back to a client. So in Dan's test, he simulated a network partition that

  • This 3-part blog series was originally featured in Cloud Computing Journal . Here’s part 1 by NuoDB CEO Barry Morris.

    The world runs on transactional database systems. Every business depends on them, and we each interact with them many times each day. Furthermore, the world needs to build thousands more applications of transactional database systems to support the next-generation web. Nothing controversial there, but there is a problem: transactional

  • In NuoDB 2.0.1, a region is a property that represents a geographic location for the database. Such locations might include a data center in a major city, country, or building location . A single NuoDB database can have multiple distinct regions. In addition to representing a location, regions can also be used to enforce database

  • When we dropped our 2.0 release back in October it was done with some fanfare . I mean, you know, two-dot-oh. Exciting! On Thursday, when we updated to 2.0.1, we kept it a little more on the down low. While a point-release like this may not seem sexy, it brings with it a couple of pretty cool things we do want to talk about.

    One of those things is stability and correctness in the face of network partition. I've recently written some thoughts about trade-offs in distributed computing and how to

  • Hello, blog readers. Some of you may know that Kyle Kingsbury of jepsen fame turned the baleful eye of his test framework against NuoDB 1.2. Specifically, the jepsen test attempts to quantify how a system with durability guarantees behaves in the presence of short-lived network partitions. Unfortunately, the jepsen tests ran into node instability issues while testing was underway. Since the big push for 2.0.x is for good multiple-datacenter support, we have been looking at this stuff pretty closely (in between all the other stuff we're working

  • Greetings loyal readers! In our previous post , we talked about the Jepsen tester and about the various improvements we made to it. In this post, I'm going to walk through a Jepsen run made with the code from our github fork, explain the test setup and then go through the output explaining the behavior that Jepsen is producing in NuoDB.

    Test Setup

    This test, and many other runs of Jepsen, were done against 6 ubuntu machines. These are actual machines, rather

Pages