Figure 1: Data model of an MP3 player.

Figure 2: Indexes to implement relationships.

While many consumer electronics devices must store and retrieve data, it is the digital media player (or MP3 player) that most resembles a walking database. Music fans buy the devices so they can carry around hundreds of hours of audio, instantly accessing songs according to the “metadata” of artist, album, title, genre, and playlist. Without the ability to extensively index, cross-reference and search a music collection according to the user’s wishes, the devices would have little appeal.

Less obvious is data management’s role in extending MP3 players’ battery life and lowering their manufacturing cost—but Japan’s JVC Company sees the connection. In late 2005, the company released what is probably a first: its new Alneo XA HD500 studio quality digital media player incorporates a commercial embedded database management system (DBMS). The new design reflects digital audio players’ memory and CPU constraints, which are extreme even for consumer electronics. JVC found that the right off-the-shelf database helps use these resources more efficiently.

Reducing RAM

In an MP3 player, RAM is precious for two reasons: using less memory reduces the device’s bill-of-materials cost, lending an important manufacturing cost advantage, and most RAM within the device is reserved for the playback buffer that caches the MP3 stream. Low-end CPUs are also deployed to minimize cost, and CPU cycles must be dramatically minimized, to afford a long playback per recharge.

Early in the design process, the JVC engineers determined it would be difficult to obtain the desired efficiency, and meet a stringent development schedule, writing their own data management code. They began exploring the alternative: integrating a proven commercial DBMS within the MP3 player’s embedded software.

The question remained, though, what kind of database would work. “Enterprise” DBMSs, designed to serve as corporations’ centralized data stores were an impossible fit due to cost and footprint; “embedded” database sounds closer, except that only a small subset of embedded databases are intended for real-time embedded systems (most are meant to be embedded in packaged software applications).

In-memory

For resource-constrained embedded devices, a key distinction within the embedded database category is on-disk DBMS, versus in-memory DBMS. Most embedded database systems manage data on-disk, and are designed to cache frequently requested data in memory – for faster access – but to write database updates, insertions, and deletes through the cache to be stored to disk. A newer approach is the in-memory database system (IMDS), which eliminates disk access and stores data in main memory, flushing to disk only when commanded to do so by the application.

In-memory data management emerged as the better fit for JVC’s MP3 player. A key issue was on-disk databases’ indexes, which enable quick access to related records. To avoid disk access—which could potentially lead to playback interference in the MP3 player—the developers determined they would need to cache all of the on-disk database (data and indexes).

Freeing memory

A great deal of redundant data is stored in on-disk databases’ indexes that manifest the relationships between data entities. With such a database this is desirable because if the required data exists in the index, the system can avoid the disk I/O that would otherwise be needed to access the data file. Disk I/O is expensive (in performance terms), so on-disk databases can justify the extra storage space to hold redundant copies of data in indexes. But in-memory databases never go to disk. There is no disk I/O to avoid, so the redundant index data can be eliminated, thus freeing memory.

In making their database selection, the JVC engineers also noted that the software logic to accomplish caching and disk I/O—which are integral to on-disk databases but non-existent in in-memory architectures—posed significant CPU demands. By eliminating these demands, the in-memory database delivered better performance with a less powerful CPU, and allowed the CPU to be “clocked down” during certain operations to maximize battery life.

Start-up time

Engineers were also concerned about the start-up time for provisioning the in-memory database. On-disk databases can be used immediately after the application opens the database, whereas an in-memory database is initially empty and must be populated (“provisioned”) with data. But in the final analysis, the modest size of the in-memory MP3 database eliminated this potential issue. For a database providing access to 5000 songs, the in-memory database required just 1 MB if the average song title string length was 20 characters; if all the song titles were the maximum 512 characters, the database was about 2 MB. With micro drive transfer rates up to 33 MB per second, the in-memory database could be provisioned in a time span well within usability thresholds. The competing on-disk database software created a database that was 7 MB in size.