Doporučte rychlý WWW widget pro view SQL tabulky

[Standa Blábol]

Pisu ted jednoduchy nastroj (Spring Boot 2.4.5), ktery prijima eventy na REST a uklada je do Postgresql tabulky pomoci PLSQL procedury, ta interne provadi deduplikaci eventu se stejnym ID pomoci "INSERT ... ON CONFLICT DO UPDATE ..."

TO vsechno funguje pekne, je to rychle, udruzuje se v tom cca 20-30k eventu.

REST API "getAll" mi vysype vsecky  udalosti CURLem za cca 800ms, po restartu Springu i Postgresu, pak se to po nakesovani zrychli  na cca 250ms, download speed 22MB/s, naprosto postacuje.
Chome dtto, zobrazeni raw JSON textu prakticky okamzite

Problem mi nastal, kdyz se pokousim ty data vizualizovat na webu, obvykle pouzivam JSF2 widget Primefaces::Datatable s paginaci, zatim jsem pouzival paginaci cca 30 radku, tam to funguje skvele.
Nyni potrebuju paginaci radove 1000 zobrazenych radku (nebo uplne bez paginace), a tam mi pri paginaci 1000 radku trvalo robrazeni Primefaces Datatable pres minutu.

Vystup profileru:

Kód [Vybrat] Rozbalit

971 ms  Loading
13791 ms  Scripting
36149 ms  Rendering
7187 ms  Painting
4322 ms  System
4115 ms  Idle
66534 ms  Total

Load dat pod sekundu, pak tam Chrome neco pres minutu vyrabi. Klientska stanice je pomerne vykonna, Lenovo P50 s Core i7 a 64 GB RAM

Muze nekdo doporucit neco lepciho, cim se da zobrazit na webu vetsi tabulka dat s podporou paginace, filtrovani, sortovani?

[Reklama]

[Filip Jirsák]

Pro prohlížeč bude určitě rychlejší, když HTML vygenerujete na serveru a prohlížeč ho jenom vyrenderuje.

Ale tabulka zobrazující 1000 záznamů je špatně z pohledu UX, navíc ještě stránkovaná. To bude někdo prohlížet tisícovky záznamů očima? Lepší by bylo poskytnout uživateli takové nástroje, aby tolik záznamů zobrazovat nemusel.

[Google CTCCTCGGCGGGCACGTAG]

jak pise Jirsak, zobrazovat 1000 zaznamu je spatne. Snad vsechny backendove frameworky maji nejakou hotovou podporu pro datatables, vcetne strankovani, filtrovani, razeni.

ja v djangu pouzivam https://pypi.org/project/django-datatables-view/

[Ondrej Nemecek]

Html tabulku s 1000 řádky dnes prohlížeče zvládají levou zadní (alespoň na desktopu). Při vhodném realtime hledání to může být i uživatelsky přívětivé a s okamžitou odezvou - lepší než čekat na refresh jsonu ze serveru nebo dokonce celé html stránky. Viz např. https://www.materialsproject.org/static/components/listjs/website/examples/performance-test.html

Pokud je to pomalé, viděl bych to na nějakou implementační chybu nebo použití nevhodného nástroje.

[anonacct]

Rozhodně nic negeneruj na serveru, zbytečně si budeš zabíjet čas serveru něčím, co může udělat klient...

Asi děláš něco špatně (špatná komponenta). Přetransformovat 1000 řádků v JSON do nějaké tabulky by mělo i v javascriptu trvat max pár ms. Podívej se na slickgrid nebo něco takového - podporuje i miliony záznamů

[Reklama]

[Filip Jirsák]

Rozhodně nic negeneruj na serveru, zbytečně si budeš zabíjet čas serveru něčím, co může udělat klient...

Otázka: Zpracování na klientovi trvá příliš dlouho.
Odpověď: Rozhodně nic negeneruj na serveru, můžeš tím přece pěkně vytížit klienta.

Anonacct, pro vaši informaci, serveru bude trvat stejně dlouho, jestli ta data bude renderovat do JSONu nebo do HTML tabulky.

Asi děláš něco špatně (špatná komponenta).

Otázka: Můžete doporučit nějakou lepší komponentu?
Odpověď: Asi používáte špatnou komponentu.

To jsou fakt odpovědi za všechny prachy.

podporuje i miliony záznamů

Zobrazovat miliony záznamů uživateli v jedné tabulce? To se používá kde, v pekle?

