[django-cs] Jak verzovat databázi MySQL proti stavu zdrojového kódu?

[Stanislav Vasko]

Zdravím,

rád bych se poradil jak verzujete či zálohujete databázi během vývoje. 
Předpokládám, že to je moje elementární neznalost daná hlavně tím, že jsem 
homo-domo-samouk. K verzování používám GIT v naprosto primitivní formě, cca 
2 větve (master + devel) a na každé větvi commit po každé větší funkčnosti. 
Velice se mi hodí, že k danému stavu se mi uloží i SQLite soubor a tedy 
pokud chci kdykoliv skočit do kteréhokoliv bodu, mám ihned k dispozici i 
funkční databázi (byť pokaždé s jiným stavem dat). Deploy pak udělám 
jednoduše nahráním změněných soubor, pustím ./manage.py migrate a podle 
migrací se vše provede. 

Dneska je na obzoru projekt, kde nejspíše budu používat MySQL(PSQL) a vůbec 
netuším jak se přiblížit podobné funkčnosti. Zkusil jsem si Django napojit 
na MySQL, bez problémů. Migrace také v pořádku, ale pokud vrátím zdrojový 
kód do stavu o několik migrací zpět, jak toto provedu i v MySQL databází? 

Díky za tip či odkaz na dokumentaci.

-- 
-- 
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/890d65bd-a672-4b9d-aa73-016ad78d95a5%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

Re: [django-cs] Jak verzovat databázi MySQL proti stavu zdrojového kódu?

[starenka .]

Cau,

migrace muzes delat i zpetny (tu ti ale nidko nevygeneruje a musis si ji
udelat sam).

cili neco jako

class Migration(migrations.Migration):

dependencies = []

operations = [
migrations.RunPython(forwards_func, reverse_func),
]



---
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:28 AM Stanislav Vasko 
wrote:

> Zdravím,
>
> rád bych se poradil jak verzujete či zálohujete databázi během vývoje.
> Předpokládám, že to je moje elementární neznalost daná hlavně tím, že jsem
> homo-domo-samouk. K verzování používám GIT v naprosto primitivní formě, cca
> 2 větve (master + devel) a na každé větvi commit po každé větší funkčnosti.
> Velice se mi hodí, že k danému stavu se mi uloží i SQLite soubor a tedy
> pokud chci kdykoliv skočit do kteréhokoliv bodu, mám ihned k dispozici i
> funkční databázi (byť pokaždé s jiným stavem dat). Deploy pak udělám
> jednoduše nahráním změněných soubor, pustím ./manage.py migrate a podle
> migrací se vše provede.
>
> Dneska je na obzoru projekt, kde nejspíše budu používat MySQL(PSQL) a
> vůbec netuším jak se přiblížit podobné funkčnosti. Zkusil jsem si Django
> napojit na MySQL, bez problémů. Migrace také v pořádku, ale pokud vrátím
> zdrojový kód do stavu o několik migrací zpět, jak toto provedu i v MySQL
> databází?
>
> Díky za tip či odkaz na dokumentaci.
>
> --
> --
> 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/890d65bd-a672-4b9d-aa73-016ad78d95a5%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/CA%2B7MNVrdG3%2B%3Dm5BNxqtGTW_dvGCkRQpV4b8RQKSZzT-PNnyaJg%40mail.gmail.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

Re: [django-cs] Jak verzovat databázi MySQL proti stavu zdrojového kódu?

[starenka .]

Docka treba tady
https://docs.djangoproject.com/en/2.1/ref/migration-operations/#runpython

pouzijes to tak, ze das: `migrate appka cislomigrace_kam_se_chces_vratit`

s.
---
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:30 AM starenka .  wrote:

