reklama

MySQL - podmíněný SELECT přes dvě tabulky

Kit

  • ****
  • 348
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #225 kdy: 26. 10. 2019, 15:47:39 »
Pomiňme, že Google pro tento účel nepoužívá SQL, ale vlastní databázi Big Table.

Jenže i v SQL tohle umíme. Stačí jen tu databázi normalizovat. Tabulka se nám rozpadne na tři tabulky a ejhle, najednou našeptávač neprochází milióny záznamů se štítky, ale jen stovky. Navíc je tabulka se štítky velmi úzká a tedy i rychlá. Samozřejmě má i svůj index.
Jenže tady vůbec nejde o databázi, ale o index. Našeptávač opravdu nemůže dělat fullscan tabulky, ani malé. Našeptávač musí vždy pracovat nad indexem. Teda pokud budete našeptávat z deseti hodnot, nemusíte to vůbec řešit v databázi a vyřešíte to na klientovi, ale o takovém případu se snad nebavíme.

Fullscan tabulky do tisíce záznamů je rychlejší, než použití indexu. Index pro více záznamů má význam až při selekci, tedy výběru podmnožiny, např. klauzulí WHERE, která vybere méně než cca 10-50 % záznamů.

Distinct je proveden teprve z této podmnožiny.

reklama


Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #226 kdy: 26. 10. 2019, 16:25:50 »
Tady se opět mýlíš. Protože dohledání bude sice přes dva indexy, ale jejichž souhrnná velikost a tedy i hloubka bude plus mínus podobná tomu jednomu indexu, velikost a rychlost dohledání samotného štítku bude oproti dohledání těch záznamů zanedbatelná úloha. Ovšem paměťová náročnost bude podstatně větší, protože ten ohromnej "denormalizaovanej index" bude jinak k ničemu, zatímco v druhém případě se použije malinký index přes štítky plus primární klíč.
Ve výsledku tedy vzhledem k hierarchickému paměťovému systému bude na rozumně zatížené databázi řešení s dvěma indexy zpravidla rychlejší, protože se nebude muset sahat pro řídčeji používaný index do pomalejších pamětí (anebo ten index naopak z těch pamětí nevytěsní jiná data, což zpomalí ostatní dotazy).
To ale popisujete případ 1 entita = 1 štítek. Když použijete vazební tabulku mezi tabulkou entit a tabulkou štítků, abyste u jedné entity mohl mít více štítků, bude index nad touhle tabulkou ještě méně používaný, než index nad seznamem štítků. Na počet odkazovaných záznamů ale ten index bude stejně velký, jako ten „ohromný denormalizovaný index“.

Tys to ale od začátku razil jako normální běžný přístup
Ne, já jsem to na začátku uvedl jako příklad. „Takhle také někdy může vypadat struktura databáze, jak tam budete aplikovat vaše pravidla.“ A vůbec tam nešlo o žádné vyhledávání ani výpis všech štítků. Nemůžu za to, že jsou tu lidé, kteří neumí uznat chybu, tak se radši chytí něčeho nesouvisejícího a začnou se točit na tom.

A kolikrát Ti budeme muset zopakovat, že INDEXY V SQL DATABÁZI PROSTĚ NEJSOU (zpravidla) NAPSANÉ TAK, ABY "ELIMINOVALI DUPLICITY", TAKŽE VE VÝSLEDKU PŮJDE I PŘI POUŽITÍ INDEXU O "SEQUENTIAL SCAN" PŘES TY DUPLICITY, než Ti to dojde?
On vás někdo nutí, abyste to psal k naprosto nesouvisejícím komentářům? Bylo snad v mém textu, nebo v komentáři Kita, na který jsem reagoval, něco o duplicitách?

Slovo spellchecker jsi poprve použil v diskusi ty. A standardní implementace spellcheckru je hunspell algoritmus. Tedy toto téma jsi do diskuse zatáhl Ty - akorát, jak se ukazuje, ani nevíš, co to vlastně je.
Nikoli, já jsem o hunspellu nic nepsal. Psal jsem o spellcheckeru v souvislosti s našeptávačem a fulltextem.

Omyl. Spellchecker má za úkol zjistit, zdali je dané slovo součástí dané gramatiky. Ať už dané výčtem, nebo, což je daleko častější, generativní gramatikou. Umíš vůbec anglicky. Víš, co znamená to "check" v tom "spellchecker"?
Nabídka korekce není nic jiného než našeptávání, a je to jiná úloha, než spellchecker, byť s ním souvisí.
Omyl. „Check“ znamená kontrola – přičemž obě naše tvrzení popisují kontrolu. Problém bude v té druhé části, v tom „spell“. Jde o to, jestli to slovíčko znamená spíš „gramatika“ nebo spíš „hláskování“. Nabídka korekce je standardní součástí funkce spellcheckeru, bez ní by byl velmi uživatelsky nepřívětivý.

Už jsem Tě několikrát vyzýval, abys - pokud s tím nesouhlasíš, ukázal jak k takovému účelu fulltext použiješ. Vždy jsi to nějak zakecal nesmyslama o spellchekrech apod. Tak tě vyzývám znovu: pokud tvrdíš, že Ti fulltext index pomůže, ukaž praktickou implementaci.
PostgreSQL:
Kód: [Vybrat]
CREATE INDEX idx_stitky ON stitky USING GIN (to_tsvector('english', stitek);
SELECT *, ts_rank_cd(to_tsvector('english', stitek), query) AS rank
  FROM stitky, plainto_tsquery(…) query
  WHERE to_tsvector('english', stitek) @@ query
  ORDER BY rank DESC
  LIMIT 10;

Ano, index pomůže v řazení. Nepomůže v tom, že bude muset projít všechny záznamy indexu pro daný štítek, což může být číslo značně větší, než počet štítků. Tedy neodstraní principiální problém, že náročnost té operace nebude záviset na počtu štítků, ale počtu oštítkovaných. O tomto problému Vašeho návrhu celou dobu mluvím a psal jsem to už asi dvacet postů dozadu.
Ano, zvolil jste pro tuhle úlohu špatný index – B-Tree vám nepomůže tolik v odstranění duplicit. Ale není pravda, že nepomůže vůbec, pomůže alespoň v tom řazení.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #227 kdy: 26. 10. 2019, 16:30:10 »
Fullscan tabulky do tisíce záznamů je rychlejší, než použití indexu. Index pro více záznamů má význam až při selekci, tedy výběru podmnožiny, např. klauzulí WHERE, která vybere méně než cca 10-50 % záznamů.
Pro našeptávač pak ale ještě potřebujete hledat v textech těch jednotlivých záznamů. Takže tím fullscanem tabulky by to neskončilo.

Logik

  • *****
  • 776
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #228 kdy: 26. 10. 2019, 22:17:50 »
Citace
To ale popisujete případ 1 entita = 1 štítek. Když použijete vazební tabulku...
Ty jsi mluvil o jednom či dvou indexech, což odpovídá tomuto modelu jeden štítek jedna entita. Ovšem i u M:N relace (kde jde o dva/tři indexy) je furt výhodnější normalizovaná struktura a tedy mít malý varchar index pro seznam štítků a velký integer index pro vazební tabulku. Furt to dohromady zabere méně místa v paměti, než jeden velký varchar index pro "vazební" tabulku. Průchod integer indexem je také o fous rychlejší.
Citace
Ne, já jsem to na začátku uvedl jako příklad. „Takhle také někdy může vypadat struktura databáze, a  jak tam budete aplikovat vaše pravidla.“
No právě. A my jste se Ti snažili vysvětlit, že takhle dobře navržená databáze nevypadná a proč.

Argumentovat nevhodností nějakého postupu tím, že nefunguje v blbě navržené db struktuře (nebo popř. v DB struktuře, která má smysl jen ve velmi raritním případě), je nesmyslná argumentace. Tedy pro to, abys obhájil svůj argument, musel bys obhájit to, že tvoje struktura není antipattern. Což nejde, protože to je antipattern, který mrví výkonnost dotazů (viz níž).

Citace
On vás někdo nutí, abyste to psal k naprosto nesouvisejícím komentářům? Bylo snad v mém textu, nebo v komentáři Kita, na který jsem reagoval, něco o duplicitách?
Ty jsi doteď ještě nepochopil, že jeden z velkých problémů Tvé DB struktury je to, že bude mít v indexu duplicitně uvedené štítky, takže není rychlá cesta, jak prohledávat názvy štítků? A že to je ta věc, kterou od začátku kritizujeme?

Citace
Nikoli, já jsem o hunspellu nic nepsal.
Psal. Psal jsi o klasickém algoritmu na spellchecking, což je prostě hunspell. To, že sis pod spelcheckingem představoval jiný algoritmus, než jak je v majoritě případů implementován, není moje chyba....

Citace
Omyl. „Check“ znamená kontrola – přičemž obě naše tvrzení popisují kontrolu.
Ne, návrh opravy chyby opravdu NENÍ kontrola správnosti, i kdyby ses postavil na hlavu. Navíc opět lžete a překrucujete, na počátku jste o spellchecku mluvil jako, cituji: "To je prostě množina slov, ve které se dá rychle vyhledat, jestli v ní dané slovo je nebo není.... té struktuře, která umožňuje rychlé vyhledávání, se říká – index.". Tedy na začátku jste definoval spellchecker jako něco, co kontroluje, jestli slovo patří do dané množiny.

Teprve když jsem vyvrátil Váš omyl, že ovšem standardní implementace spellcheckeru není implementována indexem, nýbrž generativní gramatikou, takže se to našeho problému vůbec netýká, tak jste začal jste překrucovat svoje slova i realitu, že podle Vás najednou není spellchecker něco, co kontroluje, jestli dané slovo patří do dané množiny či ne, ale nápověda v případě chyby. Což je úplně jiný problém.

Citace
Problém bude v té druhé části, v tom „spell“. Jde o to, jestli to slovíčko znamená spíš „gramatika“ nebo spíš „hláskování“.
Prosím, zjisti si, co znamená v programování gramatika, zas neznáš základní termíny a pleteš si pojmy s dojmy.
https://cs.wikipedia.org/wiki/Form%C3%A1ln%C3%AD_gramatikaSpellchecking, tedy kontrola hláskování, se v programování kontroluje gramatikami.

Citace
Nabídka korekce je standardní součástí funkce spellcheckeru....
To sice zpravidla je, ale jde o přibalení jiného algoritmu řešícího jinou věc, než samotný spellchecking. Auto se dnes také nedělá bez světel a bylo by bez nich uživatelsky nepřívětivé, ale mluvit o výkonu auta a myslet tím jak daleko dosvítí je nesmysl. Stejnětak mluvit o algoritmu spellcheckingu a myslet návrh korekce je prostě blbina.
Citace
PostgreSQL:
1) toto je vyhledávání štítku se stejným kořenem, respektive u víceslovných štítků, kde se shodují alespoň nějaké kořeny. Nijak to tedy neřeší původní problém: výpis všech štítků.
2) Neřeší to ani našeptávání štítků, protože na dotaz: "novikny" to nenajde "novinky". Není to ani podobnostní hledání, o kterém tu celou dobu mluvíš.
3) Užití GIN indexu tady vůbec nedává moc smysl: To je právě jeden z Tvých omylů, že se našeptávače implementují pomocí fulltextových indexů. Ano, někdy implementují, ovšem nikoli vždy, pouze pokud je k dané entitě přiřazený delší text. Pokud je k dané entitě přiřazený pouze jednoslovný text - jako např. zpravidla u štítků - je použití GIN indexu nesmysl. Daleko lepší výsledky dá vyhledávání pomocí trigram indexů. Toto už píšu asi po páté.

