The following is a glossary of commonly used terms when discussing Omnidex.
ACID stands for Atomicity, Consistency, Isolation and Durability. In database theory, these are properties that insure that databases transactions are processed reliably. Most relational databases support these ACID requirements and are therefore appropriate for heavy and complex transaction volume, such as an order entry system. However, these ACID requirements usually put a significant load on the system resources and slow performance considerably.
Many NoSQL databases achieve greater performance and throughput by setting these ACID requirements aside. Updates to the database may be applied in an “eventually consistent” manner, meaning that updates will eventually happen, but not precisely at the time the user requests them.
There are many variations on this theme. For example, “strong consistency” does not meet the ACID requirements; however, it insures that everyone sees the same data at the same time.
Omnidex indexes can be updated with strong consistency. Omnidex also makes it very easy to quickly rebuild and re-index a database, accommodating large bulk refreshes of the data.
NoSQL is a broad term that describes databases and data storage technologies which do not adhere to the tenants of relational database management systems.
- Relational databases are generally restricted to storing data in tables, columns, and rows. This fixed schema helps protect the integrity of the data, but is intolerant of exceptions. Many NoSQL databases offer a wide variety of flexibility storage formats such as freeform text, JSON, BSON and XML.
- Relational databases invest in managing database transactions; however, this often comes at the expense of performance and flexibility. NoSQL databases usually invest in performance and flexibility, sometimes with a more tolerant approach toward managing transactions.
- Relational databases are usually accessed using the SQL language. Many NoSQL databases provide a separate API or language for accessing their data, though some still support SQL.
Omnidex is a hybrid between a relational database and a NoSQL database. Omnidex supports traditional tables, columns and rows, accessed through standard SQL statements. In fact, Omnidex can be used alongside a traditional relational database and improve the query performance. At the same time, Omnidex can retrieve directly from raw data files and delimited files, and Omnidex provides a wide variety of flexible text search capabilities.
Delimited files are text files that store data in rows and columns. The rows and columns are separated using special delimiter characters. These are commonly used by relational databases and other data-related tools as a standard, portable data format. Tabs and commas are the most common delimiters between columns, and linefeeds are the most common delimiters between rows. Delimited files always store data in character format, though they can correlate to binary datatypes in a table definition.
Omnidex allows delimited files to be directly accessed using SQL statements without having to import them into a database. These files can also be indexed using Omnidex, providing fast query performance even with large amounts of data.
Raw Data Files
Raw data files are files that store data in rows and columns. Data can be stored in both character and binary datatype, and all rows use the same number of bytes. These are often used by relational databases and other data-related tools as a standard, portable data format. Raw data files are also known as binary files and fixed length data files.
Omnidex allows raw data files to be directly accessed using SQL statements without having to import them into a database. These files can also be indexed using Omnidex, providing fast query performance even with large amounts of data.
PowerSearch is a feature of Omnidex that allows flexible searches against databases. PowerSearch uses capabilities like synonym lists, phonetic searches, misspelling searches, transposition searches, and geographic proximity searches to find data, even if it doesn’t exactly match the original search criteria. A simple example is finding a person named “William Myers” on “825 5th Ave, New York, NY 10021” using criteria of “Bill Meyers” on “852 Fifth Avenue, New Yrok, NY, 10022”. In this example, the criteria has many mistakes, including a different name, street number, street name, city and zip code”.
PowerSearch can be customized for each database, and Omnidex administrators can create their own custom synonym lists and fuzzy search instructions for each application.
ActiveCounts is a feature of Omnidex that allows users to drill down through search criteria into their database. ActiveCounts allows an application to present search criteria choices with real-time counts for each choice, even on very large databases. This allows the user to decide how they want to drill down into their database while being informed by accurate and real-time counts.