Хранение большого количества данных в базе данных

Question

У меня есть вопрос относительно хранения большого количества данных. Ситуация следующая:

1. Я хочу хранить

   • GPS-координаты (широта и долгота) (каждую минуту или даже меньше интервала, но я рассматриваю каждую минуту)
   • Событие, которое можно повторить для нескольких координат
   • Дата и время въезда (не знаю, что лучше использовать в моем случае)
   • (идентификатор пользователя)

2. Я хочу иметь возможность запросить:

   • Событие по зоне (определение диапазона широты и долготы, например, от (1,1) до (2,2))
   • Отслеживание пользователей от даты X до даты Y (один или несколько пользователей)

Пока я думал над решением:

Решение 1

id_user (int)
id_experince (int)
id_event (int)
dt (datetime)
latitude (decimal)
longitude (decimal)

Я начал делать некоторые вычисления, и это было бы что-то вроде: - около 500 записей в день на пользователя - поскольку я готовлю приложение для некоторой загрузки, может быть около 100-150 пользователей, что будет 75000 записей в день - через месяц появятся миллионы записей

Вероятно, Решение 1 не является хорошим решением, поскольку размер базы данных растет очень быстро.

Решение 2

Имеют 2 таблицы, одна из которых будет агрегировать координаты в соответствии с событием, например, у меня есть событие "Ужин", и это занимает 30 минут, поэтому 30 записей будут сгруппированы в одном поле с типом BLOB. Эта таблица будет выглядеть так:

id_user (int)
id_experience (int)
id_event (int)
dt (datetime)
coordinates(blob)

И еще одна таблица, у которой есть рассчитанные местоположения с некоторыми "шириной" и "длиной", имеющие указатель на первую таблицу

latitude (decimal)
longitude (decimal)
id_entry_in_first_table (int)

Это решение только частично решает мою проблему, представьте, что некоторые события не будут длиться больше нескольких минут и есть необходимость во второй базе данных.

Решение 3

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

Основной вопрос: приемлемы ли какие-либо из представленных решений с точки зрения производительности базы данных? Есть ли лучшее решение для моей проблемы?

Answer 1

Я бы выбрал подход основной детализации.

Два преимущества:

1. У вас нет избыточных записей (1 основная строка и x дочерних строк с координатами)

2. Запросы все еще просты (в отличие от метода BLOB-объектов).

   SELECT m.id_user, m.id_experince, m.id_event, c.latitude, c.longitude
   FROM master_table m
   LEFT JOIN child_table c ON m.id = c.master_table_id
   

И это должно быть довольно быстро даже примного миллионов записей в основной таблице, если вы устанавливаете внешний ключ или индекс в master_table_id

Answer 2

«Миллионы записей» звучат как много, но это то, для чего предназначены базы данных. Как бы вы ни проектировали его, если вы оптимизируете его в соответствии с тем, как вы хотите извлечь из него результаты позже (то есть, на это уйдет время, а не на вставки), тогда у вас все получится.

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

Answer 3

Вы, вероятно, хотите прочитать это: http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html.

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

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

Пространственные расширения предлагают решение для этого - но они не являются "бесплатными", вы должны оптимизировать свой дизайн специально для этого.