This is an old revision of the document!
The hardware requirements for Omnidex applications vary depending on the size of the database, the nature of the queries and the number of users. That being said, most Omnidex servers are commodity servers with plenty of memory and fast disk access. There are typically two hardware profiles:
An Omnidex Indexing Server is used to load the indexes on large databases. Companies often receive new data on a regular basis, and since most Omnidex databases have a great deal of indexing, it is better to rebuild some or all of the indexes, rather than applying the updates one at a time. Applications that can be taken offline while indexing occurs do no need a separate Omnidex Indexing Server, but when an application must remain available all of the time, indexing usually occurs on a separate server.
For large relational databases, it is important that the Omnidex Server not be the same machine as the relational database. Relational databases, such as Oracle and SQL Server, consume most of the resources on the server, leaving little processing power for other applications. In these cases, Omnidex should reside on an independent server.
| Hardware | Requirement | ||
|---|---|---|---|
| CPU | 1 core for each concurrent node or database being indexed | ||
| Memory | 2 GB for each concurrent node or database being indexed | ||
| Disk Access | A high-speed SAN or separate drives for the database, the indexes and the temporary file directory| | Network | Gigabit or higher |
We are often asked which is faster, Linux or Windows? It is not an easy question to answer. There are so many other variables, such as the database platform, the amount of memory, the approach to disk storage, and so forth. In a company, the hardware acquisition and personnel costs can be large enough to outweigh the benefit of a slightly faster hardware platform. Because of this, we recommend that each company test with their own hardware, their own database platform and their own client layers.
We have run some limited benchmarks comparing Linux and Windows. In our tests, Linux was about 20% faster. That is consistent with our anecdotal experience, too. That being said, we have not tested a multitude of factors, such as multi-user concurrency, disk fragmentation and multi-processor performance. In addition, performance can vary significantly between versions of operating systems. This reinforces the need for companies to test in their own environment with their own configuration.
Some components of the Omnidex software are only available on a Windows operating system. The Omnidex Administrator, the graphic tool for managing Omnidex installations, is only available on a Windows operating system, though it can be used to manage Omnidex databases on remote servers, including Linux servers. New releases of Omnidex typically arrive on the Windows operating system first, with Linux releases following shortly thereafter and other UNIX versions provided as needed.
* Statement is only available from OdxSQL.
Use the CREATE ENVIRONMENT SQL_SYNTAX setting or the SET SQL_SYNTAX setting to activate.
| See Also: | List of Datatypes |
|---|
Omnidex supports the following standard datatypes:
| Datatype | Description |
|---|---|
| CHARACTER(n) | Space-filled character string of n characters |
| CHAR(n) | Synonym for CHARACTER(n) |
| STRING(n) | Null-terminated character string of n characters |
| VARCHAR(n)* | String of max n characters, with length variable |
| CLOB(n)* | Character large object of max n characters, with length variable |
| [SIGNED] TINYINT | 1-byte, signed integer ( -128 to 127 ) |
| UNSIGNED TINYINT | 1-byte, unsigned integer ( 0 to 255 ) |
| [SIGNED] SMALLINT | 2-byte, signed integer ( -32768 to 32767 ) |
| UNSIGNED SMALLINT | 2-byte, unsigned integer ( 0 to 65535 ) |
| [SIGNED] INTEGER | 4-byte, signed integer ( 2147483648 to 2147483647 ) |
| UNSIGNED INTEGER | 4-byte, unsigned integer ( 0 to 4294967295 ) |
| [SIGNED] BIGINT | 8-byte, signed integer ( -2^63 to 2^63-1 ) |
| UNSIGNED BIGINT | 8-byte, unsigned integer ( 0 to 2^64-1 ) |
| FLOAT | IEEE four-byte, single-precision floating point |
| DOUBLE | IEEE eight-byte, double-precision floating point |
| DATE | 10-byte ANSI date |
| TIME | 11-byte ANSI time |
| DATETIME | 24-byte ANSI datetime |
| ASCII DATE | 8-byte ASCII date ( YYYYMMDD ) |
| ASCII DATE(6) | 6-byte ASCII date ( YYMMDD ) |
| ODBC DATE | 6-byte ODBC proprietary date |
| ODBC TIME | 6-byte ODBC proprietary time |
| ODBC DATETIME | 6-byte ODBC proprietary datetime |
| ORACLE DATE | 7-byte Oracle proprietary date |
| ORACLE TIME | 7-byte Oracle proprietary time |
| ORACLE DATETIME | 7-byte Oracle proprietary datetime |
| OMNIDEX DATE(n) | Omnidex proprietary date supporting n digits of YYYYMMDD |
| OMNIDEX TIME(n) | Omnidex proprietary time supporting n digits of HHMMSSNN |
| OMNIDEX DATETIME(n) | Omnidex proprietary datetime supporting n digits of YYYYMMDDHHMMSSNN |
| * Omnidex recommends use of the CHARACTER and STRING datatypes rather than VARCHAR and CLOB due to the requirement of a length variable. | |
Omnidex also provides partial support for National Character Datatypes (sometimes called Unicode datatypes or wide characters). The Omnidex SQL Engine will process these datatypes, but the Omnidex Indexing Engine will only index the lower 8 bits of these datatypes.
| Datatype | Description |
|---|---|
| NATIONAL CHARACTER(n) | Space-filled character string of n characters |
| NATIONAL CHAR(n) | Synonym for CHARACTER(n) |
| NATIONAL STRING(n) | Null-terminated character string of n characters |
| NATIONAL VARCHAR(n)* | String of max n characters, with length variable |
| NATIONAL CLOB(n)* | Character large object of max n characters, with length variable |
| * Omnidex recommends use of the NATIONAL CHARACTER and NATIONAL STRING datatypes rather than NATIONAL VARCHAR and NATIONAL CLOB due to the requirement of a length variable. | |
os> odxsql
> CREATE ENVIRONMENT IN "myenv.xml";
> CREATE DATABASE mydb TYPE FLATFILE IN "myenv.xml";
> CREATE TABLE mytable PHYSICAL "test1"
(myseq integer, mytext char(60) quicktext)
IN "myenv.xml";
> CONNECT myenv.xml;
> UPDATE INDEXES;
> SELECT * FROM mytable where mytext = '<some criteria>';
> DISCONNECT;
> EXIT
os>
Omnidex SQL supports SQL's SELECT and Data Manipulation Statements (INSERT, UPDATE, and DELETE).
Omnidex supports statements to establish connections and set processing options for the connection as well as attach and detach individual files to an Omnidex Environment.
| CONNECT | Connect to an Omnidex Environment. |
| DISCONNECT | Disconnect from a connected Omnidex Environment. |
| SET | Set Omnidex SQL processing options. |
| ATTACH | Attach an Omnidex Standalone Table (OST) to a connected Omnidex Environment for queries and manipulation. |
| DETACH | Detach an Omnidex Standalone Table (OST) from a connected Omnidex Environment. |
Omnidex SQL has statements that create and drop objects within an Omnidex Environment.
Also see the OdxSQL Extract command to generate DDL statements from an existing Omnidex Environment.
| DDL Statement | Description |
|---|---|
| CREATE ENVIRONMENT | Create an Omnidex Environment into a named physical operating system file. |
| CREATE DATABASE | Create a Database within an Omnidex Environment. |
| CREATE TABLE | Create a Table within a Database in the Omnidex metadata or an Omnidex or RDBMS temporary table. |
| CREATE INDEX | Specify an Index in the Omnidex metadata but will not physically create the index. |
| CREATE INDEX GROUP | Specify an Index Group within the Omnidex metadata. |
| DROP ENVIRONMENT | Deletes the Omnidex Metadata Environment by physically deleting the operating system file. |
| DROP DATABASE | Remove the named Database from the Omnidex metadata. |
| DROP TABLE | Remove a table from the Omnidex metadata or deletes a previously created temporary table. |
| DROP INDEX | Removes an index from the Omnidex metadata. |
| DROP INDEX GROUP | Removes a named Index Group from the Omnidex metadata. |
| ATTACH | Attach an Omnidex Standalone Table (OST) to a connected Omnidex Environment for queries and manipulation. |
| DETACH | Detach an Omnidex Standalone Table (OST) from a connected Omnidex Environment. |
| SELECT | Peform a Query Specification and SELECT rows. |
| EXPORT | Export rows or rowids to an external file. |
| OPEN CURSOR | Open a Cursor. |
| CLOSE CURSOR | Close a previously opened cursor. |
Omnidex supports several statements to synchronize the Omnidex indexes, rollup tables and internal statistics.
| UPDATE INDEXES | Update Omnidex Indexes. |
| UPDATE ROLLUP | Update Rollup Table with summarized information. |
| UPDATE ROLLUPS | Update all Rollup Tables for an Omnidex Database. |
| UPDATE STATISTICS | Update Statistics Information. |
| UPDATE TEXT | Update Textual Statistics. |
| PARTITION | Partition a table into smaller sub tables based on criteria. |
| LOAD OFX | Load Indexes for a table. |
| Install Indexes | Specifies the Omnidex indexes into the Omnidex XML Environment. No indexing is performed. |
| Remove Indexes | Removes the Omnidex indexes from the Omnidex XML Environment. |
Omnidex supports lower level QUALIFY and JOIN statements to query the Omnidex indexes directly. These statements are advanced statements used for testing and to support legacy applications. The SELECT statement is now typically used instead.
(c)Copyright Dynamic Information Systems - This document was last updated July 6, 2010