Геоданные Титана на Кассандре

Я рассматриваю возможность использования Titan для создания масштабируемого хранилища геопространственных данных (я думаю, R-деревьев). В документации есть запрос GeoShape, а в документах сказано, что titan может делать геоданные с Lucene или ElasticSearch. Однако кажется, что это будет очень медленно, потому что обход узлов в cassandra, по сути, выполняет запросы на соединение в cassandra, что является действительно плохой идеей. Я думаю, что могу неправильно понимать представление данных.

Я прочитал документ Titan Data Model и до сих пор не совсем понял. Если бы все ребра хранились в строке Cassandra, то Титану все равно пришлось бы «присоединяться» к таблице вершин. Одним из способов решения этой проблемы было бы сделать значение столбца равным данным свойства ребра, а затем вы могли бы аккуратно упаковать данные вершины и данные ребра в строку. Однако это не работает, когда вы хотите выполнять запросы глубже, чем 1 узел, и мы снова возвращаемся к проблеме соединения.

Так. Титан эмулирует запросы на соединение в Cassandra? - и - Насколько эффективен поиск по географическому положению в этих условиях?


person Peter Klipfel    schedule 15.03.2014    source источник


Ответы (1)


Я думаю, что вопрос объединяет обход края с поиском геопространственного индекса. Они разделены как на уровне API, так и на уровне реализации. Индекс не показан на рисунках модели данных.

Давайте сделаем это немного более конкретным. Скажем, я запускаю Titan с ES и Cassandra, используя Murmur3Partitioner или RandomPartitioner. Я объявляю геопространственный индекс ES по ребрам с именем "place ", как указано на странице "Начало работы". Поиск ребер с помощью геопространственных запросов, таких как этот "WITHIN" в документации по началу работы сначала нажмите ES. ES возвращает идентификаторы, которые Titan может использовать для быстрого поиска связанных данных вершин/ребер в Cassandra, не выполняя аналогию с реляционными соединениями.

Стоимость этих поисковых запросов по геопространственным данным должна быть примерно эквивалентна стоимости реализации ES WITHIN (которая, я думаю, делегирована Spatial4j), плюс поиск, который Титан делает на Cassandra после получения идентификаторов, который должен быть примерно линейным по количеству ребра, найденные ES. Это всего лишь предварительная оценка, поэтому, пожалуйста, отнеситесь к ней с большой долей скептицизма.

После того, как я получу ребра мест с помощью географического сопоставления, если я затем захочу выполнить произвольный обход в окрестности каждого ребра в наборе, я бы посмотрел на укоренение MultiQuery в головной/хвостовой вершинах и включение кэширования на уровне базы данных. Если запрос пропускает кеш или кеш холодный/отключен, то Titan по-прежнему будет пытаться получить все ребра, которые важны для обхода, в одном срезе Cassandra для каждой вершины, когда это возможно. Если вас беспокоит эффективность обхода границ Титана, вы можете найти Бутик-график данных с Титаном интересно.

ХТН

person Dan LaRocque    schedule 25.03.2014
comment
Вы совершенно правы. Я не понял, как сюда вписывается серверная часть индексации. Спасибо! - person Peter Klipfel; 25.03.2014