17 januari 2018 - Marco de Vries (Eigenaar / Back-end ontwikkelaar)

Magento 2 Partiële Herindexering

Magento 2 treft veel maatregelen om de snelheid van de webshop te verhogen. Het heeft meer dan 30 index-tabellen om de shopping-ervaring voor de gebruiker aangenaam te maken, en daarnaast nog een flat product table en een flat category table per store view, als flat tables ingeschakeld zijn.

English translation of this article.

Als database entiteiten als producten, categorieën en klanten aangepast worden, moeten deze indexen worden bijgewerkt. Magento heeft twee manieren om dit te doen, genaamd “Indexeren bij opslaan” (“Update on Save”) en “Volgens schema bijwerken” (“Update by Schedule”).

Ik zal de term “entiteiten” hier gebruiken voor zowel producten, categorieën als klanten.

Indexeren bij opslaan is het makkelijkst uit te leggen. Steeds als een entiteit wordt toegevoegd, gewijzigd, of verwijderd in de backend of via een REST request, worden alle noodzakelijke indexen bijgewerkt om deze wijziging op te vangen. Een groot aantal extra SQL queries worden uitgevoerd in hetzelfde request dat de entiteit toevoegt, bijwerkt, of verwijdert. De index wordt niet volledig opgebouwd, het wordt alleen een beetje aangepast. Specifieke onderdelen van caches worden direct geleegd om ervoor te zorgen dat de wijziging direct zichtbaar is op de webshop.

Volgens schema bijwerken past de indexen niet aan binnen het request. Het is zelfs zo dat Magento alleen die queries uitvoert die nodig zijn om de entiteit te wijzigen, en verder niks. Toch wordt de index bijgewerkt en specieke cache-onderdelen efficiënt geleegd binnen enkele minuten.

In de rest van dit blog artikel zal ik uitleggen hoe deze Volgens-schema-bijwerken-magie werkt.

Hoe werkt het?

In het kort, Magento 2 maakt triggers aan voor elke “Volgens schema bijwerken” index. Deze triggers vuren naar aanleiding van iedere INSERT, UPDATE en DELETE op elk van de tabellen van de entiteit. Bij het vuren schrijven ze een nieuwe regel met de id van entiteit in een specifieke changelog tabel. Als de cron job loopt vergelijkt het de version_id van zijn mview_state tabel met de version_ids uit de changelog tabel. De index wordt bijgewerkt voor alle entiteiten die als gewijzigd zijn gemarkeerd. Ook worden caches voor specifieke entiteiten geleegd.

Ik zal hier nu in meer detail op in gaan.

Volledige Herindexering en Partiële Herindexering

Sommige processen (zowel uit de core als van extensies) maken expliciet de complete index ongeldig. De gebruiker kan dit zien in de backend:

De geldigheid van alle indexen is opgeslagen in de tabel indexer_state:

MySQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
mysql> select * from indexer_state;
+----------+---------------------------+---------+---------------------+----------------------------------+
| state_id | indexer_id                | status  | updated             | hash_config                      |
+----------+---------------------------+---------+---------------------+----------------------------------+
|        1 | design_config_grid        | valid   | 2017-11-28 11:44:19 | 27baa8fe6a5369f52c8b7cbd54a3c3c4 |
|        2 | customer_grid             | valid   | 2017-11-28 11:44:19 | d572ea00944c9e3f517b3f46bad058a4 |
|        3 | catalog_category_product  | valid   | 2017-11-28 11:54:50 | 57b48d3cf1fcd64abe6b01dea3173d02 |
|        4 | catalog_product_category  | valid   | 2017-11-28 11:54:50 | 9957f66909342cc58ff2703dcd268bf4 |
|        5 | catalog_product_price     | valid   | 2017-11-28 11:57:01 | 15a819a577a149220cd0722c291de721 |
|        6 | catalog_product_attribute | valid   | 2017-11-28 11:59:42 | 77eed0bf72b16099d299d0ab47b74910 |
|        7 | cataloginventory_stock    | invalid | 2017-11-28 11:59:47 | 78a405fd852458c326c85096099d7d5e |
|        8 | catalogrule_rule          | valid   | 2017-11-28 11:59:48 | 5afe3cacdcb52ec3a7e68dc245679021 |
|        9 | catalogrule_product       | valid   | 2017-11-22 11:05:50 | 0ebee9e52ed424273132e8227fe646f3 |
|       10 | catalogsearch_fulltext    | valid   | 2017-11-28 12:12:03 | 4486b57e2021aa78b526c68c9af2dcab |
|       11 | catalog_category_flat     | valid   | 2017-10-09 08:42:15 | 274b10653a52879cde1daf57a1cd21c0 |
|       12 | catalog_product_flat      | valid   | 2017-11-28 11:45:14 | b4384337c8916c0251c2ea5c5477c5f0 |
+----------+---------------------------+---------+---------------------+----------------------------------+

