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

2018-11-30 Thread Stanislav Vasko 
Už mi na serveru běhá PSQL. Nevím sice úplně dobře proč, ale funguje a 
dělám testy výkonu. Zatím to vypadá velice slibně a i přes slušnou zátěž DB 
reaguje velice svižně. Zkusím do DB dát 100 mega řádků a uvidíme jak se 
bude tvářit pak. Pokud klienta trochu ukrotím v pohledu na "nutně" 
skladovaná data bych neměl mít větší problém. Teď už jen vyřešit to 
verzování stavu DB proti zdrojáku a jsem spokojen.

Díky všem za navedení. Kdybyste případně ještě měli nějaký dobrý článek jak 
se efektivně poprat s Views resp. jak prakticky si DB donutit automaticky 
tvořit data co potřebuji, budu max. šťastný a udělám si malé vánoce :)

Příjemný večer.

On Friday, 30 November 2018 14:31:59 UTC+1, Messa wrote:
>
> MySQL je super - když si do ní chceš naprogramovat vlastní engine.
>
> Takže asi tak :)
>
> PM
>
>
> pá 30. 11. 2018 v 14:02 odesílatel Jan Walter  > napsal:
>
>> Nevim jak dneska, ale mysql nebyla pred lety dobra (plnohodnotna) relacni 
>> db, postgres je naopak supr uz hodne dlouho. Svyho casu jsem si napr. delal 
>> benchmarky rychlosti beznych r/w operaci pro vetsi stromovy struktury 
>> (postgres, mssql, neo4j) a postgres vychazel v podstate nejlip.
>>
>> Plus indexace json typu pro flexibilitu, jak rika starenka, podle me 
>> robustni (jedno z mnoha, urcite) reseni.
>>
>> Bezny dotaz na par tisic zaznamu z par milionu musi byt za destitky max 
>> malo stovek ms, jak rikaji ostatni.
>>
>> Jinymi slovy postgres rozhodne neni spatna volba.
>>
>> On Fri, 30 Nov 2018, 12:12 Jirka Vejrazka, > > wrote:
>>
>>> Tri miliony radku jsou jen drobne, pokud spravne pouzijes indexy. Mel 
>>> bys byt na zlomcich sekund pro jeden dotaz (a pokud ten dotaz nevraci 
>>> tisice zaznamu)...
>>>
>>>  Jirka
>>>
>>>
>>>
>>> On Fri, 30 Nov 2018 at 10:34, Stanislav Vasko >> > wrote:
>>>
 V mezičase jsem si napsal miniaplikaci, která natahala nějaká data z 
 Heureky a pak jsem skriptem začal soubor dat duplikovat. Aktuálně mám v 
 SQLite asi 3 milióny řádků vše běží, jen tedy vyhledat data s jedinou 
 WHERE 
 podmínkou a sortem je cca 10s (45000 výsledků), s limitem na 10 pak cca 
 6,5s. Zkusil jsem MySQL a tam jsou reakce lepší, ale hlavně pokud zapisuji 
 do DB mohu z ní v pohodě číst. Což asi bude to hlavní důvod, proč SQLite 
 nebude možné použít, neboť budu potřebovat umět současně zapisovat i číst. 
 Robot pořízující nová data může běžet taky 15-30 minut a nemohu po tuto 
 dobu aplikaci odstavit či házet errory.

 Nevíte o nějakém prakticky pojatém článku o tom jak si v MySQL či PSQL 
 ušetřit čas a nervy využitím nějakých robotů/automatiky pro zpracování dat 
 do mezitabulek, virtuálních dat apod.? Myslím, že využití a vytahání dat z 
 miliónů řádek pro dashboard apod. by měl robot v DB umět určitě lépe než 
 cokoliv co spáchám já :)

 Díky!

 On Thursday, 29 November 2018 22:17:08 UTC+1, Vítek Pliska wrote:
>
> 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 <
>> ma...@honzajavorek.cz> 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 <
>>> stanisl...@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 byc

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

2018-11-30 Thread Petr Messner 
MySQL je super - když si do ní chceš naprogramovat vlastní engine.

Takže asi tak :)

PM


pá 30. 11. 2018 v 14:02 odesílatel Jan Walter  napsal:

> Nevim jak dneska, ale mysql nebyla pred lety dobra (plnohodnotna) relacni
> db, postgres je naopak supr uz hodne dlouho. Svyho casu jsem si napr. delal
> benchmarky rychlosti beznych r/w operaci pro vetsi stromovy struktury
> (postgres, mssql, neo4j) a postgres vychazel v podstate nejlip.
>
> Plus indexace json typu pro flexibilitu, jak rika starenka, podle me
> robustni (jedno z mnoha, urcite) reseni.
>
> Bezny dotaz na par tisic zaznamu z par milionu musi byt za destitky max
> malo stovek ms, jak rikaji ostatni.
>
> Jinymi slovy postgres rozhodne neni spatna volba.
>
> On Fri, 30 Nov 2018, 12:12 Jirka Vejrazka, 
> wrote:
>
>> Tri miliony radku jsou jen drobne, pokud spravne pouzijes indexy. Mel bys
>> byt na zlomcich sekund pro jeden dotaz (a pokud ten dotaz nevraci tisice
>> zaznamu)...
>>
>>  Jirka
>>
>>
>>
>> On Fri, 30 Nov 2018 at 10:34, Stanislav Vasko 
>> wrote:
>>
>>> V mezičase jsem si napsal miniaplikaci, která natahala nějaká data z
>>> Heureky a pak jsem skriptem začal soubor dat duplikovat. Aktuálně mám v
>>> SQLite asi 3 milióny řádků vše běží, jen tedy vyhledat data s jedinou WHERE
>>> podmínkou a sortem je cca 10s (45000 výsledků), s limitem na 10 pak cca
>>> 6,5s. Zkusil jsem MySQL a tam jsou reakce lepší, ale hlavně pokud zapisuji
>>> do DB mohu z ní v pohodě číst. Což asi bude to hlavní důvod, proč SQLite
>>> nebude možné použít, neboť budu potřebovat umět současně zapisovat i číst.
>>> Robot pořízující nová data může běžet taky 15-30 minut a nemohu po tuto
>>> dobu aplikaci odstavit či házet errory.
>>>
>>> Nevíte o nějakém prakticky pojatém článku o tom jak si v MySQL či PSQL
>>> ušetřit čas a nervy využitím nějakých robotů/automatiky pro zpracování dat
>>> do mezitabulek, virtuálních dat apod.? Myslím, že využití a vytahání dat z
>>> miliónů řádek pro dashboard apod. by měl robot v DB umět určitě lépe než
>>> cokoliv co spáchám já :)
>>>
>>> Díky!
>>>
>>> On Thursday, 29 November 2018 22:17:08 UTC+1, Vítek Pliska wrote:

 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 <
> ma...@honzajavorek.cz> 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 :)
>>

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

2018-11-30 Thread Jan Walter 
Nevim jak dneska, ale mysql nebyla pred lety dobra (plnohodnotna) relacni
db, postgres je naopak supr uz hodne dlouho. Svyho casu jsem si napr. delal
benchmarky rychlosti beznych r/w operaci pro vetsi stromovy struktury
(postgres, mssql, neo4j) a postgres vychazel v podstate nejlip.

Plus indexace json typu pro flexibilitu, jak rika starenka, podle me
robustni (jedno z mnoha, urcite) reseni.

Bezny dotaz na par tisic zaznamu z par milionu musi byt za destitky max
malo stovek ms, jak rikaji ostatni.

Jinymi slovy postgres rozhodne neni spatna volba.

On Fri, 30 Nov 2018, 12:12 Jirka Vejrazka,  wrote:

> Tri miliony radku jsou jen drobne, pokud spravne pouzijes indexy. Mel bys
> byt na zlomcich sekund pro jeden dotaz (a pokud ten dotaz nevraci tisice
> zaznamu)...
>
>  Jirka
>
>
>
> On Fri, 30 Nov 2018 at 10:34, Stanislav Vasko 
> wrote:
>
>> V mezičase jsem si napsal miniaplikaci, která natahala nějaká data z
>> Heureky a pak jsem skriptem začal soubor dat duplikovat. Aktuálně mám v
>> SQLite asi 3 milióny řádků vše běží, jen tedy vyhledat data s jedinou WHERE
>> podmínkou a sortem je cca 10s (45000 výsledků), s limitem na 10 pak cca
>> 6,5s. Zkusil jsem MySQL a tam jsou reakce lepší, ale hlavně pokud zapisuji
>> do DB mohu z ní v pohodě číst. Což asi bude to hlavní důvod, proč SQLite
>> nebude možné použít, neboť budu potřebovat umět současně zapisovat i číst.
>> Robot pořízující nová data může běžet taky 15-30 minut a nemohu po tuto
>> dobu aplikaci odstavit či házet errory.
>>
>> Nevíte o nějakém prakticky pojatém článku o tom jak si v MySQL či PSQL
>> ušetřit čas a nervy využitím nějakých robotů/automatiky pro zpracování dat
>> do mezitabulek, virtuálních dat apod.? Myslím, že využití a vytahání dat z
>> miliónů řádek pro dashboard apod. by měl robot v DB umět určitě lépe než
>> cokoliv co spáchám já :)
>>
>> Díky!
>>
>> On Thursday, 29 November 2018 22:17:08 UTC+1, Vítek Pliska wrote:
>>>
>>> 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 o

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

2018-11-30 Thread Jirka Vejrazka 
Tri miliony radku jsou jen drobne, pokud spravne pouzijes indexy. Mel bys
byt na zlomcich sekund pro jeden dotaz (a pokud ten dotaz nevraci tisice
zaznamu)...

 Jirka



On Fri, 30 Nov 2018 at 10:34, Stanislav Vasko 
wrote:

> V mezičase jsem si napsal miniaplikaci, která natahala nějaká data z
> Heureky a pak jsem skriptem začal soubor dat duplikovat. Aktuálně mám v
> SQLite asi 3 milióny řádků vše běží, jen tedy vyhledat data s jedinou WHERE
> podmínkou a sortem je cca 10s (45000 výsledků), s limitem na 10 pak cca
> 6,5s. Zkusil jsem MySQL a tam jsou reakce lepší, ale hlavně pokud zapisuji
> do DB mohu z ní v pohodě číst. Což asi bude to hlavní důvod, proč SQLite
> nebude možné použít, neboť budu potřebovat umět současně zapisovat i číst.
> Robot pořízující nová data může běžet taky 15-30 minut a nemohu po tuto
> dobu aplikaci odstavit či házet errory.
>
> Nevíte o nějakém prakticky pojatém článku o tom jak si v MySQL či PSQL
> ušetřit čas a nervy využitím nějakých robotů/automatiky pro zpracování dat
> do mezitabulek, virtuálních dat apod.? Myslím, že využití a vytahání dat z
> miliónů řádek pro dashboard apod. by měl robot v DB umět určitě lépe než
> cokoliv co spáchám já :)
>
> Díky!
>
> On Thursday, 29 November 2018 22:17:08 UTC+1, Vítek Pliska wrote:
>>
>> 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
>>

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

2018-11-30 Thread Radim Novotny 
Pokud jde o "mezitabulky" tak by mohly pomoct SQL View

-- 
Radim

On Fri, Nov 30, 2018 at 10:37 AM starenka .  wrote:

> Nevim jesli to tady zaznelo, ale postgres ma JSON field (podpora i v
> djangu), kterej se da rozumne indexovat...
>
> https://www.postgresql.org/docs/10/datatype-json.html
>
> https://docs.djangoproject.com/en/2.1/ref/contrib/postgres/fields/#jsonfield
> ---
> In Perl you shoot yourself in the foot, but nobody can understand how you
> did it. Six months later, neither can you. | print 'aknerats'[::-1]
>
>
> On Fri, Nov 30, 2018 at 10:34 AM Stanislav Vasko <
> stanislav.va...@gmail.com> wrote:
>
>> V mezičase jsem si napsal miniaplikaci, která natahala nějaká data z
>> Heureky a pak jsem skriptem začal soubor dat duplikovat. Aktuálně mám v
>> SQLite asi 3 milióny řádků vše běží, jen tedy vyhledat data s jedinou WHERE
>> podmínkou a sortem je cca 10s (45000 výsledků), s limitem na 10 pak cca
>> 6,5s. Zkusil jsem MySQL a tam jsou reakce lepší, ale hlavně pokud zapisuji
>> do DB mohu z ní v pohodě číst. Což asi bude to hlavní důvod, proč SQLite
>> nebude možné použít, neboť budu potřebovat umět současně zapisovat i číst.
>> Robot pořízující nová data může běžet taky 15-30 minut a nemohu po tuto
>> dobu aplikaci odstavit či házet errory.
>>
>> Nevíte o nějakém prakticky pojatém článku o tom jak si v MySQL či PSQL
>> ušetřit čas a nervy využitím nějakých robotů/automatiky pro zpracování dat
>> do mezitabulek, virtuálních dat apod.? Myslím, že využití a vytahání dat z
>> miliónů řádek pro dashboard apod. by měl robot v DB umět určitě lépe než
>> cokoliv co spáchám já :)
>>
>> Díky!
>>
>> On Thursday, 29 November 2018 22:17:08 UTC+1, Vítek Pliska wrote:
>>>
>>> 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
>>> tec

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