[Ondrej Nemecek]

Rozhodně nic negeneruj na serveru, zbytečně si budeš zabíjet čas serveru něčím, co může udělat klient...

Otázka: Zpracování na klientovi trvá příliš dlouho.
Odpověď: Rozhodně nic negeneruj na serveru, můžeš tím přece pěkně vytížit klienta.

Anonacct, pro vaši informaci, serveru bude trvat stejně dlouho, jestli ta data bude renderovat do JSONu nebo do HTML tabulky.

Asi děláš něco špatně (špatná komponenta).

Otázka: Můžete doporučit nějakou lepší komponentu?
Odpověď: Asi používáte špatnou komponentu.

To jsou fakt odpovědi za všechny prachy.

podporuje i miliony záznamů

Zobrazovat miliony záznamů uživateli v jedné tabulce? To se používá kde, v pekle?

Myslím, že anonacct chtěl říci, že správně udělané generování na klientovi zrychlí aplikaci jako celek i pro jednotlivce, při současném zlepšení uživatelské přívětivosti. Jde přitom o dnes běžný postup. Ten listjs u mě renderuje html tabulku s 100 tis. řádky asi 0.3s a filtrování řádků je skoro okamžité. Takže pokud má kolem 1 tis. záznamů tak bych se nerozpakoval je vypsat naráz a ušetřený čas věnoval na kvalitní a názorné filtrování nebo přidání nějaké vizualizace.

Jinak pokud to v té komponentně trvá dlouho, tak se například může dělat nějaký callback po přidání každého řádku, ale správně se má použít API na dávkové vložení řádků, aby se callback provedl až na konci. To je jen příklad problému, které si může programátor způsobit když k tisíci záznamů přistupuje jak předtím k jednomu. Tazatel by se měl podívat, zda něco takového nepřehlédl.

[Filip Jirsák]

Myslím, že anonacct chtěl říci, že správně udělané generování na klientovi zrychlí aplikaci jako celek i pro jednotlivce, při současném zlepšení uživatelské přívětivosti.

Myslím, že se v tom trochu zamotáváte. Pokud aplikace generuje na serveru celou HTML stránku, dá se odezva zryhlit tím, že se pomocí kódu na klientovi vymění pouze obsah tabulky, resp. příslušná část stránky se vymění za tabulku. Ušetří se tím, že se nemusí znovu stahovat arenderovat celá stránka.

Nicméně pokud se ten obsah tabulky na klientovi vytváří tak, že se ze serveru stáhne JSON a ten se pak v klientovi transformuje na HTML, dá se odezva stránky dále urychlit tím, že se DOM nebude vyrábět na klientovi z JSONu, ale z HTML. Ale to už je optimalizace až na krev, většinou není potřeba.

Hlavní problém ale pořád vidím v tom, že tazatel chce uživateli předhodit tabulku s tisíci záznamů, ať si tam něco hledá očima, místo aby mu poskytl nástroj, pomocí kterého mu najde potřebné záznamy počítač. A nikoli, tabulka s filtrací a řazením není ten nástroj. Tyhle tabulky mají rádi programátoři, protože nemusí nic vymýšlet, jenom zabalí SQL dotaz do GI (= graphical interface, na U se v tomto případě zapomělo).

[Google CTCCTCGGCGGGCACGTAG]

A nikoli, tabulka s filtrací a řazením není ten nástroj. Tyhle tabulky mají rádi programátoři, protože nemusí nic vymýšlet, jenom zabalí SQL dotaz do GI (= graphical interface, na U se v tomto případě zapomělo).

jaky je tedy ten nastroj?

[Ondrej Nemecek]

Pokud se html generuje na klientovi a interakce s ui je také řešena na klientovi, ušetří se výpočetní výkon serveru který je pak k dispozici pro obsluhu dalších požadavků. Část výpočetního výkonu se tedy distribuuje mezi klienty. Data se ze serveru přenáší typicky pomocí JSON. Co k tomu víc dodat? Nemám dojem, že by v tom bylo něco zamotaného. Pokud se místo JSON budou posílat HTML fragmenty (a z nich pak generovat DOM s nimiž se bude dále pracovat), je to spíš komplikace než výhra, ale ano, někdy to tak frameworky dělají.

Nevím, proč by tabulka s filtrací nebyl nástroj na vyhledání záznamu? Může nad tím mít celý widget s tlačítky a hejblátky a tím omezovat výběr. Zda je to vhodný nástroj záleží na typu aplikace, samozřejmě. Asi narážíte na tu paginaci, kde zobrazovat stránku s 1 tis. řádky na každé stránce je nesmyslný koncept, protože paginace a filtrování jsou do určité míry konfliktní koncepty (z hlediska UI - v závislosti na konrétní situaci). Což může být vidět i na tom datatable widgetu, který možná vůbec nepočítá s takovým počtem řádků. Ale mít jednu tabulku s tisícem řádků nevidím jako nějaký principielní problém ani výkonnostně ani uživatelsky, pokud je k tomu filtrování či případně i vhodná vizualizace. Ano, předpokládám, že to není tak, že by se tam vypsala celá sql tabulka a filtrování že by pak suplovala sql dotazy, takové řešení by asi zarazilo každého.

Nebo si možná vůbec nerozumíme, nicméně vše podstatné podle mě bylo řečeno, tak ať si to tazatel přebere sám.

[Filip Jirsák]

jaky je tedy ten nastroj?

To záležína otm, co chce uživatel dělat. Což od tazatele nevíme. Akorát jsem si poměrně dost jistý, že uživatel nechce očima procházet tisíce záznamů.

[Filip Jirsák]

Pokud se html generuje na klientovi a interakce s ui je také řešena na klientovi, ušetří se výpočetní výkon serveru který je pak k dispozici pro obsluhu dalších požadavků. Část výpočetního výkonu se tedy distribuuje mezi klienty. Data se ze serveru přenáší typicky pomocí JSON. Co k tomu víc dodat?

Ten JSON se podle vás vezme kde? Nebo myslíte, že když bude server generovat {"jmeno": "Jiří Novák"} místo <td>Jiří Novák</td>, ušetří se tím nějak výrazně jeho výkon?

Pokud se místo JSON budou posílat HTML fragmenty (a z nich pak generovat DOM s nimiž se bude dále pracovat), je to spíš komplikace než výhra, ale ano, někdy to tak frameworky dělají.

Jak jsem psal, je to řešení případu, kdy generování DOMu na klientovi trvá dlouho. Což může být případ velkého objemu dat a starších prohlížečů, nebo třeba složité logiky, jak z dat to HTML generovat.

Nevím, proč by tabulka s filtrací nebyl nástroj na vyhledání záznamu?

Tabulka zobrazující tisíc záznamů (a ještě stránkovaně) není nástroj pro vyhledání záznamu.

Ale mít jednu tabulku s tisícem řádků nevidím jako nějaký principielní problém ani výkonnostně ani uživatelsky

K čemu uživateli těch tisíc zobrazených záznamů je? Bude je číst jeden po druhém?

[Ondrej Nemecek]

Ušetří se výkon, protože se negeneruje celá stránka ale jen data pro část stránky. Samotné generování JSON bude typicky také rychlejší, pokud porovnáme s generováním html pomocí šablonovacího nástroje (což je typická technologie pro generování celé stránky). Lze samosebou najít i protipříklady, ale já mluvím o typických rysech daného řešení. Tohle je tak provařené téma, že mi přijde tristní o tom diskutovat?

Ohledně tabulky - velkou tabulku uživatel nebude číst řádek po řádku, ale okem proskenuje charakter záznamů a zopakuje filtrování, aby zúžil výběr. Nebo bude mít  třeba předpřipravené filtry, na které klikne. Ušetřený čas může programátor věnovat vizualizaci dat v grafu nebo jakkoli jinak, což přidá další dimenzi pro orientaci v datech. Data v tabulce uživatel zřídka čte celá, protože s nimi obvykle dále pracuje - hledá maxima, minima, zjišťuje počet, záznamy edituje, exportuje apod. To myslím platí bez ohledu na počet řádků.

Vaše argumentace je jako byste říkal, proč je v tabulkovém procesoru tolik řádků. V mailovém klientovi mám momentálně 11 tis. mailů a hledám v nich pomocí rychlého filtru a není v tom žádný problém. To je use-case, který mám na mysli. Výhoda živého hledání přitom je, že uživatel neztrácí kontext - pohybuje se stále na stejném místě aplikace a pracuje stále se stejnou sadou dat. Což neplatí po odstránkování nebo přerenderování stránky.

A najdou se případy, kdy se živé hledání nehodí. Takže to už je diskuze jen kvůli diskuzi...

[Filip Jirsák]

