Posts by NuoDB TechE

NoSQL's CAP theorem busters: We don't drop ACID

Why not scale like NoSQL without giving up SQL.

NuoDB which is about to go GA any day now is already 100% SQL, 100% ACID, and 100% elastically scalable. Don't believe me? Download it for yourself at www.nuodb.com.

- w

SQL database start-up flings out code peanuts to tempt biz

Re: NuoDB is not just for the cloud

Aaron,

Thanks for the question.

I have personally worked for companies that used MySQL as their OLTP database that was replicated for reporting and warehousing, so I have some background with the scenario you describe.

Using your example, here is why you should use NuoDB:

1. Highly available

2. No need to replicate

3. No need to shard

4. Redundancy is built in

5. Super easy administration

To truly appreciate how NuoDB accomplishes this you have to look at the architecture. When you download and install NuoDB the first thing you have to establish is a NuoDB Domain. A Domain is simply a collection of host machines that you want to run NuoDB on. At any time, you can add a machine to the Domain by running a NuoDB Agent process, or you can remove a machine by shutting down a NuoDB Agent. An Agent is a tiny process that you run on a host to participate in a NuoDB Domain. At least one of these Agents needs to run in Broker mode. You can have multiple Brokers to eliminate a single point of failure. Brokers act as global agents to keep track of the network topology and orchestrate client requests to the most available NuoDB processes.

Next you can provision NuoDB Transaction Engines (TE) on one or more machine within a Domain. A TE is just an in-memory process responsible for caching your data and executing SQL. TEs have the ability to talk to each other asynchronously and can request data from each other. (This is a whole other conversation).

Finally you can also provision one or more NuoDB Storage Managers (SM) to make you data durable. SMs can persist your data currently on the File System, Amazon S3, or HDFS. The plan in the future is to make it an arbitrary key value store. You should run at least two SMs to make your data redundant. SM also communicate with each other asynchronously.

If you are looking for more performance, simply add another TE and you will instantly get more performance. If you have idle TEs and want to reallocate your hardware to some other process, no problem, simply shutdown the NuoDB processes and you can reuse the hardware for something else.

With NuoDB everything fails independently. If you have two datacenters, an entire datacenter can go down and your database will still be running.

Hope that helps.

Wiqar Chaudry

NuoDB Tech Evangelist

Re: "elastic" database?

Great question.

Elastic means that certain portions of the database can be brought online or offline depending on demand. It also means that if you distribute your database across two different datacenters, one of the the two datacenters can fail completely without bringing down your database. All provisioning or shutting down of database resources is done through a single web console.

NuoDB is not just for the cloud

My name is Wiqar Chaudry and I am the Technology Evangelist for NuoDB. Thanks for your feedback on this article. Your opinion and comments are welcomed and respected.

NuoDB is not JUST for the cloud. NuoDB can be deployed in a heterogeneous environment. In fact, you can provision a single database and have some portion of its processes running in the cloud and other processes running in a local datacenter. Its also available at no cost. You can download a copy to try it for yourself at www.nuodb.com.