Differences

This shows you the differences between two versions of the page.

--- integration:rdbms:home [2011/03/15 20:50]
els
+++ integration:rdbms:home [2016/06/28 22:38] (current)
@@ Line 10: / Line 10: @@
 [[integration:rdbms:queries|Queries]] |
 [[integration:rdbms:updates|Updates]] |
-[[integration:rdbms:implementation|Implementation Guides]]
+[[integration:rdbms:integration|Integration Guides]]
 ----
 ==== Overview ====
 Omnidex is often used to increase performance and improve flexibility on relational databases.  Most companies that have invested in a relational database solution will continue to use the relational database as their core data store, but they may want to improve query performance or enhance their searches with [[admin:indexing:activecounts:home|ActiveCounts]], [[admin:indexing:powersearch:home|PowerSearch]] or [[admin:indexing:autocomplete:home|AutoComplete]].  Omnidex can access the data in the relational database and provide a high-speed query environment.
-=== Integrating at the Database Layer ===
+One of the first decisions for the administrator is which tables Omnidex should access.  Omnidex applications often have tens or hundreds of indexes per table, delivering extremely high performance.  The overhead for real-time updates on hundreds of indexes can be substantial, and as such, Omnidex is not a good solution for indexing a high-OLTP system.  If applications are going to heavily index the data, Omnidex should be pointed to separate tables that are periodically refreshed.  If the data is not heavily updated or if the Omnidex indexing is minimal, then real-time updates remain an option.
-Integrating Omnidex into an application environment usually requires integration in two areas: the application (or client) layer, and the database (or server) layer.  At the application layer, languages and tools generally use ODBC or JDBC to access the Omnidex SQL Engine.  At the database layer, Omnidex is configured to access the underlying database.  The Omnidex SQL Engine sits in between these layers, optimizing queries using the Omnidex indexes whenever possible.
-{{:integration:integration_layers.png|}}
-=== Read-Only Databases ===
-Omnidex applications often have tens to hundreds of indexes per table, delivering extremely high performance.  As such, Omnidex is usually installed on read-only tables that are updated at periodic intervals.  Omnidex does support online indexing; however, this is not suitable for high-volume OLTP applications.
-=== An Alternative: Raw Data Files ===
+Omnidex is most commonly installed on read-only tables that are periodically refreshed.  Some companies discover that Omnidex can also provide a complete SQL engine against [[integration:rawdata:home|raw data files]].  This introduces the possibility of creating low-cost, high-performance, autonomous query environments using data extracted from the relational database.  These can be placed on a separate server, alleviating the load on the relational database while improving performance and increasing scalability.  This can also lower licensing costs for the overall application.
-Some companies that use relational databases discover that Omnidex can also provide a complete SQL engine against [[integration:rawdata:home|raw data files]].  This introduces the possibility of creating an low-cost, high-performance, autonomous query environment used data extracted from the relational database on a separate server.  This can alleviate the load on the relational database while improving performance and increasing scalability.  This can also lower licensing costs for the overall application.

Back to top

integration/rdbms/home.1300222221.txt.gz · Last modified: 2016/06/28 22:38 (external edit)

Sitemap Recent Changes