29. 11. 2018 v 20:19, Stanislav Vasko <stanislav.va...@gmail.com>: > Díky za info. Jen zopakuji, že počet dotazů je pro Heureku skoro nic, proti > jiným partnerům. Současné scrapování mám nejen povolené, ale hlavně tuto > novou aplikaci budu napojovat (základní skripty jsou už hotové) přes API
Super :) Díky za info o API, úplně nesleduju vývoj :) > JSON soubory mně také napadly, vlastně bych mohl ukládat přímo odpovědi z API > (je to JSON RPC), ale nevím jak praktické to je pro další zpracování. Ukládat celé odpovědi asi úplně přímo praktické být nemusí, ale hodí se to, kdyby sis rozmyslel, že to celé chceš dělat nějak jinak, nebo že jsi na něco zapomněl. Přinejmenším se tenhle druh dat hodně dobře komprimuje. A na AWS S3/Glacier se toho vejde :) Já osobně si toto pro archivní/debug/recompute účely docela často ukládám. > Musel bych pravidelně robotem tahat aktuální data denně vypočítat pak > dlouhodobé statistiky, ale něco takového mně u DB řešení čeká asi také. Ještě > mně napadlo, zda by nebylo efektivnější pro tyto účely využít nějaký skripty > přímo v DB, tuším, že některé mají přímo "udělátka" na vypočítání dat, > virtuálních tabulek apod. To by mi možná ušetřilo práci a vyřešilo nutnost > neustále o data nějak pečovat. > > Kibana vypadá zajímavě, ale přiznám se, že o ní slyším poprvé a vůbec nevím > jak to v tomto pojetí uchopit. Zkusím si něco nastudovat, ale raději bych se > držel něčeho co zná každý a kdokoliv případně i poradí. > Kibana je v analytických dashboardech docela mainstream, zná ji hodně lidí, ale spíš v jiných bublinách než webdev. “Skripty v DB” – to by mohly být např. materializované pohledy v PostgreSQL, v Elasticu je myslím něco podrobného. Petr Messner > Díky! > >> On Thursday, 29 November 2018 20:05:21 UTC+1, Messa wrote: >> Ahoj, >> >> tohle scrapování určitě vidí Heureka strašně ráda. Ale to je tvůj boj :) >> >> 60 tisíc záznamů denně? Hm, na to by stačil i JSON soubor. Paradoxně by jeho >> zpracování mohlo být i rychlejší, než ze špatně navržené databáze. >> >> Což ostatně není špatný nápad, si ta data vylít a zpracovávat mimo. Je to >> celkem častý postup (oddělení analytické db od transakční). Koneckonců i ten >> Dashboard může být generovaná statická webovka. >> >> Honzovo tip s Kibanou se mi taky líbí. >> >> Zkratka, podle mě tento objem ještě nijak neomezuje výběr technologie :) >> (Doufám teda, že sqlite zvládá paralelní read.) >> >> Petr Messner >> >> 29. 11. 2018 v 12:59, Stanislav Vasko <stanisl...@gmail.com>: >> >>> Zdravím, >>> >>> pár let si v Django píšu menší aplikace pro svou práci a napsal jsem pár >>> řešení pro své klienty. Pro tyto účely používám SQLite a nikdy jsem >>> nenarazil na problém, navíc si mohu DB se zdrojákem snadno verzovat v GITu. >>> Nyní ale chci jeden ze svých projektů (analýza produktů na Heureka.cz) >>> zásadně rozšířit a rád bych si od začátku zvolil vhodný DB podvozek. Budu >>> 3x denně stahovat údaje o produktech (je jich asi 10 tisíc) přes Heureka >>> API. Kromě aktuální ceny produktu ještě budu potřebovat uložit data o >>> nabídkách jednotlivých e-shopů (cca 20 e-shopů na produkt, ukládat se bude >>> aktuální cena, pozice, skladovost a několik dalších parametrů). Tedy denně >>> 10.000 (produktů) x 3 (denně stahovat nabídky) x 20 (údajů o nabídce >>> konkrétního eshopu) záznamů. K tomu se určitě ještě něco přidá. Tato data >>> potřebuji dále zpracovávat. Typicky Dashboard s reportem aktuálně produktů >>> prodávaných pod určitou cenou, report firem prodávajících pod cenou nebo >>> náhled detailu produktu s historií průměrné a minimální ceny apod. >>> >>> Chtěl bych se zeptat zkušenějších programátorů na čem (případně navést i >>> detailněji) postavit DB podvozek. Problém asi není ani tak v tom data >>> uložit, ale hlavně abych z nich byl schopen v reálném čase něco sestavit. >>> Asi bude třeba vytvořit i nějaké roboty, kteří z dat za daný den/měsíc >>> připraví nějaká mezidata, vypočtou dashboard, protože přímé realtime >>> zpracování by bylo příliš pomalé. Nebo se mýlím? >>> >>> Díky za každý tip na DB, případně budu rád i za navedení na nějaký >>> relevantní zdroj informací o tom jakou a proč DB zvolit, případně kde mají >>> limity. Osobně studuji a váhám mezi SQLite, MySQL a PostgreSQL. >>> >>> Díky, Standa >>> -- >>> -- >>> E-mailová skupina djan...@googlegroups.com >>> Správa: http://groups.google.cz/group/django-cs >>> --- >>> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny >>> „django-cs“ ve Skupinách Google. >>> Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, >>> zašlete e-mail na adresu django-cs+...@googlegroups.com. >>> Chcete-li tuto diskusi zobrazit na webu, navštivte >>> https://groups.google.com/d/msgid/django-cs/7c78faf6-54b8-4130-95bb-293f6199f14e%40googlegroups.com. >>> Další možnosti najdete na https://groups.google.com/d/optout. > > -- > -- > E-mailová skupina django-cs@googlegroups.com > Správa: http://groups.google.cz/group/django-cs > --- > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny > „django-cs“ ve Skupinách Google. > Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete > e-mail na adresu django-cs+unsubscr...@googlegroups.com. > Chcete-li tuto diskusi zobrazit na webu, navštivte > https://groups.google.com/d/msgid/django-cs/d47d668b-4d47-4964-9f61-a96a6f0c9ef0%40googlegroups.com. > Další možnosti najdete na https://groups.google.com/d/optout. -- -- E-mailová skupina django-cs@googlegroups.com Správa: http://groups.google.cz/group/django-cs --- Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs ve Skupinách Google. Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com. Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/django-cs/C616FCEB-69E1-4564-B8A8-CFF0F5EE0A03%40gmail.com. Další možnosti najdete na adrese https://groups.google.com/d/optout.
