Как лучше хранить GPS-треки в БД?

Question

[dom1n1k]

Вопрос теортический для размышления.

Есть много GPS-треков, в каждом из них много точек. Что значит много? Поскольку вопрос теоретический, конкретных цифр не назову, но потенциально может быть до нескольких миллионов и там и там. То есть перемножая одно на другое, получаем триллион.

Как лучше организовать хранение в БД? Мне один товарищ сказал, мол, делаем таблицу треков и таблицу точек. Все точки скопом попадают в неё, а когда надо получить конкретный трек, идет выборка точек по id трека и сортировка по порядку. Мне кажется, это не очень эффективно и будет отлично работать на небольших объемах, но с их ростом очень быстро ляжет.

Хранить точки каждого трека в виде блоба? Еще более странно.
Смотреть в сторону NoSQL?
Может есть стандартные схемы?

Comments

[Толстый Лорри]

Исходя из вопроса, вам нужны точки исключительно в контексте своих треков, без хитрого поиска по ним (глобально), без большой метаинформации и внешних связей, то выделять в отдельную сущность не имеет смысла. Так же вряд ли понадобится представлять точки маршрута иначе, чем в натуральном порядке (в прямом или обратном направлении). Для такого кейса блоб мне кажется годным решением.

Answer 1

[Fixid]

PostgreSQL + PostGis. Хранить в виде обычных координат желаемой точности. Возможно выборка любой сложности.
Сейчас у меня база координат занимает более 70гб, выборка координат внутри желаемого полигона занимает примерно 6мс на обычном hdd.
При желании можно треки запихать в виде multiline из которого потом легко вытащить отдельные точки

P.S. связку PostgreSQL + PostGis использует OSM, где база планеты в распакованном виде легко переваливает за 500гб

Comments

[dom1n1k]

А там можно хранить метаданные для каждой точки? Пульс и так далее - всё, что что генерируют спортивные трекеры.

[Дмитрий Шицков]

dom1n1k, вы что, собираетесь данные хранить в базе данных? Безумие.

[Fixid]

dom1n1k, конечно. Это просто реляционная БД с дополнительными геофункциями и типами данных

[dom1n1k]

Я имел в виду если использовать multiline. В обычном не-гео-специфичном виде ежу понятно что можно.

[Fixid]

dom1n1k, тогда нет, multiline это цельный объект в бинарном виде. Вы можете хранить в соседней ячейке список ключ-значение для конкретной точки на треке (по номеру точки или координатам)

Answer 2

[Илья Зверев]

Правильным будет не хранить треки в БД. Сначала ответьте на вопрос (не здесь, а для себя), зачем это нужно. Часто достаточно загружать треки в gpx куда-нибудь на сервер — например, на амазон. А в базе хранить индексы: например, предельно упрощённый LineString, точки начала и конца, какие-то важные вехи, по которым будут запросы. Другими словами, отдельно блобы gpx (в амазоне, в append-only kv-базе и т.п.), отдельно метаданные для потенциально сложных запросов. Геоданные, конечно, лучше хранить в PostGIS, как Fixid ответил.

Answer 3

[Андрей Скоржинский]

Можно использовать геоданные в реляционных БД. Например в MS SQL