4) A PŘEDEVŠÍM TVŮJ PŘÍKLAD JEN DOKAZUJE, ŽE MÁME CELOU DOBU PRAVDU, PROTOŽE I V TVÉM DOTAZU SE NAČTOU VŠECHNY HODNOTY A PAK SE NA NICH PROVEDE UNIQUE. I toto Ti píšu asi po páté.

Kód: [Vybrat]
Indexes:
...
    "test2" gin (test)

=> explain select distinct test from translations where test @@ '''teaser_cards_temp''';
                                         QUERY PLAN                                         
---------------------------------------------------------------------------------------------
 Unique  (cost=113233.38..114264.78 rows=206281 width=27)
   ->  Sort  (cost=113233.38..113749.08 rows=206281 width=27)
         Sort Key: test
         ->  Bitmap Heap Scan on translations  (cost=1910.68..90086.19 rows=206281 width=27)
               Recheck Cond: (test @@ '''teaser_cards_temp'''::tsquery)
               ->  Bitmap Index Scan on test2  (cost=0.00..1859.11 rows=206281 width=0)
                     Index Cond: (test @@ '''teaser_cards_temp'''::tsquery)


Citace
Ano, zvolil jste pro tuhle úlohu špatný index – B-Tree vám nepomůže tolik v odstranění duplicit.
Já jsem nezvolil špatný index. Protože dobrý index (přinejmenším v mnoha běžných DB) Tvojí strukturu prostě neexistuje. Já jsem Ti demonstroval na jednom konrkétním indexu, že Tvoje představa nefunguje. Nemůžu za to, že nemáš evidentně praxi s databází, ale si chytrej jak rádio, takže místo toho, aby ses chytil za nos a nechal se poučit, tak nám nevěříš, že se to týká i jiných typů indexů, a dál meleš nesmysly.

Citace
Ale není pravda, že nepomůže vůbec, pomůže alespoň v tom řazení.
To, že pomůže při řazení ale nikdo nerozporoval ani nerozporuje. Celou dobu Ti tvrdíme, že neodstraní nutnosti nějaké formy sequential scanu přes všechny duplicitní záznamy, což je podstata problému, a to prostě neodstraní. Tak fakt nechápu, proč to sem furt taháš. To, že se dají kladivem dobře zatloukat hřebíky, nijak nemění, že používat ho  na krájení chleba je pitomost, byť s ním třeba ten chleba ukrojíš líp, než řemdihem.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #229 kdy: 27. 10. 2019, 08:30:02 »
Ovšem i u M:N relace (kde jde o dva/tři indexy) je furt výhodnější normalizovaná struktura a tedy mít malý varchar index pro seznam štítků a velký integer index pro vazební tabulku. Furt to dohromady zabere méně místa v paměti, než jeden velký varchar index pro "vazební" tabulku. Průchod integer indexem je také o fous rychlejší.
Jestli je to výhodnější nezjistíte tak, že vypíšete výhody a zatajíte nevýhody.

Argumentovat nevhodností nějakého postupu tím, že nefunguje v blbě navržené db struktuře (nebo popř. v DB struktuře, která má smysl jen ve velmi raritním případě), je nesmyslná argumentace. Tedy pro to, abys obhájil svůj argument, musel bys obhájit to, že tvoje struktura není antipattern. Což nejde, protože to je antipattern, který mrví výkonnost dotazů (viz níž).
Zase si vymýšlíte. Já jsem štítky neuváděl jako argument pro vhodnost či nevhodnost nějakého postupu.

Ty jsi doteď ještě nepochopil, že jeden z velkých problémů Tvé DB struktury je to, že bude mít v indexu duplicitně uvedené štítky, takže není rychlá cesta, jak prohledávat názvy štítků? A že to je ta věc, kterou od začátku kritizujeme?
Nepochopil jsem, proč to musíte připojovat i k vláknům, která s tím nijak nesouvisí.

Psal. Psal jsi o klasickém algoritmu na spellchecking, což je prostě hunspell.
A další váš výmysl.

Citace
Omyl. „Check“ znamená kontrola – přičemž obě naše tvrzení popisují kontrolu.
Ne, návrh opravy chyby opravdu NENÍ kontrola správnosti, i kdyby ses postavil na hlavu. Navíc opět lžete a překrucujete, na počátku jste o spellchecku mluvil jako, cituji: "To je prostě množina slov, ve které se dá rychle vyhledat, jestli v ní dané slovo je nebo není.... té struktuře, která umožňuje rychlé vyhledávání, se říká – index.". Tedy na začátku jste definoval spellchecker jako něco, co kontroluje, jestli slovo patří do dané množiny.
V první větě rozporujete, že spellchecker není kontrola správnosti, abyste ve zbytku odstavce dokazoval, že to je kontrola správnosti. Spíš si to nejdřív ujasněte sám, a pak se teprve pouštějte do diskuse.

Teprve když jsem vyvrátil Váš omyl, že ovšem standardní implementace spellcheckeru není implementována indexem, nýbrž generativní gramatikou, takže se to našeho problému vůbec netýká, tak jste začal jste překrucovat svoje slova i realitu, že podle Vás najednou není spellchecker něco, co kontroluje, jestli dané slovo patří do dané množiny či ne, ale nápověda v případě chyby. Což je úplně jiný problém.
Problém je totiž v tom, že neustále vyvracíte věci, které jsem nenapsal.

