Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
admin:indexing:creation:home [2012/01/30 16:35]
doc
admin:indexing:creation:home [2016/06/28 22:38] (current)
Line 4: Line 4:
 ====== Administration:​ Omnidex Indexing ====== ====== Administration:​ Omnidex Indexing ======
  
-===== Indexing ​Creation =====+===== Index Creation =====
  
 **[[admin:​indexing:​creation:​home|Overview]]** | **[[admin:​indexing:​creation:​home|Overview]]** |
Line 11: Line 11:
 [[admin:​indexing:​creation:​files|Index Files]] | [[admin:​indexing:​creation:​files|Index Files]] |
 [[admin:​indexing:​creation:​performance|Performance]] [[admin:​indexing:​creation:​performance|Performance]]
 +----
 ==== Overview ==== ==== Overview ====
  
 Most relational databases, such as Oracle, SQL Server and MySQL, encourage administrators to create a few carefully-chosen indexes on a table. ​ These indexes are created using the CREATE INDEX statement, which sequentially scans the table and populates the index. ​ A table with three or four indexes will require three or four CREATE INDEX statements, each of which will sequentially scan the table and populate the index. Most relational databases, such as Oracle, SQL Server and MySQL, encourage administrators to create a few carefully-chosen indexes on a table. ​ These indexes are created using the CREATE INDEX statement, which sequentially scans the table and populates the index. ​ A table with three or four indexes will require three or four CREATE INDEX statements, each of which will sequentially scan the table and populate the index.
  
-Omnidex'​s indexing strategy often results in hundreds of indexes per table; therefore, Omnidex takes a more optimized approach to index creation. ​ It is inefficient to sequentially scan the table for each and every index, regardless of whether there will be a few indexes, or hundreds of indexes. ​ With Omnidex, you first declare all of the properties and options for all of the indexes, and then they are all populated ​with one command. ​ This command scans the table once, populating all of the indexes at the same time.  This allows indexes to be created at a much faster rate than the relational databases.+Omnidex'​s indexing strategy often results in hundreds of indexes per table; therefore, Omnidex takes a more optimized approach to index creation. ​ It is inefficient to sequentially scan the table for each and every index, regardless of whether there will be a few indexes, or hundreds of indexes. ​ With Omnidex, you first declare all of the properties and options for all of the indexes, and then populate ​all of the indexes ​with one command. ​ This command scans the table just once, populating all of the indexes at the same time.  This allows indexes to be created at a much faster rate than the relational databases.
  
 If needed, Omnidex does allow an index to be created individually;​ however, this is not commonly needed. ​ Omnidex generally populates indexes at a rate of 1-5 billion keywords per hour, depending on the underlying hardware. ​ This fast indexing rate makes it convenient to simply rebuild all of the indexes, usually in minutes. ​ If needed, Omnidex does allow an index to be created individually;​ however, this is not commonly needed. ​ Omnidex generally populates indexes at a rate of 1-5 billion keywords per hour, depending on the underlying hardware. ​ This fast indexing rate makes it convenient to simply rebuild all of the indexes, usually in minutes. ​
 
Back to top
admin/indexing/creation/home.1327941336.txt.gz ยท Last modified: 2016/06/28 22:38 (external edit)