Ušetří se výkon, protože se negeneruje celá stránka ale jen data pro část stránky.

Nikoli. Explicitně jsem psal, že by se generoval HTML kód pouze pro tabulku.

Tohle je tak provařené téma, že mi přijde tristní o tom diskutovat?

Tak evidentně je to pro některé novinka, že se může do prohlížeče poslat jen HTML fragment a vyměnit jen část stránky. DOM opravdu nemusíte jen vyrábět JavaScriptem, můžete ho získat i nativním parsováním HTML zabudovaným v prohlížeči.

Ohledně tabulky - velkou tabulku uživatel nebude číst řádek po řádku, ale okem proskenuje charakter záznamů a zopakuje filtrování, aby zúžil výběr.

Nebo může mít aplikace pořádné UX, aby to skenování záznamů očima mohl uživatel vynechat.

Nebo bude mít  třeba předpřipravené filtry, na které klikne.

K tomu ale není potřeba zobrazovat tisíc záznamů, že?

Data v tabulce uživatel zřídka čte celá, protože s nimi obvykle dále pracuje - hledá maxima, minima, zjišťuje počet

Kdyby tak uměly minimum, maximum a počet záznamů zjistit počítače. Bohužel to neumí, tak to musí dělat lidé.

záznamy edituje

Tisíc záznamů?

exportuje

Potřebuje ty záznamy před exportem vidět? Zase bude tisíc záznamů kontrolovat očima?

To myslím platí bez ohledu na počet řádků.

Pořád platí, že když musí uživatel číst tisíc řádků, je něco špatně. Od toho, aby pracovaly s velkým objemem dat, přece máme počítače. Počítači je jedno,jestli zpracuje deset řádků nebo tisíc, člověku ne.

Vaše argumentace je jako byste říkal, proč je v tabulkovém procesoru tolik řádků.

V tabulkovém procesoru žádné řádky nejsou, dokud je někdo nenapíše. A pokud je někdo napíše, dělá to proto, že je lidé chtějí číst. Číst mnohasetstránkové romány lidi baví. Číst tisíciřádkové tabulky nebaví nikoho. A dělají v tom lidé chyby, nějaké řádky přehlédnou apod.

V mailovém klientovi mám momentálně 11 tis. mailů a hledám v nich pomocí rychlého filtru a není v tom žádný problém.

Vida, hledáte pomocí rychlého filtru. Který vám zobrazí pár e-mailů. Neprocházíte tisíc e-mailů očima.

To je use-case, který mám na mysli. Výhoda živého hledání přitom je, že uživatel neztrácí kontext - pohybuje se stále na stejném místě aplikace a pracuje stále se stejnou sadou dat.

Akorát že to nevyžaduje zobrazovat tabulku s tisícem řádků.

Což neplatí po odstránkování nebo přerenderování stránky.

O přerenderování celé stránky tu ale píšete jenom vy.

A najdou se případy, kdy se živé hledání nehodí. Takže to už je diskuze jen kvůli diskuzi...

Na živé hledání jste se ovšem omezil jenom vy. Najdou se také případy, kdy se nehodí zorbazovat tisíciřádkovou tabulku – jsou to všechny případy zobrazení tisíciřádkové tabulky.

Ale samozřejmě, že někdy se vyplatí zobrazovat tisíciřádkovou tabulku – když je vývoj nákladnější, než práce uživatelů. Nicméně tazatel měl snahu vyjít uživatelům vstříc – a mnohem užitečnější, než zobrazovat uživateli tisíc řádků rychle, je poskytnout mu takové nástroje, aby těch tisíc řádků vůbec vidět nepotřeboval. Filtry, vyhledávání, zobrazení správných údajů (počty, extrémy), jiné formy vizualizace, než je tabulka.

[hechj]

Napište si tu vizualizaci sám. Jestli ten widget chroupe nějaký obecný json nebo váš konkrétní json, tak to může být velký rozdíl. Já bych si teda posílal tabulku ze serveru a pustil bych na to widget, který uchopí hotovou tabulku (filtrable, sortable table).

offtopic
Pro kolik je to uživatelů, že řešíte úsporu výkonu serveru? 100 000?

Nikdy jsem neviděl, že by skládání DOM v prohlížeči byla levná operace. A taky je otázka, proč zobrazovat 1000 záznamů najednou. Nejspíš je to pro někoho, kdo ví, co ta tabulka obsahuje. Proto bych použil ajax a ze serveru posílal filtrovaná data.