sql >> Databáze >  >> RDS >> Mysql

Může někdo podrobně vysvětlit funkci indexování Magentos?

Indexování Magenta je v duchu podobné pouze indexování na úrovni databáze. Jak uvádí Anton, jde o proces denormalizace, který umožňuje rychlejší provoz webu. Pokusím se vysvětlit některé myšlenky, které stojí za strukturou databáze Magento, a proč je indexování nezbytné, aby fungovalo rychle.

V "typičtější" databázi MySQL by tabulka pro ukládání katalogových produktů měla strukturu zhruba takto:

PRODUCT:
    product_id INT
    sku        VARCHAR
    name       VARCHAR
    size       VARCHAR
    longdesc   VARCHAR
    shortdesc  VARCHAR
    ... etc ...

Toto je rychlé načítání, ale pro software elektronického obchodu to ponechává zásadní problém:co děláte, když chcete přidat další atributy? Co když prodáváte hračky a místo sloupce velikosti potřebujete age_range ? Mohli byste přidat další sloupec, ale mělo by být jasné, že ve velkém obchodě (například Walmart) by to vedlo k řádkům, které jsou z 90 % prázdné a pokusy o údržbu nových atributů jsou téměř nemožné.

Aby se tento problém vyřešil, Magento rozděluje stoly na menší jednotky. Nechci v této odpovědi znovu vytvářet celý systém EAV, proto prosím přijměte tento zjednodušený model:

PRODUCT:
    product_id INT
    sku        VARCHAR

PRODUCT_ATTRIBUTE_VALUES
    product_id   INT
    attribute_id INT
    value        MISC

PRODUCT_ATTRIBUTES
    attribute_id
    name

Nyní je možné libovolně přidávat atributy zadáním nových hodnot do product_attributes a poté vložení sousedních záznamů do product_attribute_values . To je v podstatě to, co Magento dělá (s trochu větším respektem k datovým typům, než jsem zde zobrazil). Ve skutečnosti nyní není důvod, aby dva produkty měly identická pole, takže můžeme vytvořit celé typy produktů s různými sadami atributů!

Tato flexibilita však něco stojí. Pokud chci najít color košile v mém systému (triviální příklad), potřebuji najít:

  1. product_id položky (v tabulce produktů)
  2. attribute_id pro color (v tabulce atributů)
  3. Nakonec skutečná value (v tabulce atribut_values)

Magento takhle fungovalo, ale bylo to smrtelně pomalé. Aby tedy umožnili lepší výkon, udělali kompromis:jakmile majitel obchodu definoval atributy, které chtějí, pokračujte a generujte velkou tabulku od začátku. Když se něco změní, vystřelte to z vesmíru a vygenerujte to znovu. Tímto způsobem jsou data uložena primárně v našem pěkném flexibilním formátu, ale dotazována z jediné tabulky.

Tyto výsledné vyhledávací tabulky jsou "indexy" Magento. Když přeindexujete, vyhodíte do povětří starou tabulku a vygenerujete ji znovu.

Doufám, že to trochu objasní věci!

Díky, Joe



  1. Neznámá chyba sloupce v tomto COUNT příkazu MySQL?

  2. VYBERTE jeden sloupec, pokud je druhý prázdný

  3. aktualizovat sloupec tabulky po vložení nového záznamu pomocí spouštěčů MySQL

  4. jak získat sloupec podobný rowNum v sqlite IPHONE