More complex architectures usually involve more servers. Traditionally, the web server, the application server and the data servers are all separate machines. This allows scalability by allowing more web servers and application servers for a given data server. Similarly, Omnidex is usually assigned its own server. This insures that proper resources can be assigned to each component of the architecture.
Some architects will place Omnidex on the same server as the database, but when using relational databases, this comes with some peril. Relational databases are generally tuned to use most of the resources on the data server. When the relational database is consuming all of the processors and memory, and is using strategies that rely more heavily on disk access, there can be few resources left over for Omnidex. Placing Omnidex on its own server allows Omnidex performance to remain high and allows the application to be more responsive. It also allows the operating system to cache portions of the Omnidex index files, further increasing performance.
This strategy can increase the time required for building the indexes; however, this is still usually the preferred solution. When Omnidex reads the relational tables while building the indexes, the data must travel across the network between the servers, slowing this process down. Since indexes are built periodically, yet accessed frequently, it is still favorable to insure Omnidex has the resources needed to process queries.
As systems become more complex, many businesses use Omnidex Snapshots to provide further performance and flexibility, as discussed in the Omnidex Snapshots section.
See also: