Додаток буде постійно (приблизно кожну секунду) збирати місцезнаходження користувачів та зберігати їх.

Ці дані структуровані. У реляційній базі даних вона зберігатиметься як: | user | timestamp | latitude | longitude |

Однак даних є занадто багато. Щодня буде 60 × 60 × 24 = 86 400 записів на користувача. Навіть з 1000 користувачів це означає 86 400 000 записів щодня.

І це не лише 86 400 000 записів щодня. Оскільки ці записи будуть оброблені, а оброблені версії також будуть зберігатися. Отже, помножте це число приблизно на 2.

Як я планую використовувати дані

По суті, я планую зробити більш грубі версії даних про місцезнаходження для більш легкого використання. Це є:

1. Сортувати отримані дані wrt мітки часу.
2. Повторюючись у цьому списку, визначте, чи істотно змінилось місце розташування (перевіривши, наскільки змінилася широта та довгота)
3. Представляти несуттєві зміни місцеположення як єдиний запис у висновку (отже, висновок є більш грубої версією даних про місцезнаходження).
4. Повторіть цей процес на виході, вимагаючи ще більшої зміни широти та довготи для значної зміни. Отже, вихід, отриманий з попереднього випуску, буде ще більш грубозернистим.
5. Повторіть весь процес стільки, скільки потрібно.
6. Об'єднайте діапазон резолюцій та надішліть їх користувачам. Також зберігайте всі роздільні дані для подальшого споживання.

Що я повинен використовувати для зберігання цих даних? Чи слід використовувати реляційну базу даних або рішення NoSQL? Які ще речі слід враховувати при розробці цього додатка?

Деякі варіанти зберігання цих даних:

1. Черга повідомлень (можливо, розповсюджена), як Apache Kafka

Це буде оптимізовано для запису та читання потоку даних. Він ідеально підходить для збору потоків даних у простому для обробки форматі, але його зазвичай не можна запитувати, за винятком повного зчитування потоку. Отже, це буде або для архівних цілей, або проміжним кроком на шляху до шару обробки.

2. Реляційна база даних

Ви можете просто записати його в базу даних, і коли обсяг перевищує ємність БД для обробки, ви можете розподілити базу даних (= кілька підмножин даних сидять на різних серверах баз даних). Перевага: ви можете використовувати реляційний БД і не потрібно дізнаватися нічого нового. Знизу: весь код, що має справу з БД, повинен знати про те, на якому фрагменті знаходиться частина даних, агреговані запити повинні виконуватися в прикладному програмному забезпеченні.

3. Розподілена база даних NoSQL, як Cassandra.

Ви записуєте свої дані в розподілену базу даних NoSQL, і вона автоматично розподілить дані для вас. Cassandra дозволяє робити запити в кластері, вимагаючи менше коду програми для повернення даних. Перевага: більш природно підходить для великого обсягу даних, зворотний бік: вимагатиме специфічного досвіду та глибокого розуміння механіки того, як ці системи працюють для досягнення хорошої продуктивності та зробити дані пошуковими відповідно до ваших потреб. NoSQL не є магічним виправленням продуктивності, це набір компромісів, які слід розуміти, щоб орієнтуватися.

4. Hadoop / файл

Дані додаються до файлів, які автоматично розподіляються на серверах платформою Hadoop, обробляються на цих серверах за допомогою таких інструментів, як M / R або Apache Spark, і, нарешті, запитуються (як файл) за допомогою двигуна Hadoop SQL, як Hive або Impala.

Який вибрати?

Компроміси між цими альтернативами складні, і вони дуже залежать як від вашої схеми запису, так і від вашої схеми читання, тому єдиний чоловік, який може прийняти рішення про ці компроміси - це ви. Якщо вам не вистачає часу на глибоке розуміння цих альтернатив, тоді просто скористайтеся реляційною БД і знайдіть вирішення проблем, що рухаються далі. Ймовірно , YAGNI .

Погляньте на свої вимоги трохи глибше. Існує спосіб створити ілюзію відстеження позиції щосекунди.

Якщо у вас є додаток, який знає ваше поточне місцезнаходження GPS і записує його в базу даних, чому б ви продовжували писати місце, якщо воно не змінюється? Навіть якщо вам потрібні дані, якщо користувач спав протягом 7 годин, ви можете програмно заповнити пропущені часові проміжки з подвійним розташуванням, щоб зробити свої розрахунки чи картографування або все, що вам потрібно зробити.

Якщо ви відстежуєте місцеположення щосекунди, чи потрібно зберігати ці дані назавжди? Ви можете архівувати записи в іншій базі даних, щоб запобігти занадто великій кількості поточної таблиці. Або ви могли навіть просто вести записи там, де є зміна позиції. Це поширене в сховищах даних.

Ваші дані - це набір часових рядів. Ви вказали набори чисел (по два на користувача), які змінюються з часом. Як правило, ви шукаєте НЕ будь-який тип реляційного зберігання, а швидше RRD-накопичувач. Ці сховища сильно зосереджені на зменшенні роботи вводу / виводу численних невеликих записів шляхом буферизації.

Реляційне зберігання - єресь для цього обсягу часових рядів. Однак слід попередити, що розробка RRD не так добре підтримується з точки зору програмованих експлуатацій, ніж SQL. Ви, мабуть, дивитесь на серйозну інтеграційну роботу, але це навряд чи можна уникнути, враховуючи ваші вимоги.