This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
admin:features:grids:partitions [2011/03/23 21:19] deb |
admin:features:grids:partitions [2016/06/28 22:38] (current) |
||
|---|---|---|---|
| Line 7: | Line 7: | ||
| ===== Omnidex Grids ===== | ===== Omnidex Grids ===== | ||
| - | [[admin:features:grids:home|Overview]] -> **[[admin:features:grids:partitions|Partitioning Scheme]]** -> [[admin:features:grids:distribution|Distribution Plan]] -> [[admin:features:grids:creation|Grid Creation]] | + | [[admin:features:grids:home|Overview]] | **[[admin:features:grids:partitions|Partitioning Scheme]]** | [[admin:features:grids:distribution|Distribution Plan]] | [[admin:features:grids:creation|Grid Creation]] |
| ---- | ---- | ||
| Line 21: | Line 21: | ||
| Generally, the best place to start is to examine the queries. If queries are logged over a period of time and analyzed, there are generally patterns to the criteria. In many databases, most queries begin with criteria such as geography, client IDs, product IDs, or dates. If one set of criteria is common to most queries, then that becomes a logical candidate for the //partition qualifier//. For example, many databases are partitioned by a geographic region code, a state code or a zip code. Queries that provide criteria against these geographic codes can then be directed solely to those //grid nodes// that contain those rows. | Generally, the best place to start is to examine the queries. If queries are logged over a period of time and analyzed, there are generally patterns to the criteria. In many databases, most queries begin with criteria such as geography, client IDs, product IDs, or dates. If one set of criteria is common to most queries, then that becomes a logical candidate for the //partition qualifier//. For example, many databases are partitioned by a geographic region code, a state code or a zip code. Queries that provide criteria against these geographic codes can then be directed solely to those //grid nodes// that contain those rows. | ||
| - | There can be other reasons for choosing a //partition qualifier//. Some databases are segmented using a client ID or a product ID, and all queries will be narrowed to that particular client or product. Partitioning the database by these ID’s not only speeds the queries, but it also makes it possible to perform maintenance on individual clients or products because they are isolated into a specific node. Other databases provide a revolving view of recent data, such as the last 12 months or the last 30 days. In these cases, partitioning by the month or the day allows old data to be archived and new data to be incorporated without causing maintenance on the entire database. | + | There can be other reasons for choosing a //partition qualifier//. Some databases are segmented using a client ID or a product ID, and all queries will be narrowed to that particular client or product. Partitioning the database by these IDs not only speeds the queries, but it also makes it possible to perform maintenance on individual clients or products because they are isolated into a specific node. Other databases provide a revolving view of recent data, such as the last 12 months or the last 30 days. In these cases, partitioning by the month or the day allows old data to be archived and new data to be incorporated without causing maintenance on the entire database. |
| The application is unaware of the partitioning scheme. It simply sends queries and expects the results to come back quickly. This means that it is possible to alter the partitioning scheme without changing the application. Repartitioning a database can still be a large endeavor, but it can be scheduled by the database administrators without having to schedule development resources. | The application is unaware of the partitioning scheme. It simply sends queries and expects the results to come back quickly. This means that it is possible to alter the partitioning scheme without changing the application. Repartitioning a database can still be a large endeavor, but it can be scheduled by the database administrators without having to schedule development resources. | ||
| Line 54: | Line 54: | ||
| Now that you have determined your partitioning scheme, it is time to determine your [[admin:features:grids:distribution | distribution plan ]]. | Now that you have determined your partitioning scheme, it is time to determine your [[admin:features:grids:distribution | distribution plan ]]. | ||
| - | **[[admin:features:grids:home|Prev]]** | **[[admin:features:grid:distribution|Next]]** | + | **[[admin:features:grids:home|Prev]]** | **[[admin:features:grids:distribution|Next]]** |
| ====== Additional Resources ====== | ====== Additional Resources ====== | ||