> Cau,
>
> migrace muzes delat i zpetny (tu ti ale nidko nevygeneruje a musis si ji
> udelat sam).
>
> cili neco jako
>
> class Migration(migrations.Migration):
>
> dependencies = []
>
> operations = [
> migrations.RunPython(forwards_func, reverse_func),
> ]
>
>
>
> ---
> 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:28 AM Stanislav Vasko <
> stanislav.va...@gmail.com> wrote:
>
>> Zdravím,
>>
>> rád bych se poradil jak verzujete či zálohujete databázi během vývoje.
>> Předpokládám, že to je moje elementární neznalost daná hlavně tím, že jsem
>> homo-domo-samouk. K verzování používám GIT v naprosto primitivní formě, cca
>> 2 větve (master + devel) a na každé větvi commit po každé větší funkčnosti.
>> Velice se mi hodí, že k danému stavu se mi uloží i SQLite soubor a tedy
>> pokud chci kdykoliv skočit do kteréhokoliv bodu, mám ihned k dispozici i
>> funkční databázi (byť pokaždé s jiným stavem dat). Deploy pak udělám
>> jednoduše nahráním změněných soubor, pustím ./manage.py migrate a podle
>> migrací se vše provede.
>>
>> Dneska je na obzoru projekt, kde nejspíše budu používat MySQL(PSQL) a
>> vůbec netuším jak se přiblížit podobné funkčnosti. Zkusil jsem si Django
>> napojit na MySQL, bez problémů. Migrace také v pořádku, ale pokud vrátím
>> zdrojový kód do stavu o několik migrací zpět, jak toto provedu i v MySQL
>> databází?
>>
>> Díky za tip či odkaz na dokumentaci.
>>
>> --
>> --
>> 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/890d65bd-a672-4b9d-aa73-016ad78d95a5%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/CA%2B7MNVooTgzMMjCGJjkJ6Cmhz87U6bcOhzwNoQNW2Wku7ue1eA%40mail.gmail.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

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

[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] Jak verzovat databázi MySQL proti stavu zdrojového kódu?

[starenka .]

Kdyz uz spamuju,

myslim, ze se tady vscihni shodnem, ze pokud ses svuj vlastni pan, tak
rozhodne brat postgres na ukor mysql.

Vyhod sou mraky, ale kdyz se bavime o migracich, tak napriklad kdyz se neco
stane pri migrovani schematu, tak postgres je schopnej delat ALTER SCHEMA v
migraci, takze to vrati nazpatek. U MySQL zustanes s databazi v nejaky
mezifazi a musis to jit uklizet. To nechces.
---
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:32 AM starenka .  wrote:

> Docka treba tady
> https://docs.djangoproject.com/en/2.1/ref/migration-operations/#runpython
>
> pouzijes to tak, ze das: `migrate appka cislomigrace_kam_se_chces_vratit`
>
> s.
> ---
> 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:30 AM starenka .  wrote:
>
>> Cau,
>>
>> migrace muzes delat i zpetny (tu ti ale nidko nevygeneruje a musis si ji
>> udelat sam).
>>
>> cili neco jako
>>
>> class Migration(migrations.Migration):
>>
>> dependencies = []
>>
>> operations = [
>> migrations.RunPython(forwards_func, reverse_func),
>> ]
>>
>>
>>
>> ---
>> 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:28 AM Stanislav Vasko <
>> stanislav.va...@gmail.com> wrote:
>>
>>> Zdravím,
>>>
>>> rád bych se poradil jak verzujete či zálohujete databázi během vývoje.
>>> Předpokládám, že to je moje elementární neznalost daná hlavně tím, že jsem
>>> homo-domo-samouk. K verzování používám GIT v naprosto primitivní formě, cca
>>> 2 větve (master + devel) a na každé větvi commit po každé větší funkčnosti.
>>> Velice se mi hodí, že k danému stavu se mi uloží i SQLite soubor a tedy
>>> pokud chci kdykoliv skočit do kteréhokoliv bodu, mám ihned k dispozici i
>>> funkční databázi (byť pokaždé s jiným stavem dat). Deploy pak udělám
>>> jednoduše nahráním změněných soubor, pustím ./manage.py migrate a podle
>>> migrací se vše provede.
>>>
>>> Dneska je na obzoru projekt, kde nejspíše budu používat MySQL(PSQL) a
>>> vůbec netuším jak se přiblížit podobné funkčnosti. Zkusil jsem si Django
>>> napojit na MySQL, bez problémů. Migrace také v pořádku, ale pokud vrátím
>>> zdrojový kód do stavu o několik migrací zpět, jak toto provedu i v MySQL
>>> databází?
>>>
>>> Díky za tip či odkaz na dokumentaci.
>>>
>>> --
>>> --
>>> 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/890d65bd-a672-4b9d-aa73-016ad78d95a5%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/CA%2B7MNVpqx9sAh3skP0d_dSZOORn8JHyjG5MVAPD%3DcSg%2BVgDG1Q%40mail.gmail.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

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

