Jak przechowywać duże ilości danych strukturalnych?

9

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?

Utku
źródło
3
2000 rekordów na sekundę prawdopodobnie nie sprawi problemów aktualnemu silnikowi SQL. Prostym testem pojemności byłoby pobranie z konsoli programu losowych plików, które zostaną załadowane zbiorczo.
Caleth
1
@Caleth Ale czy to jest skalowalne? A co, gdy baza użytkowników wzrośnie 100 razy?
Utku
3
Zmierz, co twój sprzęt może obecnie obsłużyć. Wąskim gardłem może być albo „przetwarzanie” wartości przez procesor, albo surowa prędkość dysku. Co zamierzasz zrobić z tymi wszystkimi danymi? To powinno ukształtować jaką technologię wybierzesz do przechowywania
Caleth
3
Caleth ma absolutną rację. Miliony rekordów nie przeszkadzają nowoczesnemu systemowi baz danych. Sklepy NoSQL bardzo dobrze zapisują ogromne ilości danych bardzo szybko, ale ostatecznie chcesz zrobić coś, co wymaga ponownego przeczytania . To, ile czytania będziesz potrzebować, często określa, jakiego rodzaju sklepu powinieneś używać.
Kilian Foth,
3
Aby udzielić dobrej odpowiedzi, musimy wiedzieć, w jaki sposób planujesz korzystać z tych danych. Baza danych może być dobrym wyborem, jeśli chcesz zapytań ad hoc, podczas gdy rozwiązanie oparte na plikach byłoby prawdopodobnie lepsze do analizy całego zestawu danych. Głosowanie na zakończenie.
kdgregory

Odpowiedzi:

9

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.

  1. 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.

  1. 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.

  1. 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 .

Joeri Sebrechts
źródło
Podałem więcej szczegółów na temat tego, jak planuję korzystać z danych. Czy chcesz dodać coś, biorąc pod uwagę te informacje?
Utku
Nadal nie do końca jasne, co rozumiesz przez „rozdzielczość”. Czy chcesz agregować na poziomie geograficznym (miasto, państwo, ...) czy na jakimś układzie współrzędnych, takim jak geohash? A może interesuje Cię wielkość delty, ponieważ chcesz budować powiadomienia na podstawie progów ruchu? Krótko mówiąc: po co to wszystko?
Joeri Sebrechts
Służy do śledzenia użytkowników. Użytkownicy śledzą się nawzajem, a ja rysuję wykres, na którym użytkownicy, których śledzą, byli na urządzeniach w ciągu ostatnich 5 godzin. Zasadniczo im drobniejsze ziarna, tym lepiej. Jednak urządzenia mobilne mają ograniczoną ilość pamięci, dlatego nie można wysłać danych bez zmniejszenia ich rozdzielczości. To znaczy, powiedzmy, że użytkownik A śledzi użytkownika B, C i D. Jeśli po prostu przekażę wszystkie dane lokalizacji, które otrzymam od B, C i D do A, bez przetwarzania po stronie serwera, pamięć urządzenia użytkownika A zapełni się bardzo szybko . Dlatego muszę trochę przetworzyć.
Utku
Gdybym miał zbudować to, co opisujesz, skonstruowałbym to jako serię dzienników kafka połączonych za pomocą strumieniowania iskier, w których pozycje są zintegrowane między oknami w strumieniu iskier, a końcowy dziennik kafka jest dostarczany jako pull i przesyłać interfejsy sieciowe do klientów. Jednak ... to bardzo szczególna technologia, a w zależności od twojego pochodzenia i dostępnego czasu te wybory mogą być dla ciebie złe.
Joeri Sebrechts
Dzięki. Będę o tym pamiętać, ale zgodnie z zasadą YAGNI planuję na razie korzystać z relacyjnej bazy danych. Kiedy zajdzie taka potrzeba, przejdę na coś, co lepiej pasuje do aplikacji. Jeśli chcesz, możesz edytować dowolne informacje w swojej odpowiedzi.
Utku
6

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.

JeffO
źródło
2

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.

Arthur Havlicek
źródło