У 2ГИС на данный момент нет междугородного навигатора,
то, что описано, всего-лишь прототип, способ обозначить проблемы.
Спасибо за мнение, попробуем учесть.
Что касается поиска, переслал поближе к теме.
Про дублёры, мы пытаемся нащупать середину между теми, кому это полезно и недовольными.
Вносить в интерфейс пока видится негуманным.
Похоже на то.
В указанной статье описана нумерация тайлов с помошью Z-order.
Тайлов относительно немного и грубый (наивный) поиск работает приемлемо быстро.
Во всяком случае не прямо сейчас.
Думаю, что на малых запросах ничего не изменится т.к. читаются единичные страницы.
Разница за счет более плотной упаковки (если она вообще будет) возникнет только когда число точек в запросе заметно превысит число точек на странице.
Есть всё же в этом какая-то натяжка — разрезаем сферу на 8 кусков и с каждым работаем отдельно.
Так же поступает вышеупомянутый q3c — шесть граней куба на каждой грани z-кривая.
Спасибо за ссылку, в принципе, я в курсе некоторой части этой магии.
И эту статью рассматривал как вводную для описания алгоритма поиска именно по B-дереву, как самому честному способу хранить одномерные данные в (по большому счету) одномерном дисковом пространстве.
Через недельку — другую, добро пожаловать.
А одна старая статейка найдётся не только у вас :)
по П.1 Z-code — это число, а числа в данном случае мы укладываем в B-дерево.
То, что вы (по видимому) имели ввиду, называется k-d-деревья и это совсем другая история.
И не забывать — Z это точка, прямоугольник — четырехмерная Z точка.
глянул одним глазком,
составной индекс занимает 2 Гб,
запрос select count(1)… отрабатывается как index only scan, т.е. без обращения к таблице, читает страниц от 2 до 5 раз меньше по сравнению с X&Y.
Но это скорее хороший пример качественной работы оптимизатора, чем заслуга собственно индекса.
Опять поработаю шлюзом :)
«В сети есть один очень интересный документ: https://www.google.by/webhp?sourceid=ch… +FFT+large
А на сайте Миландра есть интересный рекламный буклет ВН028.
Из этого буклета смотрим число тактов для БПФ размера 64К cfloat. У ВН028, если пересчитать в такты, 684000.
Теперь внимательно смотрим табличку 1 в документе от TI. Для 64 К только 4 ядра вместе делают
эту задачу быстрее — 507845 тактов. Так что не так уж и абсурдным выглядит сравнение
этих двух коллег. ВН028 на своем поле (до 3 М байт) вполне конкурентен на некоторых(!)
задачах с многоядерными собратьями.
Вполне логично сравнивать ВН028 с одним ядром С6678. Их архитектуры
не так уж и отличаются. Разница в частоте скорее всего это разница в техпроцессе, т.к.
по конвейеру они практически один в один.» (C)
то, что описано, всего-лишь прототип, способ обозначить проблемы.
Спасибо за мнение, попробуем учесть.
Каждый делает кто во что горазд.
Вот так, например.
Правильные с точки зрения стратегии игры.
3-4 сек на разогретом кэше и 20-25 с холодного старта.
Из Италии в Тунис.
Про дублёры, мы пытаемся нащупать середину между теми, кому это полезно и недовольными.
Вносить в интерфейс пока видится негуманным.
В указанной статье описана нумерация тайлов с помошью Z-order.
Тайлов относительно немного и грубый (наивный) поиск работает приемлемо быстро.
маловато будет, хотя, смотря для каких целей
Думаю, что на малых запросах ничего не изменится т.к. читаются единичные страницы.
Разница за счет более плотной упаковки (если она вообще будет) возникнет только когда число точек в запросе заметно превысит число точек на странице.
Так же поступает вышеупомянутый q3c — шесть граней куба на каждой грани z-кривая.
И эту статью рассматривал как вводную для описания алгоритма поиска именно по B-дереву, как самому честному способу хранить одномерные данные в (по большому счету) одномерном дисковом пространстве.
Через недельку — другую, добро пожаловать.
А одна старая статейка найдётся не только у вас :)
То, что вы (по видимому) имели ввиду, называется k-d-деревья и это совсем другая история.
И не забывать — Z это точка, прямоугольник — четырехмерная Z точка.
составной индекс занимает 2 Гб,
запрос select count(1)… отрабатывается как index only scan, т.е. без обращения к таблице, читает страниц от 2 до 5 раз меньше по сравнению с X&Y.
Но это скорее хороший пример качественной работы оптимизатора, чем заслуга собственно индекса.
«В сети есть один очень интересный документ:
https://www.google.by/webhp?sourceid=ch… +FFT+large
А на сайте Миландра есть интересный рекламный буклет ВН028.
Из этого буклета смотрим число тактов для БПФ размера 64К cfloat. У ВН028, если пересчитать в такты, 684000.
Теперь внимательно смотрим табличку 1 в документе от TI. Для 64 К только 4 ядра вместе делают
эту задачу быстрее — 507845 тактов. Так что не так уж и абсурдным выглядит сравнение
этих двух коллег. ВН028 на своем поле (до 3 М байт) вполне конкурентен на некоторых(!)
задачах с многоядерными собратьями.
Вполне логично сравнивать ВН028 с одним ядром С6678. Их архитектуры
не так уж и отличаются. Разница в частоте скорее всего это разница в техпроцессе, т.к.
по конвейеру они практически один в один.» (C)