Párování v Mergadu
Na co párování?
- změny musí po přegenerování přežít
- logování změn (+ 2, ~ 5, - 1, ! 0)
- některé eshopy nepoužívají ITEM_ID
- manuální změny přežívají i u produktů, které ze vstupu na čas zmizí
Jak funguje párování?
- u každého projektu máme "pairing elements"
- párovací elementy musí být unikátní
Pro každý element v párovacích elementech projektu:
- Pro aktuální produkt vezmi hash hodnoty elementu
- Pokud existuje hash v tabulce pairing pouze jednou, vrať produkt
Pokud pro žádný párovací element nebyl nalezen unikátní produkt, vytvoří se nový produkt i záznam v tabulce pairing.
Chyby v párování
- produkt bez unikátního párovacího elementu
- bude vytvořen znovu, při každé synchronizaci
- extrém: projekt s 10k produkty měl v tabulce pairing 5M produktů
- hack: varianty u starého formátu Zboží.cz (PRODUCTNAME + PRODUCTNAMEEXT)
- hack2: kvůli duplicitám v tabulce pairing
Špatný návrh DB
- sloupec pro každý párovací element
Špatný návrh DB
- sloupec pro každý párovací element
Špatný návrh DB
- sloupec pro každý párovací element
- cca 27 miliónů záznamů
- cca 5 GB velikost dat na disku
- cca 15 GB velikost indexu
Redesign párování
- "rozumný" algoritmus párování
- lepší schéma databáze
Rozumné párování
- přesná shoda všech párovacích elementů
- a co když se změní URL?
- hledání prvního unikátního produktu "zdola"
- Příklad: pár. elementy ITEM_ID, URL, EAN
- je ITEM_ID nebo URL nebo EAN unikátní?
- je (ITEM_ID, URL) nebo (URL, EAN) nebo ...
- je (ITEM_ID, URL, EAN) unikátní?
Lepší DB schéma
- tabulka s univerzálními názvy sloupců
- hash1, hash2, hash3, ..., hashN
- jak velké bude N?
- jakou dat. strukturu použít pro párování?
- budeme tabulku načítat do paměti?
Problémy s imigrací
- synchronizaci je potřeba kompletně přepsat
- migrace dat bude náročná, je nutná záloha!
- XID produktů se nesmí změnit (kvůli ITEM_ID)
- je potřeba promazat všechny duplicity!