from dbazine.com
Embedded Database Primer
Introduction
If you’re anything like me, staying on top of current trends within the field of database administration is highly challenging at times. We are continually bombarded with new trends and technology that we cannot normally afford to try. For quite awhile, I have wondered what embedded databases were all about. I think of embedded databases as something small and contained in my cellular phone or as maintaining some information within my automobile. But what is the embedded database world really like?
I decided to reduce my learning curve and develop a primer about embedded databases by interviewing a vendor with this expertise. I posed a few high-level questions to Steve Wampler, Director of Database Marketing, Birdstep Technology who has worked successfully with embedded databases for some time:
Q. What exactly defines an embedded database?
We define an embedded database as a software component that is part of the application, not a separate running application. Its operations are invoked by the application. Another way to look at it is that embedded databases are embedded within an application.
Q. Can you explain to the layman how a database is embedded within an application?
It is embedded either as in-line code or linked libraries. In either case, it's code that is executed only when invoked by the application.
Q. How long has the embedded database industry been around?
More than 20 years — one could argue that since the beginning of software, embedded databases have been in existence.
Q. What drives the new features introduced in the embedded industry?
This is vendor-dependent. What you are seeing today is an application view for development — meaning features are being developed to do certain application tasks.
Q. What is the fastest growing business use for embedded databases?
One of the hottest is automotive.
Q. Does the embedded database community compete with the larger RDBMS vendors and in what regards?
In some cases, yes. One needs to look at the database market as a continuum with the embedded on one end and the enterprise on the other. There is a point in the continuum where the embedded databases are competing with the enterprise databases. Typically, this is a case where the plethora of features in enterprise databases is more important than the cost, size, and performance. These last three factors are the key advantage of embedded database over enterprise database.
Q. How do embedded databases differ from the typical relational databases such as Oracle, DB2, and SQL Server?
These databases are big, expensive, and slow. They are general purpose because they must serve a wide range of applications and users. They tend to be separate running applications that are independent of the system application.
Q. What are the top three features or business solutions for embedded databases?
Performance, small size, and price.
Q. Are embedded databases relational?
Yes. There are databases that are hierarchical (network model, XML model) as well.
Q. What is the Network Data Model?
The relational database model establishes and maintains inter-record relationships through common data fields. The Network Database Model establishes inter-record relationships directly, through physical links between the related records, rather than through common data fields.
Q. What applications are better suited for embedded databases?
Application-specific systems that have no or limited human administration or interruption.
Q. What type of applications are not meant for embedded databases?
Large enterprise systems.
Q. Are there any instances where you have seen successful conversions from major RDBMS vendors to an embedded database system?
Usually in business automation systems where the database needs to handle large data, multiple users, but can't be too expensive and must be allowed to be redistributed by the developer.
Q. What are the administration duties for maintaining an embedded database environment?
These are minimal because the application is usually the administrator.
Q. What are the tuning opportunities of an embedded database? Is there much a DBA can do for such a small footprint?
It depends on the functionality of the database. In our case, tuning can come through cache management (performance), using SQL or Native API (performance), user-defined procedures and functions.
Q. How exactly do embedded databases speed time to delivery of applications and cut development costs?
Every software application manages data. In most cases, the data is managed in a flat file — and this is fine for these applications as long as they have a short life cycle and their data is stagnant. If the application is going to have a long life cycle and/or going to grow in its use, having a database management system is 100 times cheaper to buy than to build and in many years quicker to develop.
Q. How robust is the availability, reliability, and recoverability of embedded databases?
Very robust — because of their applications, this is a must.
Q. When I hear high performance for embedded databases I immediately think they surely cannot keep up with the “big boys” in relational databases. What can we expect as far as performance from an embedded database?
This is highly dependent on if the application is mostly reading, writing, updating, etc. Typically you can find order-of-magnitude better performance in embedded database.
Q. Are there any typical limits to the size of an embedded database such as data size, footprint, or instruction set?
No.
Conclusion
Embedded databases differ from typical databases such as DB2, Oracle, and SQL Server in that it is completely integrated into the application or hardware device in such a way that the end-user has very little knowledge, if any, of its existence. Users and administrators are not burdened with time-consuming installations or maintenance as the database is literally packaged with the application and should be self maintaining.
Embedded databases are meant to run on many different platforms with various programming interfaces. The nature of embedding databases’ instruction sets being linked specifically within and for a specific application gives them a small footprint. A reduced instruction set allows them to achieve performance that is hard to beat. Surely, you wouldn’t want to put an Oracle instance within your cellular phone, but I might in my automobile.
--
James F. Koopmann is dedicated to providing technical advantage and guidance to companies within information technology. Over the years, James has worked with a variety of database-centric software and tools vendors as strategist, architect, DBA, and performance expert. He is an accomplished author appearing regularly within printed publications across the Web, and speaking at local area User Groups as well as industry conferences. He may be reached at jkoopmann@pinehorse.com or www.pinehorse.com.
No comments:
Post a Comment