Magento’s cronjob “indexer_reindex_all_invalid” bouwt alle ongeldige indexen opnieuw op.

Als de cronjobs niet actief zijn, kun je een CLI commando gebruiken om alle indexen opnieuw op te bouwen, of alleen een specifieke index:

Shell
1
bin/magento indexer:reindex

Dit commando herbouwt de indexen van de grond af aan. Voor webshops van enige omvang is dit een behoorlijke operatie. Met duizenden producten, een groot aantal categorieën en veel store views, kan dit al snel een uur duren.

Voor een shop in productie is dit onwenselijk. Gelukkig is het aantal gevallen waarin een volledige index herbouwd moet worden klein. Magento 2 kan de meeste aanpassingen aan entiteiten afhandelen door de index incrementeel bij te werken. Dit proces heet partiële herindexering.

Index Beheer and Materialized Views

De indexen en flat tables zijn binnen Magento 2 bekend als “mviews”.

Een “view”, in database terminologie, is een virtuele tabel die het resultaat weergeeft van een SELECT query. De view is live: het geeft steeds de actuele toestand van de data weer.

Een “materialized view” is een virtuele tabel die het opgeslagen resultaat weergeeft van een SELECT query. De inhoud is niet live, maar moet regelmatig worden bijgewerkt. Een materialized view is veel sneller dan een normale view omdat het eenvoudig uit te lezen is.

MySQL kent geen echte materialized views, maar een normale tabel kan als zodanig dienst doen. Dit is wat Magento doet. Magento’s “indexen” and “flat tables” zijn zulke materialized views.

In de backend kun je selecteren op welke manier Magento de indexen moet bijwerken. Je kunt dit per per index aangeven.

Als voorbeeld dat ik verder uitwerk, stel ik alleen de index “Product Platte Data” (catalog_product_flat) in op “Volgens schema bijwerken” en de rest op “Indexeren bij opslaan”.

Het effect op de database van deze admin actie wordt weergegeven in de tabel mview_state:

MySQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
mysql> select * from mview_state;
+----------+---------------------------+----------+--------+---------------------+------------+
| state_id | view_id                   | mode     | status | updated             | version_id |
+----------+---------------------------+----------+--------+---------------------+------------+
|        1 | catalog_product_category  | disabled | idle   | 2018-01-10 15:04:47 |       NULL |
|        2 | catalog_category_product  | disabled | idle   | 2018-01-10 15:05:16 |       NULL |
|        3 | design_config_dummy       | disabled | idle   | 2018-01-10 15:04:47 |       NULL |
|        4 | customer_dummy            | disabled | idle   | 2018-01-10 15:04:47 |       NULL |
|        5 | catalog_product_flat      | enabled  | idle   | 2018-01-10 15:05:00 |       NULL |
|        6 | catalog_product_price     | disabled | idle   | 2018-01-10 14:41:26 |       NULL |
|        7 | catalog_product_attribute | disabled | idle   | 2018-01-10 14:41:26 |       NULL |
|        8 | cataloginventory_stock    | disabled | idle   | 2018-01-10 14:41:27 |       NULL |
|        9 | catalogrule_rule          | disabled | idle   | 2018-01-10 14:41:27 |       NULL |
|       10 | catalogrule_product       | disabled | idle   | 2018-01-10 14:41:28 |       NULL |
|       11 | catalogsearch_fulltext    | disabled | idle   | 2018-01-10 14:41:29 |       NULL |
+----------+---------------------------+----------+--------+---------------------+------------+

Zoals je ziet, is alleen de index “catalog_product_flat” is ingeschakeld. Merk op dat de tabel een kolom version_id heeft. Hier komen we zo op terug.

Triggers

Een database trigger is een event handler die reageert op veranderingen in a database tabel.

Als een index ingesteld wordt op “Volgens schema bijwerken”, maakt Magento 2 er een aantal triggers voor aan. Voor catalog_product_flat alleen al worden 30 triggers aangemaakt. Ik zal er hier slechts 3 tonen:

MySQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
mysql> show triggers \G
 
*************************** 1. row ***************************
             Trigger: trg_catalog_product_entity_after_insert
               Event: INSERT
               Table: catalog_product_entity
           Statement: BEGIN
INSERT IGNORE INTO `catalog_product_flat_cl` (`entity_id`) VALUES (NEW.`entity_id`);
END
              Timing: AFTER
             Created: 2018-01-10 16:04:59.54
            sql_mode:
             Definer: some-magento-user@localhost
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
*************************** 2. row ***************************
             Trigger: trg_catalog_product_entity_after_update
               Event: UPDATE
               Table: catalog_product_entity
           Statement: BEGIN
INSERT IGNORE INTO `catalog_product_flat_cl` (`entity_id`) VALUES (NEW.`entity_id`);
END
              Timing: AFTER
             Created: 2018-01-10 16:04:59.56
            sql_mode:
             Definer: some-magento-user@localhost
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
*************************** 3. row ***************************
             Trigger: trg_catalog_product_entity_after_delete
               Event: DELETE
               Table: catalog_product_entity
           Statement: BEGIN
INSERT IGNORE INTO `catalog_product_flat_cl` (`entity_id`) VALUES (OLD.`entity_id`);
END
              Timing: AFTER
             Created: 2018-01-10 16:04:59.57
            sql_mode:
             Definer: some-magento-user@localhost
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci

De 3 triggers die je hier ziet corresponderen allen met veranderingen in de tabel “catalog_product_entity” (zie Table). De events zijn INSERT, UPDATE, en DELETE. Omdat er 10 tabellen bestaan die als bron dienen voor de inhoud van de materialized view catalog_product_flat, zijn er 3 x 10 = 30 triggers nodig om alle gevallen af te dekken.

De event handlers voor de “catalog_product_flat” index schrijven allemaal een enkele record in de changelog tabel “catalog_product_flat_cl”:

MySQL
1
2
3
4
5
CREATE TABLE `catalog_product_flat_cl` (
  `version_id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Version ID',
  `entity_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'Entity ID',
  PRIMARY KEY (`version_id`)
) ENGINE=InnoDB AUTO_INCREMENT=118 DEFAULT CHARSET=utf8 COMMENT='catalog_product_flat_cl'

Elke index heeft zijn eigen changelog (cl) tabel. De tabel toont alleen de id’s van de entiteiten die “dirty” zijn, en wiens index entry toegevoegd, gewijzigd of verwijderd moet worden.

De Entiteit Wordt Gewijzigd

Als een entiteit wordt gewijzigd, via de backend, via een REST call, of zelfs via een directe SQL query in phpMyAdmin, vuren sommige triggers.

De triggers vuren uitbundig, zodat een enkele wijziging aan een entiteit meerdere regels in de changelog tabel tot gevolg heeft:

MySQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
mysql> select * from catalog_product_flat_cl limit 10;
+------------+-----------+
| version_id | entity_id |
+------------+-----------+
|          1 |     22601 |
|          2 |     22601 |
|          3 |     22601 |
|          4 |     22601 |
|          5 |     22601 |
|          6 |     22601 |
|          7 |     22601 |
|          8 |     22601 |
|          9 |     22601 |
|         10 |     22601 |
+------------+-----------+
10 rows in set (0,00 sec)

De version_id kolom is slechts een auto-increment veld.

De Cronjob Partiële Herindexering

In een doorsnee Magento installatie, runt de cron job ieder minuut. De cron job voert vele taken uit. Een van deze is “indexer_update_all_views”. Deze taak controleert voor iedere index of de version_id uit mview_state overeenkomt met de version_ids uit zijn changelog tabel.

De entity_ids van de changelog records met version_id groter dan de version_id uit mview_state worden verzameld, en de index wordt bijgewerkt voor deze entiteiten.

De cronjob leegt ook alle nodige caches. Dit gebeurt heel precies. Specifieke product-pagina en categorie-pagina caches worden geleegd. Niet de hele full page cache.

Daarna wordt de version_id in mview_state opgehoogd tot de hoogste version_id uit de changelog table.

Ieder uur verwijdert een andere cronjob, “indexer_clean_all_changelogs” alle changelog records met version_id kleiner dan die in mview_state.

Conclusie

Magento 2 stelt je in staat om producten van buiten af en van binnen uit te wijzigen. Ze kunnen niet alleen worden gewijzigd via the user interface (buiten), maar ook via direct database queries (binnen). “Volgens schema bijwerken” werkt de nodige indexen bij voor je.

Als je catalogus-producten wilt bijwerken op een manier die niet mogelijk is via Magento’s admin panel, of die sneller via een directe SQL query met phpMyAdmin of met een script kunnen worden uitgevoerd, dan is dit nog steeds mogelijk, zelfs op een productie webshop. Je hebt natuurlijk wel een goede kennis nodig van Magento’s MySQL tabellen. Maar de partiële herindexeringstechnieken van “Volgens schema bijwerken” zorgen ervoor dat alle noodzakelijke indexen en flat tables bijgewerkt worden, en dat zelfs specifieke caches geleegd worden.

Referenties

Reacties:

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.