This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
admin:applications:optimization [2009/12/08 06:07] els |
admin:applications:optimization [2012/10/26 14:26] (current) |
||
|---|---|---|---|
| Line 9: | Line 9: | ||
| ===== Optimization ===== | ===== Optimization ===== | ||
| - | Omnidex applications are constantly evolving and the queries that are submitted to an application change over time as well. The Omnidex indexing strategy must evolve with it to insure that performance is maintained. This requires reviewing new queries and monitoring slow queries. It is also worthwhile to monitor statistics of index usage to eliminate indexes that are no longer used. | + | 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 be necessary to change the strategy used 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. | + | 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: | There are several common strategies for optimizing an Omnidex application: | ||
| Line 22: | Line 22: | ||
| ==== Reviewing New Queries ==== | ==== Reviewing New Queries ==== | ||
| - | As applications change, so do the queries. Queries that involve new columns should be optimized using the same techniques described in the [[admin:applications:design|Design]] section. | + | 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:applications:design|Design]] section. |
| ==== Optimizing Slow Queries ==== | ==== Optimizing Slow Queries ==== | ||
| - | Omnidex maintains a list of the slowest queries on each server. These queries are the prime candidates for optimization using the same techniques described in [[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. | + | 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: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 ==== | ==== Monitoring Statistics ==== | ||
| - | Omnidex maintains statistics of how frequently an index is used. Early in an applications life, it is common to discover Omnidex indexes that are never used. Administrators may elect to remove these 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. | + | 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. |