Подтвердить что ты не робот

Как хранить в базе данных 800 миллиардов GPS-маркеров

Мне нужно хранить треки GPS, которые пользователи записывают в базу данных. Треки будут состоять из маркера каждые 5 метров движения с целью рисования линии на карте. Я оцениваю 200-километровые дорожки, что означает отметки в 40 000 lnlt. Я оцениваю 50 000 пользователей минимум и 20 штук 200 км треков для каждого. Это означает, что по меньшей мере 40 миллиардов lnlt маркеров.

Это тоже необходимо масштабировать, поэтому для 1 миллиона пользователей мне нужна емкость для 800 миллиардов маркеров GPS.

Поскольку каждый набор из 40 000 маркеров относится к одному треку, мы говорим о 1-20 миллионах записей/наборов GPS-треков.

Требования: Пользователи запросят просмотреть эти треки поверх карты Google в мобильном приложении.

Отношения: В настоящее время у меня есть 2 таблицы. В первой таблице: [trackid], [userid], [комментарий], [расстояние], [время], [максимальная скорость].

В таблице 2 есть [trackid] [longitude] [широта], и здесь хранятся все маркеры GPS. Каков эффективный способ хранения этого объема данных GPS при сохранении производительности чтения?

Новая информация:

Сохранение данных GPS в файле KML с целью отображения их в качестве дорожки поверх карты Google является хорошим решением, которое экономит пространство базы данных. Сжатие KML в KMZ (в основном сжатый KML с расширением KMZ) значительно снижает размер файла. КМЗ загружается намного быстрее, чем GPX, и может быть интегрирован с API Карт Google в качестве уровня KML. Для получения дополнительной информации см. эту информацию от Google. Кажется, это лучшее решение для предполагаемого требования.

4b9b3361

Ответ 1

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

Хорошим местом для начала является чтение блогов, которые сравнивают производительность и использование баз данных (см. прилагаемый):

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis