vasketsov писал(а):Так вот случай 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).
Tolik писал(а):Ну вы и забрались в дебри, "абсолютные новички".
:) Никто не мешает отпилить тему "Экспорт всего мира в Android :)" (или как там она называлась?) обратно.