- How indexing works in Magento
- What exactly it does?
- Why it is required?
Magento – How indexing works in magento
indexing
Related Solutions
The indexing order when reindexing all processes is defined by Mage_Index_Model_Indexer::_runAll().
This method uses the depends property of each process to check which other processes have to run before itself can do it's work.
The getDepends() method of the index/process uses the configuration node global/index/indexer/[process-code]/depends to determine it's dependencies.
Having a look at Mage/Catalog/etc/config.xml, the indexer processes configurations there are as follows:
<index>
<indexer>
<catalog_product_attribute>
<model>catalog/product_indexer_eav</model>
</catalog_product_attribute>
<catalog_product_price>
<model>catalog/product_indexer_price</model>
</catalog_product_price>
<catalog_url>
<model>catalog/indexer_url</model>
</catalog_url>
<catalog_product_flat>
<model>catalog/product_indexer_flat</model>
</catalog_product_flat>
<catalog_category_flat>
<model>catalog/category_indexer_flat</model>
</catalog_category_flat>
<catalog_category_product>
<model>catalog/category_indexer_product</model>
</catalog_category_product>
</indexer>
</index>
No dependencies are declared at all, so I would say the concrete processing order is more or less random, or unspecified.
To have the *_flat indexer processes run before the catalog_url reindexing, it should be enough to add a dependency as follows:
<catalog_url>
<model>catalog/indexer_url</model>
<depends>
<catalog_product_flat/>
<catalog_category_flat/>
</depends>
</catalog_url>
On what condition status of an Indexer changes?
Anything that triggers the event. For more information see below.
Are various indexer available in Magento are dependent on each other?
Yes and no. You technically don't need one for the other, but performance and other issue will arise by not using them jointly.
Why it shows "Update required = Yes" even it is in "Ready" status. ?
One show the Status that needs to be updated. The "Ready" status just means its available to. When it's not available it will say processing or error.
Is indexing executed on daily basis?If yes, then from where we can change time of its execution?
It depends, you have to Update on Save. So on every save of the indexing event. There is also manual if you want to manually do it or there is tools out there that can run on cron as well.
If a store receives couple of thousand request to update inventory via Soap API, do indexer are executed and updated for every request which is received to update inventory of a product?
Yes, it will update the indexer, however, based on you setting is how it will fire. It's important to make sure that your store is getting the newest results. However, resources are used so just keep that in mind.
There is a lot of great information out there for this as well. Let me know if you have any other questions.
Best Answer
There are different kind of indexes in Magento.
All of the indexers are there to make things run faster.
I will cover here only a few of them.
Flat Index
There are 2 such indexes. One for categories and one for products.
By default the category and product entities (and customers and customer addresses but they are not important in this situation) are EAV entities. This is very nice for extensibility. But it's a performance killer because in order to get all values for all the attributes you need a lot of joins or multiple queries.
Here is where the flat indexer comes into play.
It transforms the EAV structure into a flat structure. I mean it creates a table (one for each store view in Magento) that has one column corresponding to an attribute. This makes selects faster. For categories all attributes are converted to table columns. For products only the ones you mark as 'Used in product listing' because you can sell all types of products with different attributes and creating one table with a gazillion columns may not be possible.
Also, some products may be disabled or may not belong to a certain website and there is no need to include them in the entries to search. They are excluded by the indexer.
The generated flat tables are used for reading data in the fronend. The backend still uses the EAV structure.
Catalog Search Index
You can search for products by many attribute values. Some of them may not be included in the flat tables generated by the flat indexer. This index fills in a table with the searchable attribute values for products so it's easier to look for them based on keywords. Having all the info in one table (or one field) makes it possible to use Full text search and get relevant results.
Product Prices.
The price of a product can be affected by many variables. For example, customer group, website, catalog discount rules.
Same as above, getting the products with their prices will mean a lot of joins or multiple selects. IN addition bundle products have a strange pricing system. This indexer aggregates the data in some tables (
catalog_product_index_price_*) and makes the selects (sorting and filtering) much easier.Catalog url Rewrites
This cleans up the url rewrite rules by setting which url corresponds to which product or category. It's easier this way for the url management internal system to decide which page should you view when calling a non-standard url. Instead of searching through all the product and categories URL keys it just searches in one table.
Category Products
In Magento you can set a category attribute named 'Is Anchor' to true or false. If it's true it means that the category in question will list all the products from it's child categories. Again, determining this realtime it will take more resources than just reading one table. This indexer creates the association between products and categories based on the associations you set in the backend and the 'Is Anchor' flag on the categories.
Stock Status
For simple products it's easy. They can be in stock or out of stock, but for configurable, grouped and bundle is not that easy. They can be in stock or out of stock depending on the child products associated to the main product. Again (I'm just repeating my self here) getting their status real time would mean a lot of queries.
Product Attributes.
This one collects all attributes that can be used in the layered navigation for same reason. Having all of them in one place for faster reading.
Tag Aggregation
I have no idea what this does. I've never used tags in a real live project.