This shows you the differences between two versions of the page.
|
admin:admin:applications:optimization [2011/01/10 19:17] els |
admin:admin:applications:optimization [2016/06/28 22:38] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | {{page>:top_add&nofooter&noeditbtn}} | ||
| - | ====== Administration: Administration Basics ====== | ||
| - | |||
| - | ===== Building Omnidex Applications ===== | ||
| - | |||
| - | |||
| - | [[admin:admin:applications:design|Design]] -> [[admin:admin:applications:prototype|Prototype]] -> [[admin:admin:applications:development|Development]] -> [[admin:admin:applications:testing|Testing]] -> [[admin:admin:applications:staging|Staging]] -> [[admin:admin:applications:production|Production]] -> **[[admin:admin:applications:optimization|Optimization]]** | ||
| - | |||
| - | ---- | ||
| - | |||
| - | ==== Optimization ==== | ||
| - | |||
| - | Omnidex applications are constantly evolving and the queries that are submitted to an application can change over time. The Omnidex indexing strategy must evolve with the application to insure that performance is maintained. This requires reviewing new queries and monitoring slow queries. It is also important to monitor index usage statistics to eliminate indexes that are no longer needed. | ||
| - | |||
| - | As Omnidex applications grow, it may become necessary to distribute and scale the application. A database may need to evolve into an Omnidex Grid, or an existing Omnidex Grid may require more nodes or servers. | ||
| - | |||
| - | There are several common strategies for optimizing an Omnidex application: | ||
| - | |||
| - | - [[#Reviewing_new_queries|Reviewing new queries]] | ||
| - | - [[#Optimizing_slow_queries|Optimizing slow queries]] | ||
| - | - [[#Monitoring_statistics|Monitoring statistics]] | ||
| - | - [[#Distributing_and_scaling_applications|Distributing and scaling applications]] | ||
| - | |||
| - | === Reviewing New Queries === | ||
| - | |||
| - | As applications change, so do the queries. Queries that involve new tables or columns should be optimized using the same techniques described in the [[admin:admin:applications:design|Design]] section. | ||
| - | |||
| - | |||
| - | === Optimizing Slow Queries === | ||
| - | |||
| - | Omnidex maintains a list of the slowest queries on each server. These queries are prime candidates for optimization using the same techniques described in [[admin:admin:applications:design|Design]]. Omnidex also provides tools for logging all queries in an application. This more comprehensive log allows a deeper analysis of the performance of queries and can be used to identify patterns of queries that require further optimization. | ||
| - | |||
| - | |||
| - | === Monitoring Statistics === | ||
| - | |||
| - | Omnidex maintains statistics of how frequently each index is used. Early in the life of an application, it is common to add more indexes than are needed. Administrators can remove unused indexes to conserve disk space and shorten build time. Omnidex statistics will also show the cardinalities of tables, indicating when an Omnidex Grid may be of benefit. | ||
| - | |||
| - | |||
| - | === Distributing and Scaling Applications === | ||
| - | |||
| - | Large Omnidex databases may have been deployed using an Omnidex Grid. Omnidex Grids may require new nodes, and nodes may be distributed to a variety of servers. As applications grow further, it may be beneficial to distribute copies of the data and the indexes using Omnidex Snapshots. | ||
| - | |||
| - | ==== ==== | ||
| - | **[[admin:admin:applications:production|Prev]]** | ||
| - | |||
| - | ====== Additional Resources ====== | ||
| - | |||
| - | See also: | ||
| - | |||
| - | {{page>:admin:admin:see_also&nofooter&noeditbtn}} | ||
| - | |||
| - | {{page>:bottom_add&nofooter&noeditbtn}} | ||