Closed ondrejhlavacek closed 2 years ago
tj. za me tlustej klient https://keboola.slack.com/archives/C03JBGZDG/p1532950831000114 klidne v jiny classe, soucasne by se s tim daly vyhodit array options
jde to proti konceptu config rows - musel by se dělat deferred import - importovat až na konci všech rows a data mezi tím někde skladovat. je to řešitelný, ale pokud něco zapisuje do stejný tabulky, mohl by tam bejt konflikt (ten by se teda mimochodem musel řešit i bez config rows)
to ze runner dela importy po kazdym config row je sideeffect implementace a ne nejaky designovy rozhodnuti (dokonce si jeste ani nejsme uplne jisti, jestli je to pozitivni nebo negativni sideeffect), takze zrovna timhle bych se neomezoval
data by nebylo potřeba nikde skladovat, mohlo by je to házet normálně do files. A nakonci pak jenom odpálit paralelně importy.
Jo, to by asi šlo, otázka je, jestli hromadným uploadem všeho do S3 naráz taky nezískáme nějakej čas navíc (ty uploady by taky mohly jít paralelizovat), ale proti importním jobům to může bejt zanedbatelnej bonus.
Teď jsme se ještě bavili o tom že nejlepší by bylo paralelizovat celé config rows.
ref https://github.com/keboola/output-mapping/issues/15
Může bejt víc variant, jak to implementovat
Tenkej klient
V podstatě by klient zůstal jak je, s pár drobnejma změnama, a celou paralelizaci by se řešila na straně integrace klienta (input/output mapping v docker runneru). Volání fcí klienta (upload do S3, založení tabulky) úplně snadno paralelizovat nejde (možná se pletu?) a nejsem si jistej, jestli je to úplně optimální řešení.
Tlustej klient
Veškerá paralelizace by se udělala na straně klienta. Vznikla by série metod, který by přijímaly pole (
Client::createTablesAsync
,Client::writeTablesAsync
,Client::uploadSlicedFiles
,Client::uploadFiles
apod.). Zároveň by asi bylo dobrý sjednotit interface pro slicovaný a neslicovaný soubory, který se řeší každej jinakhttps://github.com/keboola/output-mapping/blob/42ac0739d1497ea94b4e468aba2dd61deaeddf4b/Writer/Writer.php#L506-L513
Wrapper
Totéž jako tlustej klient, ale v jiný classe, ale nejsem si jistej, jestli nebude potřebovat přistupovat k nějakým private/protected metodám klienta. Ale zase by se tím vyřešilo sjednocení toho interface.
Podobně by pak šla implementovat i paralelizace exportů.