Byla vydána nová verze 2023.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení. Zdůraznit lze předpřipravené obrazy pro Hyper-V nebo to, že ve výchozím prostředí Xfce bylo PulseAudio nahrazeno multimediálním serverem PipeWire.
Tento týden byla vydána nová verze 1.52 webového prohlížeče Brave (Wikipedie, GitHub). Postavena je na Chromiu 114. Z novinek lze vypíchnout možnost povolit vertikální karty (vertical tabs). Také bylo představeno Brave Search API k vyhledávači Brave Search.
Matthias Clasen z Red Hatu oznámil v diskusním listu vývojářů Fedora Linuxu, že tým Red Hat Display Systems se zaměří na Wayland a podporu HDR na Linuxu a přestane spravovat RPM balíčky pro LibreOffice. V další major verzi RHELu už LibreOffice nebude. Pokud se nenajde správce balíčků pro Fedora Linux, zůstane pouze LibreOffice ve Flatpaku.
Na Steamu lze získat zdarma počítačovou hru Tell Me Why (ProtonDB). Na Epic Games Storu počítačovou hru Midnight Ghost Hunt (ProtonDB).
Společnost Meta představila (YouTube) brýle pro virtuální realitu Meta Quest 3. V prodeji budou na podzim a stát budou od 499,99 dolarů.
Byla vydána nová verze 2.41.0 distribuovaného systému správy verzí Git. Přispělo 95 vývojářů, z toho 29 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.
Organizace Apache Software Foundation (ASF) vydala verzi 18 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Byla vydána verze 1.70.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example. Jako reakce na rostoucí obavy z vlivu korporací na vývoj Rustu a předložený návrh restriktivních zásad používání ochranných známek Rustu, byl nedávno představen komunitní fork Rustu se 100 % méně byrokracie: Crab (CrabLang).
Oliver Smith z Canonicalu shrnuje základní vlastnosti „neměnné“ distribuce Ubuntu Core také ve srovnání s protějšky Chrome OS, Fedora Silverblue a MicroOS. Canonical připravuje desktopovou variantu Ubuntu Core vedle dosavadní serverové/embedded.
Z aktualizovaného seznamu chyb (pdf) procesoru AMD EPYC 7002: #1474 - procesor se po 1044 dnech od posledního resetu zasekne [reddit].
Ahoj, mám jen otázku, zda-li je můj SQL dotaz ideální,. Mám následujicí tabulku a data:
CREATE TABLE tbl ( id_link INT NOT NULL, id_label INT NOT NULL ); INSERT INTO tbl (id_link, id_label) VALUES (10,2); INSERT INTO tbl (id_link, id_label) VALUES (10,3); INSERT INTO tbl (id_link, id_label) VALUES (11,1); INSERT INTO tbl (id_link, id_label) VALUES (11,2); INSERT INTO tbl (id_link, id_label) VALUES (11,3); INSERT INTO tbl (id_link, id_label) VALUES (12,1); INSERT INTO tbl (id_link, id_label) VALUES (12,3); SELECT * FROM tbl; +---------+----------+ | id_link | id_label | +---------+----------+ | 10 | 2 | | 10 | 3 | | 11 | 1 | | 11 | 2 | | 11 | 3 | | 12 | 1 | | 12 | 3 | +---------+----------+ 7 rows in set (0.00 sec)
A nyní potřebuji zjistit počet id_link, které mají id_label 1 a současně 3, jde o id_link 11 a 12, celkem tedy 2. Dělám to takto:
SELECT COUNT(*) FROM (SELECT COUNT(*) AS kolikrat FROM tbl WHERE id_label IN (1,3) GROUP BY id_link HAVING kolikrat=2 ) AS tbl2; +----------+ | COUNT(*) | +----------+ | 2 | +----------+
Obdobně, když mě zajímá počet id_link, které mají současně id_label 1,2 a 3 (jde o jeden případ a to id_link 11):
SELECT COUNT(*) FROM (SELECT COUNT(*) AS kolikrat FROM tbl WHERE id_label IN (1,2,3) GROUP BY id_link HAVING kolikrat=3 ) AS tbl2; +----------+ | COUNT(*) | +----------+ | 1 | +----------+ 1 row in set (0.00 sec)
Pravda, funguje to, ale nešlo by to jednodušeji, a hlavně rychleji (při větším množství dat)?. Díky za případné náměty.
Řešení dotazu:
SELECT COUNT(*) FROM tbl t1 JOIN tbl t2 ON t1.id_link=t2.id_link AND t1.id_label=1 AND t2.id_label=3;Ci je to rychlejsie si otestuj sam, ale mohlo by. Predpokladam, ze riadky v tej tabulke su unikatne, inak by sa mnozili zaznamy. Trocha nevyhoda je, ze pre druhu podmienku (1,2,3) uz treba joinovat 3x, ale obecne su databazy skor prisposobene na rychle joiny (kde mozu vyuzivat indexy), nez na divoke subselecty (kde v tom subselecte nevyuziju index).
To funguje, problém je však v tom, že v té podmínce je proměnný počet čísel, třeba i deset.
Ne nutně. Lze použít další (dočasnou, pracovní, ...) tabulku, ze které se budou brát podmínky in a having. V rozumné databázi to o moc pomalejší než semovo řešení nebude. Navíc se u frekventovaného dotazu ušetří za hard parsing.
Váš dotaz je jednoznačně lepší než výše uvedený pomocí spojení tabulek. Netřeba to ani testovat.
Tak jsem Vaše návrhy použil na větších datech a dostal jsem tyto výsledky: při 3 číslech je metoda s JOIN 4x rychlejší, ale při 10 číslech (=10 JOINů) je zase skoro 2x pomalejší než moje původní...
Jde o MySQL, zkoušeno na 5.0, 5.1 i 5.4. Dotazy s JOIN jsou do osmi číslic 3-4krát rychlejší, pak nastane zlom, u devíti číslic je to dvakrát pomalejší a u deseti šestkrát pomalejší než můj původní select. Testováno asi takto:
SELECT COUNT(*) FROM tbl t1 JOIN tbl t2 USING (id_link) JOIN tbl t3 USING (id_link) JOIN tbl t4 USING (id_link) JOIN tbl t5 USING (id_link) JOIN tbl t6 USING (id_link) JOIN tbl t7 USING (id_link) JOIN tbl t8 USING (id_link) JOIN tbl t9 USING (id_link) JOIN tbl t10 USING (id_link) WHERE t1.id_label=15 AND t2.id_label=16 AND t3.id_label=17 AND t4.id_label=3 AND t5.id_label=14 AND t6.id_label=1 AND t7.id_label=61 AND t8.id_label=81 AND t9.id_label=7 AND t10.id_label=55
Hodne zalezi na charakteru tech dat. Group by pravdepodobne provede sort mnoziny vyhovujici podminkam a zalezi na tom, jak velka mnozina do nej bude vstupovat. Pri joinu bude podstatne, v jakem poradi se bude joinovat, pokud nektera z podminek diskriminuje vyrazne vice nez jina - napriklad pokud label 1 a 2 milion zaznamua 3 pouze deset, bude join v poradi 3, 2, 1 mnohonasobne rychlejsi nez join v poradi 1, 2, 3 (pokud tam je vhodny index). Obecne pokud se nedaji udelat zadne rozumne predpoklady o datech bych preferoval reseni s group by, ktere je minimalne prehlednejsi.
Já tam ještě vidím jeden problém. Pokud bude v tabulce dvakrát jedna dvojice id_link a id_label, tak to začne počítat špatně.
To ne, dvojice id_link, id_label je unikátní.
Ja se priznam, ze jsem takhle vecer nepochopil pointu toho HAVING kolikrat=N. K cemu tam vlastne je? Ja bych pocital distinct id_link, tzn. neco jako...
SELECT
COUNT(DISTINCT id_link) AS result
FROM
tbl
WHERE
id_label IN (1,2)
GROUP BY
id_link
SELECT COUNT(1) AS total FROM tbl tbl1 WHERE tbl1.id_label = 1 AND EXISTS (SELECT 1 FROM tbl tbl2 WHERE tbl2.id_link = tbl1.id_link AND tbl2.id_label = 3) /Obecně — a pro velké objemy dat — lze zneužít analytické funkce:
SELECT COUNT(CASE WHEN rn = 1 THEN 1 ELSE NULL END) AS total FROM (SELECT id_link, id_label, COUNT(CASE WHEN id_label IN (1, 2, 3) THEN 1 ELSE NULL END) OVER (PARTITION BY id_link) AS cnt, ROW_NUMBER() OVER (PARTITION BY id_link ORDER BY 1) AS rn FROM tbl) WHERE cnt = 3 /Podmínku na hodnoty
ID_LABEL
vsuneš do výrazu agregační funkce COUNT()
na řádce 7. Počet hodnot pro ID_LABEL
musí být uveden ve WHERE
klauzuli na řádce 12. Tedy:
SELECT COUNT(CASE WHEN rn = 1 THEN 1 ELSE NULL END) AS total FROM (SELECT id_link, id_label, COUNT(CASE WHEN id_label IN (1, 3) THEN 1 ELSE NULL END) OVER (PARTITION BY id_link) AS cnt, ROW_NUMBER() OVER (PARTITION BY id_link ORDER BY 1) AS rn FROM tbl) WHERE cnt = 2 /Výhoda je jasná: stačí full-scan nad tabulkou; žádný joiny. Zbytek odře
WINDOW-SORT
. WITH conditions AS ( SELECT 1 AS val FROM dual UNION ALL SELECT 3 FROM dual) SELECT COUNT(CASE WHEN rn = 1 THEN 1 ELSE NULL END) AS total FROM (SELECT id_link, id_label, COUNT(CASE WHEN id_label IN (SELECT val FROM conditions) THEN 1 ELSE NULL END) OVER (PARTITION BY id_link) AS cnt, ROW_NUMBER() OVER (PARTITION BY id_link ORDER BY 1) AS rn FROM tbl) WHERE cnt = (SELECT COUNT(1) FROM conditions) /Prostě jen uvedeš veškeré hodnoty ve factoring klauzuli.
SELECT COUNT(1) FROM (SELECT COUNT(1) FROM …)
.GROUP BY
či JOIN
y. Na IBM DB2 LUW stačí nahradit klíčové slovo ROW_NUMBER
klíčovým slovem ROWNUMBER
(navíc — klauzule PARTITION BY
a ORDER BY
jsou tam jako bonus nepovinné).GROUP BY
pro člověka, který zná analytické funkce.WHERE
klauzuli, nikoli na počtu vytvořených indexů či jejich existenci. Protože autor potřebuje probrousit celou tabuli — aspoň tak jsem to z dotazu pochopil —, možná by pomohl kompozitní index nad ID_LINK
a ID_LABEL
. Ale vůbec bych se nedivil, kdyby optimizér zvolil TABLE FULL-SCAN
. Proč zbytečně brousit index a pak — vlastně vše — číst pomocí TABLE ACCESS BY INDEX ROWID
? Chtělo by to udělat PoC nad velkým počtem dat. Také záleží na hodnotách NULL
… Je toho prostě víc…
Tiskni
Sdílej: