Приложение будет непрерывно (примерно каждую секунду) собирать местоположение пользователей и сохранять их.

Эти данные структурированы. В реляционной базе данных она будет храниться как: | user | timestamp | latitude | longitude |

Однако данных слишком много. Ежедневно будет 60 × 60 × 24 = 86 400 записей на пользователя. Даже с 1000 пользователей это означает 86 400 000 записей в день.

И это не только 86 400 000 записей в день. Потому что эти записи будут обработаны и обработанные версии будут также сохранены. Итак, умножьте это число примерно на 2.

Как я планирую использовать данные

По сути, я планирую сделать более грубые версии данных о местоположении для более удобного потребления. Это:

1. Сортировать полученные данные по временным меткам.
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.

Какой выбрать?

Компромиссы между этими альтернативами являются сложными, и они очень сильно зависят как от вашей записи, так и от ваших схем чтения, поэтому единственный человек, который может принять решение об этих компромиссах, это вы. Если вам не хватает времени для глубокого понимания этих альтернатив, просто используйте реляционную БД и в процессе работы придумайте решение шардинга. По всей вероятности, ЯГНИ .

Посмотрите на ваши требования немного глубже. Есть способ создать иллюзию отслеживания позиции каждую секунду.

Если у вас есть приложение, которое знает ваше текущее местоположение GPS и записывает его в базу данных, зачем вам продолжать записывать местоположение, если оно не меняется? Даже если вам требуются данные, если пользователь спал в течение 7 часов, вы можете программно заполнить недостающие временные интервалы дублирующим местоположением для выполнения ваших расчетов или картирования или чего-либо еще, что вам нужно сделать.

Если вы отслеживаете местоположение каждую секунду, нужно ли хранить эти данные вечно? Вы можете заархивировать записи в другую базу данных, чтобы предотвратить слишком большой размер текущей таблицы. Или вы можете просто вести записи, где происходит изменение позиции. Это распространено в хранилищах данных.

Ваши данные - это набор временных рядов. Вы дали наборы чисел (по два на пользователя), которые меняются со временем. Как правило, вы НЕ ищете какое-либо реляционное хранилище, а скорее хранилище RRD. Это хранилище в значительной степени направлено на уменьшение количества операций ввода-вывода для множества небольших записей путем его буферизации.

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