Administrace komentářů

Zrovna jsem chtěl položit podobnou otázku

Přemýšlel jsem nad datovým modelem pro atributy produktů v obchodě. Dejme tomu, že chci udělat něco jako eBay (ale lepší samozřejmě).

Požadavky:

• Máme slovník atributů – barva, rozměry, počet USB portů, jejich rychlosti, maximální rychlost, počet pokojů atd. klasika.
• Atributů budou stovky až tisíce, možná i víc a budou přibývat.
• Atribut může mít víc hodnot, např. rozhraní = {VGA, HDMI, DVI}.
• Nemáme pevně dané skupiny atributů (např. grafické karty mají atributy g1 až g10, reproduktory mají atributy r1 až r5); jakýkoli výrobek může mít nastaven jakýkoli atribut – to už záleží na tom, kdo zadává data, systém ale použití neomezuje.
• Atributy mohou mít různé datové typy (celé číslo, desetinné číslo, boolean, datum, výčtový typ…).
• Produkt může mít víc variant, které se mohou v některých atributech lišit zatímco jiné zase dědí.
• Kromě atributů tam budou hierarchie a budeme chtít prohledávat určitý podstrom – např. „oddělení: počítačové komponenty / grafické karty“ nebo „země výrobce: Asie / Čína“ i tyhle stromové dotazy můžou být spojené AND a OR operátory – např. „grafická karta AND (Čína OR Korea)“.
• Je potřeba mít dotazovací jazyk, který umožňuje psát složité dotazy typu: „rozměry jsou menší než X,Y,Z AND počet USB portů > 2 AND rozhraní = (VGA AND (HDMI OR DP)) AND operační systém NOT MS Windows“ + to umístění v podstromu (podstromech).
• Celé to musí být dostatečně rychlé a škálovatelné.

Tohle je takový ideál, možná nedosažitelný, ke kterému se dá jen přiblížit…

Mám rád relační databáze, na většinu úloh je to ideální nástroj a relační databáze tam určitě bude¹, takže je celkem přirozené to zkusit navrhnout nad ní. Taky je dobré minimalizovat počet použitých technologií. Na druhou stranu ve výsledku to dopadne spíš tak, že budou databáze dvě: relační na většinu dat + nějaká jiná pro atributy a hierarchie + možná ještě něco dalšího pro fulltext.

Co mě zatím napadlo:

• EAV – jakkoli se nedoporučuje, úplně bych ho nezavrhoval. Zpočátku bude dat málo a mohlo by to v pohodě fungovat. S rostoucím objemem dat se přejde na jinou technologii/model. Je totiž naivní si myslet, že na začátku člověk vybere vhodný nástroj, který mu vydrží navěky – hodně věcí se ukáže až v průběhu reálného používání a sebelepší analýza je nedokáže předem odhalit. Třeba se ukáže, že klíčové je něco jiného, než vyhledávání podle atributů a nemá cenu na něj plýtvat čas (třeba nebude chtít nikdo ty atributy zadávat nebo podle nich vyhledávat a bylo by to celé zbytečná práce).
• EAV jako primární zdroj dat + jeho denormalizovaná kopie pro lepší vyhledávání – nějaký index, materializovaný pohled, nebo dynamicky vytvořené a naplněné tabulky. To by mohlo celkem fungovat, ale tuším tam problém s prohledáváním vícenásobných atributů – buď to budou pole a tam nevím, jak to bude s rychlostí a indexy, nebo to bude více záznamů v tabulce a tam se budou hůř psát AND dotazy (OR v pohodě).
• Dynamicky generovaná tabulka, která bude obsahovat sloupec pro každý atribut – těch ale můžou být tisíce nebo i víc – jak si s tím poradí třeba PostgreSQL? Jaká bude efektivita uložení takových dat? (většina sloupečků bude prázdná – řídká data)
• Dynamicky generované tabulky – pro každý atribut jedna – opět jich můžou být tisíce nebo víc. V obou předchozích případech bude zase problém s prohledáváním vícenásobných atributů.
• XML sloupec obsahující atributy + nějaký index nad ním
• RDF databáze a jazyk SPARQL – tohle vypadá celkem slibně. Máte s tím někdo zkušenost jako s databází pro produktové atributy? Jak dobře se píší složitější dotazy? Jak je to s výkonem? Např. Apache Jena, 4store nebo MonetDB.
• Sloupcové databáze, Druid.io, Apache Cassandra, Hadoop, Neo4j…

P.S. zatím to jsou spíš teoretické úvahy a diskuse na nedělní odpoledne

_{[1] fakt nechci vést účetnictví nebo údaje o klientech v nějaké bezschémové/noSQL databázi a mít tam bordel a při psaní každého dotazu si rvát vlasy}