Nie mam doświadczenia w programowaniu wielowątkowym, dlatego proszę Was o pomoc;) Przygotowuje aplikacje testową. Przyjmuje plik CSV, apka ma wykonać operacje na danych z CSV i zwrócić zmieniony plik CSV do klienta. Wymagania są następujące: - very large sets of trades (millions). - a large set of products (10k to 100k)
Czy dobrym podejściem jest: 1. Przyjęcie pliku , wygenerowanie UUID i zwrócenie go klientowi i wywołanie asynchroniczne operacji na pliku CSV, zapisanie danych do bazy danych i zwrócenie ich jak klient powtórnie odpyta endpoint z wygenerowanym UUID?
2. Operacja synchroniczna na pliku. Myślałem żeby podzielić plik na mniejsze kawałki, wykonać na nim operacje wielowątkowo i jeśli wszystkie wątki skończą pracę to złożyć ten plik i zwrócić go klientowi.
jak zawsze w IT "to zależy" :) trochę mieszasz pojęcia - jak podzielisz plik na kawałki i wielowątkowo przetworzysz, to dalej możesz klientowi zwrócić UUID i zrobić async.
wymagania są trochę niedokładne - imho istotną kwestią jest złożoność samego przetwarzania - np. czy musisz odwoływać się do innych systemów itd. ilu takich plików spodziewasz się na raz? czy masz jakieś SLA na przetworzenie pliku/ x k rekordów? czy kolejność ma rekordów ma znaczenie (skoro to trades, to może mieć :))? czy oferujesz upload przez jakiś endpoint, czy jakoś inaczej - czy potrzeba robić jakąś kontrolę poprawności? i oczywiście, wszystko rozbija się o budżet - deploy w chmurze, jakieś serverlessy, kolejki itd.
@quwer: napisz i wtedy zobacz. Opcja druga jest zawsze dobrym rozwiązaniem, ale jeśli przeprocesowanie nie trwa długo a klient chce dane na już to przekombinowanie nic nie daje
Z drugiej strony rozmiar jest raczej spory i nawet jak algorytm będziesz miał szybki to lepiej to zrobić asynchronicznie, bo klient będzie w swojej niecierpliwości będzie odpalał te akcje cały czas
jakiś proces dzieli plik na części i ładuje na kolejkę.
Wybierz jedno. Miliony czy very large sets? Bo wiesz, przejechanie nawet miliarda rowków w CSV jednym wątkiem to jest robota na max kilka minut, o ile oczywiście nie musisz uderzać do innych systemów. Ale jeśli musisz - to nadal jeden wątek + async.
@Saly: wszystko zależy - OP nie napisał za dużo o danych, sposobie ich przetwarzania i ew. zależnościach od innych systemów, a to imho jest potrzebne do określenia sposobu przetwarzania i ew. dobór narzędzia/technologii, która ma wykonać pracę. nie wiemy, czy zwracamy w CSV tę samą liczbę rekordów, czy agregujemy jakoś, czy przetwarzamy cały plik jako kompletny dataset, czy niezależnie wiersz po wierszu, jakiś spodziewany czas przetworzenia - trochę wróżenie z fusów bez szczegółów.
fakt, zależy, ile to "dużo" danych, niektóre MQ mają dość mocne ograniczenie na rozmiar payloadu.
btw. jeśli dobrze pamiętam, wystarczą 3 maszynki, żeby odpalić kafkę z domyślną redundancją, teraz już można bez zookeepera, więc narzut nie
Przygotowuje aplikacje testową. Przyjmuje plik CSV, apka ma wykonać operacje na danych z CSV i zwrócić zmieniony plik CSV do klienta.
Wymagania są następujące:
- very large sets of trades (millions).
- a large set of products (10k to 100k)
Czy dobrym podejściem jest:
1. Przyjęcie pliku , wygenerowanie UUID i zwrócenie go klientowi i wywołanie asynchroniczne operacji na pliku CSV, zapisanie danych do bazy danych i zwrócenie ich jak klient powtórnie odpyta endpoint z wygenerowanym UUID?
2. Operacja synchroniczna na pliku. Myślałem żeby podzielić plik na mniejsze kawałki, wykonać na nim operacje wielowątkowo i jeśli wszystkie wątki skończą pracę to złożyć ten plik i zwrócić go klientowi.
3. ?
#programowanie #java
trochę mieszasz pojęcia - jak podzielisz plik na kawałki i wielowątkowo przetworzysz, to dalej możesz klientowi zwrócić UUID i zrobić async.
wymagania są trochę niedokładne - imho istotną kwestią jest złożoność samego przetwarzania - np. czy musisz odwoływać się do innych systemów itd. ilu takich plików spodziewasz się na raz? czy masz jakieś SLA na przetworzenie pliku/ x k rekordów? czy kolejność ma rekordów ma znaczenie (skoro to trades, to może mieć :))?
czy oferujesz upload przez jakiś endpoint, czy jakoś inaczej - czy potrzeba robić jakąś kontrolę poprawności?
i oczywiście, wszystko rozbija się o budżet - deploy w chmurze, jakieś serverlessy, kolejki itd.
Z drugiej strony rozmiar jest raczej spory i nawet jak algorytm będziesz miał szybki to lepiej to zrobić asynchronicznie, bo klient będzie w swojej niecierpliwości będzie odpalał te akcje cały czas
@
Wybierz jedno. Miliony czy very large sets?
Bo wiesz, przejechanie nawet miliarda rowków w CSV jednym wątkiem to jest robota na max kilka minut, o ile oczywiście nie musisz uderzać do innych systemów. Ale jeśli musisz - to nadal jeden wątek + async.
nie wiemy, czy zwracamy w CSV tę samą liczbę rekordów, czy agregujemy jakoś, czy przetwarzamy cały plik jako kompletny dataset, czy niezależnie wiersz po wierszu, jakiś spodziewany czas przetworzenia - trochę wróżenie z fusów bez szczegółów.
fakt, zależy, ile to "dużo" danych, niektóre MQ mają dość mocne ograniczenie na rozmiar payloadu.
btw. jeśli dobrze pamiętam, wystarczą 3 maszynki, żeby odpalić kafkę z domyślną redundancją, teraz już można bez zookeepera, więc narzut nie