Prosím, zjisti si, co znamená v programování gramatika, zas neznáš základní termíny a pleteš si pojmy s dojmy.
https://cs.wikipedia.org/wiki/Form%C3%A1ln%C3%AD_gramatikaSpellchecking, tedy kontrola hláskování, se v programování kontroluje gramatikami.
Další nesmysl. A to vám není hloupé odkazovat na neexistující stránku? To jste si myslel, že si toho nevšimnu? Navíc nemůžu za to, že znáte jenom jedinou metodu implementace spellcheckeru, u které navíc ani nevíte, jak funguje.

To sice zpravidla je, ale jde o přibalení jiného algoritmu řešícího jinou věc, než samotný spellchecking.
Ano, ale je dobré na to myslet už při návrhu algoritmu samotného spellcheckeru. Jinak byste také mohl navrhnout hash index, ve kterém budete zjišťovat existenci slov, a pak zjistíte, že pro návrh možných korekcí vám je ten index úplně k ničemu.

1) toto je vyhledávání štítku se stejným kořenem, respektive u víceslovných štítků, kde se shodují alespoň nějaké kořeny. Nijak to tedy neřeší původní problém: výpis všech štítků.
O tom vašem „původním problému“ už jsme si vysvětlili, že je to velmi raritní případ, tudíž je to nesmyslná argumentace.

2) Neřeší to ani našeptávání štítků, protože na dotaz: "novikny" to nenajde "novinky". Není to ani podobnostní hledání, o kterém tu celou dobu mluvíš.
Zjistěte si, co je to našeptávač. Našeptávač na dotaz „nov“ nabídne „novinky“.

3) Užití GIN indexu tady vůbec nedává moc smysl: To je právě jeden z Tvých omylů, že se našeptávače implementují pomocí fulltextových indexů. Ano, někdy implementují, ovšem nikoli vždy, pouze pokud je k dané entitě přiřazený delší text. Pokud je k dané entitě přiřazený pouze jednoslovný text - jako např. zpravidla u štítků - je použití GIN indexu nesmysl. Daleko lepší výsledky dá vyhledávání pomocí trigram indexů. Toto už píšu asi po páté.
Běžně se používají i víceslovné štítky. Navíc jste chtěl řešení ve standardním Postgresu, předpokládal jsem tedy PostgreSQL bez extenzí. Tak se předveďte, jak v PostgreSQL bez extenzí vytvoříte trigram index.

4) A PŘEDEVŠÍM TVŮJ PŘÍKLAD JEN DOKAZUJE, ŽE MÁME CELOU DOBU PRAVDU, PROTOŽE I V TVÉM DOTAZU SE NAČTOU VŠECHNY HODNOTY A PAK SE NA NICH PROVEDE UNIQUE. I toto Ti píšu asi po páté.
Kde v mém dotazu se provádí unique?

=> explain select distinct test from translations where test @@ '''teaser_cards_temp''';
Ano, tenhle dotaz je trochu podobný mému dotazu. Jsou tam stejná slova SELECT, FROM a WHERE. Ale to jsou klíčová slova jazyka SQL, vyskytují se prakticky ve všech dotazech.

Já jsem Ti demonstroval na jednom konrkétním indexu, že Tvoje představa nefunguje.
Kdybyste věděl něco o databázích, věděl byste, že to, že na něco nejde použít jeden typ indexu, neznamená, že jiný typ indexu selže také. Proto máme různé typy indexů, protože se každý hodí na něco jiného.

Nemůžu za to, že nemáš evidentně praxi s databází, ale si chytrej jak rádio, takže místo toho, aby ses chytil za nos a nechal se poučit, tak nám nevěříš, že se to týká i jiných typů indexů, a dál meleš nesmysly.
Obecně jiných typů indexů se to netýká, sám jste už vyjmenoval typy indexů, které to zvládnou v pohodě, jsou dokonce s tím záměrem vytvořené.

Věřit vám, že se to týká i jiných typů indexů, nebude nikdo soudný – velký kvantifikátor („pro všechna X platí“) nemůžete dokazovat příkladem (malým kvantifikátorem – „existuje X, pro které platí“).

Ten příklad, který jste uvedl, totiž závisí na mnoha faktorech, které jste neuvedl. Jedním je konkrétní implementace B-Tree – i B-Tree index je možné implementovat tak, že v něm každý klíč bude jenom jednou, a duplicity budou řešené seznamem odkazů na záznamy. Dál to závisí na tom, zda plánovač dotazů dokáže nebo nedokáže DISTINCT stlačit (push down) do podmínek.

To, že pomůže při řazení ale nikdo nerozporoval ani nerozporuje. Celou dobu Ti tvrdíme, že neodstraní nutnosti nějaké formy sequential scanu přes všechny duplicitní záznamy, což je podstata problému, a to prostě neodstraní. Tak fakt nechápu, proč to sem furt taháš. To, že se dají kladivem dobře zatloukat hřebíky, nijak nemění, že používat ho  na krájení chleba je pitomost, byť s ním třeba ten chleba ukrojíš líp, než řemdihem.
Já nerozporuju, že při použití pro raritní případ výpisu všech štítků bude muset PostgreSQL při použití B-Tree indexu projít přes všechny duplicitní záznamy. To jenom vy máte potřebu to pořád psát u nesouvisejících komentářů.

reklama


