У мене є магазин, і весь час ВСІ індекси недійсні. Я помітив, що у мене немає поняття, коли індекс недійсний.
Чи можете ви надати мені список "всіх" подій, які роблять один чи більше цих індексів недійсними?
Відповіді:
Зробивши греп на каталозі кодів, ви отримаєте список файлів, які викликають недійсність.
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 є
Атрибути продукту
специфічний атрибут збереження (є частиною плоского продукту), зберігати, зберігати_групу, якщо включений продукт плоского каталогу
Ціни на продукцію
перевірка збереження налаштувань конфігурації (як ціна). або зберегти продукт, створити / видалити веб-сайт
Каталог URL Переписує
немає конкретної інвалідизації
Дані про плоскі продукти
Конкретний атрибут збереження (є частиною плоского продукту), якщо увімкнено плоский каталог продукту, Після увімкнення плоского продукту
Категорія Плоскі дані
Перевірити рівну категорію каталогів увімкнено та конкретну категорію збереження, Після активації рівну категорію
Категорія Продукція
Перевірити рівну категорію каталогів увімкнено та конкретну категорію збереження
Каталог пошуку в каталозі
специфічний атрибут збереження (є частиною атрибутів для пошуку), зберігайте, зберігайте_групу, якщо включений плоский каталог каталогу
Дані агрегації тегів
Ніколи не визнається недійсним, крім загальних умов, зазначених нижче
Статус запасу
специфічна Система> Налаштування параметрів на вкладці «Інвентар», наприклад, показуйте товари, що не є на складі
Усі вони визнаються недійсними після System > Tools > Backupвідкопування резервної копії та створення, видалення або переміщення по веб-сайтах, магазинах і переглядах магазинів. Після запуску імпорту потоку даних для продукту недійсні:
Кілька індексаторів, як плоскі дані та індексатор 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.
Підводячи підсумок: зрозумійте сфери своєї проблеми, перш ніж сліпо застосовувати рішення. Оскільки не кожен біт даних буде точно таким же, і планувати та впроваджувати рішення ПІСЛЯ ви добре зрозуміли / вирішили проблему. Оптимізація бази даних може бути дуже корисною для управління змінами. Такі як запобігання страху 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. :(
Список літератури: