Вне полюсов иглу ведет себя как строчная развертка.
А если нас интересуют полярные области, в астрономии, например, лучше нанести объекты на сферу и использовать трехмерный индекс.
В принципе, есть вполне строгая методика для определения параметров индекса.
1) определяем, сколько элементов индекса входит на одну страницу индекса СУБД (ну, или делаем предположение)
3) делим ожидаемое число объектов на число на странице, получаем идеальное число ячеек. Предполагается, что идеальный вариант, когда все данные ячейки помещаются на 1-2 страницы
3) берем корень квадратный от числа страниц (если экстент квадратный), вот и число ячеек по X и Y
Природу не обманешь :) Пусть у нас 1000Х1000 ячеек, большинство из них слабозаполнены — 1..2 объекта, некоторые заполнены сильно. Миллион рутовых страниц R-дерева вынь да положь. Плюс еще адреса этих страниц хранить надо. Да транзакциями всё это покрыть. А честное R-дерево просто достроится там где надо. Но приз моих личных симпатий принадлежит обычному B-дереву с самоподобным ключем. При правильной работе с ним оно и для универсальных данных превосходит R-дерево за счет простоты и компактности.
Но это уже совсем другая история.
Смотря что понимается под комбинированием. Можно хранить два индекса, тогда по B-дереву быстро оценить объем перебора и переключиться на R-дерево. А стоит ли оно того?
Многомерный поиск (в любых координатах), если он приводит к неравномерности распределения, лучше не пробовать на Igloo. Представьте, что у Вас четыре объекта по углам и миллиард кучкуется в центре. Для того, чтобы найти любой объект из центра придется перебрать их все.
Впрочем, эта ситуация разруливается самоподобными индексами.
Пробовали, но не именно таким методом.
Для небесных объектов лучше всего подошли бы трехмерные координаты (как если бы их нанести на сферу). Тогда нет искажений к полюсам, но сложней задавать поисковый экстент.
Что-ж, по всей видимости, зря я «гнал» на ранд, это таким образом вылезло ограничение диапазона значений. А «верный признак дурного человека» — это выдавать скороспелые заключения.
А если нас интересуют полярные области, в астрономии, например, лучше нанести объекты на сферу и использовать трехмерный индекс.
1) определяем, сколько элементов индекса входит на одну страницу индекса СУБД (ну, или делаем предположение)
3) делим ожидаемое число объектов на число на странице, получаем идеальное число ячеек. Предполагается, что идеальный вариант, когда все данные ячейки помещаются на 1-2 страницы
3) берем корень квадратный от числа страниц (если экстент квадратный), вот и число ячеек по X и Y
Но спасибо за наводку.
Но это уже совсем другая история.
Но R-дерево оно заметно тяжелее нежели простое B-дерево.
Впрочем, эта ситуация разруливается самоподобными индексами.
Для небесных объектов лучше всего подошли бы трехмерные координаты (как если бы их нанести на сферу). Тогда нет искажений к полюсам, но сложней задавать поисковый экстент.