ВОПРОСЫ АБСОЛЮТНЫХ НОВИЧКОВ

[Shoorick]

Основание для иронии - считать индексирование специальным способом оптимизации.

Хорошо, я имел в виду, что СУБД с пространственными расширениями (специндексами, функциями и запросами) в данном конкретном случае сразу, из коробки дает пользователю возможность оптимально выполнять такие запросы, в том числе на разреженных данных. Запрос "выбрать объекты внутри полигона" - наверное, один из самых, если не самый типичный.

То есть это первый потенциальный способ ускорить подобные запросы.
Второй - алгоритм закрашивания, но он, видимо, потребует чуть другого способа доступа к кэшу либо новых виртуальных функций для доступа к кэшу (если кэш виртуализирован).

Более того - копирование части кэша внутри области и работа потом по результирующему кэшу (то есть обратная ситуация) по сути и будет таким индексированием.

Не понял.

Это проблема неадекватной области выделения. Неадекватной реальным данным. Если бы область выделения была в точности та же, что и для скачки - попадание в БД было бы 100%-ным.

Ну а я иногда выкачиваю снимки береговой линии. Снимок моря тоже интересен и важен, так как там могут быть камни и мели. Они могут уходить и далеко. Однако сервисы предпочитают на некотором, заранее неизвестном, расстоянии от берега обрывать область хорошего разрешения. В результате заранее выделить полигон, в котором будет 100% данных, практически невозможно.

Только я ещё раз уточню, что оптимизация sparsed (разреженных) данных (вернее их индексирования и хранения) в общем случае не связана с геопространственными данными. Это могут быть любые данные...

Согласен, но геоданные по своей природе очень часто разреженные (если хотите, называйте их "почти пустыми", мне непринципиально). В SAS проще, так как чаще всего используется сценарий "обработка идеальной области выделения".

[vasketsov]

Более того - копирование части кэша внутри области и работа потом по результирующему кэшу (то есть обратная ситуация) по сути и будет таким индексированием.

Не понял.

Я о разнице между вариантами:
1. Есть произвольный кэш, выделяем произвольную область, работаем с ней.
2. Есть произвольный кэш, выделяем произвольную область, переносим её отдельно, работаем со всей перенесённой областью без использования области выделения.
Так вот случай 2 с точки зрения операций над кэшем фактически раносилен актуальному кластерному индексу над случаем 1.

сервисы предпочитают на некотором, заранее неизвестном, расстоянии от берега обрывать область хорошего разрешения. В результате заранее выделить полигон, в котором будет 100% данных, практически невозможно

Если в кэше будет сохранться TNE - попадание в индекс будет 100%-ным, ибо NULL или TNE в качестве тела тайла - это тоже данные. Причём в индекс они попадают на любой из поддерживаемых СУБД, если говорить про СУБД. Не попадание в индекс будет в том случае, если координата отсутствует в индексе, то есть если нет тайла и нет TNE.

Согласен, но геоданные по своей природе очень часто разреженные (если хотите, называйте их "почти пустыми", мне непринципиально)

Давайте я попробую объяснить разницу. Ибо с точки зрения хранилища и индексирования она принципиальна:
1. Если TNE сохраняется, и тайла нет, то в хранилище есть об этом запись. Так как все поля в первичном ключе (координаты тайла) не NULL, то на любой СУБД такая запись попадает в индекс. Соответственно используя этот индекс, можно быстро найти адрес, где физически хранится тело тайла. Обнаружим мы там реальный тайл или NULL - индексу совершенно по лампочки, потому что поле "тело тайла" очевидно само по себе не входит в первичный ключ и вообще не индексируется. Это конечно несколько упрощено, хотя бы исходя из наличия покрывающего индекса над первичным ключём. Но суть вполне отражает. Так вот разреженным хранилищем называется такое (возвращаясь к нашим баранам), где записи TNE есть, и их много, то есть в поле "тело тайла" очень много значений NULL. В этом случае имеет смысл хранить записи с NULL и не с NULL по-разному, чтобы не ходить лишний раз по индексу и тратить меньше места на хранение пустого поля. В этом и заключается оптимизация sparsed storage.
2. Если TNE не сохраняется, и тайла нет, то в хранилище нет об этом записи. Соответственно такая отсутствующая запись гарантированно не попадает ни в какие индексы, просто потому что невозможно предусмотреть логику предметной области: БД не знает, какие вообще могут быть записи внутри неё. Поэтому БД не может сделать никаких предположений о тайлах и TNE, которых у неё нет. Соответственно хранилище знать не знает, что оно не заполнено, и что там есть пустые места. Я это назвал "почти пустым", хотя специального названия такой ситуации нет (и уж точно это не разреженное хранилище), так как оно просто не нужно. Это самая обычная рабочая ситуация, и никакой оптимизации в хранении тут быть не может по определению: мы не знаем, что через секунду может упасть в БД, и как потребуется это "переоптимизировать". Соответственно в индекс отсутствующие записи не попадают, значит по индексу СУБД не сможет определить, где хранится то, чего нет (более того, даже индекс может быть неактуален из-за протухания статистики, так что всё ещё хуже чем могло бы быть).

[Tolik]

Ну вы и забрались в дебри, "абсолютные новички".

[Shoorick]