[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

[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

[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] Jak verzovat databázi MySQL proti stavu zdrojového kódu?

[Stanislav Vasko]

Všude narážím, že raději PSQL než MySQL, ale je někde takto pěkně a jasně 
ukázáno/řečeno/popsáno proč PSQL, ideálně praktické příklady. Knížek je 
hodně, ale ta než dorazí, to čekat nebudu. Nebo co bych měl určitě vědět a 
užít (viz např. views, i když je to jen uložené view, teď studuji 
materialized views).

Moc díky za nasměrování, večer budu chytrej jak rádio :)

On Friday, 30 November 2018 10:35:53 UTC+1, starenka wrote:
>
> Kdyz uz spamuju, 
>
> myslim, ze se tady vscihni shodnem, ze pokud ses svuj vlastni pan, tak 
> rozhodne brat postgres na ukor mysql. 
>
> Vyhod sou mraky, ale kdyz se bavime o migracich, tak napriklad kdyz se 
> neco stane pri migrovani schematu, tak postgres je schopnej delat ALTER 
> SCHEMA v migraci, takze to vrati nazpatek. U MySQL zustanes s databazi v 
> nejaky mezifazi a musis to jit uklizet. To nechces.
> ---
> 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:32 AM starenka .  > wrote:
>
>> Docka treba tady 
>> https://docs.djangoproject.com/en/2.1/ref/migration-operations/#runpython
>>  
>>
>> pouzijes to tak, ze das: `migrate appka cislomigrace_kam_se_chces_vratit`
>>
>> s.
>> ---
>> 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:30 AM starenka . > > wrote:
>>
>>> Cau, 
>>>
>>> migrace muzes delat i zpetny (tu ti ale nidko nevygeneruje a musis si ji 
>>> udelat sam). 
>>>
>>> cili neco jako 
>>>
>>> class Migration(migrations.Migration):
>>>
>>> dependencies = []
>>>
>>> operations = [
>>> migrations.RunPython(forwards_func, reverse_func),
>>> ]
>>>
>>>
>>>
>>> ---
>>> 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:28 AM Stanislav Vasko >> > wrote:
>>>
 Zdravím,

 rád bych se poradil jak verzujete či zálohujete databázi během vývoje. 
 Předpokládám, že to je moje elementární neznalost daná hlavně tím, že jsem 
 homo-domo-samouk. K verzování používám GIT v naprosto primitivní formě, 
 cca 
 2 větve (master + devel) a na každé větvi commit po každé větší 
 funkčnosti. 
 Velice se mi hodí, že k danému stavu se mi uloží i SQLite soubor a tedy 
 pokud chci kdykoliv skočit do kteréhokoliv bodu, mám ihned k dispozici i 
 funkční databázi (byť pokaždé s jiným stavem dat). Deploy pak udělám 
 jednoduše nahráním změněných soubor, pustím ./manage.py migrate a podle 
 migrací se vše provede. 

 Dneska je na obzoru projekt, kde nejspíše budu používat MySQL(PSQL) a 
 vůbec netuším jak se přiblížit podobné funkčnosti. Zkusil jsem si Django 
 napojit na MySQL, bez problémů. Migrace také v pořádku, ale pokud vrátím 
 zdrojový kód do stavu o několik migrací zpět, jak toto provedu i v MySQL 
 databází? 

 Díky za tip či odkaz na dokumentaci.

 -- 
 -- 
 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/890d65bd-a672-4b9d-aa73-016ad78d95a5%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/4aa34fe2-cc3f-48f3-b145-abe496d3c1fe%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

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

[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

[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

[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