Logik

  • *****
  • 776
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #230 kdy: 27. 10. 2019, 11:18:44 »
Citace
Jestli je to výhodnější nezjistíte tak, že vypíšete výhody a zatajíte nevýhody.
Nevýhody - nutnost projití dalším, mělkým a paměťově řádově méně náročným indexem, nijak nezatajuji. Jen tvrdím, že pro celkový výkon DB to není tak velká nevýhoda, jako jí zaplácnout stovky MB paměti větším indexem. Vidíš tam ještě jiné nevýhody?

Citace
Já jsem štítky neuváděl jako argument pro vhodnost či nevhodnost nějakého postupu.
Jo, takže jsme se bavili o vhodnosti DB struktury, ty jsi přišel se štítkama, ale nebyla to ukázka toho, kdy je podle Tebe nějaká struktura vhodná. Aha.....
Citace
V první větě rozporujete, že spellchecker není kontrola správnosti,
Ano, přepsal jsem se. Myslím, že alespoň trochu inteligentní člověk z toho je schopen pochopit, co jsem chtěl napsat: že spellchecking není návrh správnosti, ale kontrola. Tak nevím.... nepochopil jste to? Anebo vaším cílem není diskutovat, ale něco jiného, a nepochopil jste to naschvál?

Citace
Problém je totiž v tom, že neustále vyvracíte věci, které jsem nenapsal.
Ne, problém je, že každou chvíli tvrdíte něco jiného, podle toho, co se zrovna povede vyvrátit tak, že už nemáte žaludek na tom dál trvat.Např. na začátku jste tvrdil, že

"To je prostě množina slov, ve které se dá rychle vyhledat, jestli v ní dané slovo je nebo není..."
chvíli poté
"Spellchecker má za úkol na základě vstupu najít možná podobná slova ze slovníku existujících slov."
a teď zas tvrdíte, že jste to netvrdil a že spellchecker je kontrola správnosti, takže první definice.

Citace
Další nesmysl. A to vám není hloupé odkazovat na neexistující stránku? To jste si myslel, že si toho nevšimnu?
Podle sebe soudím Tebe? Víš, normální člověk nediskutuje proto, aby z druhého dělal vola, a takovéto metody nepoužívá.Zkus to prosím také, diskuse začne být o mnoho kvalitnější. Odkaz se nějak pomrvil, správný odkaz je tady:
https://cs.wikipedia.org/wiki/Form%C3%A1ln%C3%AD_gramatika

Citace
Navíc nemůžu za to, že znáte jenom jedinou metodu implementace spellcheckeru, u které navíc ani nevíte, jak funguje.
Ne, znám standardní implementaci spellcheckru, která je použita v největších SW balících (libreoffice, mozilla, chrome). A vím, že alternativní spellcheckery (ispell, aspell, myspell, snowball) používají stejný princip. Takže prostě pokud mluvíte o spellcheckru a myslíte tím jiný přístup než generativní gramatiku, tak evidentně mluvíte o něčem, co vůbec neznáte.

A co se týče toho, kdo neví, jak spellchecker funguje, tak já nemluvil o spellcheckru jako o indexu....

Citace
Ano, ale je dobré na to myslet už při návrhu algoritmu samotného spellcheckeru.
Ano, je dobré myslet při návrhu auta na světla. Ale když někdo mluví o tom, na jakém principu jezdí auto, tak nemyslí světlo.

Citace
Jinak byste také mohl navrhnout hash index, ve kterém budete zjišťovat existenci slov,
No, a budete asi překvapen, ale zrovna majoritní implementace: hunspell - alespoň prokazatelně v OS software - na to prostě moc nemyslela a datovou strukturu na to připravenou prostě nemá. A vzhledem k tomu, že je to majoritní spellchecker, tak pochybuji, že jsou na tom ostatní o tolik lépe, některé určitě ne, možná o trochu líp Aspell se svojí implementací soundslikes, ale on to je z principu u hodně ohýbaných jazyků těžko řešitelný problém.

Citace
O tom vašem „původním problému“ už jsme si vysvětlili, že je to velmi raritní případ, tudíž je to nesmyslná argumentace.
Zaprve to sis vysvětlil možná tak sám sobě. Zadruhé jsi původně tvrdil, že to umíš a vysmíval ses ostatním, že to neumí.
Dobře, beru toto jako přiznání, že to neumíš. Že by ses omluvil od Tebe čekat asi nemohu.

Citace
Zjistěte si, co je to našeptávač. Našeptávač na dotaz „nov“ nabídne „novinky“.
Tak proč jste do toho celou dobu tahal cituji: "možná podobná slova ze slovníku existujících slov."? Najednou, když jste zjistil, že ani to neumíte, tak to také není potřeba? Dobrý našeptávač si poradí i s překlepy.

Citace
Běžně se používají i víceslovné štítky.
Zaprve o tom běžně bych pochyboval (ale to těžko dokážeme), zadruhé pokud už se používají, tak jejich text má význam jako celek, čili i tam nemá fulltext (který indexuje jednotlivá slova) zpravidla smysl.
Citace
Navíc jste chtěl řešení ve standardním Postgresu, předpokládal jsem tedy PostgreSQL bez extenzí. Tak se předveďte, jak v PostgreSQL bez extenzí vytvoříte trigram index.
pg_trgm je součástí distribuce postgresu, ač implementována jako modul. To je jako byste tvrdil, že do unixového jádra nepatří moduly a že se má člověk obejít bez nich.
Citace
Kde v mém dotazu se provádí unique?
Aha, vy to unique vlastně ani neprovádíte. Takže pokud ten dotaz poběží nad tou strukturou, kterou tu celou dobu prosazujete, tak vám to našeptá jeden stejný výraz tisíckrát. Tak to se omlouvám, to, že napíšeš dotaz vracející jiný výsledek než chceme jsem nečekal a myslel jsem, že máš na mysli dotaz s distinctem.
Že na to ještě ovšem upozorníš, jako by to byla přednost Tvého dotazu, nějak nechápu. Takže Tě prosím znovu, ukaž dotaz, který umí efektivně vrátit z Tebou prosazované datové struktury unikátní našeptávací návrhy. A klidně pomocí GIN indexu, pomineme, že dobrý spellchecker nabízí i korekce.
Jen Tě upozorňuji, abychom si ušetřili další kola Tvých marných pokusů, že Tvoje víra v schopnosti GIN indexu je mylná, protože kupodivu GIN neindexuje text jako celek, ale jednotlivá slova, takže to ani z principu nemůže umět. Fulltext index by mohl (kdyby byla taková funkcionalita zpřístupněna) efektivně vypsat unikátní použitá slova ve štítcích, nikoli unikátní štítky.

Citace
Obecně jiných typů indexů se to netýká, sám jste už vyjmenoval typy indexů, které to zvládnou v pohodě, jsou dokonce s tím záměrem vytvořené.

Právě jste překonal další metu: ve svém postu jsem Vám demonstroval, že to GIN index neumí, a vy na to bez jakéhokoli důkazu napíště, že to umí. Anebo jste myslel jiný index? Který konkrétně?

Citace
Ten příklad, který jste uvedl, totiž závisí na mnoha faktorech, které jste neuvedl. Jedním je konkrétní implementace B-Tree.....
Ano, a to co vám celou dobu tvrdíme je, že v databázích JSOU ty KONKRÉTNÍ IMPLEMENTACE TAKOVÉ, ŽE TO zpravidla PROSTĚ NEUMÍ, A TEDY JE VAŠE ŘEŠENÍ PRO PŘÍPAD SQL DATABÁZÍ ANTIPATTERN. Že možná vyškrábnete databázi X s indexem Y, která to jako výjimka umět bude, na té antipatternovosti nic nemění.

Celý problém naší debaty je v tom, že neznáte, jak věci implementované JSOU. A jen teoreticky přemýšlíte, jak by věci implementované být MOHLY. A když Vám ukazujeme, že se mýlíte, tak to neumíte přiznat. A nejste schopen připustit, že ač by index v databázi mohl být implementován tak, že by akcelerovat DISTINCT, že tak prostě v drtivé většině prostě NENÍ.
Úplně stejný problém je s tím spellcheckingem: myslel jste si, že je implementován jako index a samozřejmě, že by tak být implementován mohl. Ovšem prostě v majoritních spellchekrech tak implementován NENÍ. Běžné formáty slovníků pro spellchecking nedávají seznam slov výčtem, ale gramatikou.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #231 kdy: 27. 10. 2019, 13:25:07 »
Nevýhody - nutnost projití dalším, mělkým a paměťově řádově méně náročným indexem, nijak nezatajuji. Jen tvrdím, že pro celkový výkon DB to není tak velká nevýhoda, jako jí zaplácnout stovky MB paměti větším indexem. Vidíš tam ještě jiné nevýhody?
Netuším, kde jste přišel na ty stovky MB a řády. Další nevýhodou je, že ten index bude efektivní jenom při hledání podle štítků – dotazy „štítek AND další podmínky“ budou mnohem méně efektivní.

Ano, přepsal jsem se. Myslím, že alespoň trochu inteligentní člověk z toho je schopen pochopit, co jsem chtěl napsat: že spellchecking není návrh správnosti, ale kontrola. Tak nevím.... nepochopil jste to? Anebo vaším cílem není diskutovat, ale něco jiného, a nepochopil jste to naschvál?
Alespoň trochu inteligentní člověk hledá jiná vysvětlení, než že jste hlupák. OK, takže už jsme si ujasnili, že na mé tvrzení, že samotný spellchecking slouží ke kontrole slov, jste reagoval tím, že to není pravda, že spellchecking přece slouží ke kontrole slov. Takže vaším cílem není diskutovat, ale hádat se? Když musíte rozporovat i to, co sám vzápětí napíšete stejně…

Ne, problém je, že každou chvíli tvrdíte něco jiného, podle toho, co se zrovna povede vyvrátit tak, že už nemáte žaludek na tom dál trvat.Např. na začátku jste tvrdil, že

"To je prostě množina slov, ve které se dá rychle vyhledat, jestli v ní dané slovo je nebo není..."
chvíli poté
"Spellchecker má za úkol na základě vstupu najít možná podobná slova ze slovníku existujících slov."
a teď zas tvrdíte, že jste to netvrdil a že spellchecker je kontrola správnosti, takže první definice.
To ovšem nevysvětluje, proč vyvracíte tu první definici, abyste ji vzápětí sám použil.

Odkaz se nějak pomrvil, správný odkaz je tady:
https://cs.wikipedia.org/wiki/Form%C3%A1ln%C3%AD_gramatika
No jo, jenže tenhle odkaz zase nijak nepotvrzuje vaše tvrzení.

A co se týče toho, kdo neví, jak spellchecker funguje, tak já nemluvil o spellcheckru jako o indexu....
Vždyť jsem to psal, že nevíte, jak spellchecker funguje.

Citace
Zjistěte si, co je to našeptávač. Našeptávač na dotaz „nov“ nabídne „novinky“.
Tak proč jste do toho celou dobu tahal cituji: "možná podobná slova ze slovníku existujících slov."? Najednou, když jste zjistil, že ani to neumíte, tak to také není potřeba? Dobrý našeptávač si poradí i s překlepy.
Už zase si pletete našeptávač a spellchecker. Citoval jste část věty, která celá zněla takhle: „Spellchecker má za úkol na základě vstupu najít možná podobná slova ze slovníku existujících slov.“