2018-11-30 Thread starenka . 
Nevim jesli to tady zaznelo, ale postgres ma JSON field (podpora i v
djangu), kterej se da rozumne indexovat...

https://www.postgresql.org/docs/10/datatype-json.html
https://docs.djangoproject.com/en/2.1/ref/contrib/postgres/fields/#jsonfield
---
In Perl you shoot yourself in the foot, but nobody can understand how you
did it. Six months later, neither can you. | print 'aknerats'[::-1]


On Fri, Nov 30, 2018 at 10:34 AM Stanislav Vasko 
wrote:

> V mezičase jsem si napsal miniaplikaci, která natahala nějaká data z
> Heureky a pak jsem skriptem začal soubor dat duplikovat. Aktuálně mám v
> SQLite asi 3 milióny řádků vše běží, jen tedy vyhledat data s jedinou WHERE
> podmínkou a sortem je cca 10s (45000 výsledků), s limitem na 10 pak cca
> 6,5s. Zkusil jsem MySQL a tam jsou reakce lepší, ale hlavně pokud zapisuji
> do DB mohu z ní v pohodě číst. Což asi bude to hlavní důvod, proč SQLite
> nebude možné použít, neboť budu potřebovat umět současně zapisovat i číst.
> Robot pořízující nová data může běžet taky 15-30 minut a nemohu po tuto
> dobu aplikaci odstavit či házet errory.
>
> Nevíte o nějakém prakticky pojatém článku o tom jak si v MySQL či PSQL
> ušetřit čas a nervy využitím nějakých robotů/automatiky pro zpracování dat
> do mezitabulek, virtuálních dat apod.? Myslím, že využití a vytahání dat z
> miliónů řádek pro dashboard apod. by měl robot v DB umět určitě lépe než
> cokoliv co spáchám já :)
>
> Díky!
>
> On Thursday, 29 November 2018 22:17:08 UTC+1, Vítek Pliska wrote:
>>
>> 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 účel

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

2018-11-30 Thread Stanislav Vasko 
V mezičase jsem si napsal miniaplikaci, která natahala nějaká data z 
Heureky a pak jsem skriptem začal soubor dat duplikovat. Aktuálně mám v 
SQLite asi 3 milióny řádků vše běží, jen tedy vyhledat data s jedinou WHERE 
podmínkou a sortem je cca 10s (45000 výsledků), s limitem na 10 pak cca 
6,5s. Zkusil jsem MySQL a tam jsou reakce lepší, ale hlavně pokud zapisuji 
do DB mohu z ní v pohodě číst. Což asi bude to hlavní důvod, proč SQLite 
nebude možné použít, neboť budu potřebovat umět současně zapisovat i číst. 
Robot pořízující nová data může běžet taky 15-30 minut a nemohu po tuto 
dobu aplikaci odstavit či házet errory.

Nevíte o nějakém prakticky pojatém článku o tom jak si v MySQL či PSQL 
ušetřit čas a nervy využitím nějakých robotů/automatiky pro zpracování dat 
do mezitabulek, virtuálních dat apod.? Myslím, že využití a vytahání dat z 
miliónů řádek pro dashboard apod. by měl robot v DB umět určitě lépe než 
cokoliv co spáchám já :)

Díky!

On Thursday, 29 November 2018 22:17:08 UTC+1, Vítek Pliska wrote:
>
> 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, uk

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 django-cs+...@googlegroups.co

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á s

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 e

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.