4 posts • joined Monday 26th November 2012 15:59 GMT
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.
Re: NuoDB is not just for the cloud
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.
NuoDB Tech Evangelist
Re: "elastic" database?
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.
- It's true, the START MENU is coming BACK to Windows 8, hiss sources
- iSPY: Apple Stores switch on iBeacon phone sniff spy system
- Pic NASA Mars tank Curiosity rolls on old WET PATCH, sighs, sniffs for life signs
- How UK air traffic control system was caught asleep on the job
- Google embiggens its fat vid pipe Chromecast with TEN new supported apps