Takže pokud ten dotaz poběží nad tou strukturou, kterou tu celou dobu prosazujete, tak vám to našeptá jeden stejný výraz tisíckrát.
Ten dotaz nic nenašeptává, vrací seznam entit podle zadaného textu štítků.


Tak to se omlouvám, to, že napíšeš dotaz vracející jiný výsledek než chceme jsem nečekal
Ono je totiž těžké z vašich komentářů zjistit, co vlastně chcete – teda kromě toho, že se chcete hádat za každou cenu.


Takže Tě prosím znovu, ukaž dotaz, který umí efektivně vrátit z Tebou prosazované datové struktury unikátní našeptávací návrhy.

Kód: [Vybrat]
CREATE INDEX idx_stitky_gist ON stitky USING GIST(stitek gist_trgm_ops);

SELECT DISTINCT ON (stitek) AS nazev, stitek <<<-> query AS vzdalenost
  FROM stitky
  WHERE stitek <<% query
  ORDER  BY vzdalenost DESC, stitek
  LIMIT 10;


to co vám celou dobu tvrdíme je
Ne, tohle jste teď napsal poprvé. A ještě nejspíš píšete jen o PostgreSQL, ne obecně o relačních databázích (a už vůbec ne o databázích obecně).

TEDY JE VAŠE ŘEŠENÍ PRO PŘÍPAD SQL DATABÁZÍ ANTIPATTERN
Vidím, že vám dělá radost, že s vámi v něčem souhlasím, takže to budete pořád dokola opakovat, dokonce to musíte vyřvávat. Sice je to mimo téma diskuse, protože já jsem nikdy netvrdil, že je to doporučený postup, jak ve většině případů dělat štítky, ale když vám to dělá radost to pořád opakovat…

A nejste schopen připustit, že ač by index v databázi mohl být implementován tak, že by akcelerovat DISTINCT, že tak prostě v drtivé většině prostě NENÍ.
Opět se mýlíte. Já jsem se k DISTINCTu nevyjadřoval, protože to nebyla věc, kterou bych v téhle diskusi řešil. Když jsme si ujasnili, že vážně chcete na uživatele nasypat seznam všech štítků, potvrdil jsem vám, že pro takový případ opravdu není vhodná taková struktura databáze, jakou jsem popsal.

Úplně stejný problém je s tím spellcheckingem: myslel jste si, že je implementován jako index a samozřejmě, že by tak být implementován mohl. Ovšem prostě v majoritních spellchekrech tak implementován NENÍ. Běžné formáty slovníků pro spellchecking nedávají seznam slov výčtem, ale gramatikou.
Myslíte, že třída HashMgr je ve zdrojácích hunspellu jenom omylem a nepoužívá se? Nebo to podle vás není index?

Logik

  • *****
  • 776
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #232 kdy: 27. 10. 2019, 17:13:05 »
Citace
Netuším, kde jste přišel na ty stovky MB
Netušíte, protože evidentně nemáte s DB zkušenost. Vemte si velkou tabulku, udělejte jí index nad varchar a integer sloupcem a koukněte se, jak je veliký... A to obzvlášť, když budete mít víceslovné, tedy dlouhé štítky.

Citace
a řády.
Pokud bude počet štítků řádově menší než počet oštítkovaný, tak bude kupodivu řádově menší index nad těmi štítky než nad vazební tabulkou. To musím vysvětlovat i takovéto primitivnosti?
Citace
dotazy „štítek AND další podmínky“ budou mnohem méně efektivní.
Udržíš moč? Protože myšlenku evidentně ne. :-) Teď se - na Tvůj popud - bavíme o situaci M:N, kde žádná taková výhoda denormalizace není.

Citace
Už zase si pletete našeptávač a spellchecker. Citoval jste část věty, která celá zněla takhle: „Spellchecker má za úkol na základě vstupu najít možná podobná slova ze slovníku existujících slov.“
Z té TVÉ věty je evidentní, že spellchecker s našeptávačem si pleteš dohromady TY. Už jsme se tedy doufám shodli, že návrh/našeptání korekce a spellchecker jsou dvě různé věci. Já se akorát ptal, proč návrh korekce (ať už jí nazýváš dobře nebo špatně), jsi do toho vůbec pletl, když teď tvrdíš, že taková funkcionalita vůbec není potřeba.

Citace
Ten dotaz nic nenašeptává, vrací seznam entit podle zadaného textu štítků.
A proč ho sem dáváš? Když celou dobu řešíme to, že Tvá databázová struktura není efektivní pro našeptávání štítků, a o vyhledávání entit se tu nikdo v této souvislosti nebavil? A když to byla tvá odpověď na: "....Tedy že vyhledání i malého počtu štítků ve velkém počtu záznamů pomocí fulltextového indexu není tak rychlé, jako vyhledání téhož v normalizované datové struktuře...", tedy na dotaz jak uděláš efektivní vyhledávání štítků a ne štítkovaných entit???,
 
Citace
Kód: [Vybrat]
CREATE INDEX idx_stitky_gist ON stitky USING GIST(stitek gist_trgm_ops);

SELECT DISTINCT ON (stitek) AS nazev, stitek <<<-> query AS vzdalenost
  FROM stitky
  WHERE stitek <<% query
  ORDER  BY vzdalenost DESC, stitek
  LIMIT 10;
Ufff. Zaprve, tendle dotaz je úplně špatně. Neumíte vůbec pracovat s DISTINCT ON. Pominu-li, že nevíte, že DISTINCT ON neříká, které sloupce mají být ve výstupu, takže DISTINC ON AS je nesmysl, tak máte blbě i ORDER BY, protože DISTINCT ON vyžaduje správný ORDER. Takovýto dotaz se musí napsat se subselectem (který vám mimojiné odhalí marnost vašeho počínání :-)). No a pak tam máte i blbé operátory, ale to jste asi jen blbě opsal manuál....

