Мы рассматриваем использование системы баз данных NoSQL для большого проекта. В настоящее время мы немного ознакомились с MongoDB и Cassandra, хотя у нас нет абсолютно никакого опыта. Мы очень хорошо разбираемся в традиционных реляционных базах данных, таких как MySQL и Microsoft SQL, но NoSQL (хранилище ключей/значений) - это новая парадигма для нас.
Итак, в основном, какую базу данных NoSQL вы рекомендуете для нашего использования?
Мы делаем как тяжелые записи, так и записи. В основном у нас есть десятки тысяч устройств, которые сообщают:
device_id (int), широта (десятичная), долгота (десятичная), дата/время (дата и время), заголовок char (2), speed (int)
Каждую минуту. Таким образом, в пиковые времена мы должны иметь возможность обрабатывать сотни записей в секунду.
Затем у нас также есть пользователи, которые запрашивают эту информацию в форме, дают мне все сообщения с device_id 1234 за последний день или на прошлой неделе. Кроме того, пользователи делают другие запросы, например, дайте мне все сообщения от device_1234, где скорость больше 50, а дата - сегодня.
Итак, наши первоначальные мысли заключаются в том, что MongoDB или Cassandra позволят нам масштабировать это намного проще, чем традиционная база данных.
Документ или значение в MongoDB или Cassandra для нас могут выглядеть так:
{
device_id: 1234,
location: [-118.12719739973545, 33.859012351859946],
datetime: 1282274060,
heading: "N",
speed: 34
}
Какую систему вы рекомендуете? Большое спасибо.
MongoDB имеет встроенную поддержку геопространственных индексов: http://www.mongodb.org/display/DOCS/Geospatial+Indexing
В качестве примера, чтобы найти 10 ближайших устройств в этом месте, вы можете просто сделать
db.devices.find({location: {$near: [-118.12719739973545, 33.859012351859946]}}).limit(10)
У меня есть сообщение в приложении, основанном на местоположении, с использованием MongoDB, как и тот, который вы описали. MongoDB, с его поддержкой запросов и индексов, может сделать его лучшим выбором для вас. Как и Cassandra, MongoDB имеет разбиение на разделы и репликацию, для масштабирования чтения и записи. Их базовая архитектура очень отличается.
Несмотря на то, что вы не указали какие-либо запросы на основе местоположения, если вас интересуют запросы типа "дайте мне все устройства в радиусе r местоположения l и между временем t1 и t2", вы найдете геопространственный запрос MongoDB и индексирование чрезвычайно полезно.
Я проделал определенную работу с mongodb и геопространственными данными, но не по упомянутой выше шкале. Геопространственные поиски очень быстры, намного больше, чем mysql.
Я предлагаю изучить возможности mongodb sharding, replication и clustering для работы с объемом записей. Осколок через идентификатор устройства может быть хорошим способом работы с объемом записи. Если вас интересует близость событий, то более подходящим может быть осколок через lat/lng.
Гнездо
Пойдите с mongodb для поиска геолокации. Версия 2.4 улучшает основные функции географии. Многие крупные сайты используют его для поиска геолокации.
Вы можете использовать ElasticSearch. ES хранит JSON исходного документа вместе со всеми проиндексированными полями. JSON может быть внедрен в любые современные переменные/аргументы. В Java можно даже отключить это и сохранить собственные данные о сохранении Java в поле. После поиска, просто выполните цикл и создайте экземпляр исходных типов объектов.
Использование Elastic Search дает вам индексы Trie для индексов высокоскоростных индексов диапазона, очевидно, что вы получаете полный текстовый поиск каждого аромата и запросы на географические ограничивающие прямоугольники, все в фильтрах AND или OR. Поиск по дате также является родным (хотя Java-передача дат сосет, поэтому я переключился на представления BIG INT временных меток для представления дат)
НЕОБХОДИМО использовать некоторые прошлые и, возможно, существующие решения NoSQL, географическое индексирование и запрос являются ЧАСТЬю любого запроса и никаких дополнительных шагов не требуется. I.E., одно решение MongoDB в недавнем прошлом потребовало геопространственного поиска для сбора соответствующих идентификаторов документов, затем вы использовали эти идентификаторы внутри другого запроса и искали в них те же критерии по другим критериям. В действительности, то, что происходит во всех решениях в любом случае, но это намного быстрее и кэшируется в ElasticSearch.