Re: [django-cs] Volba databáze a její možnosti

2018-11-29 Thread Vítek Pliska 
Určitě scrapy může i v tomto případě pomoct např. s tím jak pracuje s 
concurrent requests a třebas autothrottle - to záleží na pravidlech toho API 
které se bude konzumovat, co je dovoleno/jaké jsou limity. Pokud není dovoleno 
dělat víc požadavků najednou tak bych tam asi scrapy ani netahal…

Vítek

> 29. 11. 2018 v 22:09, Honza Javorek :
> 
> Já bych řekl, že se specializuje na těžení a že má dost věci, které ti to 
> těžení usnadní, pokud jde o HTML. Pokud jde o JSON, nic usnadňovat 
> nepotrebujes, mas json.loads(), a pak ale pořad stavis na tom těžení.
> 
> HJ
> 
> On Thu, 29 Nov 2018 at 21:05, Petr Messner  > wrote:
> Ahoj,
> 
> myslel jsem, že scrapy se specializuje na těžení dat z HTML. Říkáš, že se 
> hodí i na JSON API?
> 
> Petr
> 
> čt 29. 11. 2018 v 20:47 odesílatel Honza Javorek  > napsal:
> Ahoj,
> 
> mirne offtopic, ale pokud muzu komentovat tu cast kde budes bombardovat to 
> API, tak bych zvazil https://scrapy.org/  On si clovek 
> casto nemysli ze neco takovyho potrebuje, az kdyz do toho zabredne a trva to 
> misto tri dnu mesic, tak si uvedomi, ze misto requests mohl pouzit nejaky 
> framework.
> 
> Honza
> 
> On Thu, Nov 29, 2018 at 8:19 PM Stanislav Vasko  > wrote:
> 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, 
> které Heureka nedávno uvolnila, zpoplatnila přístup a je na toto přímo 
> postaveno.
> 
> 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í. 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í.
> 
> 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 >:
> 
>> 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
>> 
>> -- 
>>

Re: [django-cs] Volba databáze a její možnosti

2018-11-29 Thread Honza Javorek 
Já bych řekl, že se specializuje na těžení a že má dost věci, které ti to
těžení usnadní, pokud jde o HTML. Pokud jde o JSON, nic usnadňovat
nepotrebujes, mas json.loads(), a pak ale pořad stavis na tom těžení.

HJ

On Thu, 29 Nov 2018 at 21:05, Petr Messner  wrote:

> Ahoj,
>
> myslel jsem, že scrapy se specializuje na těžení dat z HTML. Říkáš, že se
> hodí i na JSON API?
>
> Petr
>
> čt 29. 11. 2018 v 20:47 odesílatel Honza Javorek 
> napsal:
>
>> Ahoj,
>>
>> mirne offtopic, ale pokud muzu komentovat tu cast kde budes bombardovat
>> to API, tak bych zvazil https://scrapy.org/ On si clovek casto nemysli
>> ze neco takovyho potrebuje, az kdyz do toho zabredne a trva to misto tri
>> dnu mesic, tak si uvedomi, ze misto requests mohl pouzit nejaky framework.
>>
>> Honza
>>
>> On Thu, Nov 29, 2018 at 8:19 PM Stanislav Vasko <
>> stanislav.va...@gmail.com> wrote:
>>
>>> 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, které Heureka nedávno uvolnila, zpoplatnila přístup a je na toto přímo
>>> postaveno.
>>>
>>> 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í.
>>> 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í.
>>>
>>> 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 :

 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

Re: [django-cs] Volba databáze a její možnosti

2018-11-29 Thread Petr Messner 
Ahoj,

myslel jsem, že scrapy se specializuje na těžení dat z HTML. Říkáš, že se
hodí i na JSON API?

Petr

čt 29. 11. 2018 v 20:47 odesílatel Honza Javorek 
napsal:

> Ahoj,
>
> mirne offtopic, ale pokud muzu komentovat tu cast kde budes bombardovat to
> API, tak bych zvazil https://scrapy.org/ On si clovek casto nemysli ze
> neco takovyho potrebuje, az kdyz do toho zabredne a trva to misto tri dnu
> mesic, tak si uvedomi, ze misto requests mohl pouzit nejaky framework.
>
> Honza
>
> On Thu, Nov 29, 2018 at 8:19 PM Stanislav Vasko 
> wrote:
>
>> 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, které Heureka nedávno uvolnila, zpoplatnila přístup a je na toto přímo
>> postaveno.
>>
>> 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í.
>> 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í.
>>
>> 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 :
>>>
>>> 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á

Re: [django-cs] Volba databáze a její možnosti

2018-11-29 Thread Honza Javorek 
Ahoj,

mirne offtopic, ale pokud muzu komentovat tu cast kde budes bombardovat to
API, tak bych zvazil https://scrapy.org/ On si clovek casto nemysli ze neco
takovyho potrebuje, az kdyz do toho zabredne a trva to misto tri dnu mesic,
tak si uvedomi, ze misto requests mohl pouzit nejaky framework.

Honza

On Thu, Nov 29, 2018 at 8:19 PM Stanislav Vasko 
wrote:

> 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, které Heureka nedávno uvolnila, zpoplatnila přístup a je na toto přímo
> postaveno.
>
> 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í.
> 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í.
>
> 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 :
>>
>> 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

Re: [django-cs] Volba databáze a její možnosti

2018-11-29 Thread Petr Messner 

29. 11. 2018 v 20:19, Stanislav Vasko :

> 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 :
>> 
>>> 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
> --- 
>

Re: [django-cs] Volba databáze a její možnosti

2018-11-29 Thread Stanislav Vasko 
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, 
které Heureka nedávno uvolnila, zpoplatnila přístup a je na toto přímo 
postaveno.

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í. 
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í.

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 
> >:
>
> 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 zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/d47d668b-4d47-4964-9f61-a96a6f0c9ef0%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

Re: [django-cs] Volba databáze a její možnosti

2018-11-29 Thread Petr Messner 
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 :

> 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 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/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 zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/F9669759-7C6A-40F6-9C52-0FBF92F8135A%40gmail.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

Re: [django-cs] Volba databáze a její možnosti

2018-11-29 Thread Honza Král 
Ahoj,

ja bych neco takoveho nacpal do Elasticsearch. Zadarmo k tomu dostanes
kibanu kde si muzes naklikat jakekoliv ad-hoc dashboardy se kterymi se
nemusis pak trapit rucne (idealne kibana jako prototyp a pak vytvorit
vlastni aplikaci pro lepsi UI/UX) a zaroven se nemusis strachovat o zadne
skalovani a podobne veci.

Disclaimer: elasticsearch je muj zamestnavatel takze o objektivite nemuze
byt rec, ale tohle je use case ktery u nasich uzivatelu vidim casto a
funguje to dobre.

Honza Král
E-Mail: honza.k...@gmail.com
Phone:  +420 606 678585


On Thu, Nov 29, 2018 at 12:13 PM Stanislav Vasko 
wrote:

> 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 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/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 zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CADoCwr3Y%3DAy9ihYicDh84kZsH-WRhaYoiBGyEyH8d7bSPhjKGw%40mail.gmail.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Volba databáze a její možnosti

2018-11-29 Thread Stanislav Vasko 
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 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/7c78faf6-54b8-4130-95bb-293f6199f14e%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.