Aplikacja będzie stale (mniej więcej co sekundę) zbierać lokalizację użytkowników i przechowywać ich.

Te dane są uporządkowane. W relacyjnej bazie danych byłby przechowywany jako: | user | timestamp | latitude | longitude |

Istnieje jednak zbyt dużo danych. Będzie dziennie 60 × 60 × 24 = 86.400 zapisów na użytkownika. Nawet przy 1000 użytkowników oznacza to 86 400 000 rekordów dziennie.

I to nie tylko 86 400 000 rekordów dziennie. Ponieważ te rekordy będą przetwarzane, a ich przetworzone wersje również będą przechowywane. Pomnóż tę liczbę przez około 2.

Jak planuję korzystać z danych

Zasadniczo planuję tworzyć gruboziarniste wersje danych lokalizacji dla łatwiejszego zużycia. To jest:

1. Sortuj odebrane znaczniki czasu wrt danych.
2. Na tej liście w kolejności ustal, czy lokalizacja uległa znaczącej zmianie (sprawdzając, o ile zmieniła się szerokość i długość geograficzna)
3. Reprezentują nieistotne zmiany lokalizacji jako pojedynczy wpis w danych wyjściowych (stąd wyjście jest grubszą ziarnistą wersją danych lokalizacji).
4. Iteruj ten proces na wyjściu, wymagając jeszcze większej szerokości i długości geograficznej dla znacznej zmiany. W związku z tym produkcja, która ma być wytworzona z poprzedniej produkcji, będzie jeszcze bardziej gruboziarnista.
5. Powtarzaj cały proces tyle, ile potrzeba.
6. Zagreguj zakres rozdzielczości i wyślij je do użytkowników. Ponadto przechowuj wszystkie rozdzielczości danych do późniejszego wykorzystania.

Czego powinienem użyć do przechowywania tych danych? Czy powinienem używać relacyjnej bazy danych czy rozwiązania NoSQL? Jakie inne rzeczy należy wziąć pod uwagę przy projektowaniu tej aplikacji?

Niektóre alternatywy dla przechowywania tych danych:

1. Kolejka wiadomości (prawdopodobnie dystrybuowana), taka jak Apache Kafka

Zostanie to zoptymalizowane do zapisu i odczytu strumienia danych. Jest idealny do zbierania strumieni danych w łatwym do przetworzenia formacie, ale zwykle nie można o nie pytać inaczej niż poprzez odczytanie całego strumienia. Byłoby to więc do celów archiwalnych lub pośredni krok na drodze do warstwy przetwarzania.

2. Relacyjne bazy danych

Możesz po prostu zapisać go do bazy danych, a gdy wolumin przekroczy pojemność bazy danych do obsługi, możesz oddzielić bazę danych (= mieć wiele podzbiorów danych na różnych serwerach bazy danych). Korzyści: możesz użyć relacyjnej bazy danych i nie musisz uczyć się niczego nowego. Wada: cały kod zajmujący się bazą danych musi być świadomy, na którym fragmencie danych żyje, zagregowane zapytania muszą być wykonywane w oprogramowaniu aplikacyjnym.

3. Rozproszona baza danych NoSQL, jak Cassandra.

Zapisujesz swoje dane w rozproszonej bazie danych NoSQL, która automatycznie podzieli dane za Ciebie. Cassandra pozwala wykonywać zapytania w klastrze, wymagając mniej kodu aplikacji, aby odzyskać dane. Korzyści: bardziej naturalnie dostosowane do dużych ilości danych, wady: będą wymagały specjalistycznej wiedzy i głębokiego zrozumienia mechaniki działania tych systemów, aby osiągnąć dobrą wydajność i sprawić, że dane będą odpowiadały twoim potrzebom. NoSQL nie jest magiczną poprawką wydajności, jest to zestaw kompromisów, które należy rozumieć jako nawigowane.

4. Hadoop / file

Dane są dołączane do plików, które są automatycznie dystrybuowane między serwerami przez platformę Hadoop, przetwarzane na tych serwerach za pomocą narzędzi takich jak M / R lub Apache Spark, a na koniec kwerendy (jako pliki) za pomocą silnika SQL Hadoop, takiego jak Hive lub Impala.

Który wybrać?

Kompromisy między tymi alternatywami są złożone i bardzo zależą zarówno od twoich zapisów, jak i wzorców czytania, więc jedyną osobą, która może zdecydować o tych kompromisach, jesteś ty. Jeśli brakuje ci czasu na głębsze zrozumienie tych alternatyw, po prostu użyj relacyjnej bazy danych i znajdź rozwiązanie dzielenia na fragmenty. Najprawdopodobniej YAGNI .

Przyjrzyj się swoim wymaganiom nieco głębiej. Istnieje sposób na stworzenie iluzji śledzenia pozycji co sekundę.

Jeśli masz aplikację, która zna twoją aktualną lokalizację GPS i zapisuje ją w bazie danych, dlaczego miałbyś zapisywać lokalizację, jeśli się nie zmienia? Nawet jeśli potrzebujesz danych, jeśli użytkownik spał przez 7 godzin, możesz programowo uzupełnić brakujące przedziały czasowe o zduplikowane miejsce, aby wykonać obliczenia, mapowanie lub cokolwiek innego, co musisz zrobić.

Jeśli śledzisz lokalizację co sekundę, czy musisz przechowywać te dane na zawsze? Możesz zarchiwizować rekordy w innej bazie danych, aby zapobiec nadmiernemu powiększeniu bieżącej tabeli. Lub możesz po prostu przechowywać zapisy, w których następuje zmiana pozycji. Jest to powszechne w hurtowniach danych.

Twoje dane to zestaw szeregów czasowych. Podano zestawy liczb (dwa na użytkownika), które ewoluują z czasem. Zazwyczaj NIE szukasz żadnego rodzaju magazynu relacyjnego, ale raczej magazynu RRD. Te pamięci masowe koncentrują się na zmniejszeniu pracy we / wy wielu małych zapisów przez buforowanie.

Relacyjne przechowywanie jest herezją dla tego tomu szeregów czasowych. Należy jednak pamiętać, że rozwój RRD nie jest tak dobrze obsługiwany pod względem programowalnych exploitów, jak SQL. Prawdopodobnie patrzysz na poważne prace integracyjne, ale nie da się tego uniknąć, biorąc pod uwagę twoje wymagania.