EEPW论坛

CENTURA 公司（原RAIMA公司）是嵌入式数据库软件方面的领先者。自1982年以来，RAIMA公司一直针对高性能的数据库开展工作，在建立快速和可靠的数据库方面取得了很大成绩。 AT&T、Anderson Consulting、IBM、DEC、Cabletron、SIMENS、Motorola......都是RAIMA公司的客户。 Complex Embedded systems Need Real databases By maurzio Monesi, Hewlett-Packard Embedded systems need the ability to manage not just more data-this could be solved with additional RAM and CPU cycles—but to manage data that is persistent as well as increasingly complex and dynamic. The usual firmware –based approach to data management using homemade solutions based on flat operation system files, proved particularly lacking in such areas as developer productivity, scalability, and long-term efficiency, The need for better data management in embedded systems became acute for my group at Hewlett-Packard when planning development of the company’s next-generation office-communications device. This new product, called the HP 9100C Digital Sender ( see photo, next page), digitizes pager documents and distributes them by e-mail and to printers, faxes, and HP JetSend-enabled applications, The preceding products, HP’s Network ScanJet 5 product line, employed flat-file data management to store some 5,000 destination addresses. Early in the project, it became clear that the HP 9100C Digital Sender would require data management on a much larger scale, Our product specification called for managing more than 700,000 records including public and private distribution lists with a number of complex data relationships. Scaling our existing flat-file system to meet the needs of this new project threatened to add an unacceptable amount of development time. Flat-file schemes are easy to configure for a specific task but a given flat file solution is usually not extensible to meet all the needs of a couples embedded application. Flat-file storage also generates a lot of redundant data that wastes system resources. In addition, access-mediation mechanisms for multiple processes and failure recovery are notoriously difficult to develop for flat-file storage. Facing a substantially lengthened development cycle, we looked for alternatives to flat-file data management. Embedding a DBMs The successful solution was an approach that is more familiar to business application developers than to embedded systems engineers: we adopted a commercial database management system. The database we shoes was Centura Software’s (formerly Raima’s ) RDM/Vx running on the VxWorks real-time operating system. The VxWorks RTOS, RDM/Vx database structure, and the various applications that access the database reside on magnetic storage within the Digital Sender. We identified three areas to apply the database. Two of these, the Log Manager and the Device Monitor, are largely administrative ad contain information about past jobs and internal tasks. The other application area, the digital Sender’s operations ad is accessed constantly in real time. The database defines multiple types of address books, including one public email address book, public email distribution lists, and personal users email address books. Each book is an RDM/Vx record type, consisting of multiple C data types. (RDM/Vx support all C data types, including arrays and structs.) The available methods for constructing data relationships are one of the major differences between the flat-file approach and the database system used in the Digital Sender, Information in flat files is usually arranged sequentially. Information is stored-and subsequently retrieved, updated or deleted- on a “first-in, first-out” bases. A single flat file can be seen as a table, consisting of rows(individual records) and columns(which contain a single attribute of each record). This format leads to significant duplication. For example, if you construct a personal email address book in this table allocates space for the address book ”owner’s” identity, even if that owner’s name is repeated many times. In fact, the most logical data storage and management scheme is to include the owner’s name once and define a relationship from that record to all ”member” e-mail addresses. This is called “data normalization” and while the concept is quite common for business applications, it is not used as often in the world of embedded systems because database managers have not been commonly used for developing embedded systems. Choosing a Database Model Providing efficient information structures and access methods needed to normalize data is the hallmark of database management systems. In a relational database, for example, owners and members might be contained in separate tables with an index establishing a relationship between the primary key value-the owner-on one table and the foreign key values –the members-on the other table. RDM/Vx supports this relational database model. However, we found the network database model, a less well known ( but more powerful for our purposes) data organization method also supported by RDM/Vx, to be even more useful. The network database model(see Fig 1, previous page) is based on sets, which typically consist of owners and members. The owner and members are connected physically, via pointers, in a linked-list structure. These direct links between related records make for fast, efficient record access. This contrasts sharply to the relational model, in which data access requires traversing an index-a process that can be costly in terms of efficiency. We use indexes in our application but we make more use of sets because that is the natural way of organizing our data and of implementing access to the address books. Locking Mechanism Must Prevent Corruption In addition to making data access efficient, a data-management component-whether a home-made system or a commercial DBMS-must have the ability to mediate among several processes simultaneously requesting data. A locking mechanism is needed to prevent data corruption. The digital Sender incorporates seven processes that may try to access data at eh same time. The IMSP(Internet Message Support Protocol) server application alone contains five of these. In a flat-file system, you would probably use OS synchronization methods to serialize file access. Because of its critical role in preventing corruption, development of safe file-access methods for a multitasking system requires extensive debugging and testing. And again, extensibility would like present a problem-can the locking mechanisam developed and tested for one part of an application be extended to others? The alternative provided by RDM/Vx is the Lock Manager, which isolates the relevant subset of the database during access, queues additional access requests, and grants access when the database is available. Locking in RDM/Vx generally takes place at the level of record type, and a solution based on RDM/Vx gains interprocess data access synchronization automatically. Failure Recovery Even with an access-synchronization mechanisam in place data corruption is still possible in the event of system failure. Multiple updates to the database must sometimes take place as a group to avoid data corruption in the event of system failure. Otherwise, information in the database can ge “out of sync.” Database managers address this possibility through “transactions,” which group multiple file updates, into one unit, to succeed or fail as a group. RDM/Vx provides this capability. Along with an automatic ”roll forward” feature that completes pending transactions after system recovery. But transaction incur performance overhead. When updates are committed as a group, portions of the database are “off limits” to other processes, causing potential access latency. Fortunately, you can configure this feature and make performance tradeoffs. For example, the HP 9100C Digital Sender supports batch configuration in which an ASCII file of e-mail addresses is downloaded to the machine. The file contents are processed and entered into the database. At first, we configured the entire store as one transaction. However, this approach required too much tie for an address book with 150,000 entries. We later grouped the operation into several hundred addresses per transaction to that the database would be available to other processes, such as the Control Panel, between transactions. Tradeoffs like this are common in working with a database. As a matter of fact, even the choice to use a database involved a tradeoff: self-developed solutions are infinitely configurable given enough time and development resources. However, we were happy to trade this potential flexibility for a real solution. In terms of saving money, time and sanity, it made infinite sense to focus on creating our intelligent embedded system and to license the database form database experts.