Так вот случай 2 с точки зрения операций над кэшем фактически раносилен актуальному кластерному индексу над случаем 1.

Копирование данных происходит лишний раз. Индексирование может быть быстрее.

Если уж можно выбрать нужные данные, следует их сразу и обрабатывать, вместо того, чтобы лишний раз перекладывать и потом обрабатывать.
А индекс полезен на предыдущем этапе, чтобы выбрать их быстро из всего массива данных.

Если в кэше будет сохранться TNE - попадание в индекс будет 100%-ным, ибо NULL или TNE в качестве тела тайла - это тоже данные.

Понятно. Тогда приведу случай, когда области выкачивания и выгрузки не совпадают. Выкачиваем острова поштучно, а карту формируем всего архипелага за раз.
Абсолютно бессмысленно заниматься попытками выкачивания моря между островов, так как там будет TNE (либо уже может быть рельеф морского дна?). Данные разреженные, либо в первоисточнике, либо по смыслу задачи.

1. Если TNE сохраняется, и тайла нет, то в хранилище есть об этом запись.
2. Если TNE не сохраняется, и тайла нет, то в хранилище нет об этом записи.

По-моему, хранилище тайлов (либо других выкачиваемых геообъектов) - и есть разреженная матрица.
Общий ее размер соответствует планете Земля, а небольшое количество ненулевых значений - и есть те кусочки планеты, которые интересуют данного конкретного пользователя.

Оптимизация разреженного хранилища и разреженный индекс вполне подходят под эту задачу.
Согласитесь, индекс не совсем обычный. В обычном индексируются значения, разбросанные по всему диапазону, например, индекс фамилий это "Иванов", "Петров", "Сидоров". Индекс имеющихся тайлов - это координаты 101, 102, 103, 104 ... 199, потом 801, 802, 803, 804 ... 849, и т.д. Такие данные как раз для разреженного индекса, который хранит не каждое значение, а минимальное в каждом блоке и длину блока.

В этом случае имеет смысл хранить записи с NULL и не с NULL по-разному, чтобы не ходить лишний раз по индексу и тратить меньше места на хранение пустого поля. В этом и заключается оптимизация sparsed storage.

По-моему, это уже не разреженное хранилище в чистом виде, а его специфический случай, для SAS.Планеты, ориентированный аж на два вида нулевых значений: традиционный NULL (данных нет) и TNE (данных нет, и еще проверено, что их нет и в первоисточнике выкачивания).

Эти TNE можно дополнительно оптимизировать как для хранения, так и в индексе. Забивать индекс TNE, как Вы верно заметили, чревато лишним хождением по индексу и хранением пустого поля. Как вариант, здесь мог бы использоваться отдельный разреженный битовый массив. "1" стоит - TNE. "0" - всё остальное. Длинные последовательности нулей не хранятся.

В результате, в идеале весь кэш представляет собой набор тайлов, плюс разреженный пространственный индекс по тайлам, плюс разреженный битовый массив для слежения за несуществующими на оригинальном сервере тайлами (TNE).

Ну вы и забрались в дебри, "абсолютные новички".

:) Никто не мешает отпилить тему "Экспорт всего мира в Android :)" (или как там она называлась?) обратно.

[Tolik]

Никто не мешает отпилить тему "Экспорт всего мира в Android " (или как там она называлась?) обратно.

Форум так достал своими тормозами и "503", что не то что отпиливать, даже читать уже не хочется!

[Parasite]

Никто не мешает отпилить тему "Экспорт всего мира в Android " (или как там она называлась?) обратно.

Форум так достал своими тормозами и "503", что не то что отпиливать, даже читать уже не хочется!

Фей месяц назад обещался переехать. Что характерно - хостинг давно куплен и файлы давно перенесены - но это же фей, и владелец домена (с правами на перенос) именно он.

А 503 - это да, это уже просто какой-то ужас.

[Papazol]

Несмотря ни на что, рассуждения "вширь и вглубь" не должны быть в данной теме, думаю, это все понимают.

[Shoorick]

Покрытие google street view, яндекс панорам можно ли вытащить отдельно от самих сервисов?
Не сами панорамы, а места, где они имеются.
Это же возможно с координатами снимков panoramio.

p.s. Согласен и с ужасами 503, и с переносом предыдущей темы обсуждения.

[Tolik]

Даже не представляю, как их можно вытащить. Но на Гугле когда-то видел страничку с описанием street view, и на ней были перечислены все города, где она есть.

[rass]

Покрытие google street view, яндекс панорам можно ли вытащить отдельно от самих сервисов?

Кстати хороший вопрос. И есть ли у них версии, а если есть, то можно ли просмотреть предыдущие панорамы?

Тут на дня был случай, где-то дней 10 назад. С одним заказчиком зашел спор по поводу высоты одного здания. Нашел это здание в google street view,
хороший был вид, как раз видны были все спорные моменты. Уже хотел нажать кнопку ПринтСкрин, но отвлекся минут на 40.
А когда вернуся, стал смотреть снова панорамы гугла, и не мог понять, машины, окружение изменились, а вид здания теперь накрывает ветка дерева!
Я бегал по виртуальной улице взад и вперед и не мог поверить, что за мое 40-минутное отсутсивие Гугл обновил панорамы этой части города.....