[markaron]

Nietrywialny problem. Jest system A, który ma za zadanie pobierać dane z B i wysyłać do C. W jaki sposób rozwiązalibyście problem synchronizacji danych w taki sposób, aby do systemu C wysyłać tylko nowe dane, czyli takie, które nie zostały do tej pory przetworzone. Dane z systemu B można otrzymać wysyłając żądanie pod przykładowy adres /api/products który zwraca listę wszystkich produktów.

Najprostszym rozwiązaniem jest przechowywanie przez system A lokalnie metadanych produktów które zostały już przesłane i za każdym razem porównywanie ich z kolekcją zwracaną przez B, ale dla dużych zbiorów danych takie rozwiązanie wydaje się mało optymalne. Jednym ze sposobów na optymalizację tego typu filtrowania mogłoby być użycie po stronie A bazy NoSQL np. klucz-wartość, mimo wszystko trzeba za każdym razem pobierać z B wszystkie dane o produktach.

Jakieś inne pomysły?

#programowanie

[Kaczus2B]

@markaron: Zależy od danych - ilości ect - najprostsze indeksowanie zmian i system C pyta danych od indeksu zmian takiego i takiego. Ale bez pełnej struktury co ma być przechowywane ciężko dać najlepsze rozwiązanie.

[markaron]

@Kaczus2B: To są ogólne rozważania, więc można dać wodze fantazji :)

Co do twojego pomysłu to w moim pytaniu system C ma tylko przyjmować dane od A. Cała odpowiedzialność za synchronizację danych, transformacje itp jest po stronie A.

[k.....l]

@markaron: A jest możliwość modyfikowania systemu b?

[Kaczus2B]

@markaron: Moim zdaniem to nie do konca dobry pomysl, oczywiscie moze byc czesc takiej odpowiedzialnosci - np odpowiednie przetworzenie zapytania, ale gdy dane z jakiś powodów w C nie zostana zapisane (np ostatnia paczka), to A o tym nie wie i przysle nowsze dane i powstanie dziura. Przynajmniej w obrebie sesji lepszym byloby pochwalenie sie C jakie dane juz ma.

[markaron]

@kisi3l: Nie :)
@Kaczus2B:

Jest to typowy problem z zakresu integracji systemów. Stworzyć usługę, która będzie przesyłać dane z jednego systemu do drugiego bez możliwości ingerencji w obydwa systemy

[Kaczus2B]

@markaron: wiem i podobne systemiki robilem i z doswiadczenia powiem, ze schamat podany, ze C chwali sie co juz ma i dopiero sa dosylane dalsze dane zazwyczaj byl lepszy - jak napisalem sie chwalenie sie co ma to kwestia jakiegos indeksu, daty albo kombinacji takowych. Inaczej powstawaly luki (w zaleznosci od uwarunkowan) w danych.

[markaron]

@Kaczus2B: Ok, teraz złapałem co miałeś na myśli. Ma to sens w sytuacji, gdy system A wyśle dane, które nie dotrą do C. A będzie myślał, że dane zostały dostarczone, a fizycznie ich nie będzie. Rozwiązaniem byłby jakiś mechanizm potwierdzania, co wprowadza dodatkową złożoność do systemu.

[phosphor-bronze]

@markaron: jeśli nie masz możliwości weryfikacji co jest już w C lub czy C zapisał poprawnie dany batch, to generalnie jesteś w miejscu gdzie plecy tracą swą szlachetną nazwę :) BTW interfejs systemu B jest słaby skoro nie ma możliwości wysłania parametrów filtrowania, co jak produktów będzie milion? System B powinien mieć filtrowanie, dane z unikalnym kluczem, ew mógłbyś haszować jeśli klucza nie ma i deduplikowac na tym haszu. Reasumując, nie

[markaron]

@phosphor-bronze: Pełna zgoda, problem w tym, że takie interfejsy istnieją i trzeba sobie jakoś radzić :)

[phosphor-bronze]

@markaron: no to trzymasz rejestr w A, tam deduplikujesz, a spójność z C sprawdzasz w jakiś magiczny sposób, np. pani Krysia z C przesyła arkusz Excela - zakładam, że A musi być w jakiś sposób powiązana z B i C instytucjonalnie/B2B ;) Ewentualnie ludzie od C tworzą system D, który wyciąga raporty z C dostępne dla A. Kluczową sprawą też będzie częstotliwość updatów. Jest dużo łatwiej jak to będzie jeden load

[markaron]

@phosphor-bronze: Przekombinowane, rozwiązanie zaproponowane przez @Kaczus2B: wydaje się być najrozsądniejszą opcją. Gratuluję :)

[phosphor-bronze]

@markaron: może tak, a może nie. IMHO za dużo tu niewiadomych, żeby zaproponować jedynie słuszne rozwiązanie.

[markaron]

@phosphor-bronze: Bo to było takie ogólne pytanie żeby wywołać jakąś ciekawą dyskusję i dowiedzieć się czegoś nowego :)