 |
eXtremeSQL™ embedded database SQL interface
Download the eXtremeSQL data sheet (PDF)
McObject's eXtremeSQL embedded database interface is a high-performance implementation of the SQL database programming language for the eXtremeDB in-memory database. With eXtremeSQL, McObject targets the real-time enterprise software market by greatly simplifying programming with eXtremeDB for corporate developers using SQL. The new interface strengthens eXtremeDB’s appeal for application development in fields such as banking and securities trading, where real-time responsiveness is a must and SQL is the dominant database language.
In addition to working with the eXtremeDB in-memory database system (IMDS), eXtremeSQL provides a SQL interface for eXtremeDB Fusion, McObject’s hybrid database that enables developers to combine all-in-memory with on-disk data storage in the same application. For details on these hybrid database capabilities, see the page for eXtremeDB Fusion.
Built on the unsurpassed performance of eXtremeDB, and a RAM-based SQL optimizer, eXtremeSQL delivers blazingly fast processing of dynamic SQL queries.
Benefits of using eXtremeSQL include...
Co-exists with native eXtremeDB. Use eXtremeSQL alongside the eXtremeDB embedded database API in the same application. Where maximum performance is critical, the eXtremeDB API can’t be beat. When a higher level of access would be beneficial, such as in retrieving data from multiple tables or performing aggregation, then McObject’s embedded SQL interface is advantageous.
Broad coverage of the SQL-89 standard. eXtremeSQL implements much of the ANSI SQL-89 specification.
Extensions to exploit eXtremeDB features and data types. In addition, eXtremeSQL implements eXtremeDB-specific extensions including support for structures, arrays and vectors, as well as query optimizations based on specific eXtremeDB capabilities.
Compatible with all eXtremeDB editions. eXtremeSQL is fully compatible and interoperable with the Standard Edition, High Availability Edition, and Transaction Logging Edition of McObject’s eXtremeDB RAM database. There is no need to worry about the migration path within the product family
No client/server inter-process communications. Like eXtremeDB, eXtremeSQL is embedded in the application, not deployed as a separate process. This eliminates client/server inter-process communication round-trips from the execution path, resulting in breakthrough performance.
Interactive SQL utility. eXtremeSQL comes with an interactive SQL program, eXQL, that can be used to test SQL statements independently from application programs. Full source code for the utility is provided so that it also serves as a useful example of a full eXtremeSQL implementation. In addition to executing SQL statements, eXQL also supports eXtremeDB-specific commands, such as "report" and "save ".
eXQL can also be employed as a batch processing utility by redirecting input from a text file containing eXtremeSQL statements.
eXtremeSQL Query Optimization
Creating the optimal execution plan for real-time SQL statements is complex and challenging. SQL optimizers analyze queries and select the best database search strategies. Query optimization greatly depends on data distribution. Often, optimizers use samples and statistics provided by the database engine, and collect statistical information themselves, to calculate the cost of candidate execution plans. Therefore, building optimal plans is CPU-intensive unpredictable; optimization time varies from query to query, and execution plans can change from one invocation to another as data distribution changes.
For real-time and embedded systems demanding predictable performance, a rule-based optimizer such as is used by eXtremeSQL is more appropriate. In addition, the McObject’s SQL optimizer makes it possible for applications to specify their own execution plan. For example, the optimizer never reorders tables in the query: the joins are performed in the sequence the tables were specified in query. Some of the other key rules that are used for query optimization include:
- If possible, an index is used
- Each table is assigned an index representing its position in the FROM list
- The search predicate is divided into the set of conjuncts and the conjuncts are sorted. Therefore the expressions accessing the tables with smaller indices are checked first.
The execution of subqueries is optimized by checking the dependencies of the subquery expression. The results of the subquery are saved and recalculated only if the subquery expression refers to fields from the enclosing scope.
|
 |
