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í

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)
• hack²: 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í

1. přesná shoda všech párovacích elementů
   • a co když se změní URL?
2. 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!

Konec