Мне повезло с индексами растровых изображений при манипулировании большим количеством данных в памяти с использованием пользовательских структур данных, но они довольно неудобны для реализации в сторонних базах данных, которые не имеют хороших (подобных postgresql) ) API для расширения их индексных структур.
В общем, поскольку вы все равно будете искать по индексу B-Tree, вы ничего не получите, если судите по моему опыту.
Итак, нет.
Если ваше приложение по своей природе является OLAP по своей природе, и у вас есть небольшое количество измерений, которые естественным образом группируются в упорядоченные диапазоны, и вам действительно нужно изменить асимптотику вашей задачи, вы можете рассмотреть создание структуры, подобной «таблице сумм», вы можете запросить его для любого иерархического ответа с помощью 2 ^ d операций, и вы можете амортизировать его, если выполняете несколько связанных запросов.
Пример в 2d с координатами x и y, где вас интересует сумма в диапазоне от (x1, y1) до (x2, y2).
Хранится отдельно, вам нужно будет суммировать количество записей, пропорциональных области.
Используя сумму, для каждой позиции (x, y) не сохраняйте значение этой позиции, а вместо этого сохраняйте сумму области от (0,0) до (x, y).
Тогда вы можете ответить на любой запрос диапазона, спросив:
сумма (x2, y2) - сумма (x1, y2) - сумма (x2, y1) + сумма (x1, y1)
постоянная сумма накладных расходов (ну, логарифмическая по размеру набора данных, при условии, что у вас есть индекс по x и y и вы храните его в SQL)
Это, конечно, не работает, если у вас есть сложные атрибуты, которые не разбиваются на диапазоны, но могут обрабатывать простые лексикографические индексы, даты и т. Д.