Consumer electronics companies are seeking ways to simplify data management software development in digital audio players. Data management is central to these devices. The sorting, storing and retrieval tasks in the devices are mostly straightforward, but the severe constraints of memory and CPU of MP3 players present resource-efficiency demands that are extreme even for consumer electronics.
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. Low-end CPUs are also deployed in portable music players to minimize cost, and CPU cycles must be dramatically minimized for power management.
There is an increasing trend in embedded systems - to integrate a commercial, off-the-shelf database management system (DBMS) within the MP3 player's embedded software. This allows a desired efficiency in the data management code while also meeting a tight development schedule. The DBMSs, in their more traditional roles as office/corporate data repositories, are typically designed to cache frequently requested data in memory for faster access, but also to write database updates, insertions, and deletes through the cache to be stored to disk.
In-memory data management emerged as the better fit for the highly resource-constricted environment of MP3 players. One of the key issues is with disk-based database indexes, a type of key that enables quick access to related records. To avoid disk access, which could potentially lead to playback interference in the MP3 player, developers would need to cache all of the disk-based database (data and indexes). In that scenario, as the indexes contain redundant copies of the indexed data, the disk-based database would consume significantly more memory compared to the in-memory database, which does not contain redundant data in indexes.
The song entity contains information about the song. The playlistsong entity is used to implement a many-to-many relationship between the playlist and song entities. This supports the real-world fact of a playlist featuring two or more songs, and any given song can appear on more than one playlist.
Each of the arrows in Fig 1 represents a relationship between the two entities on either end of the arrow. Conventionally, indexes are used to implement the relationships. In this context, indexes are referred to as a primary key and a foreign key. A primary key is the unique identifier of a row in a table, providing access to that row distinct from all other rows in the table. A foreign key is a field or group of fields in a database record (row) that matches a primary key field (or fields) in a related table, enabling cross-referencing of information. Fig 2 depicts how indexes are used to implement relationships in a portable media player.
To retrieve the list of songs in a playlist, the name of the playlist is retrieved from the index and used as the search value in the playlistsong foreign key. Similarly, to locate the media file for a song, the track name is retrieved and used as the search value into the song primary key.
A great deal of redundant data is stored in the indexes that manifest the relationships between the data entities. With an on-disk database this is desirable because if the required data exists in the index, the data can be retrieved from there, avoiding the additional disk I/O that would have been 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.
A designer of a portable music player wants to avoid disk I/O, to maximize battery life and to avoid skipping during playback. This can be achieved by storing all (or as much as possible) data in memory. But portable media player devices have very little available RAM, and most memory is dedicated to the playback buffer. To maximize available RAM, even the redundant data in the indexes should be eliminated. In-memory databases accomplish this. They hold all data in memory, so the performance cost of reading the data table to retrieve the value is trivial, but the space saved by eliminating the redundant data in the index structures is enormous. An in-memory database index structure contains only the index metadata and no application data.
Another consideration driving the engineers' database selection is that the software logic to accomplish caching and disk I/O - which is integral to disk-based databases but non-existent in in-memory architectures - poses significant CPU demands. These are eliminated via the in-memory database option, making room for better performance with a less powerful CPU, and enabling the developers to "clock down" the CPU during certain operations to maximize battery life.
Engineers are also concerned about the start-up time of the in-memory database. Disk-based 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 eliminates this potential issue. For a database providing access to 5,000 songs, the in-memory database requires just 1MB if the average song title string length is 20 characters. If all the song titles are the maximum 512 characters, the database is about 2MB. With micro drive transfer rates up to 33MB per second, the in-memory database can be provisioned in a time span well within usability thresholds. The competing disk-based software creates a database that is 7MB in size, regardless of song title length, taking valuable memory away from the MP3 playback buffer.
by Steven T. Graves, Co-founder, CEO, McObject
(December 2005 Issue, Nikkei Electronics Asia)
Nikkei Electronics |
Nikkei Monozukuri |
Nikkei Automotive Technology |
|---|---|---|
 |
 |
 |
| The magazine for electronics designers and managers. | Design You Won't Regret - How to Reduce the Risk of Accidents | The comprehensive automotive technology magazine. |
Copyright © 1995-2010 Nikkei Business Publications, Inc. All rights reserved.
All editorial content and graphics on this Web site may not be reproduced in whole or in part without the express permission of the copyright owner.
