Какую версию Magento вы используете? Довольно много изменений было сделано в v1.13 - так что ожидайте отличий в версии до этой версии. Вот хороший пост в блоге, объясняющий модуль mView и индексацию в версии 1.13 Magento: eschrade.com/page/…
Pitt
Ответы:
63
В Magento есть разные виды индексов.
Все индексаторы предназначены для ускорения работы.
Я расскажу здесь только о некоторых из них.
Флэт Индекс
Есть 2 таких индекса. Один для категорий и один для продуктов.
По умолчанию категории и объекты продукта (а также клиенты и адреса клиентов, но они не важны в этой ситуации) являются объектами EAV . Это очень хорошо для расширяемости. Но это снижает производительность, потому что для получения всех значений для всех атрибутов вам нужно много объединений или несколько запросов.
Вот где в игру вступает плоский индексатор.
Это превращает структуру EAV в плоскую структуру. Я имею в виду, что он создает таблицу (по одной на каждое представление магазина в Magento), в которой один столбец соответствует атрибуту. Это делает выбор быстрее. Для категорий все атрибуты преобразуются в столбцы таблицы. Для продуктов только те, которые вы помечаете как «Используемые в списке продуктов», потому что вы можете продавать все типы продуктов с разными атрибутами, и создание одной таблицы со столбцами gazillion может оказаться невозможным.
Кроме того, некоторые продукты могут быть отключены или не принадлежать определенному веб-сайту, и нет необходимости включать их в записи для поиска. Они исключены индексатором.
Сгенерированные плоские таблицы используются для чтения данных во внешнем интерфейсе. Бэкэнд все еще использует структуру EAV.
Индекс
поиска по каталогу Вы можете искать товары по множеству значений атрибутов. Некоторые из них могут не включаться в плоские таблицы, генерируемые плоским индексатором. Этот индекс заполняет таблицу значениями атрибутов для поиска для продуктов, поэтому их проще искать по ключевым словам. Наличие всей информации в одной таблице (или в одном поле) позволяет использовать полнотекстовый поиск и получать релевантные результаты.
Цены на продукцию .
На цену товара могут влиять многие переменные. Например, группа клиентов, сайт, каталог скидок.
То же, что и выше, получение товаров по их ценам будет означать много соединений или несколько вариантов выбора. Кроме того, комплектация товаров имеет странную систему ценообразования. Этот индексатор объединяет данные в некоторых таблицах ( catalog_product_index_price_*) и делает выборки (сортировку и фильтрацию) намного проще.
Каталог
переписывает URL Это очищает правила перезаписи URL, устанавливая, какой URL соответствует какому продукту или категории. Таким образом, внутренней системе управления URL проще решить, какую страницу следует просматривать при вызове нестандартного URL. Вместо поиска по всем URL-адресам ключей продуктов и категорий, он просто ищет в одной таблице.
Продукты категории
В Magento вы можете установить для атрибута категории «Is Anchor» значение true или false. Если это правда, это означает, что в рассматриваемой категории будут перечислены все товары из ее дочерних категорий. Опять же, определение этого в реальном времени потребует больше ресурсов, чем просто чтение одной таблицы. Этот индексатор создает связь между продуктами и категориями на основе ассоциаций, установленных в бэкэнде, и флага «Якорь» в категориях.
Статус склада
Для простых продуктов это просто. Они могут быть в наличии или в наличии, но для конфигурируемых, сгруппированных и связанных не так просто. Они могут быть на складе или на складе в зависимости от дочерних продуктов, связанных с основным продуктом. Опять же (я просто повторяю себя здесь), получение статуса в реальном времени означало бы много запросов.
Атрибуты продукта .
Он собирает все атрибуты, которые можно использовать в многоуровневой навигации по той же причине. Наличие всех их в одном месте для быстрого чтения.
Агрегация тегов
Я понятия не имею, что это делает. Я никогда не использовал теги в реальном живом проекте.
спасибо, Мариус, это пока лучший ответ ... я получил
сонам
Что вы имели в виду, когда говорили, что плоские таблицы используются только во внешнем интерфейсе (а в бэкэнде все еще используется структура EAV)? Я новичок, и из того, что я понял, когда мы создаем / обновляем сущности, такие как продукты, он все еще использует таблицы EAV для выполнения этих операций, и мы должны установить опцию обновления плоских таблиц после сохранения или обновления их вручную для эти изменения должны быть отражены в плоских таблицах. Вы имеете в виду этот процесс, когда сказали это? Не могли бы вы уточнить это, пожалуйста? Благодарность!
Бхарадвад Сригирираджу
1
@Marius: во время переиндексации я получаю ошибку переполнения таблицы. Пожалуйста помоги. Я получаю сообщение об ошибке: Таблица 'catalog_product_index_price_bundle_sel_tmp' заполнена
Черная Борода
1
@Marius после 3-х лет ответа на этот вопрос, теперь у вас есть какие-либо идеи об объединении тегов, связано ли это с тегами продуктов?
Муртуза Забуавала
1
@Black. У вас есть 2 настройки для индексов. «Обновить при сохранении» и «Вручную». Для обновления при сохранении все должно происходить автоматически при сохранении продукта. Но это может вызвать проблемы с производительностью. Например, если вы меняете несколько продуктов одновременно. В ручном режиме переиндексация не запускается сразу после сохранения, но вам придется перестраивать вручную, когда вы закончите.
Индексирование 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 (с немного большим уважением к типам данных, чем я показал здесь). Фактически, теперь нет никаких причин для двух продуктов иметь одинаковые поля, поэтому мы можем создавать целые типы продуктов с разными наборами атрибутов!
Однако такая гибкость имеет свою цену. Если я хочу найти цвет рубашки в моей системе (тривиальный пример), мне нужно найти:
Product_id товара (в таблице товаров)
Атрибут attribute_id для цвета (в таблице атрибутов)
Наконец, фактическое значение (в таблице attribute_values)
Раньше Magento работал так, но это было очень медленно. Таким образом, чтобы обеспечить лучшую производительность, они пошли на компромисс: как только владелец магазина определил нужные атрибуты, продолжайте и создавайте большую таблицу с самого начала. Когда что-то меняется, уберите его из космоса и сгенерируйте заново. Таким образом, данные хранятся в основном в нашем удобном гибком формате, но запрашиваются из одной таблицы.
Эти результирующие таблицы поиска являются «индексами» Magento. Когда вы переиндексируете, вы взрываете старую таблицу и генерируете ее снова.
Magento - довольно мощная и сложная система. Это позволяет работать с большими объемами данных, но когда база данных перегружена тоннами записей, она становится тяжелой и медленной. Magento использует индексы для решения этой проблемы. Индексы представляют собой дополнительные таблицы базы данных с некоторыми плоскими данными, что позволяет организовать быстрые ответы из базы данных.
По умолчанию базовая система обновляет индексы при сохранении каждого элемента. Но в некоторых случаях вам нужно сделать это вручную, например, некоторые типы массовых действий и т. Д. Вы можете обновить индексы в любое время из административной части (Admin-> System-> Index Management). Но иногда это вызывает проблемы.
Например, если у вас более 10 тыс. Товаров и много категорий, перестройка индекса каталога перезаписи URL может занять несколько часов. Тогда скрипт php может просто сломаться из-за превышения max_execution_time. Есть способ решить несколько проблем, запустив процесс переиндексации из командной строки.
Ответы:
В Magento есть разные виды индексов.
Все индексаторы предназначены для ускорения работы.
Я расскажу здесь только о некоторых из них.
Флэт Индекс
Есть 2 таких индекса. Один для категорий и один для продуктов.
По умолчанию категории и объекты продукта (а также клиенты и адреса клиентов, но они не важны в этой ситуации) являются объектами EAV . Это очень хорошо для расширяемости. Но это снижает производительность, потому что для получения всех значений для всех атрибутов вам нужно много объединений или несколько запросов.
Вот где в игру вступает плоский индексатор.
Это превращает структуру EAV в плоскую структуру. Я имею в виду, что он создает таблицу (по одной на каждое представление магазина в Magento), в которой один столбец соответствует атрибуту. Это делает выбор быстрее. Для категорий все атрибуты преобразуются в столбцы таблицы. Для продуктов только те, которые вы помечаете как «Используемые в списке продуктов», потому что вы можете продавать все типы продуктов с разными атрибутами, и создание одной таблицы со столбцами gazillion может оказаться невозможным.
Кроме того, некоторые продукты могут быть отключены или не принадлежать определенному веб-сайту, и нет необходимости включать их в записи для поиска. Они исключены индексатором.
Сгенерированные плоские таблицы используются для чтения данных во внешнем интерфейсе. Бэкэнд все еще использует структуру EAV.
Индекс
поиска по каталогу Вы можете искать товары по множеству значений атрибутов. Некоторые из них могут не включаться в плоские таблицы, генерируемые плоским индексатором. Этот индекс заполняет таблицу значениями атрибутов для поиска для продуктов, поэтому их проще искать по ключевым словам. Наличие всей информации в одной таблице (или в одном поле) позволяет использовать полнотекстовый поиск и получать релевантные результаты.
Цены на продукцию .
На цену товара могут влиять многие переменные. Например, группа клиентов, сайт, каталог скидок.
То же, что и выше, получение товаров по их ценам будет означать много соединений или несколько вариантов выбора. Кроме того, комплектация товаров имеет странную систему ценообразования. Этот индексатор объединяет данные в некоторых таблицах (
catalog_product_index_price_*) и делает выборки (сортировку и фильтрацию) намного проще.Каталог
переписывает URL Это очищает правила перезаписи URL, устанавливая, какой URL соответствует какому продукту или категории. Таким образом, внутренней системе управления URL проще решить, какую страницу следует просматривать при вызове нестандартного URL. Вместо поиска по всем URL-адресам ключей продуктов и категорий, он просто ищет в одной таблице.
Продукты категории
В Magento вы можете установить для атрибута категории «Is Anchor» значение true или false. Если это правда, это означает, что в рассматриваемой категории будут перечислены все товары из ее дочерних категорий. Опять же, определение этого в реальном времени потребует больше ресурсов, чем просто чтение одной таблицы. Этот индексатор создает связь между продуктами и категориями на основе ассоциаций, установленных в бэкэнде, и флага «Якорь» в категориях.
Статус склада
Для простых продуктов это просто. Они могут быть в наличии или в наличии, но для конфигурируемых, сгруппированных и связанных не так просто. Они могут быть на складе или на складе в зависимости от дочерних продуктов, связанных с основным продуктом. Опять же (я просто повторяю себя здесь), получение статуса в реальном времени означало бы много запросов.
Атрибуты продукта .
Он собирает все атрибуты, которые можно использовать в многоуровневой навигации по той же причине. Наличие всех их в одном месте для быстрого чтения.
Агрегация тегов
Я понятия не имею, что это делает. Я никогда не использовал теги в реальном живом проекте.
источник
Не могу взять кредит на себя, так как он взят из оригинального поста по адресу: /programming/4945307/can-someone-explain-magentos-indexing-feature-in-detail
Индексирование Magento похоже только на индексирование на уровне базы данных по духу. Как утверждает Антон, это процесс денормализации, позволяющий ускорить работу сайта. Позвольте мне попытаться объяснить некоторые соображения, лежащие в основе структуры базы данных Magento, и почему она делает индексацию необходимой для быстрой работы.
В более «типичной» базе данных MySQL таблица для хранения каталожных продуктов будет иметь такую структуру:
Это быстро для поиска, но это оставляет фундаментальную проблему для части программного обеспечения электронной коммерции: что вы делаете, когда хотите добавить больше атрибутов? Что делать, если вы продаете игрушки, а не размер столбца, вам нужно age_range? Можно добавить еще один столбец, но должно быть ясно, что в большом хранилище (например, в Walmart) это приведет к пустым строкам на 90%, а попытка обслуживания новых атрибутов практически невозможна.
Чтобы решить эту проблему, Magento разбивает таблицы на более мелкие единицы. Я не хочу воссоздавать всю систему EAV в этом ответе, поэтому, пожалуйста, примите эту упрощенную модель:
Теперь можно добавлять атрибуты по желанию, вводя новые значения в product_attributes, а затем помещая соседние записи в product_attribute_values. Это в основном то, что делает Magento (с немного большим уважением к типам данных, чем я показал здесь). Фактически, теперь нет никаких причин для двух продуктов иметь одинаковые поля, поэтому мы можем создавать целые типы продуктов с разными наборами атрибутов!
Однако такая гибкость имеет свою цену. Если я хочу найти цвет рубашки в моей системе (тривиальный пример), мне нужно найти:
Раньше Magento работал так, но это было очень медленно. Таким образом, чтобы обеспечить лучшую производительность, они пошли на компромисс: как только владелец магазина определил нужные атрибуты, продолжайте и создавайте большую таблицу с самого начала. Когда что-то меняется, уберите его из космоса и сгенерируйте заново. Таким образом, данные хранятся в основном в нашем удобном гибком формате, но запрашиваются из одной таблицы.
Эти результирующие таблицы поиска являются «индексами» Magento. Когда вы переиндексируете, вы взрываете старую таблицу и генерируете ее снова.
Надеюсь, это немного прояснит ситуацию!
источник
nuke it from space, здорово :)Magento - довольно мощная и сложная система. Это позволяет работать с большими объемами данных, но когда база данных перегружена тоннами записей, она становится тяжелой и медленной. Magento использует индексы для решения этой проблемы. Индексы представляют собой дополнительные таблицы базы данных с некоторыми плоскими данными, что позволяет организовать быстрые ответы из базы данных.
По умолчанию базовая система обновляет индексы при сохранении каждого элемента. Но в некоторых случаях вам нужно сделать это вручную, например, некоторые типы массовых действий и т. Д. Вы можете обновить индексы в любое время из административной части (Admin-> System-> Index Management). Но иногда это вызывает проблемы.
Например, если у вас более 10 тыс. Товаров и много категорий, перестройка индекса каталога перезаписи URL может занять несколько часов. Тогда скрипт php может просто сломаться из-за превышения max_execution_time. Есть способ решить несколько проблем, запустив процесс переиндексации из командной строки.
источник