I finally got some time to play around with the beta 7 release of NuoDB that I downloaded a few weeks ago. Personally I don’t think NuoDB yet gives downloaders enough information on how to get started so I decided to tackle that here myself.
Before I get into the details, why bother? Who will benefit from this beta?
IMHO, if you are working on developing a web-scale app that will require the supporting database to scale a lot, both out and in, then you should try this software. In working with the NuoDB team, I haven’t had any issues pushing my test up to 50 nodes. NuoDB has said that they will be offering even greater elastic scaling out/in in future releases. If they do, then this software is going to be the answer for many next-generation SQL apps.
Second, developers who need to migrate an existing app onto the cloud will also benefit from NuoDB. Let me state the fact that NuoDB is a cloud database that’s fully SQL compliant and offers the ACID guarantees we all have come to expect from a transactional database. I haven’t tried migrating a SQL application myself but I’ve heard from a couple of other beta users who have and they didn’t have issues. They indicated it was pretty easy. It really depends on how many vendor-specific SQL extensions you have used.
OK, now that you know you are, or aren’t, someone who could benefit, where to start?
NuoDB seems to be doing a new beta every 4-5 weeks before they release the product later this year; so it may be that beta 8 is due out shortly. Whatever the version, you can find the latest release here. You will need to fill out a short form but approval is automatic.
Installation is as simple as it gets. For Windows, you can download an EXE install. MacOS is a tarball. For Linux platforms, it is a rpm or deb file or a tarball. Make sure you have at least Java JRE 1.6 installed. Then add the <NuoDB>/bin directory to your system PATH.
The peer-to-peer, asynchronous nature of NuoDB lends itself to a configuration that is a little bit different from what you are used to with SQL Server or other “client/server” databases. You provision your system by defining a NuoDB domain – a group of servers that can host NuoDB engine processes (they also call these nodes!) – by running an instance of a Java process called “NuoAgent” on each host. At least one of these “agents” must be run in ”broker mode”. A broker is the initial connection point for any application client. It helps establish direct connections between the clients and Transaction Engines in the domain.
This brings me to the beauty of this database. NuoDB separates transaction processing from storage by defining two types of database engine processes – the Transaction Engine and the Storage Manager. If your app requires more throughput from the database, just add another Transaction Engine. If you want durability of your data, add another Storage Manager. Each Storage Manager maintains (and keeps in sync) an entire copy of your database.
A minimal system requires at least one NuoDB broker to define a domain. Start a broker like so:
$ java –jar nuoagent.jar –broker –domain mydomain –password domain_pwd
NuoDB has a nice management GUI called NuoDB Console. It lets you tap into NuoDB domains and start up (and manage) engine processes. A collection of these processes is called a “chorus”. Effectively, a chorus is a database.
Upon starting the Console for the first time, it will ask you which domain you want manage. In our example, that would be ‘mydomain’. Select the domain and then “add process”. Step through the wizard to define and start a Storage Manager. It is here that you will define a chorus (database) name. Run the wizard again to create a Transaction Engine in the same chorus. That’s it! You have a minimal database up and running.
Action Items:
- Download and try out NuoDB
- Leave a comment with your experiment
Reference: Pinal Dave (http://blog.sqlauthority.com)
Like this:
Like Loading...
Read Full Post »
