Overview | Benefits | Creation | Portability | Scalability
Omnidex Snapshots provide a lot of benefits and advantages, especially when used in parallel with an underlying database. The most obvious advantages are performance and portability, but there are many other opportunities as well.
The chief benefit of Omnidex Snapshots is their high performance. Data is stored in Raw Data Files, which can be processed very quickly. Omnidex Snapshots can also be heavily indexed since they are read-only copies of the data. This combination allows an Omnidex Snapshot to perform extremely well. Applications often take advantage of this by point their online search or business analytic queries to an Omnidex Snapshot.
An Omnidex Snapshot consists of data files and index files, both of which can be easily moved between servers. These data files and index files can also be easily moved between Microsoft Windows and Linux operating systems, as well as 32-bit and 64-bit architectures. This portability allows for easy migration of data to other parts of an application.
If permitted within the security requirements for the data, Omnidex Snapshots can be easily migrated to temporary servers, or even desktops and laptops, to aid development or analysis. Developers can maintain a complete environment on their development server, including web servers, data servers and application servers. Analysts can use Omnidex Snapshots to reference copies of current or archived data without impacting the primary data server.
An Omnidex Snapshot can be easily replicated between multiple servers to provide autonomous, independent query environments. These independent environments can be used for failover, and can also be used for co-location of data. If needed, multiple copies of Omnidex Snapshots can be distributed and load balanced to insure the highest performance even under substantial load. The simplicity of an Omnidex Snapshot is a key asset, making it easy to move data as needed for an application.
Omnidex Snapshots are often placed on a Storage Area Network (SAN). Since the Snapshot consists of simple, read-only files, these Snapshots can be easily accessed by multiple servers. They can also be easily copied to separate partitions or nodes of the SAN to insure the highest performance.
An Omnidex Snapshot can be a copy of the underlying data model, or it can be modified to meet the needs of the application. Tables can be denormalized. Data can be aggregated, summarized or classified. Data can be split or combined, creating new columns designed to support the application. Data from multiple databases, and even multiple database vendors, can be combined into one powerful database.
Omnidex Snapshots can be created using Omnidex's SQL Engine, employing all of the capabilities of SQL to aggregate, join, filter and sort data. SQL statements can also create new columns based on complex expressions. Omnidex Snapshots can also be created using a company's preferred database or ETL tools, as the only requirement is that an Omnidex Snapshot be either a raw data file or a delimited file.
Omnidex Snapshots can be used to archive historical data while still maintaining easy and fast access to the data. For example, an Omnidex Snapshot may contain a previous year's historical data separate from the current year's data. The Omnidex Snapshot can remain active as a separate environment, or it can be archived and restored later as needed. If needed, multiple snapshots can be brought back together as nodes on an Omnidex Grid, allowing queries to span all the data as needed.
Omnidex Snapshots are ideal when paired with a underlying relational database. The underlying database can provide the transactional integrity needed for an OLTP application, while the Omnidex Snapshot can provide the flexibility and speed needed for an OLAP application.
Omnidex Snapshots gain much of their power from their simplicity. Since an Omnidex Snapshot is simply a set of data and index files, they become easily managed and manipulated, avoiding the overhead of cost inserts or deletes from the relational databases. In this case, the simple solution is also the highest performing solution, since raw data files are extremely fast to process.