Я как-то понимаю, как работает индексация в Magento, но я не видел никакой хорошей документации по этому поводу. Я бы хотел узнать следующее.
Я думаю, что эта информация будет очень полезной для других в моей лодке, которые не полностью получают процесс индексирования.
ОБНОВЛЕНИЕ. После комментария к моему вопросу и ответа Анкура, я думаю, что у меня что-то не хватает, насколько мне известно, просто нормальное индексирование базы данных. Так это только версия Magento по обработке индексирования, и лучше ли мне получить мой ответ с точки зрения индексирования базы данных в целом, например, эта ссылка здесь Как работает индексация базы данных?
Индексирование Magento аналогично индексированию на уровне базы данных по духу. Как утверждает Антон, это процесс денормализации, позволяющий ускорить работу сайта. Позвольте мне попытаться объяснить некоторые мысли о структуре базы данных Magento и почему она делает индексацию необходимой для работы на скорости.
В более «типичной» базе данных MySQL таблица для хранения продуктов каталога будет структурирована примерно так:
PRODUCT: product_id INT sku VARCHAR name VARCHAR size VARCHAR longdesc VARCHAR shortdesc VARCHAR ... etc ... Это быстро для поиска, но это оставляет фундаментальную проблему для части программного обеспечения для электронной коммерции: что вы делаете, когда хотите добавить больше атрибутов? Что делать, если вы продаете игрушки и вместо столбца размера вам нужен age_range ? Ну, вы могли бы добавить еще один столбец, но должно быть ясно, что в большом магазине (например, Walmart) это приведет к тому, что строки на 90% пусты и попытка обслуживания новых атрибутов почти невозможна.
Для борьбы с этой проблемой Magento разбивает таблицы на меньшие единицы. Я не хочу воссоздавать всю систему EAV в этом ответе, поэтому, пожалуйста, примите эту упрощенную модель:
PRODUCT: product_id INT sku VARCHAR PRODUCT_ATTRIBUTE_VALUES product_id INT attribute_id INT value MISC PRODUCT_ATTRIBUTES attribute_id name
Теперь можно добавлять атрибуты по желанию, введя новые значения в product_attributes и затем помещая смежные записи в product_attribute_values . Это в основном то, что делает Magento (с меньшим уважением к типам данных, чем я показал здесь). Фактически, теперь нет никаких оснований для того, чтобы у двух продуктов были одинаковые поля, поэтому мы можем создавать целые типы продуктов с разными наборами атрибутов!
Однако эта гибкость сопряжена с большими затратами. Если я хочу найти color рубашки в моей системе (тривиальный пример), мне нужно найти:
product_id элемента (в таблице продуктов) attribute_id для color (в таблице атрибутов) value (в таблице attribute_values) Мадженто работал так, но он был мертв медленно. Таким образом, чтобы обеспечить лучшую производительность, они сделали компромисс: после того, как владелец магазина определил нужные им атрибуты, вперед и создайте большую таблицу с самого начала. Когда что-то меняется, удалите его из космоса и сгенерируйте его снова. Таким образом, данные хранятся в основном в нашем удобном гибком формате, но запрашиваются из одной таблицы.
Эти результирующие таблицы поиска представляют собой «индексы» Magento. Когда вы повторно индексируете, вы взрываете старый стол и генерируете его снова.
Надеюсь, что это немного разъяснит!
Спасибо, Джо
Индексирование Magento не похоже на обычное индексирование базы данных и больше похоже на процесс денормализации базы данных (http://en.wikipedia.org/wiki/Denormalization). В большинстве случаев он занимает структуру EAV и делает ее доступной для структуры плоских таблиц, которая, без сомнения, быстрее доступна для доступа и поиска.
Если ваш обычный запрос EAV будет состоять из 200 левых объединений для получения всех продуктов в каталоге и данных по их атрибутам и многоуровневым навигационным значениям, то после «индексации» эти данные будут доступны через денормализованную структуру данных для более быстрого запроса / доступа
Индексирование Magento как-то похоже на обычное индексирование базы данных, но различие заключается в том, что вам нужно сделать это вручную в некотором случае.
когда вы индексируете, например, индексирование каталога, тогда он делает запись вашего продукта каталога в отдельной таблице для различного типа сортировки. Маленьким примером является хранилище, предположим, что у вас есть продукт и разные детали для разных магазинов, затем сначала он будет извлекать запись из сложных объединений в отдельной таблице (когда вы будете выполнять индексирование)
Другим лучшим примером является многоуровневая индексация навигации: если вы запустите многоуровневую навигационную индексацию, то она проверит в базе данных продукта все атрибуты атрибута shop, а затем по каждому атрибуту, как может быть доступен продукт, он также сохранит это значение.
В основном такой тип индексации требуется, если вы делаете некоторые прямые изменения в базе данных или, хотя ваш собственный код
Пожалуйста, дайте мне знать, если у вас есть другой запрос на индексирование