Копирование данных происходит лишний раз. Индексирование может быть быстрее.vasketsov писал(а):Так вот случай 2 с точки зрения операций над кэшем фактически раносилен актуальному кластерному индексу над случаем 1.
Если уж можно выбрать нужные данные, следует их сразу и обрабатывать, вместо того, чтобы лишний раз перекладывать и потом обрабатывать.
А индекс полезен на предыдущем этапе, чтобы выбрать их быстро из всего массива данных.
Понятно. Тогда приведу случай, когда области выкачивания и выгрузки не совпадают. Выкачиваем острова поштучно, а карту формируем всего архипелага за раз.Если в кэше будет сохранться TNE - попадание в индекс будет 100%-ным, ибо NULL или TNE в качестве тела тайла - это тоже данные.
Абсолютно бессмысленно заниматься попытками выкачивания моря между островов, так как там будет TNE (либо уже может быть рельеф морского дна?). Данные разреженные, либо в первоисточнике, либо по смыслу задачи.
По-моему, хранилище тайлов (либо других выкачиваемых геообъектов) - и есть разреженная матрица.1. Если TNE сохраняется, и тайла нет, то в хранилище есть об этом запись.
2. Если TNE не сохраняется, и тайла нет, то в хранилище нет об этом записи.
Общий ее размер соответствует планете Земля, а небольшое количество ненулевых значений - и есть те кусочки планеты, которые интересуют данного конкретного пользователя.
Оптимизация разреженного хранилища и разреженный индекс вполне подходят под эту задачу.
Согласитесь, индекс не совсем обычный. В обычном индексируются значения, разбросанные по всему диапазону, например, индекс фамилий это "Иванов", "Петров", "Сидоров". Индекс имеющихся тайлов - это координаты 101, 102, 103, 104 ... 199, потом 801, 802, 803, 804 ... 849, и т.д. Такие данные как раз для разреженного индекса, который хранит не каждое значение, а минимальное в каждом блоке и длину блока.
По-моему, это уже не разреженное хранилище в чистом виде, а его специфический случай, для SAS.Планеты, ориентированный аж на два вида нулевых значений: традиционный NULL (данных нет) и TNE (данных нет, и еще проверено, что их нет и в первоисточнике выкачивания).В этом случае имеет смысл хранить записи с NULL и не с NULL по-разному, чтобы не ходить лишний раз по индексу и тратить меньше места на хранение пустого поля. В этом и заключается оптимизация sparsed storage.
Эти TNE можно дополнительно оптимизировать как для хранения, так и в индексе. Забивать индекс TNE, как Вы верно заметили, чревато лишним хождением по индексу и хранением пустого поля. Как вариант, здесь мог бы использоваться отдельный разреженный битовый массив. "1" стоит - TNE. "0" - всё остальное. Длинные последовательности нулей не хранятся.
В результате, в идеале весь кэш представляет собой набор тайлов, плюс разреженный пространственный индекс по тайлам, плюс разреженный битовый массив для слежения за несуществующими на оригинальном сервере тайлами (TNE).
:) Никто не мешает отпилить тему "Экспорт всего мира в Android :)" (или как там она называлась?) обратно.Tolik писал(а):Ну вы и забрались в дебри, "абсолютные новички".
Никто не мешает отпилить тему "Экспорт всего мира в Android 
