|
Notes |
|
|
|
|
Первый и главный вопрос - надо ли поддерживать полноценно AVersionInfo: IMapVersionInfo в наследниках TTileStorageAbstract или это пока что затычки разной степени кривости и стопроцентно будет переписываться? |
|
|
|
|
|
Это задел на будущее. Если никто не напишет хранилище с его поддержкой, то так и останется затычкой. |
|
|
|
|
Ну как минимум с точки зрения БД это одно необязательное поле, так что реализуется просто.
Я имел в виду конкретно имеет ли смысл первоначально:
а) вытащить в интерфейс, заполнить типа 1.23.0 для яндексспутника и сделать доступным в паскальскрипте как переменная, чтобы потом было что передавать в хранилище;
б) пописать флаги доступности опций для хранилища IStorageTypeAbilities - добавить флаг поддержки версий в дополнение к доступности чтения, записи и т.п.
в) должно ли хранилище уметь возвращать актуальную версию в случае отсутствия требуемой и корректно информировать об этом, что вернулась не запрошенная версия.
Или пока забить? В принципе разницы большой с точки зрения SQL нет, всё равно нельзя в первичный ключ пихать версию, да и большинство вопросов актуальны для версий вообще, а не субд в частности. |
|
|
|
(0004986)
|
|
vdemidov
|
15-01-2012 20:10
(edited on: 15-01-2012 20:11) |
|
а) вытащить в интерфейс, заполнить типа 1.23.0 для яндексспутника и сделать доступным в паскальскрипте как переменная, чтобы потом было что передавать в хранилище;
Давно сделано.
б) пописать флаги доступности опций для хранилища IStorageTypeAbilities - добавить флаг поддержки версий в дополнение к доступности чтения, записи и т.п.
Не знаю как это лучше прописать.
в) должно ли хранилище уметь возвращать актуальную версию в случае отсутствия требуемой и корректно информировать об этом, что вернулась не запрошенная версия.
Уже сейчас умеет. В структуре ITileInfo предусмотрено поле с актуальной версией
|
|
|
|
|
>Давно сделано
Блин, слона то я и не ...
Тогда буду делать сразу с версиями. |
|
|
|
|
|
Просто внедрять версии в zmp в репозиториях нельзя пока нет стабильного релиза с поддержкой версий. |
|
|
|
(0004990)
|
|
zed
|
|
15-01-2012 20:44
|
|
|
Чувствую "стабильный" релиз появится ещё не скоро. А уже почти как год прошёл с прошлого релиза. Таки надо с этим что-то делать. |
|
|
|
|
>Просто внедрять версии в zmp в репозиториях нельзя пока нет стабильного релиза с поддержкой версий
Я не буду править zmp (и всё что касается zmp) вообще. Просто я имел в виду, что буду сходить из заполненности версии (точнее даже, что она будет передаваться в хранилище). В крайнем случае всегда можно вбить дежурный "нолик", если вдруг работа хранилища без указания версии будет "кривой". Как только в хранилище полетит версия - ну значит версионность заработает. В этом смысле доработка сугубо отдельная, она совершенно не "держит" выпуск релиза. Пока не будут готовы новые "настройки" на VTV - делать сейчас настройки gps тоже работа впустую (да и так работает, как раньше без настроек, формат треклога garmin и расширения gpx я менять уже не буду, опции будут только для его ограничения). Так что как посчитаете нужным (метки там, беркли или качалка или ещё что осталось) - отпочковывайте релиз, да и всё. |
|
|
|
|
|
Я правильно понимаю, что в сасе нет функции для получения идентификатора тайла вида 121201203210012 по xyz (как для бинга и нокиамапкреатора)? Что-то не нашёл. |
|
|
|
|
|
Сделайте. Заодно можете добавить новый вид файлового кэша. |
|
|
|
|
Сделаю попытку актуализировать тему, поделиться мыслями, авось кто чего подскажет.
Сперва по поводу версий и их формата. Покуда действительно уникальный реально используемый идентификатор версии для сервиса - строковый, от него и будем отталкиваться. Вместе с тем, очень многие сервисы используют простое число для идентификации версии. Не пользоваться этим тоже было бы преступно, хотя бы про причине более простых операций сравнения для чисел.
Итого придумалось примерно такое хранение версий тайлов:
create table VER (
id_ver smallint not null,
ver_value varchar(50) not null,
ver_date datetime not null,
ver_number int default 0 not null,
constraint PK_VER primary key (id_ver)
)
create unique index u_VER on VER (ver_value ASC)
Здесь и далее - VER не реальное название таблицы, покуда есть разные варианты хранения версий, в одной куче (и тогда есть ещё поле ссылки на "карту") или в разрезе сервисов (далее будет подробно объяснено).
Итого идентификатор версии - smallint, то бишь 65 тыщ разных версий. Одно из значений резервируется для "без версии". Покуда и 32 тыщи с лишним - за глаза, можем обойтись значением 0 для "без версии", остальные значения пусть растут в положительную сторону. К сожалению, привязываться к конкретному СУБД я не могу, поэтому никаких smalluint или word тут не прокатит. Впрочем (до внедрения) можно заменить на соответствующее значение numeric(N,0), если кому-то вдруг потребуется.
Рядом с этим есть такая вот ерунда:
create table t_ver_comp (
id_ver_comp char(1) not null,
ver_comp_field varchar(30) not null,
ver_comp_name varchar(30) not null,
constraint PK_T_VER_COMP primary key (id_ver_comp)
)
строковые поля уникальные.
сюда валятся значения:
values ('0','-','No')
values ('I','id_ver','By id')
values ('V','ver_value','By value')
values ('D','ver_date','By date')
values ('N','ver_number','By number')
это варианты "сравнимости" версий.
Это сделано вот для чего (подсказка: ver - от слова version, comp - от слова compare).
Предполагается 2 режима работы.
Первый режим - это когда при запросе тайла конкретной версии разрешается показать тайл предыдущей версии, если её нет - ещё более предыдущей, и т.п., короче говоря - последней доступной версии, не "больше" чем запрошенной. Если запрошен тайл без версии - показываем самую последнюю доступную версию. Если ничегошеньки нет - показываем тайл без версии.
Второй режим - это когда показывается в точности та самая версия, которая запрошена. Если запрошен тайл без версии - показывается без версии.
В первом режиме становится актуальным вопрос сравнения версий. Какая "больше"? С точки зрения обобщённого хомяка, 107 в гугле больше чем 99, а версии от terraserver (которые такие длинные что офигеть, да ещё и с датой снимка) - сугубо различны и ни при каких условиях не подлежат смешиванию и одновременному отображению в сасе. Заодно и яндекс имеет что сказать: 1.23.54 > 1.9.34. И т.п.
И тут как нельзя кстати для карты (сервиса) мы укажем конкретное значение id_ver_comp из списка выше. Скажем '0' - значит ни при каких условиях не вернётся тайл другой версии (для terraserver). Или 'D' - сортировка тайлов в SELECTе будет по полю ver_date (дата версии, контекст даты любой, хоть дата добавления, хоть дата снимка). И т.п.
Чтобы не заставлять руками указывать эти значения - напрашивается примерно такой алгоритм. Прилетает одна версия в виде строки - скажем '1035' у Bing. Смотрим, возможно ли её конвертировать в число. Если возможно - конвертируем и записываем в ver_number, иначе туда залетит значение по умолчанию. Если же кроме того оно влазит в smallint - пробуем его впихнуть в id_ver. Если вдруг такое значение id_ver уже есть - в принципе можно рассматривать это как коллизию, можно блокировать создание новой версии, можно просто пихать min()-1 - и пусть валятся ниже нуля. Причина коллизии в том, что id_ver определяется через конвертацию значения уникального поля ver_value. Соответственно если такой облом возникает при вставке версии '107' - значит уже есть запись с id_ver=107 и ver_value отличным от '107'. Что само по себе коллизия. Дальше конечно может прилететь версия '-1' и т.п. - но пока что вроде бы если версия представима в виде числа, и оно влазит в smallint, и сервис не подкинет свинью со сменой типа идентификатора версии - проблем не будет.
С яндексом ситуация несколько иная. Номер версии 1.23.54 несравним по правилу сравнения строк. А по правилу сравнения чисел - надо выделять составные части в отдельные поля. Чего конечно очень не хочется, потому как ни для чего более это использоваться не будет. Для яндекса предполагается сравнение версий по дате (здесь дата - это дата добавления версии в БД). Соответственно более поздние версии позжа добвляются в БД. Если вдруг пропустились несколько версий, и залетели в неверном порядке - в принципе можно поправить дату и руками.
Смысл всей этой ботвы в том, что по возможности сортировать тайлы в SELECTе без связки с таблицей версий, только по полю id_ver. Ну а коли невозможно - делать это по полю такого типа, сравнение по которому наиболее быстрое и простое (в этом смысле сравнение версий по строке длиной в 50 символов конечно совсем никуда не годно). При безусловной уникальности по строковому идентификатору версии (конечно, в рамках сервиса).
Есть правда ещё один вариант (назовём его условно F). Это когда id_ver инкрементируется с неким шагом скажем 10). Остаётся 3 тыщи версий для карты. При этом id_ver становится полностью суррогатным, сортируемся в SELECTе ТОЛЬКО по нему (не нужна уже таблица версий), всякие даты - не более чем информационное поле, если потребуется. Минус - в случае пропуска версии его придётся вставлять между существующих значений id_ver. При наличии тайлов менять id_ver уже нельзя - а значит и сильно много пропускать тоже нельзя.
Пример. Перед отпуском яндекс был версии 1.1.1, а после отпуска 1.2.5. Первое значение залетело с id_ver=10, второе с id_ver=20. Тайлы уже закачаны. Потом узнаём, что была ещё версия 1.2.1. Качаем и её. Залетит она ну скажем с id_ver=15 (чтобы минимизировать вероятность последущих косяков). А потом внезапно выясняется что была 1.2.2 и все с 1.1.7 по 1.1.18. И приплыли, вариант F облажался.
Можно конечно сначала сортироваться по id_ver (по варианту F), как только будет обнаружен прикол с пропусками - переключаться на остальные поля (и в конце концов на работающую даже в самом худшем случае сортировку версий по дате), но это всё равно приведёт к структуре, уже описанной выше (с отдельными полями под сортировку и линком с таблицей версий в SELECTе тайлов), так что вот даже и не знаю, стоит оно "выделки", или даже и не заморачиватьс с этой "овчинкой" в виде варианта F.
А теперь пример таблицы с сервисами (они же карты):
create table t_service (
id_service smallint identity,
service_name varchar(26) not null,
id_contenttype smallint not null,
id_ver_comp char(1) default '0' not null,
constraint PK_T_SERVICE primary key (id_service)
)
Здесь уникальным является очевидно наименование сервиса (service_name).
Ограничение service_name по длине - для того, чтобы генерить производные наименования (в некоторых вариантах реализации это требуется) и умещаться в 30 символов (общее ограничение длины имени объекта для многих старых версий СУБД). Впрочем 26 символов представляется более чем достаточным (человеческое описание карты остаётся в zmp).
Дальше будет про сами тайлы. |
|
|
|
|
зы. Удаление и запись тайлов происходят только для конкретной версии, предыдущие не трогаются.
Пока что многое, что касается хранения тайлов, дискуссионно, и надо как-то аргументированно выбрать (устраивающий всех) нужный вариант (или несколько - но тогда придётся реализовывать процедуру миграции между вариантами).
1. Базовый вид таблицы с тайлами:
create table TILES (
id_tile <TYPE> not null,
id_ver smallint not null,
id_contenttype smallint not null,
load_date datetime default getdate() not null,
tile_size int default 0 not null,
tile_body image null,
constraint PK_TILES primary key (id_tile, id_ver)
)
Как видно, в первичный ключ входят id_tile (некий идентификатор тайла) и id_ver (идентификатор версии). Очевидным образом id_contenttype (как атрибут тайла) в ПК не входит.
Поскольку тайлов (даже для одного сервиса) мягко говоря дофига, совершенно естественным желанием представляется разделить тайлы по нескольким таблицам. Ну то есть на самом деле с точки зрения труъ-канонов проектирования под СУБД это как раз противоестественное желание. Однако надо понимать, что тайлов у нас может быть на нижнем зуме INTxINT, а среднестатистический хомяк и слышать ничего не слышал про настройку кэша, секционирования (партицирования) таблиц и т.п. В общем скорее всего придётся выбирать из более реальных вариантов.
Также имеет место вот какая дилема. С одной стороны, тайл в сасе (и не только) адресуется по XYZ (тут версия неважна, так как во всех реализациях id_ver выделено отдельно). С другой стороны, если это преобразовать в QuadKey или HexKey - размер идентификатора сильно уменьшится. А размер кластерного первичного ключа прямым образом влияет на почти всё, что связано с таблицей. Так что вполне разумным является идея его по возможности уменьшить. На самом деле даже QuadKey можно ещё сжать примерно вполовину, если попарно заменять символы 0123 на символы 'A'-'P', если останется один - оставить его как есть (назовём это 'AHP1' или HexKey). Также немаловажным является то, чтобы "близкие" тайлы находились "рядом". С другой стороны есть такая процедура как построение карты заполнения. И если по диапазону XY и значению Z для адресации тайлов в БД по XYZ она выполняется тривиально (два условия between отлично попадают в ПК), то строить SELECT (точнее WHERE clause для него) по тому же QuadKey я даже думать не хочу начинать ))), это представляется чем-то крайне нетривиальным. В принципе конечно карта заполнения - это некий бонус, и по одному тайлу она всё равно построится, как и сейчас, но хотелось бы её строить тоже быстро (пусть не в один SELECT, но тогда нужна какая-то логика выделения общих QuadKey, чтобы что-то типа id_tile like '01232%' попадало в ПК, а то ничего не останется, как тупо перечислить их в id_tile in ('012323','012322',...) - те же яйца, только в профиль).
Итак имеем важную проблему - выбор идентификатора дял тайла, и работу с ним для целей построения карты заполнения (для остальных целей с точки зрения быдлокодинга разницы пока что никакой нет).
Варианты:
ОДНО поле id_tile varchar(N) not null
НЕСКОЛЬКО полей типа z smallint not null, x int not null, y int not null.
Для целей уменьшения размера ПК конкретные типы (по ширине) подбираются исходя из максимальной ширины значений поля(ей) в ПК.
Пока что однозначно выбрать между XYZ, 0123 (aka QuadKey) и AHP1 (aka HexKey) не могу. В принципе rintime для всех этих трёх вариантов у меня написан (в смысле генерации SQL для команд в хранилище), так что можно оставить и более одного.
Где то рядом с этим стоит идея деления тайлов на несколько таблиц по зумам. Дело в том, что размер QuadKey и HexKey одинаков для всех тайлов на конкретном зуме. Это позволяет максимально использовать мощность тайлового идентификатора, используя разный размер char(N) в качестве типа для id_tile для разных таблиц на разных зумах. Ну и на старшем зуме, так как не будет тайлов из предыдущих зумов, общее число тайлов уменьшится на треть. Менее очевидно - но даже и в случае XYZ замена типов на numeric может позволить уменьшить размер ПК. То есть это как бы правильный нужный тренд. Вопрос касается только деления тайлов на таблицы по зумам.
В этом смысле вид табличек несколько изменяется. Скажем так:
create table s_%SERVICE%_%ZOOM% (
x numeric not null,
y numeric not null,
id_ver smallint not null,
id_contenttype smallint not null,
load_date datetime not null,
tile_size int not null,
tile_body image null,
constraint K_%SERVICE%_%ZOOM% primary key (x, y, id_ver)
)
или так:
create table sas_ahp1_%ZOOM% (
id_tile char(N) not null,
id_ver smallint not null,
id_contenttype smallint not null,
load_date datetime default getdate() not null,
tile_size int default 0 not null,
tile_body image null,
constraint PK_SAS_AHP1_%ZOOM% primary key (id_tile, id_ver)
)
Соответственно %SERVICE% и %ZOOM% заменяются на конкретные значения, типы для полей в ПК тоже подставляются нужные (всё это при создании таблицы в БД, скорее всего при первом обращении к отсутствующей таблице).
Но всё равно если подсчитать - на последнем зуме в таблице оказывается столько тайлов, что среднестатистическому хомяку будет крайне нетривиально настроить СУБД, чтобы полностью выкачанное - оно ещё и шевелилось.
Дальнейшие варианты декомпозиции совсем уже нетривиальны (хоть и математически обоснованы) и касаются деления идентификатора тайла на две части и отнесения первой в имя таблицы, а вторая при это остаётся урезанным идентификатором тайла. Получается что таблица хранит тайлы конкретного сервиса конкретного зума в некоторой области (исходя из деления соответствующего идентификатора). Тогда уже число тайлов в любой таблице становится совсем уж детским. На примере QuadKey - в id_tile улетают 16 правых символов, остальное слева - в имя таблицы. Для HexKey это будет уже 8 символов. А для XY (Z тут уже заведомо в имени таблицы)это просто деление на верхние и нижние "слова" в каждом числе, "вершки" - в имя таблицы, "корешки" - в id_tile (smallint,smallint). Более того, такое деление по факту ничуть не усложняет обычные операции типа чтения одиночного тайла, удаления тайла, обновления тайла и т.п. И для такого деления runtime уже есть. Проблема в основном касается карты заполнения.
Соответственно базовый вид таблицы с тайлами в реальности становится совсем неузнаваемым (в части имени таблицы и в части id_tile).
2. Ещё немаловажный вопрос - трактовка TNE. С одной сторны, если размер тайла равен 0 - это как бы неплохой кандидат на критерий TNE. С другой стороны, TNE означает отсутствие тайла (HTTP 404), а не HTTP 200 size 0. Опять же если забацать отдельную таблицу для TNE (отдельную от реальных тайлов) - её можно легко чистить, не касаясь вообще таблиц с тайлами. Так что определённая логика есть в обоих вариантах. Я пока что не делаю отдельную тблицу для TNE, так как она тривиально делается из таблицы тайлов откидыванием размера и тела тайла.
Вот пока что как-то так. |
|
|
|
|
>2. Ещё немаловажный вопрос - трактовка TNE. С одной сторны, если размер тайла равен 0 - это как бы неплохой кандидат на критерий TNE. С другой стороны, TNE означает отсутствие тайла (HTTP 404), а не HTTP 200 size 0.
Кто-то мешает TNE-кам присвоить размер -1? Везде же используется знаковый тип для размеров. И проверять в случае чего удобно, if <1 - и отброшены и нулевые тайлы и tne.
Много читал, мало понял. Но вспомнил, что операции выборки тайлов сразу с нескольких зумов вроде как не применяются (или редки), то логично делить таблицу по зумам для уменьшения длины id тайла.
И ещё, XYZ занимает 23+23+5=51 бит и легко влазит в Int64, такого типа разве ж в БД нет? Он уж точно проще разных странных QuadKey и HexKey. Но может я чего и не понял, звиняйте. |
|
|
|
|
>делить таблицу по зумам для уменьшения длины id тайла
Это понятно (с возможностью деления по зуму). Вопрос в другом.
На зуме N (если зумы с 1 начинаются) общее число тайлов будет равно 4^(N-1). При этом координаты X и Y каждая меняются от 0 до 2^(N-1)-1. Длина у QuadKey будет (N-1). Примеры:
для 10 зума это будет 4^9 = 262 144 тайлов.
для 11 зума это будет 4^10 = 1 048 576 тайлов.
для 12 зума это будет 4^11 = 4 194 304 тайлов.
для 13 зума это будет 4^12 = 16 777 216 тайлов.
для 14 зума это будет 4^13 = 67 108 864 тайлов.
для 16 зума это будет 4^15 = 1 073 741 824 тайлов.
для 17 зума это будет 4^16 = 4 294 967 296 тайлов.
для 18 зума это будет 4^17 = 17 179 869 184 тайлов.
для 19 зума это будет 4^18 = 68 719 476 736 тайлов.
для 20 зума это будет 4^19 = 274 877 906 944 тайлов.
Вопрос в том, что надо где-то ещё "поделиться", чтобы желающие выкачать весь мир хотя бы на 14-м зуме могли после этого с ним работать. А лучше если и на 15-м. А иногда и побольше зумом. В одно таблице 50 млн. записей уже являются неким гроссмейстерским результатом, выше которого нормальное шевеление СУБД в части этой таблицы говорит о прямых руках и понимании принципов настройки СУБД. Так что даже для 14 зума выкачать весь мир в одну таблицу и поиметь профит несколько нереально. Это ещё не коснулось оценки размера всего этого удовольствия.
Пример деления проще всего привести для QuadKey (для XYZ по сути то же самое, деление по словам или байтам). Скажем, делимся по char(12). Это означает, что у QuadKey будет 12 правых символов уходить внутрь таблицы, а если что-то есть левее 12 символов (а это будет тоько если их >=13 - то есть от 14 зума и выше) - оно пойдёт в имя таблицы. Соответственно (для зума 16):
'012312301020012' будет сохранено в таблицу '%_012' под идентификатором '312301020012'.
'012110220020010' будет сохранено в таблицу '%_012' под идентификатором '110220020010'.
'011211001103321' будет сохранено в таблицу '%_011' под идентификатором '211001103321'.
(здесь % - некий общий префикс у всех этих таблиц)
Получаем размножение таблиц, но уменьшение количества записей в них (не более чем 4^12 = 16 777 216 тайлов в каждой). При таком делении для зума 14 будет 4 таблицы (суффиксы от '_0' до '_3'), для зума 15 будет 16 таблиц (суффиксы от '_00' до '_33') и т.п., для зума 18 будет 4^(18-13)= 1024 таблицы (а если ещё дальше в лес...).
А с точки зрения деления XY по байтам, 12 например не очень хорошо подходит. Красиво подходит 16, но 4^16 уже 4 294 967 296 - полноценный 16-ричный мильярд, "вылезший" даже из LongWord.
>Кто-то мешает TNE-кам присвоить размер -1?
Я с тем же успехом могу присвоить им и 0.
Вопрос в выделении под них отдельной таблицы ради а) удобной процедуры их чистки и б) упрощённой процедуры перечисления версий для тайла (не надо проверять размер в SELECTе - соответственно SELECT будет ходить только по первичному ключу, а не по таблице).
>легко влазит в Int64, такого типа разве ж в БД нет?
Во-первых, не во всех СУБД он есть. Но это дело поправимое, есть numeric.
Во-вторых, как только XY образуют некую единую сущность - перестаёт работать карта заполнения одним запросом (ну и похожие по сути вещи, которые работают по диапазону XY, например, получение списка существующих версий тайлов для всех тайлов на экране). |
|
|
|
|
По результатам тестов отказался от QuadKey сотоварищи - для него надо существенно больше места (на зумах от 14-го и выше - примерно на 3 порядка). Это полностью нивелирует "плюшки" от разделения таблиц по секциям (партициям) по 'key%' ради кэширования компактных участков. Остаётся только XY.
Между 2-байтным smallint от -2^15 (-32,768) до 2^15-1 (32,767) и tinyint (или byte) ничего нету. Так что вариантов особо тоже нет. Если делиться по таблицам - значит в таблице (без учёта версии) первичный ключ будет x smallint not null, y smallint not null. Ёмкость его (даже если плюнуть на отрицательные значения, то есть на старший бит) будет более 1 млрд. значений. Соответственно полностью его забивать нельзя. Оптимальным было бы кидать в таблицу максимум 4096*4096 = 16 777 216 записей. То есть X и Y чтобы были только от 0 до 4095. Фактически подошёл бы целочисленный полуторабайтовый тип ))), но такого нет.
С другой стороны, как уже писалось, должны (вернее, очень бы хотелось чтобы так было) работать запросы по диапазону X и Y. Иначе запаковали бы 3 байта в 2+1 - и дело с концом, нижние биты XY бы преобразовывали в smallint+tinyint, всё максимально компактно, но карта заполнения строится потайлово (60 тайлов на экране = 60 запросов в таблицы).
А значит коли есть лишних полбайта на каждой координате - наклёвывается интересная идея. После того как взяли от X нижние полтора байта (and 4096) - сдвигаем их влево (соответственно было от 0 до 4095 - получили от 0 до 8190). А теперь финт ушами: нечётные значения X начинают обозначать tne ))) Когда тащим из БД - соответственно пишем диапазон не X between 12 and 20, а X between 24 and 41 - и получаем сразу и тайлы и tne (смотрим остаток, значение сдвигаем вправо). Из-за сдвига остаётся работать SELECT по диапазону. Вроде бы все счастливы. Таким образом засовывается информация о tne в первичный ключ, что позволит строить карту заполнения только по его (ключа) данным.
Можно даже ещё туда что-нибудь пихнуть, есть ещё 2 разряда и неизнасилованный Y ))) |
|
|
|
(0008869)
|
|
Tolik
|
|
13-09-2012 04:40
|
|
|
Не понял, что занимает на 3 порядка больше места? |
|
|
|
|
Вероятно vasketsov юзал строки, вместо того что бы упаковать QuadKey в Int64 или, если учесть разбиение на таблицы, то можно и в Int32.
И кстати, при использовании QuadKey совсем не обязательно получать инфу о каждом тайле в прямоугольнике отдельным запросом. Конечно больше одного, но не линейно от количества тайлов в прямоугольнике. По моим оценкам, если прямоугольник MxN то придется сделать максимум O(log(M)*log(N)) запросов, а это не так и много. |
|
|
|
|
>что занимает на 3 порядка больше места?
QuadKey в оригинальном виде.
>вместо того что бы упаковать QuadKey
Если упаковывать - проще сразу брать XY для упаковки ))).
>совсем не обязательно получать инфу о каждом тайле в прямоугольнике отдельным запросом. Конечно больше одного
Разумеется. НО пока что об алгоритме я не думал. А вообще конечно, границы же разбиения совпадают с границами тайлов на нижележащих значениях зумов, так что сверхсложно быть не должно. |
|
|
|
|
|
Загрузил модель БД (в PowerDesigner 15.3), если вдруг кому интересно, и "есть что сказать" (Ц). Файлик SAS_DB.pdm. Модель для Sybase ASE, так как из него можно генерить скриптом скрипты для остальных СУБД, но с точки зрения "открыл, посмотрел и всё понял" это неважно, специфики там нет. |
|
|
|
|
Залил в репо интерфейс для СУБД (u_TileStorageDBMS). Пока в гуй этот типа кэша не вытащен.
Интерфейс реализует шлюз между DLL и хостом (сасом) для всех существующих функций хранилища. Если чего вдруг надо добавить или реализовать иначе - обсудим.
Осталась самая малость: забацать DLL. |
|
|
|
|
|
Извиняюсь, недопонял, т.е. теперь любое новое хранилище можно подключить в виде отдельной dll? В том числе файловые? Или только на БД? |
|
|
|
|
>теперь любое новое хранилище можно подключить в виде отдельной dll?
В принципе это уже давно можно, но с некоторыми (впрочем существенными) ограничениями: упрощённый вариант работает для GE и GC, только чтение.
Здесь же работа касается реализации поддержки полного перечня функций хранилища:
1. Все потайловые операции чтения-записи-удаления.
2. Все групповые операции типа работы с кэшем и построения карыт заполнения.
3. Полная поддержка версий.
4. Поддержка множества contenttype для одного сервиса.
5....
Пока что не сделана поддержка аутентификации, ибо если получится просто передать HWND в DLL и показать оттуда окно с логином-паролем (сохранять его в укромном месте мы умеем) - сас и без этого обойдётся, вытаскивать аутентификацию в интерфейс не придётся.
Поддержка архива часто используемых тайлов (common tiles) пока что получается вообще без информирования об этом саса. Но вытащить наружу интерфейс чтобы сказать "вот этот тайл что-то подозрительно часто используется - давайте его будем хранить отдельно, а в тайлах пусть только ссылки на него будут" всё равно придётся.
Ну и по мелочи типа нотификации разрыва соединения с СУБД.
>В том числе файловые?
Любые. Впрочем для файловых это не самый простой способ их поддержки, их наверняка проще делать модификацией существующих файловых. |
|
|
|
|
Набыдлокодил DLL-ину. Ещё не запускал. Не реализован пока метод для создания итератора (там как бы в идеале надо fetch-иццо и сразу сдаваццо наружу в итератор) и карта заполнения. Остальное по идее уже в неком виде, близком к финишному.
Забил на ODBC и сделал на dbx. Если внезапно понадобится - на SF есть драйвер ODBC для dbx (якобы даже 2, пока не юзал их).
Лежит тут: https://bitbucket.org/vasketsov/tilestorage_dbms
Для целей ознакомления. Возможно есть какие мысли, советы по параметрам и т.п. |
|
|
|
|
В принципе для некоторых типов сервера всё уже готово и работает.
А вот для некоторых - полный фэйл.
Допускаю, что если пересобраться на XE2 с новыми драйверами DBX, или раздобыть вообще альтернативные, всё будет несколько иначе, но пока что имеем ровно то что имеем.
Итак сделал 2 варианта (переключаются опцией условной компиляции, дальше поглядим), первый через dbExpress, второй через ZeosLib (как старый резервный).
По первому варианту - для ODBC использовал драйвер dbxoodbc_3_2012_0724dev
http://sourceforge.net/projects/open-dbexpress/
Совершенно отлично работает с PostgreSQL, Sybase ASE, MimerSQL и Microsoft SQL Server с их родными драйверами ODBC.
Для MySQL глючит, так что MySQL работает через ZeosLib, а потому в первом приближении не рекомендуется.
От Interbase, Sqlite и прочих файловых отказываемся по определению.
От Firebird пришлось отказаться ввиду отсутствия его работоспособности в текущей версии, BLOB-ы просто никуда не годятся.
Oracle+DB2+Informix ещё не делал, их малость отложим.
Если кто-то уже готов что-нибудь потестировать - ставьте или настраивайте любой перечисленный выше сервак (кроме Interbase/Firebird), какой лучше знаете и умеете пилить.
А я покуда в репо описание и примерчиков с настройками подключения понакидаю, да EXE для тестирования соберу. |
|
|
|
(0009959)
|
|
Tolik
|
|
19-11-2012 23:35
|
|
Ого! Объять необъятное?
А какую БД можно (лучше всего) поставить чисто для САСа, если на компе нет никакой? |
|
|
|
|
>Объять необъятное?
Логика у всех СУБД примерно одинакова.
Так что в нашем случае важны будут прежде всего отличия в синтаксисе + качество реализации используемой библиотеки для подключения. Короче говоря - всё упирается в свободное время для "потестить" (ну и иногда обновить версию СУБД).
>можно (лучше всего) поставить
Во всех случаях надо ставить ту, с которой больше всего разбираешься )). Когда в БД будет гигов этак 100500, и она будет с трудом шевелиться, надо будет знать что делать. То есть даже если не сам - всё равно под боком должен быть "шарящий" чел. Потому что с СУБД вопрос обслуживания и восстановления - это не вопрос "если", это вопрос "когда".
Естественно не надо ставить такие, где нет функциональности создания и восстановления backup-ов. А также такие, где после пропадания питания и крэша ОС надо руками всё поднимать побайтно.
Есть некоторые приятности у некоторых СУБД, например у PostgreSQL есть наследование таблиц (и можно испустить один запрос по куче таблиц, но это пока не очень актуально), а Sybase ASE умеет быстро "приаттачивать" сохранённые ранее бэкапы как отдельные БД в режиме read-only (а это кстати может быть весьма актуально).
Также имеет смысл сразу выбирать такую СУБД, которая поддерживает логическое (в смысле условий) разбиение таблицы для партиции (секции). Это позволит как не умереть на вставке данных в СУБД, так и читать будет попроще, если разбить таблу по x, y, v.
Если совсем "на компе нет никакой" (C) - репликация вряд ли понадобится, как и прочие кластеры и Failover/HA.
Разумеется есть вопросы касающиеся лицензирования и ограничений конкретной редакции СУБД. Например есть Oracle XE с лимитом в один гиг оперативы и 11 гигов данных.
Если совсем "на компе нет никакой" (C) - я б поглядел для начала на PostgreSQL. Хотя есть очень компактный и быстрый такой экзотический вариант как MimerSQL, против которого играет его экзотичность (хотя пока что он на микрообъёмах засасывал и выплёвывал тайлики не хуже Sybase ASE).
Просто надо отчётливо понимать, что переход с одной СУБД на другую, когда уже нажита непосильным трудом сотня миллионов тайлов - процесс нереальный. Так что выбор должен быть сразу правильный. |
|
|
|
|
Приаттачил SASPlanet_DBMS_20121120.rar
ссылка на репо:
https://bitbucket.org/vasketsov/tilestorage_dbms
Файл TileStorage_DBMS.dll в папке Bin.
Файл dbxoodbc.dll в папке dbxoodbc.
Скрипты в папке DBMS.
Описание и примеры в папке sasgis (прочитать и понять). |
|
|
|
(0009962)
|
|
Tolik
|
|
20-11-2012 02:18
|
|
«Имя, сестра, имя!» ©
:)
Чё бы такое поставить, чтобы потестировать новую фичу?
По работе сталкивался с Ораклом и Sybase и MySql (и Times10 какая-то всплывает в памяти) - всё это под юниксом, но поднимать большую серверную БД задача не стоит, интересно попробовать некую альтернативу Беркли (вдруг понравится). |
|
|
|
|
|
Если совсем "на компе нет никакой" (C) - я б поглядел для начала на PostgreSQL. |
|
|
|
(0009964)
|
|
Tolik
|
20-11-2012 07:06
(edited on: 20-11-2012 07:11) |
|
1. Весьма неудобно скачивать эти все файлики из репо по одному. Вернее не скачивать (такой кнопки не нашёл), а копи-пастить! Надо запаковать всё, что нужно, в архив. Пока сделал клон, стащил сразу всё.
2. Не понял, зачем 2 ini. В случае постгре надо пользоваться ZEOS или DBX? Или оба нужны?
|
|
|
|
(0009965)
|
|
Tolik
|
20-11-2012 07:11
(edited on: 20-11-2012 07:12) |
|
> Итак сделал 2 варианта (переключаются опцией условной компиляции, дальше поглядим), первый через dbExpress, второй через ZeosLib (как старый резервный).
Какой вариант в SASPlanet_DBMS_20121120.rar?
|
|
|
|
(0009966)
|
|
Tolik
|
20-11-2012 10:28
(edited on: 20-11-2012 10:32) |
|
Все нужные файлы распихал (и сюда выложил: SASPlanet.DB.zip)
Поставил постгре, пароль задал 123456 (как в ини-файлах), создалась БД postgres, всё красиво, порт 5432 слушает.
Что теперь? Надо создавать БД sas? Или что-то ещё?
ODBC Data Source надо прописывать в контрол панели?
Из readme не понял, нужна пошаговая инструкция.
САС качает тайлы, но, видимо, никуда не складывает и ничего не показывает.
|
|
|
|
|
>зачем 2 ini
DBX нужен для dbExpress и не нужен для ZEOS.
ZEOS нужен для ZEOS и не нужен для DBX.
Они разные потому что пространство имён разное.
Ну и для простоты, как ни странно.
Возможно ZEOS в окончательной редакции выпилится, если в нём не будет необходимости.
>Или оба нужны?
В случае постгреса он отлично работает через драйвер ODBC. Достаточно только DBX.
>сделал 2 варианта
>Какой вариант в SASPlanet_DBMS_20121120.rar?
В архиве один вариант, потому что это сас.
Два варианта возможны у DLL. Та что с ZEOS-ом - её в репо нет, как раз чтобы не путаться )))))))). DLL для работы через ZEOS я пожалуй сложу в папку с ZEOS-ом, как в следующий раз руки до него дойдут.
>ODBC Data Source надо прописывать в контрол панели?
Да. Во всех случаях использования ODBC надо сходить в панель управления и создать там System DSN, проверить подключение. После этого в ini-шке сделать по примеру секцию [System_DSN\$] как написано в readme.
>нужна пошаговая инструкция
Ну значит будет инструкция. moscow never sleeps ))
>Надо создавать БД sas?
Не обязательно. Все параметры подключения вплоть до БД указываются в настройках ODBC. У меня например сас гадит в БД postgres в схему public. Лично мне не очень жалко. Если внезапно захочется чтобы гадил в другое место - есть возможность прописать ему в ini другую схему. Но...
>Или что-то ещё?
Но пока что имеет смысл запустить pgAmin III и поглядеть, как что внутри расположено (после запуска и подключения там кликаем на БД - потом на postgres - потом на Схемы - потом на public - потом на таблицы), создались ли таблицы с именами типа Z_ALL_SQL.
Первоначальная задача - убедиться, что
а) создались базовые таблички с именами Z_* (их должно быть 6 штук, они создаются скриптом из файла .sql);
б) в таблице Z_ALL_SQL опять жа 6 записей (ПКМ - просмотр данных), в неё залетают команды из скрипта .xql;
в) в таблице Z_SERVICE есть запись, соответствующая картосервису;
г) есть таблица с именем X_<SVC>, где <SVC> - имя сервиса (например X_googlesat) и в ней есть хотя бы одна запись для хотя бы однй версии (таблица и версия должны создаться автоматически, впрочем как и всё остальное).
Кроме того специфично для PostgreSQL надо убедиться, что:
а) создались функции lo_in и lo_out;
б) в настройке ODBC (настройка - datasource) на второй закладке включить галочку "bytea as LO"; не помню, трогал ли я там же на 1 закладке, но "Parse statements" у меня включено;
в) может быть и не критично, но драйвер ODBC у меня выбран юникодный. |
|
|
|
(0009968)
|
|
Tolik
|
|
20-11-2012 13:21
|
|
> как раз чтобы не путаться ))))))))
В общем нужен полностью готовый один ini-файл и пошаговая инструкция, как добавлять System DSN. Со всеми адресами, паролями и явками.
Что-то не получилось подключиться к серверу. |
|
|
|
|
Так может прото драйвера ODBC нет родного для PostgreSQL?
Он так и зовётся PostgreSQL ODBC Driver (UNICODE).
В администраторе ODBC переходим на закладку System DSN и там создаём новый источник данных. Выбираем там (судя по всему ближе к концу списка) указанный драйвер (если его нет - надо качнуть с оф.сайта), а потом у самой записи настраиваем параметры.
Приаттачил 2 картинки. |
|
|
|
(0009970)
|
|
Tolik
|
20-11-2012 14:05
(edited on: 20-11-2012 14:15) |
|
Качнуть что именно?
Это что ли? http://ftp.postgresql.org/pub/odbc/versions/msi/psqlodbc_09_01_0200-1.zip
|
|
|
|
(0009971)
|
|
Tolik
|
20-11-2012 14:26
(edited on: 20-11-2012 14:29) |
|
Ага, этот драйвер работает, но ini не осилил.
Непонятно, чё писать в MAIN
|
|
|
|
|
В никакой MAIN ничего писать не надо.
В _DBX_TileStorage_DBMS.ini должна быть простая секция:
[PostgreSQL_OdbcW\$]
DriverName=Odbc
User_Name=postgres
Password=123456
Тогда:
а) будет использоваться System DSN с названием PostgreSQL_OdbcW;
б) его же надо вписать в zmp (только поправить скрипт чтобы Version подставлял для скачки):
DefURLBase=http://khm.google.com/kh/v=
Version=118
NameInCache=PostgreSQL_OdbcW\$\googlesat
CacheType=7
как-то так ))) |
|
|
|
(0009974)
|
|
Tolik
|
20-11-2012 15:04
(edited on: 20-11-2012 15:13) |
|
Блин, ну чё ж всё клещами надо вытягивать!
Как можно было догадаться ещё и про ZMP!
Секция-то должна называться [PostgreSQL35W\$] наверно? (а, это у меня такое имя по умолчанию получилось)
А Version обязательно?
А через maps.ini можно?
Всё равно не работает, таблицы не создаются.
|
|
|
|
|
В zmp пишется только:
NameInCache=PostgreSQL35W\$\googlesat
CacheType=7
никаких новых секций там не добавляется (только новый тип кэша и полный путь до картосервиса в БД).
А это:
[PostgreSQL35W\$]
DriverName=Odbc
User_Name=postgres
Password=123456
надо запихнуть в _DBX_TileStorage_DBMS.ini |
|
|
|
|
>А Version обязательно?
В zmp - нет.
А вот в DLL и БД - да. Хранилище принципиально версионное.
Объясняю:
Во всех операциях с тайлами (чтение, запись,...) укаывается версия. Та самая, которая указана в zmp в поле Version, она же в настройке карты, она же по ПКМ выбирается при перечислении версий.
Если при обращении к хранилищу указывается пустая версия - используется специальная резервная запись с номером 0 и пустым именем версии, она создастся автоматически.
Отдельное выделение Version в zmp имеет смысл, если хочется поиграться с разными версиями (тем более что есть места где гугл последний десяток версий много обновлялся), попереключаться между ними (там правда не всегда корректно переключение отрабатывает, что-то vdemidov недокрутил с рассылкой смены версии, так что бывает надо перезапустить сас). То есть в случае хранения тайлов в СУБД - всегда.
Если же не хочется многоверсионности - я если честно не вижу смысла в играх с СУБД. Размер на диске это точно не уменьшит.
зы. Не надо сильно злиться. Многие веши, очевидные для меня, могут быть неочевидны для других, и наоборот. Потихоньку всё выясним, и всё заработает. |
|
|
|
(0009977)
|
|
Tolik
|
|
20-11-2012 15:47
|
|
Короче, у меня:
в maps\maps.ini
[{F6574B06-E632-4D5F-BC75-C8FA658B57DF}]
Name=Satellite (Google maps)
pnum=2
Version=118
CacheType=7
NameInCache=PostgreSQL35W\$\sat
в DBMS\_DBX_TileStorage_DBMS.ini
[PostgreSQL35W\$]
DriverName=Odbc
User_Name=postgres
Password=123456
Ещё в DBMS:
dbxoodbc.dll
TileStorage_DBMS.PG.sql
TileStorage_DBMS.PG.xql
В основной директории:
TileStorage_DBMS.dll
SASPlanet.exe из этой темы
БД живая, ODBC тест проходит, но таблицы не создаются.
Нужен дебаг - кто куда не пишет. |
|
|
|
|
>maps.ini
уж не знаю, пролетит ли оно оттуда.
лучше удалить вообще из maps.ini и в zmp вписать.
На всякий случай надо ещё поглядеть из сасовой iniшки содержимое секции [PATHtoCACHE]. Там параметр с именем DBMSCache. По идее задумывалось, что если все 3 поля есть в NameInCache - от общего параметра DBMSCache ничего не зависит. Но на всякий случай надо проверить. У меня там: DBMSCache=cache_sasgis\cache_sasgis |
|
|
|
(0009979)
|
|
Tolik
|
|
20-11-2012 16:22
|
|
там по умолчанию стоит
DBMSCache=cache_dbms
а этот путь чему должен соотв? |
|
|
|
|
|
Приаттачил ещё архивчик с dbxadapter30.rar, его надо распаковать и сложить рядом с dbxoodbc.dll. Шаманство, но мало ли. |
|
|
|
(0009981)
|
|
Tolik
|
|
20-11-2012 16:26
|
|
|
|
|
|
>а этот путь чему должен соотв?
Если в NameInCache уже формат указан как S\D\T - то по идее на DBMSCache наплевать.
Если в NameInCache только T (например, googlesat) - то всё остальное (PostgreSQL35W\$) должно быть в общем параметре DBMSCache. Задумано для единой общей настройки СУБД для всех картосервисов, чтобы в zmp был только googlesat.
Я б пока не особо напрягался на тему DBMSCache.
Вполне возможно там что-то не так определяется, и в итоге в DLL в качестве пути пролетает не PostgreSQL35W\$\sat, а какая-то фигня.
Надо вписать туда cache_sasgis\cache_sasgis и забыть о том, что этот параметр вообще есть. Сильно вряд ли, что играет роль, cache_dbms там или cache_sasgis\cache_sasgis. |
|
|
|
|
Приаттачил TileStorage_DBMS_ZEOS.rar
Там только одна DLL, собранная для работы через zeos.
Соответственно настройки соединения она берёт из _ZEOS_TileStorage_DBMS.ini, так что всё связанное с DBX ей как бы не надо вовсе.
Пример секции для postgresql:
[PostgreSQL35W\$]
Protocol=postgresql
HostName=localhost
Port=5432
Database=postgres
User=postgres
Password=123456
$LOAD_LIBRARY_ALT=C:\Program Files\PostgreSQL\9.2\bin\libpq.dll
$SYNC_SQL_MODE=2
Пусть не смущает PostgreSQL35W в названии секции - для zeos это просто ничего не значащее уникальное имя, так как zeos с PostgreSQL работает напрямую через оригинальную либу.
Если вдруг будут ошибки с перерисовкой - надо попробовать заменить последний параметр на $SYNC_SQL_MODE=1 |
|
|
|
|
Приаттачил для тестов TileStorage_DBMS_ODBC.rar.
Работает ТОЛЬКО с драйверами ODBC. Но зато по идее с любыми, и ничего левого не требует ))
Имя ini-шки для неё - _ODBC_TileStorage_DBMS.ini
Внутри этой ini-шки проще некуда:
[PostgreSQL35W\$]
DSN=PostgreSQL35W
UID=postgres
PWD=123456
$ODBC_ConnectWithParams=0
$SYNC_SQL_MODE=1
То есть указывается только имя системного DSN и логин-пароль.
Последние 2 строки указывать обязательно. |
|
|
|
(0010015)
|
|
Tolik
|
|
22-11-2012 10:30
|
|
Обязательно попробую позже.
Что значит "левого"? Надо удалить что-то из того, что я скачивал?
Или лучше так: Что конкретно требуется:
1. SASPlanet.exe
2. TileStorage_DBMS.dll
3. _ODBC_TileStorage_DBMS.ini в дир. DBMS
4. драйвер ODBC и настройка System DSN в контрол панели
5. путь к кэшу в zmp
6. ?
7. ??
8. ??? |
|
|
|
|
>Что значит "левого"?
То и значит, что нужен только родной настроенный дравер ODBC.
Удалять ничего не надо. Хотя потенциально если ODBC заработает, DBX поддерживать не будем, достаточно будет резервного прямого доступа через ZEOS.
Список верен, если сас из этой темы ))
Чтобы не было сомнений, что за DLL используеся - запихнул небольшое описание в информацию о версии, через odbc или через zeos.
Далее:
6. Чтобы первые 2 части пути к кэшу (PostgreSQL35W\$) соответствовали названию секции [PostgreSQL35W\$].
7. Не забываем про CacheType=7.
И ещё. На всякий случай необходимо проверить, что в название DSN входит "POSTGRESQL" (регистр не важен). Я нашёл косячок, из-за которого тип драйвера ODBC мог определяться не по его реальному типу, а по имени DSN. Но в случае PostgreSQL35W это заведомо выполняется, просто на будущее. Тип драйвера ODBC прежде всего используется для определения, по каким именно скриптам генерить структуру БД (ну и разные небольшие отличия в работе). |
|
|
|
|
Сильно поковырял modbc в плане в плане скорости и ошибок.
Приаттачена новая версия SASPlanet_DLL_ODBC.rar
В архиве только сас + dll для ODBC.
По идее сейчас можно не использовать параметр $SYNC_SQL_MODE в _ODBC_TileStorage_DBMS.ini. Но если вдруг будет "зависать" перерисовка тайлов - этот параметр по-прежнему можно включить. |
|
|
|
|
Заменил аттачи на новую версию SASPlanet_DBMS_ODBC.rar (в архиве EXE+DLL).
Реализована карта заполнения (на +8 - это отдельная песня) + устранены некоторые мелкие баги.
Из оставшегося - "дорожная карта":
1. Выпиливание жуков и разного рода неоптимальностей.
2. Реализация скана хранилища для работы в качестве источника для менеджера кэша. Впрочем для работы в качестве получателя кэша менеджер тоже надо допиливать, как минимум чтобы версия умела заменяться налету (чтобы старые снимки того же бинга залетели в БД с нужной версией).
3. Поддержка oracle и db2, возможно ещё чего-нибудь.
4. Информирование саса о критических ошибках в DLL (типа не подходит логин и пароль просрочен). Пока что сас будет тупо долбиться в DLL, никакого статуса нигде не отображается, и никакие мессаги никуда не прилетают.
5. Совсем далёкое будущее - реализация настройки параметров хранилища через внутренний протокол в обычном внутреннем веббраузере через обычный http прямо в сасе, чтобы сас знать не знал о том, что у хранилиа есть какие-то неизвестно какие параметры, а лишь был транспортом между вебом и хранилищем. |
|
|
|
|
Начал как обычно с конца )) сделал настройку опций через внутренний протокол (типа как информация о карте).
Чтобы до неё достучаться, надо в zmp в файле info.txt написать кусок вида:
sas://TileStorageOptions/{40E4E9FA-727F-4A86-8A5D-A21B728C57A7}
где GUID должен быть настоящим реальным GUID-ом текущей карты (из params.ini).
После этого по ПКМ в информации о карте надо тыкнуться на этот урл. Откроется нечто типа:
Options
Server defined as PG
Это просто заголовок и служебная информация, как идентифицирован сервер. Здесь это аббревиатура PostgreSQL.
Дальше будет типа табличка:
How to compare versions
С 5 вариантами в строчку, здесь я их перенёс для наглядности:
None
By ID
By Value
By Date
By Number
Под каждым либо Current (что означает текущее значение) либо Select (и если тыкнуться - значение изменится на выбранное).
Чтобы для bing-а и прочих гуглов можно было сравнивать версии, надо тынцнуться на By ID.
Изменения этого параметра СОХРАНЯЮТСЯ в БД для текущего картосервиса, так что аккуратнее. По умолчанию все картосервисы имеют несравнимые версии (при наличии прямых рук изменение значения по умолчанию на таблице Z_SERVICE допускается, так как при вставке информации о новом картосервисе для поля id_ver_comp не подставляется никакого значения, и залетает значение по умолчанию).
Со второй табличкой "What to do if tile not found" всё несколько сложнее.
Её изменения пока что НЕ СОХРАНЯЮТСЯ в БД, так как изначально я предполагал их хранить в zmp, а потом передумал. Так что если хочется при пустой версии видеть последнюю, или при указанной версии и отсутствии тайла видеть последнюю предыдущую - придётся после запуска саса ходить и включать соответственно опции
"Show tile with last version if no tile for request without version" (последняя) и "Show tile with prevoius version if no tile for request with version" (предпоследняя).
Только пожалуйста будьте аккуратнее с генерацией зумов наверх, в БД новые тайлы залетают ВСЕГДА только с той версией, что указана в настройках карты. В этом смысле случайно подтянуть устаревшие версии и нагенерить "новых" гораздо проще, чем кажется.
Так как смена версии у карты не всегда корректно отрабатывает (иногда остаются неперерисованные тайлы со старых версий), при наличии сомнений лучше включать карту заполнения, она всё чётко покажет.
В очередной раз приаттачил новый архивчик с EXE+DLL. |
|
|
|
|
Приаттачил новую версию EXE+DLL в SAS_ODBC_NEW.rar
Устранил 2 ошибки, приводящие к Exception-ам.
Сделал сохранение доступных настроек в БД (см. предыдущее сообщение).
Чтобы оно (сохранение) заработало, надо чтобы в таблицу Z_SERVICE добавились новые поля. Также надо создать новую таблицу Z_VER_BY_TILE, без неё всё что сейчас будет работать как прежде, она будет нужна только для автоопределения версии тайла.
Если кто уже напугался - зря. Ничего сложного в этом нет.
Это можно сделать 2-мя способами.
Способ 1 - если надо обновить существующую рабочую БД.
Необходимо подключиться к серверу административной тулзой и выполнить в рабочей базе на сервере 4 команды вида:
ALTER TABLE Z_SERVICE
ADD tile_load_mode smallint NOT NULL DEFAULT 0
ALTER TABLE Z_SERVICE
ADD tile_save_mode smallint NOT NULL DEFAULT 0
ALTER TABLE Z_SERVICE
ADD tile_hash_mode smallint NOT NULL DEFAULT 0
ALTER TABLE Z_SERVICE
ADD new_ver_by_tile smallint NOT NULL DEFAULT 0
Выполнять по одной.
После этого выполнить:
create table Z_VER_BY_TILE (
id_ver_by_tile smallint not null,
tile_contenttype smallint not null,
src_parser varchar(255) not null,
src_desc varchar(255) null,
src_catalog varchar(255) null,
src_root varchar(63) null,
src_name varchar(63) null,
src_mode char(1) null,
dst_mode char(1) null,
ver_mode char(1) null,
dat_mode char(1) null,
num_mode char(1) null,
dsc_mode char(1) null,
auxillary_ver smallint null,
auxillary_dat TIMESTAMP null,
auxillary_num int null,
constraint PK_Z_VER_BY_TILE primary key (id_ver_by_tile, tile_contenttype)
)
И всё. Для конкретного сервера синтаксис может отличаться, здесь приведено для PostgreSQL. Скрипты в репозитории уже поправлены, Z_VER_BY_TILE последняя, Z_SERVICE предпоследняя.
Способ 2 - если надо обновить существующую рабочую БД.
Необходимо подключиться к серверу административной тулзой и выполнить в рабочей базе на сервере 1 команду (хотя можно и в интерфейсе мышкой удалить, только не очистить, а именно удалить совсем):
drop table Z_SERVICE
Это приведёт к удалению таблицы с картосервисами, но нам это и надо. При этом удалении ни один тайл, ни одна версия, ничего не пострадает (так как тайлы и версии не ссылаются на таблицу с картосервисами).
Потом надо сходить в репозиторий и скачать обновлённый скрипт sql для соответствующей версии СУБД. Скрипты xql не поменялись.
При последующем подключении и начале работы эта табличка (а также заодно и Z_VER_BY_TILE тоже) будет создана из скрипта заново. Надо только не забыть взять из репозитория новые скрипты и положить куда следует (в подпапку DBMS рядом с файлом _ODBC_TileStorage_DBMS.ini).
При создании новой БД достаточно подложить обновлённую версию скрипта sql и старую версию скрипта xql. |
|
|
|
(0010085)
|
|
vasketsov
|
29-11-2012 17:59
(edited on: 29-11-2012 18:01) |
|
Да, глюки с перерисовкой тайлов на экране при смене версии тоже поборол.
Кому лениво ходить в репо - приаттачил все актуальные скрипты в виде ALL_SQL_SCRIPTS.rar.
|
|
|
|
|
Поправил скрипт для informix, добавил скрипты для oracle.
Для oracle инфа: версия обязательна, ибо пустую строку он не умеет пихать в поле NOT NULL.
На этом планируемые СУБД кончились, если чего ещё надо - пишите, обсудим.
Кроме того устранил неожиданный баг: если обламывалась запись в БД, сас ничего не сообщал об этом. Теперь будет ругаться, пока на ломаном английском (иногда с кодом ошибки).
Новая версия (EXE+DLL)приаттачены, собраны по актуальной версии репо (заместо ночнушки). Файл SAS_ODBC_BETA.rar.
Из roadmap-а осталось 2 пункта (scan БД + блокирование хранилища и выдача критической ошибки в интерфейс), оба не критичных.
Далее задумал сделать создание версии в БД по описанию метки (полигона) ну и в принципе руками. Как пойдёт. Может и до парсера тайла дело дойдёт, если универсальный алгоритм генерации уникальной версии по exif придумается. |
|
|
|
(0010128)
|
|
vasketsov
|
04-12-2012 22:23
(edited on: 04-12-2012 22:25) |
|
Очередная партия изменений.
В EXE - внизу в главном контекстном меню рядом с информацией о карте пункт Map Storage Info (только если это поддерживается тайлохранилищем; если же не поддерживается, а это все кроме СУБД, то его не будет). По нажатию на него сразу переход на Tile Storage Options.
В DLL изменений сильно больше, все они связаны с Tile Storage Options:
1. Добавлен вывод списка всех существующих в БД версий для текущей карты.
2. Добавлена пара настроек, связанных с сохранением тайлов в БД. Они касаются определения версии тайла по самому тайлу.
В качестве подарка всем любителям картосервисов Nokia сделано автоматическое определение версии тайла при закачке тайлов без версии. Чтобы оно заработало как надо, необходимо (очевидно, кроме перенастройки zmp на СУБД) в окне Tile Storage Options:
а) для опции "How to compare versions" выбрать значение "By Date";
б) в следующей табличке "What to do if tile not found" включить последний пункт "Show tile with last version if no tile for request without version";
в) в следующей табличке "Storage can parse saving tile to obtain its version" включить первый пункт "Allow to parse tile without version" и последний пункт "Can save tile without version for parser (for another zoom generation)"; если не включить последний пункт, то не будет работать генерация мелких зумов, так как при генерации пропадает EXIF, а с этой опцией сгенерированные тайлы будут залетать в СУБД без версии;
г) в следующей опции "Select algorithm to use by tile parser" выбрать либо "NMC by unique TileIdentifier", либо "NMC by latest AcquisitionDate";
д) убедиться что в сасе в zmp и в настройках карты НЕТ никакого указания о версии тайла.
Подробнее про различие режимов "NMC by unique TileIdentifier" и "NMC by latest AcquisitionDate". Разница касается только стыковых тайлов, где более одного снимка. На таких тайлах tileIdentifier отличается от всех featureId в тайле (если снимок в тайле один - они совпадают, хотя это никем не гарантируется). Так вот если "by unique TileIdentifier", то в качестве версии будет залетать уникальный идентификатор версии тайла, а если "by latest AcquisitionDate" - будет залетать тот featureId, для которого максимальна дата снимка. Если не баловаться с версиями в параметрах карты, разницы никакой не будет, кроме случая какой-нибудь цветокоррекции, когда tileIdentifier возможно поменяется, а больше ничего не поменяется. Дата в версию во всех случаях залетает как максимальная из всех дат снимков в тайле.
Так как реализовано это при сохранении тайла в БД, работать оно будет в том числе при копировании кэша в БД, лишь бы был EXIF в тайликах.
3. Добавлено кэширование ошибки при подключении к СУБД. Теперь один раз долбанулись к серваку, если критический облом при подключении (невано какой) - поднимается флаг недступности этого конкретного сервера, и больше к нему карта не тычется. Прочитать сообщение об ошибке можно всё в том же окне Tile Storage Options, если нет подключения к серверу, оно там будет отображаться. Также там будет ссылка чтобы сбросить этот флаг и разрешить снова пытаться подключиться к СУБД. Это на тот случай, если просто забыли поднять СУБД или сеть упала, чтобы восстановить работоспособность без перезапуска.
|
|
|
|
(0010130)
|
|
Garl
|
05-12-2012 04:59
(edited on: 05-12-2012 05:00) |
|
а в файловый кэш такое хозяйство прилепить всё ещё никак?
просто ради 200-300 мб локального файлового кэша поднимать сервер СУБД - не ризон.
|
|
|
|
(0010131)
|
|
vasketsov
|
05-12-2012 10:16
(edited on: 05-12-2012 10:20) |
|
>в файловый кэш такое хозяйство прилепить всё ещё никак?
Покуда файловый не версионный - очевидно что никак ))
А вообще привыкайте к СУБД. Когда-нибудь туда и метки переползут. Тем более что возможно если поглядеть в окошко системных служб (services), там запросто уже может оказаться какой-нибудь MSSQL Express Edition )))) некоторые програмки его ставят для своих нужд.
|
|
|
|
(0010146)
|
|
Tolik
|
06-12-2012 09:46
(edited on: 06-12-2012 10:05) |
|
Наконец-то я запустил БД!
Теперь могу доступным языком объяснить, что для этого надо (если кто-то ещё захочет попробовать).
1. Скачать ночнушку, SAS_ODBC_2012_12_05.rar, DBMS.ZIP (это мой упрощённый вариант), всё это распаковать.
То есть к обычному набору добавляются новый SASPlanet.exe, TileStorage_DBMS.dll и директория DBMS, в которой 3 файла:
TileStorage_DBMS.PG.sql
TileStorage_DBMS.PG.xql
_ODBC_TileStorage_DBMS.ini
2. Скачать и проинсталлировать СУБД PostgreSQL
http://get.enterprisedb.com/postgresql/postgresql-9.2.1-1-windows.exe
(отсюда: http://www.postgresql.org/download/windows/)
и драйвер ODBC к ней
http://ftp.postgresql.org/pub/odbc/versions/msi/psqlodbc_09_01_0200-1.zip
3. Зайти в Administrative Tools - Data Sources (ODBC) и добавить System DSN.
Всё по умолчанию, имя DSN PostgreSQL35W, юзер postgres, пароль 123456.
Нажать кнопку Test, порадоваться.
Тут есть скриншоты.
4. Запустить SASPlanet.exe, зайти в параметры карты и исправить:
Тип кэша - DBMS, Путь к кэшу - например, PostgreSQL35W\$\sat
(т.е. к обычному пути кэша добавить PostgreSQL35W\$\, чтобы программа знала, в какую БД пихать).
5. ???????
6. PROFIT!!!
Теперь можно попытаться выяснить, в чём, собственно, профит :)
|
|
|
|
(0010147)
|
|
Tolik
|
06-12-2012 09:56
(edited on: 06-12-2012 10:02) |
|
По поводу п.4 сразу предложение: надо добавить в параметры программы DSN по умолчанию, чтобы не приходилось для КАЖДОЙ карты править параметры программы (или zmp).
На вкладке Cache добавить поле System DSN и вбить туда PostgreSQL35W\$\
Если какая-то карта хранится в другой БД, тогда уж править параметры карты.
И кстати, я не понял, зачем нужен параметр DBMS root: cache_sasgis\cache_sasgis
P.S. Кажется, DBMS root для этого и был задуман, но не работает.
Также не работает глобальная настройка Cache Type (можно выбрать DBMS, но это ни на что не влияет).
|
|
|
|
|
>DBMS root для этого и был задуман, но не работает
Да, параметр
DBMS root: cache_sasgis\cache_sasgis
и был задуман, чтобы ему вписать например
PostgreSQL35W\$
а в zmp чтобы было по-старому, одним словом.
Бум искать баг. Покуда я пользовался всегда только полным путём вида PostgreSQL35W\$\sat - в том числе в копировании кэша, я и не налетал на него.
>не работает глобальная настройка Cache Type
В смысле, весь кэш по умолчанию в БД? Ну да, тоже не тестил ((, у меня мало где указан относительный путь до кэша, так что везде в zmp и тип вписан нужный.
Впрочем радует что наконец-то попёрли багрепорты ))
>можно попытаться выяснить, в чём, собственно, профит
Профит в экономии места на диске (разница зависит от СУБД), в более быстром доступе (нет проверок доступа + меньше места + кэш), в упрощённых процедурах backup/restore по сравнению с ФС (только phpAdmin-ом не пользуйтесь, он кривой, надо юзать pgAdmin). Проигрыш в необходимости установки СУБД и в необходимости его запускать. |
|
|
|
|
|
Я б только для PostgreSQL рекомендовал создать отдельный tablespace и отдельную БД над ним (всё делается в pgAdmin по ПКМ в левом дереве, указание tablespace при создании БД на второй закладке). |
|
|
|
(0010150)
|
|
Tolik
|
|
06-12-2012 11:33
|
|
Ну, продвинутые настройки БД - это следующий этап.
Для начала надо бы найти, в каких файлах она хранится, как делать бэкап/restore и перенос на другой комп :) Впрочем, к сасу это уже отношения не имеет. |
|
|
|
|
>надо бы найти, в каких файлах она хранится
Так вот при создании tablespace и указывается папка, где это всё будет храниться. Так банально проще, ответ сразу очевиден.
Причём один из допустимых способов бэкапа всего tablespace на postgresql - это просто копирование папки (правда ндо сервер останавливать). |
|
|
|
(0010152)
|
|
Tolik
|
|
06-12-2012 12:26
|
|
> Я б только для PostgreSQL рекомендовал создать отдельный tablespace и отдельную БД над ним
Правильно, надо будет это и в инструкцию вписать. Нехорошо гадить в системную БД.
Первое впечатление хорошее: САС не тормозит, БД не убивается. |
|
|
|
(0010153)
|
|
Fetser
|
|
06-12-2012 15:04
|
|
Я никогда не имел дела с базами данных, поэтому у меня совсем дилетантские вопросы:
1 При попытке установить postgresql-9.2.1-1-windows (скачал от туда откуда посоветовал Tolik) и сразу получил "Unable to write inside TEMP environment variable path." Подскажите чего ей не нравится? устанавливал в своём компьютере.
2 Если у меня нет непосредственного доступа к серверу, а просто выделено там место и у меня права на чтение и запись возможно там установить postgresql? (установить там sasplanet и файловый кэш и SRTM у меня отлично получилось)
3 Сейчас у меня один экземпляр sasplanet с сервера запускают более 50 человек одновременно (метки конечно только на чтение)возможно ли такой же вариант если кэш будет не тайловый, а база данных? |
|
|
|
|
>При попытке установить postgresql-9.2.1-1-windows
Буквально только что вышла новая версия кстати ))
>нет непосредственного доступа к серверу
Никак. Все приличные серваки стартуют как системная служба, лишь в редких исключениях их запускают с консоли как обычный процесс, например для лечения.
>один экземпляр sasplanet с сервера запускают более 50 человек одновременно
Одновременный доступ к накачанному безуслово возможен, более того, на 50 юзерах виндовая служба сервера бессовестно сольёт любому серверу БД. Это даже не нагрузка, это ерунда.
К меткам формат кэша отношения не имеет. Меткам полностью пофигу, где хранится кэш. Метки пока в PostgreSQL или любую другую "взрослую" БД не запихнуть. В принципе я даже пока что вообще не смотрел, что там с метками. Мне и с кэшем пока забот хватает, несмотря на то что хранилище в принципе уже рабочее. |
|
|
|
(0010155)
|
|
Fetser
|
|
06-12-2012 17:15
|
|
>Буквально только что вышла новая версия кстати
Скачал postgresql-9.2.2-1-windows.exe при запуске выдаёт туже ошибку "Unable to write inside TEMP environment variable path." Пробовал запускать и из корня диска (чтобы в путях не было кириллицы) не запускается :( В чём может быть ещё причина? Стоит XP 32 бита. Именно такой инсталятор и скачал. |
|
|
|
|
Так TEMP может указывать внутрь профиля с кириллицей.
Если дело в этом, то замена в настройках окружения TEMP на что-то типа C:\temp поможет. |
|
|
|
(0010157)
|
|
Fetser
|
|
06-12-2012 17:59
|
|
>замена в настройках окружения TEMP на что-то типа C:\temp поможет
Проблема где то в другом месте у меня
TEMP=C:\WINDOWS\Temp
TMP=C:\WINDOWS\Temp
Завтра попробую на другом компьютере если получится буду искать разницу |
|
|
|
|
>TEMP=C:\WINDOWS\Temp
Это системное значение. Пользовательское - выше, и оно имеет приоритет. |
|
|
|
|
Обновил EXE+DLL в приаттаченном SAS_ODBC_2012_12_06.rar
Изменения касаются только облагораживания обработки ошибок и сообщений о них.
В Tile Storage Options сделан показ всех Unknown Errors, если таковые были.
Теперь по идее в случае какой-то ошибки можно будет понять, что случилось.
Баг с тем что игнорируется общая настройка DBMS root сегодня не смотрел даже.
Подозреваю что следующая версия DLL на этой неделе будет релизной, и пункт я закрою (возможно открыв парочку новых мелких).
Во всяком случае критичного там судя по всему уже ничего нет.
А интерфейс для менеджера кэша (scan всех тайлов) чую задницей что надо будет писать для каждого типа СУБД отдельно, то есть отдельными пунктами, так как работа с курсорами слабо переносима между СУБД. |
|
|
|
(0010160)
|
|
Tolik
|
|
07-12-2012 04:31
|
|
Хорошо бы скрипты захардкодить, а секцию из ini запихнуть в SASPlanet.ini.
То есть избавиться от лишних файлов и всей директории DBMS. |
|
|
|
|
>Хорошо бы скрипты захардкодить
Шутишь? Это исключено, инфа 100%, иначе как их руками править, например сразу нужное значение по умолчанию вписать сразу при создании таблицы или tablespace или опции хранения типа где будут картинки валяться.
То что это рабочие скрипты - не означает, что они подойдут для всех случаев.
Да и смысла их все в памяти держать нет никакого, для конкретного сервера надо только 2 файла, и только на момент первого залёта, потом можно и без них, так как в процессе работы новые таблички создаются только на основе таблицы z_all_sql, и скрипты уже не нужны.
>секцию из ini запихнуть в SASPlanet.ini
Какую именно и почему одну секцию надо туда запихнуть? И зачем? |
|
|
|
(0010163)
|
|
Fetser
|
|
07-12-2012 08:25
|
|
Дополнение для инструкции:
1 Для использования PostgreSQL необходимо иметь установленный Microsoft VC++ скачать можно здесь http://forum.oszone.net/thread-145766.html
2 Если при установке появляется ошибка "Unable to write inside TEMP environment variable path" необходимо проверить в реестре:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings строковый параметр "Enabled" Присвоить ему значение 1
также подобную ошибку вызывает:
HKEY_CLASSES_ROOT\.vbs если (Default)не VBSFile а другая программа. Часто там бывает ассоциация Notepad++_file Надо вернуть ассоциацию по умолчанию. |
|
|
|
(0010164)
|
|
Tolik
|
|
07-12-2012 08:25
|
|
|
Ладно, пусть будет как есть. |
|
|
|
|
Обновление, надеюсь, последнее в этой теме. Если до вечера понедельника ничего не найдётся - закрываем тему.
Из изменений: продолжение сильной переделки обработки ошибок и выдачи их юзеру, так что что-нибудь могло и отъехать в плане именно обработки ошибок. Если все DSN-ы настроены и всё работало - значит то неактуально.
Таки придумал ситуацию, чтобы не таскать с собой лишнюю ini-шку. Если настройка подключения совпадает с существующим System DSN и нет ini-шки - подключение будет к нему, все параметры по умолчанию, логин и пароль пустые. Не все СУБД это допускают, но в принципе многие. Только для ODBC.
Для Sybase ASE изменил блокировку тайловых таблиц, чтобы сэкономить немного килобайт на хранении тайлов.
Для PostgreSQL удалил из скрипта всё что относилось к типу lo. Оно было добавлено, так как раньше для подключения было обязательно включать галочку 'bytea as LO' в настройках DSN (см. приаттаченные картинки), и без типа lo оно просто не работало. Теперь подключение к PostgreSQL будет работать независимо от состояния этой галочки. Более того, её рекомендуется выключить, а тип lo вместе с функциями lo_in и lo_out удалить (удалить их можно только КАСКАДНО, так как тип ссылается на функции, а функции на тип, это делается по ПКМ в pgAdmin, либо там можно выполнить drop type lo cascade). На всякий случай будет нелишним убедиться, что в используемом скрипте TileStorage_DBMS.PG.xql его не было (вместо него должно быть bytea), и ни в одну табличку lo не залетел (это можно сделать просто глазами, пройдя в pgAdmin по табличкам слева, справа внизу будет код их создания). Особенность типа lo в том, что после удаления записи физически тайл может оставаться в БД, если на него ещё кто-то будет ссылаться, для bytea всё более предсказуемо.
На всякий случай: правильный код создания таблички в pgAdmin отображается примерно так:
CREATE TABLE "6I_bingsat"
(
x smallint NOT NULL,
y smallint NOT NULL,
id_ver smallint NOT NULL,
tile_size integer NOT NULL DEFAULT 0,
id_contenttype smallint NOT NULL,
load_date timestamp without time zone NOT NULL DEFAULT now(),
tile_body bytea,
CONSTRAINT pk_6i_bingsat PRIMARY KEY (x, y, id_ver)
)
WITH (
OIDS=FALSE
);
Также отключил повторное использование подключения к СУБД картосервисами. Теперь если 2 картосервиса сервиса живут на одном сервере БД, каждый будет иметь свой подключение. Это сделано для повышения надёжности работы, у ODBC вообще плохо с получением данных по одному соединению в несколько потоков.
На всякий случай кто не в курсе - мануал по настройке PostgreSQL.
Ссылка даётся а) как на русскоязычный и б) ради первого параграфа.
http://www.opennet.ru/docs/RUS/postgresql_tune/
Так что настраивайте сервак - и он отплатит вам надёжной быстрой работой.
И ещё замечание. Я пока что не тестировал необходимость замены BLOB на CLOB для векторных тайлов (на разных СУБД эти имена разные, это может быть text вместо image или bytea). Возможно на некоторых СУБД после такой замены и включения сжатия можно получить существенную экономию места при хранении например PanoramioKML или Wiki. А возможно и так, что сжатием нельзя будет пользоваться из-за проседания скорости работы. Это всё только после "полевых испытаний" будет понятно, более того, у всех могут быть свои особенности настройки сервера, железо, ОС и т.п. Но в любом случае изменений структуры БД это не потребует. Все прочие запланированные на сей момент к реализации доработки также не приведут к необходимости изменения стрктуры БД. Файлик TODO не публикую, чтобы не сильно донимали )))
Традиционно в файле SAS_ODBC_2012_12_09.rar лежат EXE+DLL, а также рядом все акуальные скрипты создания структуры БД. |
|
|
|
|
Ещё забыл написать:
1. Тип кэша по умолчанию полечен, так что можно указать типа кэша DBMS (пока не переведено как СУБД) как кэш по умолчанию.
2. Общий DBMS root работает - в zmp можно писать только по-старому кончики типа bingsat или googlesat - начало типа PostgreSQL35W\$ будет подставляться из DBMS root (если оно там указано). Значение DBMS root - это в настройках саса в настройках кэша текстовое поле для указания общего сервера БД.
3. А вот в диалоге копирования кэша при выборе цели как СУБД - необходимо указывать ПОЛНЫЙ путь, то есть PostgreSQL35W\$\bingsat, а не просто bingsat. Оставлено по причине того, что тянуть туда глобальные настройки кэша не очень удобно и вообще далековато.
4. Старайтсь не называть (в смысле NameInCache) свои сервисы в zmp по-русски (украински, белорусски, казахски, татарски,...) или слишком длинными названиями. Сейчас имя сервиса обрезается до 20 букв. Это относится к последнему идентификатору после символа "\" в поле NameInCache. Просто от греха подальше. |
|
|
|
(0010170)
|
|
zed
|
|
09-12-2012 10:16
|
|
|
А из каких соображений реализация хранилища вынесена в dll? Там какие-то варезные компоненты юзаются или что? |
|
|
|
|
Из тех что многим это нафиг не надо (как и внутренний веб-сервер например).
Это не для встраиваемых СУБД, так что кинуть DLL в папку по сравнению с установкой и настройкой СУБД сущая ерунда.
Что более важно - через DLL подключение возможно как через ODBC, так и через ZEOS напрямую (что возможно увеличит скорость для некоторых СУБД из-за удаления прослойки ODBC или использования специфичного транспорта типа SharedMem если mssql установлен локально). Если линковать оба транспорта - будет 1.5 мега лишних в сасе. А так просто замена DLL на новую для ZEOS + другая ini-шка. А для моньякофф есть BlackFishSQL который вместе с delphi идёт, для которого есть только dbExpress-ный драйвер, который можно использовать только если собрать DLL для работы через DBX. Так что залить в сас единственно корректную имплементацию DLL которая бы всех устраивала (пусть даже без DBX и BlackFishSQL) не представляется возможным.
зы. Ничего варезного там нет. |
|
|
|
(0010172)
|
|
Tolik
|
|
09-12-2012 15:34
|
|
|
Что за хрень - 'bytea as LO'? |
|
|
|
|
Галочка в настройках DSN на второй закладке свойств, см. приаттаченные сверху картинки.
В теории Delphi работает только с ней включённой. На практике научились и без неё. |
|
|
|
(0010174)
|
|
Tolik
|
|
10-12-2012 06:18
|
|
|
Не, это понятно, мне просто интересно, что эта непереводимая игра слов означает. |
|
|
|
|
На PostgreSQL существует 2 типа больших бинарных объектов - bytea и lo.
Первый - простой как валенок, второй обладает искуственным интеллектом, подсчитывает ссылки на себя и вообще всячески живёт своей беспорядочной жизнью в своих одельных файликах.
Первый напрямую нельзя использовать в широко распространённых библиотеках подключения на Delphi, так как ему нужен немного другой тип переменной при обращении к нему в коде (это я уже сам выяснил, все на это забивают и включают галочку).
Эта галочка как раз и приводит к тому, что поле в БД как bytea, а на клиента прилетает как lo (драйвер ODBC химичит). При этом не производится конвертации значения, просто тип подменяется (а вот производится ли конвертация при залетании в БД типа lo в поле bytea - сказать сложно).
ОДНАКО. Эта галочка и подмена bytea->lo не работают, если в БД нет типа lo (если включить галочку и удалить lo - при работе с pg будут ошибки). И по умолчанию его нет. Чтобы он появился - и был написан скрипт по созданию типа lo и функций для доступа к нему.
Сейчас lo не нужно, так как поле bytea и работать мы с ним научились как с bytea, так что и галочку надо снять, и lo от греха подальше удалить. Если lo не удалить - можно будет работать и с включённой галочкой. НО при этом возникает вероятность создать что-нибудь типа lo (не обязательно из саса, а вообще). |
|
|
|
|
Итак, сделал доработку 1124 - и закрываем этот пункт тоже.
Приаттачен файлик TileStorage_DBMS_ODBC_1.0.0.11.rar - там только DLL. |
|
|
|
(0010188)
|
|
Tolik
|
|
13-12-2012 07:12
|
|
|
Вот только ночнушек уж 2 недели нет :(, где взять exe? |
|
|
|
(0010189)
|
|
vasketsov
|
13-12-2012 12:02
(edited on: 13-12-2012 12:05) |
|
|
|
|
(0010196)
|
|
vasketsov
|
14-12-2012 20:57
(edited on: 14-12-2012 20:58) |
|
Последнее микрообновление в рамках этой темы.
Реализована возможность по ПКМ в подменю "Версия" (aka Version) создать новую версию по описанию метки, а также переключиться на неё - два новых подпунктика (Make и Select). Под Make понимается в том числе обновление существующей, а не обязательно создание новой. Дату там подправить или описание....
Работает _по_умолчанию_ только для меток, созданных из формы поиска снимков для сервиса DG (так как по ним можно генерить версии для нокии, декарты и т.п.). Для бинга и гугла процедура бессмысленна, так как версии там числовые. Для яндекса очевидно тоже.
Хотя в принципе попытаться создать/изменить версию можно для любой метки/версии/сервиса (лишь бы он был в СУБД), так как по ходу выполнения этой процедуры значения можно подправить руками. Единственное техническое ограничение - недопустима (случайная или нет) правка пустой версии, созданной по умолчанию.
Приаттачены свеженькие билды (2012_12_15).
|
|
|
|
|
Ещё добавлю по поводу реализации хранилища не в DLL, а сразу в EXE.
Сейчас оно весит 450k (и так путём немыслимых кастраций mODBC), но там ещё нет трёх больших планируемых доработок.
Ну пусть будет 500-550k. Из них примерно 70k приходится на рантайм (Classes и т.п.). Ещё наверное 150-200k можно сэкономить, если реализовать работу с ODBC руками (не через пописанный mODBC). Итого - если вырезать всё ненужное и залить напрямую в сас только реализацию через ODBC - думаю что прибавится 250k примерно. Оценка конечно очень грубая. Ну и минус шлюз (stdcall+callback между EXE и DLL) конечно.
А теперь мысленно представим себе, что ещё и метки в СУБД надо уронить. Оно конечно интерфейс поменьше будет, логики никакой, но всё равно отдельная либа потянет кил на 300 минимум. А если всю работу с ODBC (хранилище+метки) сделать в сасе - практически гарантировано уложимся в 400k прибавки.
Итого - практически ощутимо выгоднее при реализации хранения меток в СУБД сливать работу с ODBC прямо в EXE. Потому что если этого не сделать - обе либы (или одна с общим интерфейсом) будут кил под 800 весить.
Для сравнения по размерам: если вырезать EmbeddedWB - это минус 200k, если внутренний прокси как DLL - она сейчас 105k, если она в сасе напрямую будет - наверное прибавка 30-40k будет (вместе с интерфейсом для мозиллы в комплекте). То есть 400k всё же приличный довесок. |
|
|
|
(0010255)
|
|
vasketsov
|
29-12-2012 19:56
(edited on: 29-12-2012 22:05) |
|
Важное обновление - вырезано всё лишнее, оставлено только ODBC, причём руками (без mODBC), без датасетов, всё на стеке (ну кроме буферов под ad-hoc данные и имена полей), в теории - максимально быстро и компактно (на практике конечно могут быть баги, хотя вроде бы я всё полностью проверил). После вырезания размер DLL падал до 202k, что даже меньше прогноза.
Поправлен скрипт для informix (он был один такой дурацкий, с нестандартными символами квотирования идентификаторов, сейчас это побеждено, и стало всё красиво). Других изменений нет. Архив с актуальными скриптами заменён (файл ALL_DBMS_SCRIPTS.rar).
Реализован интерфейс итератора тайлов для работы менеджера кэша. Начиная со вчерашней версии ночнушки в совокупности с DLL версии от 1.0.1.0 - должно работать как в качестве источника, так и в качестве целевого кэша.
Реализована возможность шардинга (ну или секционирования между серверами). Если кому будет интересно - подробности настройки с примерами есть в репозитории (файл sasgis\TSS.txt). Сюда его не прикладываю, чтобы не травмировать нежную психику начинающих базовладельцев.
Новую тему (в смысле, хотелку) создавать не стал, всё равно ещё релиз не выпущен, если честно не думал что успею до НГ доделать.
После двух этих доработок размер DLL отрос до 217k. С реализацией меток в СУБД размер вырастет копеечно, а при переносе в сас (без DLL останется вообще наверное 150k).
Планируются ещё 2 микрообновления (после каникул, на каникулах только баги):
1. Выполнение INSERT+UPDATE для тайла за одну операцию (в смысле UPSERT aka MERGE или другие аналогичные извращения) на тех СУБД (и начиная с тех версий), где это поддерживается. Должно привести к уменьшению I/O и упрощению логики записи тайла в БД.
2. Добавка TOP 1 (или аналога) в SELECT тайлов, чтобы при наличии нескольких версий одного тайла остальное не подымалось (в смысле IMAGE) даже в кэш. Опять же если поддерживается СУБД.
Праттачен архив TileStorage_DBMS_1.0.1.0.rar. Он и объявляется Maintenance Release )). Ну и всех с наступающим, всем хорошего настроения, и не болеть, только если за наших хоккеистов.
зы. Ещё заменил имя INI-шки. Теперь INI-шка должна лежать прямо рядом с DLL и иметь то же имя - то есть она должна зваться TileStorage_DBMS.ini.
|
|
|
|
|
Обновил TileStorage_DBMS.dll до версии 1.0.1.1.
Изменения:
1. Добавлен TOP 1 или FIRST 1 или LIMIT 1 (в зависимости от СУБД) при селекте одиночного тайла. Будет чуть быстрее тащить тайлы из БД.
2. Добавлена обработка ситуации, когда прилетает пустой тайл (NIL) не как TNE. Важно при миграции кэша, чтобы не выискивать и не удалять такой мусор специально.
Качать тут:
https://bitbucket.org/vasketsov/tilestorage_dbms/downloads |
|
|
|
|
Обновил TileStorage_DBMS.dll до версии 1.0.1.3.
Изменения:
1. Устранена старая ошибка, которая могла возникать при получении списка версий для тайла.
2. Реализован учёт признака показа предыдущих версий с хоста (ShowPrevVersion). Включение перекрывает настройку хранилища. Отключение приводит к тому, что используются настройки хранилища. С предыдущими версиями EXE работать будет как будто признак ShowPrevVersion отключен.
Качать тут:
https://bitbucket.org/vasketsov/tilestorage_dbms/downloads |
|
|
|
(0011193)
|
|
vasketsov
|
23-04-2013 14:34
(edited on: 23-04-2013 14:37) |
|
Обновил TileStorage_DBMS.dll до версии 1.0.1.5.
Изменение одно, но серьёзное:
1. Реализован пул Statement-ов, для каждого подключения свой. Если драйвер ODBC сам использует пул Statement-ов, ничего принципиально не изменится (и в принципе можно не обновляться). Если драйвер ODBC сам НЕ использует пул Statement-ов, то будет небольшое ускорение работы. Поскольку некоторые драйвера ODBC не поддерживают режим MARS и вообще написаны криворукими сантехниками, в случае неотображения тайлов (как будто подключение зависло, но сам сас работает) для таких СУБД необходимо будет в ini-шке для подключения указать $SYNC_SQL_MODE=1. Если зависаний не будет - можно оставить и $SYNC_SQL_MODE=0.
Качать тут:
https://bitbucket.org/vasketsov/tilestorage_dbms/downloads
|
|
pgsql_odbc_1.jpg (22,224) 20-11-2012 13:57
DBMS.ZIP (2,715) 06-12-2012 09:22