В основном это продолжение поста @Anony-Mousse, который весьма точен.
Индексы должны быть добавлены в базу данных пользователем. В настоящее время автоматическое индексирование отсутствует (поскольку любой индекс потребует дополнительной памяти и времени на создание). -db.index является параметром для этого. Поддержка автоматического индексирования находится в списке пожеланий, но для этого требуются тщательно настроенные модели затрат. Для небольшого набора данных или многомерных данных или когда пользователю вообще не нужны запросы такого типа, добавление индекса будет стоить денег.
База данных будет пересылать запрос на каждый индекс по порядку. Выигрывает тот индекс, который предлагает ускорение первым. Если ни один индекс не возвращает ускоренный запрос, база данных вернется к линейному сканированию, если только не была дана подсказка DatabaseQuery.HINT_OPTIMIZED_ONLY. В этом случае будет возвращено null. Линейное сканирование может быть принудительно выполнено с помощью QueryUtil, что в основном полезно для индексов модульного тестирования.
М-деревья могут работать с любым числовым расстоянием, но если расстояние не метрическое, результаты могут быть неверными. Следует сообщать об ошибке, если функция расстояния не сообщает isMetric() как истину.
R-деревья могут работать с любой функцией расстояния, которая реализует SpatialPrimitiveDistanceFunction, что по существу означает реализацию нижней границы расстояния между точкой и прямоугольником. Нижняя граница может быть найдена для многих функций расстояния, но эффективность может варьироваться. Например, угловые расстояния гораздо меньше выиграют от прямоугольных страниц, которые использует R-дерево.
Что касается метода run. Предпочтительная подпись для обычных методов векторного пространства:
YourResultType run(Database database, Relation<V> relation)
На данный момент базу данных можно получить через relation.getDatabase(), но это может измениться в будущем. Существует ряд ситуаций, когда это проблематично, и некоторые ситуации, в которых в настоящее время, к сожалению, не могут быть легко удалены. В любом случае, это явная форма, которая удобна для запуска алгоритмов из кода Java, т. е. позволяет мне указать, какое отношение использовать, вместо того, чтобы использовать базу данных, где это единственное подходящее отношение (поэтому оно выбирается автоматически).
У меня есть планы сделать это еще более явным в долгосрочной перспективе, добавив явную поддержку выбора подмножества данных для обработки и, возможно, также запросов. Затем об этом позаботится абстрактный родительский метод run. автоматический оптимизатор будет полагаться на это: он сначала запросит все алгоритмы, которые должны быть запущены, на предмет их требований, включая требования запроса. Затем на основе запросов, набора данных, доступной памяти и т. д. оптимизатор может выбрать соответствующие индексы и передать алгоритму соответствующие методы запроса. Чтобы сохранить простоту подписи run, она, скорее всего, будет обрабатываться с помощью некоторых классов Instance, а вместо этого будет использоваться шаблон factory. Но не беспокойтесь об этом сейчас.
Если вы хотите понять, зачем нам это нужно, взгляните, например, на алгоритмы обнаружения геопространственных выбросов. Подпись, используемая SLOM, например:
OutlierResult run(Database database, Relation<N> spatial, Relation<O> relation)
т. е. SLOM использует два два отношения. Первое отношение — это пространственное отношение экземпляров, т.е. географические позиции. Второе отношение - это фактические данные, например. измерения. Географические позиции используются для определения того, какие экземпляры должны быть похожими (но это также могут быть, например, многоугольники!), в то время как второе отношение определяет данные, которые затем фактически сравниваются на предмет сходства.
person
Erich Schubert
schedule
14.10.2013
