In my previous post I briefly mentioned Database Appliance with Project Indiana. Now that Sun has acquired MySQL (or as some people say MySQL has acquired Sun) and with our existing work in progress with PostgreSQL, there are quite a bit of options available of using some combination of Storage, System, Operating System, Database along with some end user application and present it as either Database Appliance or use it as Embedded Database.
I thought I will just discuss the audience, symptoms, merits, cons etc regarding the two approach and how they can be useful.
The first question is who likes database appliances and who wants embedded database? To answer that I would put the question back: What do you in hand? A hammer or a screw-driver? Because if you have a hammer, the whole world is a nail to you and if you have a screw driver the whole world is full of screws. Similarly if you love databases (DBA) and you want to query everything via a SQL statement then database appliances are for you. If you dont like to interact with databases (System Administrator, Application User) then you essentially want an embedded database where the OS or your end application takes care of interacting with the database. Well that is quite simple.
First lets talk about database appliance. Think of it as your existing wireless routers. You bring it in house, plug it into your network (essentially to your cable modem) and power it on. Connect your laptop to one of the LAN ports, run DHCP, fire up a browser and go to typically htp://192.168.1.1 and lo and behold you get a website to login and administer your router. A typical database appliance in some way will behave similarly. It has a web-based administrator to set it up quickly and allow you to connect to the database via rest of your applications on the network. In fact all the pieces are already out there: Storage, Server, Operating System, Database and even a web based management tool like webconsole (to configure ZFS) and Webmin which even supports mysql. This help reduce the knowledge of underpinning Operating System that you trust to "just work". Once setup, your applications just connect through your applications talking to client/server setup of a normal database. While the appliance takes care of snapshots, backups, clones via the web-based tool. Can a database be easier than that? That's the values that a database appliance brings to the table. Its DBA's dream to not go through a System Administrator to allocate the OS resources for the database. It abstracts the resilient operating system underneath it and makes it easier for the DBA to quickly deploy it in actual usage.
What about Embedded Databases? In some ways it is anti-database appliance. Other way to look at it is abstraction of the database functions itself via end application Functions which interacts with the database. The application can be either Operating System or the end application. One of the analogy that can be used here is an integrated database in the operating system which is controlled via services of the operating system. For example if you use "svcadm enable postgres:version_82" on Solaris, a PostgreSQL 8.2 instance is enabled for you in the background. Which means you are ready to use it with no idea on where it is or what it is (except from the svcadm name). That's an analogy of embedded database. Many applications infact create their own menu items to backup application which includes the database underneath it and so on. If things are setup right, then you dont even have to execute any dedicated PostgreSQL commands to stop/start, backup etc and everything is done using application like svcadm, zfs snapshot, etc.
After all it is all about choice and what one desires. Options and components already available. As database becomes a commodity, I wouldnt be surprised to see small consumer devices with a hard disk presenting itself as a MySQL or PostgreSQL database for structured information and as a NAS device for unstructured information. Talk about being a commodity.
No comments:
Post a Comment