3
<title>Challenges in Embedded Database System Administration</title>
7
<h1>Challenges in Embedded Database System Administration</h1>
8
<h3>Margo Seltzer, Harvard University</h3>
9
<h3>Michael Olson, Sleepycat Software, Inc.</h3>
10
<em>{margo,mao}@sleepycat.com</em>
13
Database configuration and maintenance have historically been complex tasks,
15
requiring expert knowledge of database design and application
17
In an embedded environment, it is not feasible to require such
18
expertise and ongoing database maintenance.
19
This paper discusses the database administration
20
challenges posed by embedded systems and describes how the
21
Berkeley DB architecture addresses these challenges.
23
<h2>1. Introduction</h2>
25
Embedded systems provide a combination of opportunities and challenges
26
in application and system configuration and management.
27
As an embedded system is most often dedicated to a single application or
28
small set of tasks, the operating conditions of the system are
29
typically better understood than those of general purpose computing
31
Similarly, as embedded systems are dedicated to a small set of tasks,
32
one would expect that the software to manage them should be small
34
On the other hand, once an embedded system is deployed, it must
35
continue to function without interruption and without administrator
38
Database administration consists of two components,
39
initial configuration and ongoing maintenance.
40
Initial configuration consists of database design, manifestation,
42
The instantiation of the design includes decomposing the design
43
into tables, relations, or objects and designating proper indices
44
and their implementations (e.g., Btrees, hash tables, etc.).
45
Tuning a design requires selecting a location for the log and
46
data files, selecting appropriate database page sizes, specifying
47
the size of in-memory caches, and specifying the limits of
48
multi-threading and concurrency.
49
As embedded systems define a specific environment and set of tasks,
50
requiring expertise during the initial system
51
configuration process is acceptable, and we focus our efforts on
52
the ongoing maintenance of the system.
53
In this way, our emphasis differs from other projects such as
54
Microsoft's AutoAdmin project <a href="#Chaud982">[3]</a>, and the "no-knobs"
55
administration that is identified as an area of important future
56
research by the Asilomar authors<a href="#Bern98">[1]</a>.
58
In this paper, we focus on what the authors
59
of the Asilomar report call "gizmo" databases <a href="#Bern98"> [1]</a>,
61
that reside in devices such as smart cards, toasters, or telephones.
62
The key characteristics of such databases are that their
63
functionality is completely transparent to users, no one ever
64
performs explicit database operations or
65
database maintenance, the database may crash at any time and
66
must recover instantly, the device may undergo a hard reset at
67
any time, requiring that the database return to its initial
68
state, and the semantic integrity of the database must be maintained
70
In Section 2, we provide more detail on the sorts of tasks
71
typically performed by database administrators (DBAs) that must
72
be automated in an embedded system.
74
The rest of this paper is structured as follows.
75
In Section 2, we outline the requirements for embedded database support.
76
In Section 3, we discuss how Berkeley DB
77
is conducive to the hands-off management
78
required in embedded systems.
79
In Section 4, we discuss novel features that
81
DB's suitability for the embedded applications.
82
In Section 5, we discuss issues of footprint size.
83
In Section 6 we discuss related work, and we conclude
86
<h2>2. Embedded Database Requirements</h2>
87
Historically, much of the commercial database industry has been driven
88
by the requirements of high performance online transaction
89
processing (OLTP), complex query processing, and the industry
90
standard benchmarks that have emerged (e.g., TPC-C <a href="#TPCC">[9]</a>,
91
TPC-D <a href="#TPCD">[10]</a>) to
92
allow for system comparisons.
93
As embedded systems typically perform fairly simple queries,
94
such metrics are not nearly as relevant for embedded database
95
systems as are ease of maintenance, robustness, and small footprint.
96
Of these three requirements, robustness and ease of maintenance
98
Users must trust the data stored in their devices and must not need
99
to manually perform anything resembling system administration in order
100
to get their unit to work properly.
101
Fortunately, ease of use and robustness are important side
102
effects of simplicity and good design.
103
These, in turn, lead to a small size, providing the third
104
requirement of an embedded system.
105
<h3>2.1 The User Perspective</h3>
107
In the embedded database arena, it is the ongoing maintenance tasks
108
that must be automated, not necessarily the initial system configuration.
110
that are traditionally performed by DBAs,
111
but must be performed automatically
112
in embedded database systems.
114
log archival and reclamation,
116
data compaction/reorganization,
117
automatic and rapid recovery, and
118
reinitialization from scratch.
120
Log archival and backup are tightly coupled.
121
Database backups are part of any
122
large database installation, and log archival is analogous to incremental
124
It is not clear what the implications of backup and archival are in
126
Consumers do not back up their VCRs or refrigerators, yet they do
127
(or should) back up their personal computers or personal digital
129
For the remainder of this paper, we assume that backups, in some form,
130
are required for gizmo databases (imagine having to reprogram, manually,
131
the television viewing access pattern learned by some set-top television
133
Furthermore, we require that those backups are nearly instantaneous or
134
completely transparent,
135
as users should not be aware that their gizmos are being backed up
136
and should not have to explicitly initiate such backups.
138
Data compaction or reorganization has traditionally required periodic
139
dumping and restoration of
140
database tables and the recreation of indices.
141
In an embedded system, such reorganization must happen automatically.
143
Recovery issues are similar in embedded and traditional environments
144
with a few exceptions.
145
While a few seconds or even a minute recovery is acceptable
146
for a large server installation, no one is willing to wait
147
for their telephone or television to reboot.
148
As with archival, recovery must be nearly instantaneous in an embedded product.
149
Secondly, it is often the case that a system will be completely
150
reinitialized, rather than simply rebooted.
151
In this case, the embedded database must be restored to its initial
152
state, freeing all its resources.
153
This is not typically a requirement of large server systems.
154
<h3>2.2 The Developer Perspective</h3>
156
In addition to the maintenance-free operation required of the
157
embedded systems, there are a number of requirements that fall
158
out of the constrained resources typically found in the "gizmos"
159
using gizmo databases. These requirements are:
162
programmatic interface for tight application coupling and
163
to avoid the overhead (in both time and size) of
164
interfaces such as SQL and ODBC,
165
application configurability and flexibility,
166
support for complete memory-resident operation (e.g., these systems
167
must run on gizmos without file systems), and
168
support for multi-threading.
170
A small footprint and short code-path are self-explanatory, however
171
what is not as obvious is that the programmatic interface requirement
172
is the logical result of them.
173
Traditional interfaces such as ODBC and SQL add significant
174
size overhead and frequently add multiple context/thread switches
175
per operation, not to mention several IPC calls.
176
An embedded product is less likely to require the complex
177
query processing that SQL enables.
178
Instead, in the embedded space, the ability for an application
179
to configure the database for the specific tasks in question
180
is more important than a general query interface.
182
As some systems do not provide storage other than RAM and ROM,
183
it is essential that an embedded database work seemlessly
184
in memory-only environments.
185
Similarly, many of today's embedded operating systems provide a
186
single address space architecture, so a simple, multi-threaded
187
capability is essential for application requiring any concurrency.
189
In general, embedded applications run on gizmos whose native
190
operating system support varies tremendously.
191
For example, the embedded OS may or may
192
not support user-level processing or multi-threading.
193
Even if it does, a particular embedded
194
application may or may not need it.
195
Not all applications need more than one thread of control.
196
An embedded database must provide mechanisms to developers
197
without deciding policy.
198
For example, the threading model in an application is a matter of policy,
200
not on the database software, but on the hardware, operating
201
system, and the application's feature set.
202
Therefore, the data manager must provide for the use of multi-threading,
205
<h2>3. Berkeley DB: A Database for Embedded Systems</h2>
206
Berkeley DB is the result of implementing database functionality
207
using the UNIX tool-based philosophy.
208
The current Berkeley DB package, as distributed by Sleepycat
209
Software, is a descendant of the hash and btree access methods
210
distributed with 4.4BSD and its descendents.
211
The original package (referred to as DB-1.85),
212
while intended as a public domain replacement for dbm and
213
its followers (e.g., ndbm, gdbm, etc), rapidly became widely
214
used as an efficient, easy-to-use data store.
215
It was incorporated into a number of Open Source packages including
216
Perl, Sendmail, Kerberos, and the GNU C-library.
218
Versions 2.X and higher are distributed by Sleepycat Software and
219
add functionality for concurrency, logging, transactions, and
221
Each piece of additional functionality is implemented as an independent
222
module, which means that the subsystems can be used outside the
223
context of Berkeley DB. For example, the locking subsystem can
224
easily be used to implement locking for a non-DB application and
225
the shared memory buffer pool can be used for any application
226
caching data in main memory.
227
This subsystem design allows a designer to pick and choose
228
the functionality necessary for the application, minimizing
229
memory footprint and maximizing performance.
230
This addresses the small footprint and short code-path criteria
231
mentioned in the previous section.
233
As Berkeley DB grew out of a replacement for dbm, its primary
234
implementation language has always been C and its interface has
235
been programmatic. The C interface is the native interface,
236
unlike many database systems where the programmatic API is simply
237
a layer on top of an already-costly query interface (e.g. embedded
239
Berkeley DB's heritage is also apparent in its data model; it has
241
The database stores unstructured key/data pairs, specified as
242
variable length byte strings.
243
This leaves schema design and representation issues the responsibility
244
of the application, which is ideal for an embedded environment.
245
Applications retain full control over specification of their data
246
types, representation, index values, and index relationships.
247
In other words, Berkeley DB provides a robust, high-performance,
248
keyed storage system, not a particular database management system.
249
We have designed for simplicity and performance, trading off
250
complex, general purpose support that is better encapsulated in
253
Another element of Berkeley DB's programmatic interface is its
254
customizability; applications can specify Btree comparison and
255
prefix compression functions, hash functions, error routines,
257
This means that embedded applications can tailor the underlying
258
database to best suit their data demands.
259
Similarly, the utilities traditionally bundled with a database
260
manager (e.g., recovery, dump/restore, archive) are implemented
261
as tiny wrapper programs around library routines. This means
262
that it is not necessary to run separate applications for the
263
utilities. Instead, independent threads can act as utility
264
daemons, or regular query threads can perform utility functions.
265
Many of the current products built on Berkeley DB are bundled as
266
a single large server with independent threads that perform functions
267
such as checkpoint, deadlock detection, and performance monitoring.
269
As mentioned earlier, living in an embedded environment requires
270
flexible management of storage.
271
Berkeley DB does not require any preallocation of disk space
272
for log or data files.
273
While many commercial database systems take complete control
274
of a raw device, Berkeley DB uses a normal file system, and
275
can therefore, safely and easily share a data space with other
277
All databases and log files are native files of the host environment,
278
so whatever utilities are provided by the environment can be used
279
to manage database files as well.
281
Berkeley DB provides three different memory models for its
282
management of shared information.
283
Applications can use the IEEE Std 1003.1b-1993 (POSIX) <tt>mmap</tt>
285
data, they can use system shared memory, as frequently provided
286
by the shmget family of interfaces, or they can use per-process
287
heap memory (e.g., malloc).
288
Applications that require no permanent storage and do not provide
289
shared memory facilities can still use Berkeley DB by requesting
290
strictly private memory and specifying that all databases be
292
This provides pure-memory operation.
294
Lastly, Berkeley DB is designed for rapid startup -- recovery can
295
happen automatically as part of system initialization.
296
This means that Berkeley DB works correctly in environments where
297
gizmos are suddenly shut down and restarted.
299
<h2>4. Extensions for Embedded Environments </h2>
300
While the Berkeley DB library has been designed for use in
301
embedded systems, all the features described above are useful
302
in more conventional systems as well.
303
In this section, we discuss a number of features and "automatic
304
knobs" that are specifically geared
305
toward the more constrained environments found in gizmo databases.
307
<h3>4.1 Automatic compression</h3>
308
Following the programmatic interface design philosophy, we
309
support application-specific (or default) compression routines.
310
These can be geared toward the particular data types present
311
in the application's dataset, thus providing better compression
312
than a general purpose routine.
313
Note that the application could instead specify an encryption
314
function and create encrypted databases instead of compressed ones.
315
Alternately, the application might specify a function that performs
316
both compression and encryption.
318
As applications are also permitted to specify comparison and hash
319
functions, the application can chose to organize its data based
320
either on uncompressed and clear-text data or compressed and encrypted
322
If the application indicates that data should be compared in its
323
processed form (i.e., compressed and encrypted), then the compression
324
and encryption are performed on individual data items and the in-memory
325
representation retains these characteristics.
326
However, if the application indicates that data should be compared in
327
its original form, then entire pages are transformed upon being read
328
into or written out of the main memory buffer cache.
329
These two alternatives provide the flexibility to trade space
330
and security for performance.
332
<h3>4.2 In-memory logging & transactions</h3>
333
One of the four key properties of transaction systems is durability.
334
This means that transaction systems are designed for permanent storage
335
(most commonly disk). However, as mentioned above, embedded systems
336
do not necessarily contain any such storage.
337
Nevertheless, transactions can be useful in this environment to
338
preserve the semantic integrity of the underlying storage.
339
Berkeley DB optionally provides logging functionality and
340
transaction support regardless of whether the database and logs
341
are on disk or in memory.
343
<h3>4.3 Remote Logs</h3>
344
While we do not expect users to backup their television sets and
345
toasters, it is conceivable that a set-top box provided by a
346
cable carrier should, in fact, be backed up by that cable carrier.
347
The ability to store logs remotely can provide "information appliance"
348
functionality, and can also be used in conjunction with local logs
349
to enhance reliability.
350
Furthermore, remote logs provide for catastrophic recovery, e.g., loss
351
of the gizmo, destruction of the gizmo, etc.
353
<h3>4.4 Application References to Database Buffers</h3>
355
Typically, when data is returned to the user, it must be copied
356
from the data manager's buffer cache (or data page) into the
357
application's memory.
358
However, in an embedded environment, the robustness of the
359
total software package is of paramount importance, not the
360
isolation between the application and the data manager.
361
As a result, it is possible for the data manager to avoid
362
copies by giving applications direct references to data items
363
in a shared memory cache.
364
This is a significant performance optimization that can be
365
allowed when the application and data manager are tightly
368
<h3>4.5 Recoverable database creation/deletion</h3>
370
In a conventional database management system, the creation of
371
database tables (relations) and indices are heavyweight operations
372
that are not recoverable.
373
This is not acceptable in a complex embedded environment where
374
instantaneous recovery and robust operation in the face of
375
all types of database operations is essential.
376
While Berkeley DB files can be removed using normal file system
377
utilities, we provide transaction protected utilities that
378
allow us to recover both database creation and deletion.
380
<h3>4.6 Adaptive concurrency control</h3>
381
The Berkeley DB package uses page-level locking by default.
382
This trades off fine grain concurrency control for simplicity
383
during recovery. (Finer grain concurrency control can be
384
obtained by reducing the page size in the database.)
385
However, when multiple threads/processes perform page-locking
386
in the presence of writing operations, there is the
387
potential for deadlock.
388
As some environments do not need or desire the overhead of
389
logging and transactions, it is important to provide the
390
ability for concurrent access without the potential for
393
Berkeley DB provides an option to perform coarser grain,
394
deadlock-free locking.
395
Rather than locking on pages, locking is performed at the
396
interface to the database.
397
Multiple readers or a single writer are allowed to be
398
active in the database at any instant in time, with
399
conflicting requests queued automatically.
400
The presence of cursors, through which applications can both
401
read and write data, complicates this design.
402
If a cursor is currently being used for reading, but will later
403
be used to write, the system will be deadlock prone if no
404
special precautions are taken.
405
To handle this situation, we require that, when a cursor is
406
created, the application specify any future intention to write.
407
If there is an intention to write, the cursor is granted an
408
intention-to-write lock which does not conflict with readers,
409
but does conflict with other intention-to-write locks and write
411
The end result is that the application is limited to a single
412
potentially writing cursor accessing the database at any point
415
Under periods of low contention (but potentially high throughput),
416
the normal page-level locking provides the best overall throughput.
417
However, as contention rises, so does the potential for deadlock.
418
As some cross-over point, switching to the less concurrent, but
419
deadlock-free locking protocol will result in higher throughput
420
as operations must never be retried.
421
Given the operating conditions of an embedded database manager,
422
it is useful to make this change automatically as the system
423
itself detects high contention.
425
<h3>4.7 Adaptive synchronization</h3>
427
In addition to the logical locks that protect the integrity of the
428
database pages, Berkeley DB must synchronize access to shared memory
429
data structures, such as the lock table, in-memory buffer pool, and
430
in-memory log buffer.
431
Each independent module uses a single mutex to protect its shared
432
data structures, under the assumption that operations that require
433
the mutex are very short and the potential for conflict is
435
Unfortunately, in highly concurrent environments with multiple processors
436
present, this assumption is not always true.
437
When this assumption becomes invalid (that is, we observe significant
438
contention for the subsystem mutexes), we can switch over to a finer-grained
439
concurrency model for the mutexes.
440
Once again, there is a performance trade-off. Fine-grain mutexes
441
impose a penalty of approximately 25% (due to the increased number
442
of mutexes required for each operation), but allow for higher throughput.
443
Using fine-grain mutexes under low contention would cause a decrease
444
in performance, so it is important to monitor the system carefully,
445
so that the change can be executed only when it will increase system
446
throughput without jeopardizing latency.
448
<h2>5. Footprint of an Embedded System</h2>
449
While traditional systems compete on price-performance, the
450
embedded players will compete on price, features, and footprint.
451
The earlier sections have focused on features; in this section
452
we focus on footprint.
454
Oracle reports that Oracle Lite 3.0 requires 350 KB to 750 KB
455
of memory and approximately 2.5 MB of hard disk space <a href="#Oracle">[7]</a>.
456
This includes drivers for interfaces such as ODBC and JDBC.
457
In contrast, Berkeley DB ranges in size from 75 KB to under 200 KB,
458
foregoing heavyweight interfaces such as ODBC and JDBC and
459
providing a variety of deployed sizes that can be used depending
460
on application needs. At the low end, applications requiring
461
a simple single-user access method can choose from either extended
462
linear hashing, B+ trees, or record-number based retrieval and
463
pay only the 75 KB space requirement.
464
Applications requiring all three access methods will observe the
466
At the high end, a fully recoverable, high-performance system
467
occupies less than a quarter megabyte of memory.
468
This is a system you can easily incorporate in your toaster oven.
469
Table 1 shows the per-module break down of the entire Berkeley DB
470
library. Note that this does not include memory used to cache database
474
<tr><th colspan=4>Object sizes in bytes</th></tr>
475
<tr><th align=left>Subsystem</th><th align=center>Text</th><th align=center>Data</th><th align=center>Bss</th></tr>
476
<tr><td>Btree-specific routines</td><td align=right>28812</td><td align=right>0</td><td align=right>0</td></tr>
477
<tr><td>Recno-specific routines</td><td align=right>7211</td><td align=right>0</td><td align=right>0</td></tr>
478
<tr><td>Hash-specific routines</td><td align=right>23742</td><td align=right>0</td><td align=right>0</td></tr>
479
<tr><td colspan=4></td></tr>
480
<tr><td>Memory Pool</td><td align=right>14535</td><td align=right>0</td><td align=right>0</td></tr>
481
<tr><td>Access method common code</td><td align=right>23252</td><td align=right>0</td><td align=right>0</td></tr>
482
<tr><td>OS compatibility library</td><td align=right>4980</td><td align=right>52</td><td align=right>0</td></tr>
483
<tr><td>Support utilities</td><td align=right>6165</td><td align=right>0</td><td align=right>0</td></tr>
484
<tr><td colspan=4></td></tr>
485
<tr><th>All modules for Btree access method only</th><td align=right>77744</td><td align=right>52</td><td align=right>0</td></tr>
486
<tr><th>All modules for Recno access method only</th><td align=right>84955</td><td align=right>52</td><td align=right>0</td></tr>
487
<tr><th>All modules for Hash access method only</th><td align=right>72674</td><td align=right>52</td><td align=right>0</td></tr>
488
<tr><td colspan=4></td></tr>
489
<tr><th align=left>All Access Methods</th><td align=right>108697</td><td align=right>52</td><td align=right>0</td></tr>
490
<tr><td colspan=4><br></td></tr>
491
<tr><td>Locking</td><td align=right>12533</td><td align=right>0</td><td align=right>0</td></tr>
492
<tr><td colspan=4></td></tr>
493
<tr><td>Recovery</td><td align=right>26948</td><td align=right>8</td><td align=right>4</td></tr>
494
<tr><td>Logging</td><td align=right>37367</td><td align=right>0</td><td align=right>0</td></tr>
495
<tr><td colspan=4></td></tr>
496
<tr><th align=left>Full Package</th><td align=right>185545</td><td align=right>60</td><td align=right>4</td></tr>
500
<h2>6. Related Work</h2>
502
Every three to five years, leading researchers in the database
503
community convene to identify future directions in database
505
They produce a report of this meeting, named for the year and
506
location of the meeting.
507
The most recent of these reports, the 1998 Asilomar report,
508
identifies the embedded database market as one of the
509
high growth areas in database research <a href="#Bern98">[1]</a>.
510
Not surprisingly, market analysts identify the embedded database
511
market as a high-growth area in the commercial sector as well <a href="#Host98">
514
The Asilomar report identifies a new class of database applications, which they
515
term "gizmo" databases, small databases embedded in tiny mobile
516
appliances, e.g., smart-cards, telephones, personal digital assistants.
517
Such databases must be self-managing, secure and reliable.
518
Thus, the idea is that gizmo databases require plug and play data
519
management with no database administrator (DBA), no human settable
520
parameters, and the ability to adapt to changing conditions.
521
More specifically, the Asilomar authors claim that the goal is
522
self-tuning, including defining the physical DB design, the
523
logical DB design, and automatic reports and utilities <a href="#Bern98">[1]</a>
525
few researchers have accepted this challenge, and there is a dearth
526
of research literature on the subject.
528
Our approach to embedded database administration is fundamentally
529
different than that described by the Asilomar authors.
530
We adopt their terminology, but view the challenge in supporting
531
gizmo databases to be that of self-sustenance <em>after</em> initial
532
deployment. Therefore, we find it, not only acceptable, but
533
desirable to assume that application developers control initial
534
database design and configuration. To the best of our knowledge,
535
none of the published work in this area addresses this approach.
537
As the research community has not provided guidance in this
538
arena, most work in embedded database administration has fallen
539
to the commercial vendors.
540
These vendors fall into two camps, companies selling databases
541
specifically designed for embedding or programmatic access
542
and the major database vendors (e.g., Oracle, Informix, Sybase).
544
The embedded vendors all acknowledge the need for automatic
545
administration, but fail to identify precisely how their
546
products actually accomplish this.
547
A notable exception is Interbase whose white paper
548
comparison with Sybase and Microsoft's SQL servers
549
explicitly address features of maintenance ease.
550
Interbase claims that as they use no log files, there is
551
no need for log reclamation, checkpoint tuning, or other
552
tasks associated with log management. However, Interbase
553
uses Transaction Information Pages, and it is unclear
554
how these are reused or reclaimed <a href="#Interbase">[6]</a>.
555
Additionally, with a log-free system, they must use
556
a FORCE policy (write all pages to disk at commit),
557
as defined by Haerder and Reuter <a href="#Haerder">[4]</a>. This has
558
serious performance consequences for disk-based systems.
559
The approach described in this paper does use logs and
560
therefore requires log reclamation,
561
but provides hooks so the application may reclaim logs
562
safely and programmatically.
563
While Berkeley DB does require checkpoints, the goal of
564
tuning the checkpoint interval is to bound recovery time.
565
Since the checkpoint interval in Berkeley DB can be expressed
566
by the amount of log data written, it requires no tuning.
567
The application designer sets a target recovery time, and
568
selects the amount of log data that can be read in that interval
569
and specifies the checkpoint interval appropriately. Even as
570
load changes, the time to recover does not.
572
The backup approaches taken by Interbase and Berkeley DB
573
are similar in that they both allow online backup, but
574
rather different in their affect on transactions running
575
during backup. As Interbase performs backups as transactions
576
<a href="#Interbase">[6]</a>, concurrent queries can suffer potentially long
577
delays. Berkeley DB uses native operating system system utilities
578
and recovery for backups, so there is no interference with
579
concurrent activity, other than potential contention on disk
582
There are a number of database vendors selling in
583
the embedded market (e.g., Raima,
584
Centura, Pervasive, Faircom), but none highlight
585
the special requirements of embedded database
587
On the other end of the spectrum, the major vendors,
588
Oracle, Sybase, Microsoft, are all becoming convinced
589
of the importance of the embedded market.
590
As mentioned earlier, Oracle has announced its
591
Oracle Lite server for embedded use.
592
Sybase has announced its UltraLite platform for "application-optimized,
593
high-performance, SQL database engine for professional
594
application developers building solutions for mobile and embedded platforms."
595
<a href="#Sybase">[8]</a>.
596
We believe that SQL is incompatible with the
597
gizmo database environment or truly embedded systems for which Berkeley
599
Microsoft research is taking a different approach, developing
600
technology to assist in automating initial database design and
601
index specification <a href="#Chaud98">[2]</a><a href="#Chaud982">[3]</a>.
602
As mentioned earlier, we believe that such configuration is, not only
603
acceptable in the embedded market, but desirable so that applications
604
can tune their database management for the target environment.
605
<h2>7. Conclusions</h2>
606
The coming wave of embedded systems poses a new set of challenges
608
The traditional server-based, big footprint systems designed for
609
high performance on big iron are not the right approach in this
611
Instead, application developers need small, fast, versatile systems
612
that can be tailored to a specific environment.
613
In this paper, we have identified several of the key issues in
614
providing these systems and shown how Berkeley DB provides
615
many of the characteristics necessary for such applications.
617
<h2>8. References</h2>
619
[1] <a name="Bern98"> Bernstein, P., Brodie, M., Ceri, S., DeWitt, D., Franklin, M.,
620
Garcia-Molina, H., Gray, J., Held, J., Hellerstein, J.,
621
Jagadish, H., Lesk, M., Maier, D., Naughton, J.,
622
Pirahesh, H., Stonebraker, M., Ullman, J.,
623
"The Asilomar Report on Database Research,"
624
SIGMOD Record 27(4): 74-80, 1998.
627
[2] <a name="Chaud98"> Chaudhuri, S., Narasayya, V.,
628
"AutoAdmin 'What-If' Index Analysis Utility,"
629
<em>Proceedings of the ACM SIGMOD Conference</em>, Seattle, 1998.
632
[3] <a name="Chaud982"> Chaudhuri, S., Narasayya, V.,
633
"An Efficient, Cost-Driver Index Selection Tool for Microsoft SQL Server,"
634
<em>Proceedings of the 23rd VLDB Conference</em>, Athens, Greece, 1997.
637
[4] <a name="Harder"> Haerder, T., Reuter, A.,
638
"Principles of Transaction-Oriented Database Recovery,"
639
<em>Computing Surveys 15</em>,4 (1983), 237-318.
642
[5] <a name="Host98"> Hostetler, M., "Cover Is Off A New Type of Database,"
644
http://www.theadvisors.com/embeddeddbnews.htm,
648
[6] <a name="Interbase"> Interbase, "A Comparison of Borland InterBase 4.0
649
Sybase SQL Server and Microsoft SQL Server,"
650
http://web.interbase.com/products/doc_info_f.html.
653
[7] <a name="Oracle"> Oracle, "Oracle Delivers New Server, Application Suite
654
to Power the Web for Mission-Critical Business,"
655
http://www.oracle.com.sg/partners/news/newserver.htm,
659
[8] <a name="Sybase"> Sybase, Sybase UltraLite, http://www.sybase.com/products/ultralite/beta.
662
[9] <a name="TPCC"> Transaction Processing Council, "TPC-C Benchmark Specification,
663
Version 3.4," San Jose, CA, August 1998.
666
[10] <a name="TPCD"> Transaction Processing Council, "TPC-D Benchmark Specification,
667
Version 2.1," San Jose, CA, April 1999.
added
removed
libdb/docs/ref/refs/embedded.html
