У меня есть магазин, и все ВСЕ индексы недействительны. Я заметил, что понятия не имею, когда индекс недействителен.
Можете ли вы дать мне список «всех» событий, которые делают один или несколько из этих индексов недействительными?
Выполнение grep в каталоге кода даст вам список файлов, которые вызывают аннулирование.
grep -Ri '::STATUS_REQUIRE_REINDEX' .
Следующие основные файлы вызывают недействительность
./core/Mage/CatalogSearch/Model/Indexer/Fulltext.php
./core/Mage/Catalog/Model/Product/Indexer/Flat.php
./core/Mage/Catalog/Model/Product/Indexer/Price.php
./core/Mage/Catalog/Model/Category/Indexer/Flat.php
./core/Mage/Catalog/Model/Category/Indexer/Product.php
./core/Mage/Catalog/Model/System/Config/Backend/Catalog/Product/Flat.php
./core/Mage/Catalog/Model/System/Config/Backend/Catalog/Category/Flat.php
./core/Mage/Catalog/Model/Indexer/Url.php
./core/Mage/Backup/Helper/Data.php
./core/Mage/CatalogInventory/Model/Indexer/Stock.php
./core/Mage/ImportExport/Model/Import.phpОсновные события в ядре Magento CE:
Атрибуты продукта
определенный атрибут сохранения (является частью плоского продукта), store, store_group, если включен плоский каталог продукта
Цены на продукцию
проверка сохранения настроек конфигурации (например, объем цены). или продукт сохранить, сайт создать / удалить
Каталог URL переписывает
нет конкретного признания недействительным
Плоские данные продукта
Специфический атрибут сохранения (является частью плоского продукта), если продукт плоского каталога включен, после включения плоского продукта
Категория Плоские Данные
Проверьте, включена ли категория плоского каталога и определенная категория сохранения, После включения категории плоских
Категория Продукты
проверьте, включена ли категория плоского каталога и определенная категория сохранения
Индекс поиска по каталогу
определенный атрибут сохранения (является частью доступных для поиска атрибутов), store, store_group, если продукт плоского каталога включен
Данные агрегации тегов
Никогда не аннулируется, за исключением общих условий, указанных ниже
Состояние на складе
Конкретная система> Настройки конфигурации во вкладке инвентаризации сохраните, например, покажите, нет в наличии товаров
Все они становятся недействительными после отката резервной копии System > Tools > Backupи создания, удаления или перемещения по веб-сайтам, магазинам и магазинам. После запуска импорта потока данных для продукта становится недействительным следующее: catalog_product_price, catalog_category_product, catalogsearch_fulltext, catalog_product_flat
Некоторые индексаторы, такие как плоские данные и индексатор URL, также считаются недействительными при сохранении core_config_dataзначений.
Может быть, это идея временно создать переписать для этого сайта на
Mage_Index_Model_Resource_Process
Затем сделайте что-то вроде:
<?php
class YourNamespace_YourModule_Model_Resource_Process
extends Mage_Index_Model_Resource_Process
{
public function updateStatus($process, $status)
{
if ($status === Mage_Index_Model_Process::STATUS_REQUIRE_REINDEX) {
Mage::log(sprintf('Indexer %s was invalidated.', $process->getIndexer()->getName()), null, 'invalid_index.log', true);
foreach (debug_backtrace() as $db) {
Mage::log(sprintf('%s::%s', $db['class'], $db['function']), null, 'invalid_index.log', true);
}
}
return parent::updateStatus($process, $status);
}
}Это должно легко определить, когда индексатор становится недействительным, и трассировка вызова, которая за это ответственна.
Так как другие уже ответили на ваши вопросы по специфике. Я подумал, что может быть лучше объяснить, зачем нужна индексация и как она связана с Magento и как она связана с современными базами данных .
Индекс: алфавитный список имен, предметов и т. Д. Со ссылками на места, где они встречаются, как правило, в конце книги.
Так что же такое индекс с точки зрения баз данных ?
Индекс - это структура данных, которая сортирует количество записей в одном или нескольких полях и ускоряет поиск данных. Это сделано для того, чтобы при поиске в базе данных не сканировать дисковые блоки, охватываемые таблицей.
И что такое индексирование с точки зрения Magento ? Побочный продукт EAV (Entity Attribute Value) AKA базы данных в базе данных. При наличии нескольких таблиц поиска сбор всех атрибутов, помеченных как проиндексированные, должен быть объединен в одну плоскую таблицу всех таблиц поиска для более быстрых запросов и сокращения операций ввода-вывода и циклов ЦП.
Я вспоминаю упоминание о том, что, когда Magento изначально разрабатывался, гибкость была высокой в списке приоритетов, и понятно, почему они решили использовать модель данных EAV. Однако, в конечном счете, цена такой гибкости повлияла на производительность, и это с самого начала преследовало Magento.
В общем, инженерам Magento было поручено, в первую очередь, создать максимально гибкую, настраиваемую систему из возможных, а потом беспокоиться о производительности. Почему Magento такой медленный?
EAV отлично подходит для хранилищ данных, но ужасен для транзакций. Итак, для чего нам нужны индексы для начала? Поскольку тот же подход реляционной модели был реализован, Magento теперь должен обрабатывать все, что MySQL делает сам внутри себя. Некоторые вещи, которые следует учитывать, такие как индексы, уже существующие в таблицах MySQL. Имея это в виду также, рассмотрим модель данных EAV сейчас:
То же самое должно быть переопределено, что является очень «анти-шаблонным» ИМО.
Кроме того, по этой же причине вы обнаружите, var/locksчто индексатор использует блокировку процесса индексирования. По тем же причинам базы данных имеют блокировку строк / таблиц.
Теперь, когда запись, скажем, значение продукта было изменено, flat tableили index(как то, что MySQL назвал бы это) нужно обновить, чтобы отразить запросы на вновь измененные данные, которые можно найти быстро и эффективно без сканирования многочисленных записей. Плоские таблицы существуют так, как они используются по той же причине, по которой они есть в MySQL, без такого индекса (например, книги) для получения записи требуется полное сканирование таблицы. Это означает огромное количество операций ввода-вывода как для диска и памяти, так и для циклов ЦП для определения местоположения запрошенных данных, что очень плохо сказывается на производительности.
Поскольку Magento использует модель данных EAV, существует множество справочных таблиц, которые необходимо отсканировать, чтобы собрать все данные вместе, чтобы найти запрошенные данные. Это то, что происходит, если вы отключите каталоги Flat. Точно так же, как MySQL, сканирование для записи против использования индекса (плоская таблица), который будет использоваться, чтобы быстро найти запись, сохраняя драгоценные циклы ввода / вывода. Создание таблицы и отсутствие добавления индексов - это то же самое, что и использование плоских таблиц в magento. Хотя эти два сценария могут хорошо работать в разных сценариях, см . Очень хороший ответ Бена в Сонасси на этот вопрос. (Подсказка подразумевает понимание объема данных.)
Хотя это и не является прямым ответом на ваш вопрос, понимание движущихся частей и лучшая подготовка к ним должны помочь облегчить некоторые из головных болей, возникающих при индексировании. « Лечить проблему, а не симптом ».
Изучение внутренних особенностей современных систем баз данных может помочь лучше понять, как и почему необходима индексация и как она (в некоторой степени) связана с индексацией Magento.
Подводя итог: поймите ваши проблемы, прежде чем вслепую применять решения. Поскольку не все биты данных будут одинаковыми, а планирование и внедрение решений ПОСЛЕ того, как у вас будет хорошее / полное понимание проблемы. Оптимизация базы данных может быть очень полезной для управления изменениями. Такие, как предотвращение страшного DEADLOCKS.
Вы также можете рассмотреть возможность установки всех своих индексаторов Manualи настройки альтернативных процессов для перестройки индекса в часы непиковой нагрузки (когда администраторы отсутствуют). Только так Product Pricesи Stock Statusдолжно быть установлено Update on Save.
Теперь рассмотрим, как работает индексация с технической точки зрения. Основной модуль отвечает за индексацию Mage_Index. Основные модели индексатор: Indexer, Process, Event.
Mage_Index_Model_Indexerявляется индексатором, все взаимодействия с другими модулями модуля Mage_Indexпроисходят через этот сервис. Он содержит следующие методы:
processEntityAction() Создает и регистрирует событие и запускает процесс индексации.logEvent() Создает событие и регистрирует его для последующей индексации;indexEvent() Запускает события индексации;getProcessesCollection()Возвращает коллекцию всех процессов, таких как атрибуты продукта, цены продукта, перезапись URL-адресов каталога и т. Д. Обычно после изменения сущности, например, метода _afterSaveили _afterCommitмы выполняем частичное переиндексацию.Процесс Mage_Index_Model_Processили - это сущность вашего индексатора, который хранит состояние, последнюю операцию запуска. Все процессы хранятся в таблице index_process. В программе есть метод, getIndexer()который возвращает индекс модели. Большая часть задач делегирована процессом индексной модели.
Mage_Index_Model_Eventхранит информацию о произошедшем событии Например, мы храним продукт и после сохранения создаем новое событие и храним информацию о том, какой тип сущности мы только что сохранили, какой идентификатор имеет дух и какое действие мы выполнили для этого вещества.
Общий список, когда происходит недействительность:
Любая модель ресурсов с зарегистрированным индексом в модуле config.xmlпосле сохранения транзакции. afterCommitCallback()вызывается с префиксом. Здесь регистрируются события индекса, так как это происходит в конце успешной транзакции.
... и мне грустно, что EAV все еще есть в Magento 2. :(
Ссылки: