I had the pleasure of interviewing a happy long-term customer this month, who unfortunately cannot allow me to use his company name. This is a summary of how he has been using Raima Database Manager (RDM) and his relationship with Raima over the years.
Why Raima’s Database Manager?
This customer develops a Networking and Telecom application for his company and distributes it to hundreds of outlets. RDM was initially chosen because it was embedded, but the product has grown with the application over a span of more than 15 years, managing this customer’s database of up to 10,000 user profiles per installation. Because it is embedded, RDM is delivered and installed as a part of the application system. End-users have the benefit of a DBMS in the program they are using, but none of the responsibilities of administering a database. The program is used primarily for policy management, working with a user base of 100 or more, up to 10,000 users. In the 1990’s, RDM was chosen as the going-forward database management winner when two solutions had been initially implemented in different areas of functionality: one area with Btrieve, one with RDM. Since then, moving from RDM version 4.5 to 7.2 to 9.1 to 11.0, there have been no reports of corrupted databases and only one call to Raima for technical support.
The design of this database makes heavy use of indexing and BLOBs. The application is coded in C++ and uses the traditional low-level core API (what we call the “d_” API). The core API is fast, and the application can support as many as 10,000 queries per second on the database. In the larger installations of this application, multiple Linux-based servers share the load. Updates to the database are migrated to all of the coordinated servers, facilitating greater scale-up performance and high availability.
Moving Forward with Raima
Each new release of a software application opens up new choices for its implementation. Technology is advancing at a high rate and forcing new requirements on applications that were adequate only five years ago. This is the situation for the Configuration and Policy Management application as well. Performance continues to be a driving factor as it always has been, but today’s end-users expect to add their own customized queries for reporting, or interconnections to other system. They also expect new enhancements to the application to be implemented in a timely way. With RDM’s implementation of SQL now available (since version 10.1), the next generation of this database will no longer manage BLOBs, but the contents of those BLOBs will become SQL tables. No longer will the application interpret the contents of the BLOBs – SQL will provide its full range of analytical queries.
With RDM’s next release, even more improvements can propagate up through the application. With the addition of SQL/PL, SQL becomes a powerful customization language for both developers and end-users. Other enhancements, like an optimized in-memory solution and a compressed, portable database format expand the performance and platform range for all applications.
How This Affects You
This has been a successful application and has no end-of-life in view. Would that be true if another choice had been made? Perhaps, but the early choice of RDM gave it some advantages. First, reliability. RDM stood out as a component in his system that didn’t need attention. Second, price. RDM is a commercial product, but it can be argued that the total-cost-of-ownership over this long-term relationship has been very low. Free or Open Source software requires either in-house expertise or external support. It often requires licensing when used in commercial applications. Third, performance. With support for a high number of users performing frequent queries, this system has demonstrated a low-latency, high query rate that can be scaled up in the larger installations.
