This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
admin:admin:applications:design [2011/01/10 19:08] els |
admin:admin:applications:design [2016/06/28 22:38] (current) |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | {{page>:top_add&nofooter&noeditbtn}} | + | ~~NOTOC~~ |
| + | {{page>:top_add&nofooter&noeditbtn}} | ||
| - | ====== Omnidex Administration ====== | ||
| + | ====== Administration: Administration Basics ====== | ||
| ===== Building Omnidex Applications ===== | ===== 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]] | + | **[[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]] |
| ---- | ---- | ||
| Line 15: | Line 16: | ||
| ==== Design ==== | ==== Design ==== | ||
| - | As with most applications, this is the most important step of the entire application applications. During the design step, key decisions are made about how to approach Omnidex queries and updates in the application. These decisions can lead to high-performing applications, and they can also lead to poor performance. It is worth spending the needed time on this step. | + | As with most applications, this is the most important step of the entire application. During the design step, key decisions are made about how to approach Omnidex queries and updates in the application. These decisions can lead to high-performing applications, and they can also lead to poor performance. It is worth spending the needed time on this step. |
| This article focuses on the design steps for an Omnidex application. It does not focus on the steps for application design in general. These steps should be interwoven with the design steps needed for the overall application. | This article focuses on the design steps for an Omnidex application. It does not focus on the steps for application design in general. These steps should be interwoven with the design steps needed for the overall application. | ||
| Line 34: | Line 35: | ||
| == Development Languages == | == Development Languages == | ||
| - | Typically, Omnidex treated as a database layer, accessed through ODBC or JDBC. Omnidex in turn will index and access the underlying database layer as needed. The application can also maintain separate connections directions to the underlying database in scenarios where Omnidex indexing is not needed. | + | Typically, Omnidex is treated as a database layer, accessed through ODBC or JDBC. Omnidex in turn will index and access the underlying database layer as needed. The application can also maintain separate connections to the underlying database in scenarios where Omnidex indexing is not needed. |
| == Relational Databases and Raw Data Files == | == Relational Databases and Raw Data Files == | ||
| Line 47: | Line 48: | ||
| == Omnidex Grids == | == Omnidex Grids == | ||
| - | Omnidex Grids allow large databases to be partitioned to improve performance and scalability. Databases with over 20 million rows are candidates for Omnidex Grids, and there are several strategies for distributing the nodes of the grid to achieve the greatest flexibility and performance. Omnidex Grids are also a common way to incorporate large amounts to new data. Large volumes of data can be added to a new node in the grid without having to affect the entire database. | + | Omnidex Grids allow large databases to be partitioned to improve performance and scalability. Databases with over 20 million rows are candidates for Omnidex Grids, and there are several strategies for distributing the nodes of the grid to achieve the greatest flexibility and performance. Omnidex Grids are also a common way to incorporate large amounts of new data. Large volumes of data can be added to a new node in the grid without having to impact the entire database. |
| == Omnidex Index Servers == | == Omnidex Index Servers == | ||
| Line 55: | Line 56: | ||
| ==== ==== | ==== ==== | ||
| - | Architects would benefit from a deeper understanding of these concepts, and are encouraged to read the article on [[admin:admin:architecture|Omnidex Architecture]]. | + | Architects would benefit from a deeper understanding of these concepts, and are encouraged to read the article on [[admin:admin:architecture:home|Omnidex Architecture]]. |
| Line 108: | Line 109: | ||
| * **Criteria Columns** - Most administrators index all of the columns used in criteria. Omnidex's SQL engine can process criteria that is not indexed, but it is affordable enough that administrators usually start by indexing all of the columns used in criteria. Each index can also have options, such as textual indexes and case sensitivity. | * **Criteria Columns** - Most administrators index all of the columns used in criteria. Omnidex's SQL engine can process criteria that is not indexed, but it is affordable enough that administrators usually start by indexing all of the columns used in criteria. Each index can also have options, such as textual indexes and case sensitivity. | ||
| - | * **Aggregations** - Simple counts do not require any special indexing beyond indexing the criteria columns and optimizing the table joins. More complex aggregations, such as distinct counts, sums, averages, mins and maxs, require an index containing the group by columns and the aggregated columns in any order. When there are a lot of combinations of columns for aggregations, larger indexes can be created with that satisfy multiple scenarios. | + | * **Aggregations** - Simple counts and distinct counts do not require any special indexing beyond indexing the criteria columns and optimizing the table joins. More complex aggregations, such as sums, averages, mins, maxs, and grouped distinct counts require an index containing the group by columns and the aggregated columns in any order. Multi-column indexes may be needed for high-cardinality group by columns as well. When there are a lot of combinations of columns for aggregations, larger indexes can be created that satisfy multiple scenarios. |
| * **Ordering** - Ascending order by clauses are optimized with an index containing the order by columns. These indexes often overlap those created to optimize aggregations. | * **Ordering** - Ascending order by clauses are optimized with an index containing the order by columns. These indexes often overlap those created to optimize aggregations. | ||
| Line 118: | Line 119: | ||
| - | ====== ====== | + | ==== ==== |
| **[[admin:admin:applications:home|Prev]]** | **[[admin:admin:applications:prototype|Next]]** | **[[admin:admin:applications:home|Prev]]** | **[[admin:admin:applications:prototype|Next]]** | ||