[jacobsonik]

Hej Mirki potrzebuje porady #programista15k. Otóż potrzebuję zrobić system coś a'la Endomondo - typek chodzi, wysyła punkty GPS które po stronie serwera są zapisywane do bazy. W przypadku małej ilości userow to wszystko będzie śmigało ale w miarę jak to będzie rosło to będzie jak DDoS dla serwera. Pomyślałem o czymś w stylu Kafka lub może rabbitmq żeby apki wysyłały tam lokalizację a w intervalu jakis worker zbierał paczkę punktów i ładował do bazy danych. Czy dobrze myślę czy może jest jakieś lepsze rozwiązanie ? Będę chciał operować na MySQL i PHP na backendzie (nie nie będę chciał tego zmienić ( ͡~ ͜ʖ ͡°)).

[ulises]

@jacobsonik: a czy każdy jeden punkt musi być wysyłany jako osobny request do serwera?
może jakiś mechanizm - np po requeście serwer wysyła w odpowiedzi, kiedy najwcześniej klient może kolejne zapytanie zrobić, w tym czasie apka #!$%@? wszystkie punkty i potem je w zbiorczym requescie wysyła

[bmLq]

@ulises: Jak chce mieć to live to średnio, spowalnia czas odświeżania

[ulises]

@bmLq: nie było napisane, że ma być, aż tak "live" ( ͡° ͜ʖ ͡°)

a jaka jest szacowana liczba użytkowników?

[maque]

@jacobsonik: Chcesz zrobić system z TimeSeries data, a planujesz użyć tylko bazy relacyjnej? :) Kafka jak najbardziej, ale dorzuć InfluxDB czy coś w tym stylu

[jacobsonik]

@ulises to w sumie jest też fajne rozwiazanie bo tak czy siak bym pewnie robił request z daną lokalizacja i np wysyłał to co 10 sekund ( bo sekunda to czasami mało czasu żeby się przemieścić). Szacowana liczba użytkowników to oczywiście cały świat :p

@maque w sumie to weryfikację punktu lub np scalanie w stylu "ten punkt GPS powtarzał się przez X sekund" zostawilbym po stronie aplikacji. Jedynie będę musiał regularnie pytać

[jacobsonik]

@maque po dłuższej lekturze influxDB wygląda bardzo fajnie :) pytanie czy mimo wszystko kafke zaprzęgać. Nie ma problemu żeby cała struktura opierała się na MySQL a logika samych danych lokalizacyjnych na influxDB prawda ?

[imateapot]

@jacobsonik: zacznij od tego jak bardzo dokładne mają być te pomiary gps z tel. (jak bardzo to zajedziesz ludziom baterie) oraz jak często wysyłać request z pomiarami na serwer (najlepiej jakiś pakiet co x minut). W przypadku 1 requesta od usera co 15-30 minut to nawet zwykły serwer ms sql powinien wystarczyć (prosty request json), o ile serwer wykonuje get/post (z zapisem do bazy) asynchronicznie.

Przy zabawie w "cały świat" jedenie

[jacobsonik]

@imateapot w sumie tu istotne jest częste wysyłanie, bo user Jak chodzi to ma sprawdzać czy napotka na swojej drodze punkt innego usera czyli najlepiej chyba zrobić request wysyłający punkt i jako zwrotkę punkty innych userow w okolicy. Co 1 sekundę to za często ale np co 10 sekund brzmi dość sensownie. Dlatego ten influxDB pod obsługę punktów brzmi dość sensownie :)

[maque]

@jacobsonik: Poczytaj o koncepcji Fast Data vs Big Data. Łączenie kilku baz danych jest jak najbardziej sensowną koncepcją. Generalnie poszukałbym architektur które wpasowują się w Twój pomysł. Mam wrażenie że to kilka różnych koncepcji, z jednej strony trochę Fast Data, trochę Big Data, trochę analiza, trochę zarządzanie mapami (a co za tym idzie liczenie odległości, koordynaty - być może warto przemyśleć inne systemy systemy kartograficzne jak UTM zamist GPS).
Co do

[jacobsonik]

@maque do odważnych świat należy :) poza tym postaram się zrobić jak najbardziej otwarte na rozszerzenia żeby w przyszłości moc ulepszyć rozwiązania :)