A zadruhé, když ty všechny chyby opravíte tak, že to bude fungovat, tak to opět bude stejná písnička, bude se tam provádět UNIQUE operace nad stejnými záznamy. Jen jste opět  prokázal, že to prostě napsat neumíte (protože to ani nejde). Ale aspoň jste si konečně zjistil něco o trigram indexes.


Citace
Ne, tohle jste teď napsal poprvé. A ještě nejspíš píšete jen o PostgreSQL, ne obecně o relačních databázích (a už vůbec ne o databázích obecně).
To je holt problém, když místo toho, co bys pořádně četl, co Ti tu lidé píší, tak jen dokolečka tvrdohlavě opakuješ svůj názor, dávno v diskusi vyvrácený.
Psal jsem Ti to např. tady:https://forum.root.cz/index.php?topic=21909.msg319312#msg319312a tady
https://forum.root.cz/index.php?topic=21909.msg319198#msg319198a psali Ti to i jiníhttps://forum.root.cz/index.php?topic=21909.msg319193#msg319193další výskyty mě už nebaví hledat.

A píšeme tam o jiných databázích, protože toto je zrovna věc, která funguje plus mínus všude stejně, nejoptimálnější implementace indexů prostě distinct akcelerovat neumí, a protože to v rozumných DB strukturách potřeba není, tak se zpravidla pro tento účel speciální indexy nezavádí.

Už chápete, proč radši některé věci zdůrazňuji "křikem", když je píšu poxté a doteď jste to ignoroval? Teď Vás to donutilo aspoň to vnímat.

Citace
Opět se mýlíte. Já jsem se k DISTINCTu nevyjadřoval,
Takže se tady celou dobu nebavíme o našeptávání štítků? ??? Které jaksi v té Tvé struktuře bez distinctu napsat prostě nejde? ??? ? Nebo tvrdíš, že to nějak napíšeš bez distinctu? A todle psal kdo? Mimozemšťan?
Citace
SELECT DISTINCT v takovém případě bude full table scan
O existenci indexů jste už slyšel?
Od toho debata začala a celou dobu po Vás chci, abyste ukázal, jak toto naimplementujete, a to buďto pro výpis štítků (kde jste se nejprve snažil a pak prohlásil, že to není potřeba), nebo alespoň pro našeptávání (kde jste si zatím netroufl tvrdit, že to není potřeba).Protože tvrdím, že to efektivně našeptat nejde a tedy že je vaše datová struktura nevhodná.

Citace
To ovšem nevysvětluje, proč vyvracíte tu první definici, abyste ji vzápětí sám použil....
Máš evidentně problém s pochopením psaného textu. Nevyvracel jsem, že spellchecker slouží k testování toho, že dané slovo patří do množiny. Vyvracím Ti, že je to index.

Citace
Myslíte, že třída HashMgr je ve zdrojácích hunspellu jenom omylem a nepoužívá se? Nebo to podle vás není index?
Auto má motor a používá ho a motor je v autě podstatný. Znamená to, že je auto motor? ??? ??? Spellcheker používá index, znamená to, že spellchecker je index? ??? Index je struktura, která slouží k dohledání záznamu v datovém souboru. Jelikož ovšem hunspell nemá žádný datový soubor, ale pouze pravidla pro generování validních slov, tak prostě není indexem.

Index se v hunspellu používá pouze k dohledání kořenů slov, nikoli k samotnému otestování, zdali je slovo validní, a je to technologicky nejméně zajímavá součást hunspellu. Takže přirovnání k autu a motoru tu vlastně nesedí, ten hashindex je v hunspellu asi v takové pozici, jako kola pro auto. Jo, auto bez kol nepojede: ale to, že umíte udělat kolo, ještě neznamená, že umíte udělat auto. A označovat kolo za auto je prostě nesmysl.

Btw. Teď jste si hezky sám vyvrátil své předchozí tvrzení, že spellcheckry přeci myslí na korekce: sám jste si dokázal, že hunspell během svého fungování používá hash a tedy nemá interní struktury optimalizované na korekce. Zkuste příště než zas plácnete nějaké "musí to tak být" tomu věnovat aspoň takovouto chvíli, jako teď, a bude diskuse o dost jednodušší. A kdybyste si ty zdrojáky hunspellu prohlédl trochu pozorněji, tak byste si ušetřil i tento omyl....

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #233 kdy: 27. 10. 2019, 17:32:38 »
Omlouvám se, moje chyba. Když jsem na začátku zjistil, že 70 % vašeho komentáře evidentně reaguje na něco, co jsem nenapsal, mělo mi dojít, že i těch zbývajících 30 %, které se dají vyložit jako reakce na můj text, je na tom ve skutečnosti stejně.

Logik

  • *****
  • 776
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #234 kdy: 27. 10. 2019, 19:27:46 »
Jinými slovy, "když jsem zkusil asi pěti pokusy napsat efektivní dotaz a nikdy se mi to nepovedlo, a když jsem konečně zjistil, že to opravdu nejde, tak se z toho musím nějak vykecat."
Tak jo, beru to, čekal jsem, že líp uznat omyl nebudeš umět.

PS: Pro příště: méně trapné je radši neodpovědět vůbec, když už jsi příliš hrdý na to se omluvit.
 

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #235 kdy: 27. 10. 2019, 19:31:10 »
radši neodpovědět vůbec, když už jsi příliš hrdý na to se omluvit.

Nezaměňujte hrdost s pýchou.

 

reklama