0001611: Добавить условное сжатие на бинарный контент в кэше

Notes
(0009301) zed (manager) 08-10-2012 14:26	По-моему, в API Беркли БД была какая-то встроенная опция, которая разрешает автоматическое сжатие всех данных, но как-то я её поостерёгся включать. Да и как быть с уже накопленным кэшем?

(0009302) vdemidov (manager) 08-10-2012 14:31	Не. Эту штуку если и включать, то только отдельным типом кэша.

(0009311) Tolik (reporter) 08-10-2012 16:04	Каждый тайл сжимать? Тогда получится не экономия, а только потеря! Сжал для проверки тайл гугл мапса размером 18391 байт, получилось 18427.

(0009314) Parasite (administrator) 08-10-2012 16:16 edited on: 08-10-2012 16:22	>автоматическое сжатие всех данных А я не про все, а про блобы. Индексы, координаты и проч-сжимать не надо (от этого будет вред). >Сжал для проверки тайл гугл мапса размером 18391 байт, получилось 18427. А теперь сожми _массив_ гибрида в зип. z12: было 3++Гб, стало 960Mb >как быть с уже накопленным кэшем? Можно проверять ряд "Compressed" (который и ввести в новом кэше). Если не найдео - значит без компрессии, если найдено и равно единице - то гзип, если двойке - то lz2, итд......классическая обратная совместимость.

(0009319) Tolik (reporter) 08-10-2012 16:30	Вы не поверите. Взял кусок гугло-мапс кэша в 64.9 МБ (без учёта кластеров, конечно), сжал в зип с макс. компрессией - получилось 65.8 МБ. Так что смысла сжимать картинки (в базе данных) нет никакого.

(0009321) Parasite (administrator) 08-10-2012 16:40 edited on: 08-10-2012 16:42	>Так что смысла сжимать картинки Про жпег было сказано в начале тикета - и это всего лишь частный вариант юзания кэша. Выше я просил пожать массив _гибрида_, если что. Опять же, Ваш жпег нигде не назван по параметрам - практически любой жпег, утоптанный в зип - будет занимать МЕНЬШЕ оригинального жпега хотя бы из-за компрессии жпег-заголовка, помноженного на число тайлов. И да, гзип - это не зип, это еще меньше.

(0009322) Tolik (reporter) 08-10-2012 16:42	Я сжимал именно png. Твой кэш 3++Гб - это сумма размеров файлов или размер на диске?

(0009323) Parasite (administrator) 08-10-2012 16:46 edited on: 08-10-2012 16:49	>это сумма размеров файлов или размер на диске? Мне сегодня лениво доказывать очевидное, пардон. Аттач. Хоть и в RAR под руку попалось - да не суть важно, смысл в том же. Это как раз вполне конкретный гуглогибрид, лежащий на раздаче на торренте. И нет, это еще ДО потерьь на кластеризацию\фрагментацию ФС - это таки голые размеры RAW-контента по отношению к утоптанному.

(0009324) Tolik (reporter) 08-10-2012 16:50	64 файла - 3 ГБ - так ты файлы Беркли сжимаешь (а не тайлы) - это меняет дело!

(0009325) Parasite (administrator) 08-10-2012 16:54	>файлы Беркли сжимаешь (а не тайлы) - это меняет дело! 1. Тикет был как раз про беркли. 2. Сжатие голых тайлов - еще больше, ибо ужмет еще и пути\названия. PS: тайлы я жму чуть менее чем ежедневно. Насмотрелся.

(0009326) Parasite (administrator) 08-10-2012 17:18 edited on: 08-10-2012 17:21	>Взял кусок гугло-мапс кэша в 64.9 МБ (без учёта кластеров, конечно), сжал в зип с макс. компрессией - получилось 65.8 МБ. Так что смысла сжимать картинки (в базе данных) нет никакого. Таки не поленился и сжал в ЗИП на примере z11 того же беркли того же гуглогибрида. Аттач2, -50% за пару кликов. Don't even think to beat that, и в этом и есть запрашиваемый сабж введения компрессии в беркли. А глубже будет еще лучше - там пустых однотипных тайлов больше. :) PS: и это еще с информацией о восстановлении - +10% к архиву в моем случае, если склероз не изменяет.

(0009331) vdemidov (manager) 08-10-2012 19:11	Не путай сжатие кучи файлов в один и сжатие каждого файла по отдельности. Более того не путай сжатие файла базы со сжатием блобов внутри базы.

(0009335) Parasite (administrator) 09-10-2012 01:26	>Не путай сжатие кучи файлов в один и сжатие каждого файла по отдельности. Разница минимальна (ну будет на доли процентов больше из-за необходимости хидера к каждому файлу. Сжатие боди будет тем же самым, подозреваю - до байта, а гзип как таковой можно вообще без хидеров юзать - как поток). >Более того не путай сжатие файла базы со сжатием блобов внутри базы. Блобы внутри базы - как раз просятся тут. Сжатие базы (чуть менее чем полностью состоящей из блобов по своему размеру) было приведено просто для примера степени выигрыша места, коль скоро механизма продемонстрировать сжатие только блобов пока что нет. Он и просится, повторяю. Ты же не хочешь мне сказать, что 2\3 размера базы беркли из примера выше занималось НЕ блобами - кое столь хорошо и пожалось? :) PS: а на гифовых тайлах сжатие будет еще больше - они изначально несжаты...

(0009340) zed (manager) 09-10-2012 04:42	Сжатие сделать можно, только, конечно, не безусловное, а по галочке в настройках карты. И такая опция будет полезна не только для Беркли, но и например, для разрабатываемого сейчас vasketsov'ым СУБД и в теории для любого будущего файлового кэша. Причём, опцию следует воспринимать как: "Сожми, если умеешь". Не знаю, удастся ли это прикрутить к Беркли ввиду необходимости поддержания старого формата, но подумать можно.

(0009341) Dima2000 (reporter) 09-10-2012 04:47	>PS: а на гифовых тайлах сжатие будет еще больше - они изначально несжаты... Вот тут вы чуток неправы, gif-ы внутри тоже сжаты, алгоритмом lzw. Из gif,jpg,png,bmp без сжатия разве что bmp, да и то, того, не всегда, там rle вполне может быть ...

(0009342) Tolik (reporter) 09-10-2012 05:04	> Таки не поленился и сжал в ЗИП на примере z11 того же беркли того же гуглогибрида. Это опять-таки сжатие больших файлов базы данных, внутри которых куча одинаковых пустышек или почти пустышек (прозрачных квадратов с несколькими буквами). А я всё толкую про то, что сжимать каждый тайл перед сохранением в беркли-кэш (как написано в техзадании) не имеет смысла, т.к. каждый файл только увеличивается за счёт разных хедеров, а сама картинка уже сжата. А вот насчёт блобов ничего не могу сказать.

(0009345) zed (manager) 09-10-2012 05:22	Кстати да, проверил сейчас на случайно-взятом тайле гугло-гибрида (png). Тайл архиватором (zip) не сжимается, а наоборот, увеличивается в размерах. Т.е. и на "той стороне" интернета сидят не дураки (в большинстве) и используют возможности форматов для уменьшения размеров тайлов.

(0009350) Parasite (administrator) 09-10-2012 05:40	>Сжатие сделать можно, только, конечно, не безусловное, а по галочке в настройках карты. А зачем? Имхо, тонкости хранения в базе - уже сугубо системная фишка и 99% хомяков будет непонятна. Мы же у них сейчас не спрашиваем, в каком виде и в каких полях с какими именами беркли хранит. Оно просто хранит так, как умеет - и подавляющему большинству хомяков там делать просто делать нечего. >Причём, опцию следует воспринимать как: "Сожми, если умеешь". Я бы все же понастаивал на безусловной операции - и эту безусловность возложил бы на сам "движок кэша" в процессе прикручивания к сасу. В смысле, "если технически можно этот тип кэша прикрутить к САСу с компрессией - так с ней и прикручивать". Вот тайловый например - нельзя, а базоводный - на ура, вот так жестко и прикодить. Эхх....плагинный подход тут бы весьма органично вписался б... >Вот тут вы чуток неправы, gif-ы внутри тоже сжаты, алгоритмом lzw. Я к тому, что после такого "сжатия" можно совершенно безболезненно гзипнуть еще наполовину как минимум. Так-то сжатие конечно присутствует - та же индексация цвета есть тоже своего рода "сжатие" исходного изображения...только таблица индексов с индексацией цвета гзипуется на 80-90%. :) В этом смысле я и говорил про отличие от png (который уже погзипован внутри себя - но и там выигрыш будет, если топтать еще и блобы). Вот каноничная GIF-картинка из википедии про GIF-формат, та самая с красным шариком на белом фоне - изначально 26++Кб, а в тупеньком зипе - уже 15Кб. Выигрыщ почти 50%, что и требовалось доказать и что косвенно подтверждается скринами в шапке. >каждый файл только увеличивается за счёт разных хедеров, Хидер у гзипа один, и его размер - 10 байт. >а сама картинка уже сжата. В массе тайлов кэша - сжатый всегда весит меньше, чем несжатый. >внутри которых куча одинаковых пустышек или почти пустышек И что с того? Это уже не кэш, что ли? Ну пожмутся более информационнонаполненные похуже, а более пустые - получше -> в общем и целом размер ВСЕГО кэша будет уменьшен без потерь в качестве. В этом смысле сжатие кэша всего мира (а не избранной области с исключительно высокой наполненностью, типа единственного тайла космоснимка в ЖПЕГе - по наполненности стремящегося к белому шуму) как раз и показательно. В крайнем случае (в ОЧЕНЬ крайнем! И даже исключительном - лично я не знаю ни одной карты со 100% заполненностью белым шумом попиксельно 100% тайлов) размер сжатого кэша будет равен размеру несжатого, либо же будет больше на (10 байт хидера GZIP * число тайлов). 10 байт по отношению к среднестатистическому размеру тайла 10Кб - это 0.1% прибавки к размеру всего кэша - ЕСЛИ, повторяю, 100% тайлов будут заполнены попиксельным белым шумом 100% своего объема. Сжатие первого же попавшегося пустого тайла снивелирует собой хидеры тысячи таких 100%-заполненных, другими словами. Но таких карт все равно нет и не будет, соответственно - практически везде будет процент сжатия, стремящийся к 100% в зависимости от контента. Что и требовалось доказать. :) PS: а гзип можно и вообще без хидеров юзать, повторюсь. Еще -10 байт с каждого утоптанного тайла до кучи к уже полученному сжатию.

(0009355) zed (manager) 09-10-2012 06:02	>>а сама картинка уже сжата. >В массе тайлов кэша - сжатый всегда весит меньше, чем несжатый. Докажи. Сожми каждый тайл в отдельный архив и сравни занимаемое место с пачкой несжатых тайлов.

(0009356) Tolik (reporter) 09-10-2012 06:12 edited on: 09-10-2012 06:14	Да даже закинуть директорию с тайлами в зип - размер получается больше (без учёта потерь на кластеры), т.к. зип пакует каждый по отдельности. Если в tgz - чуть лучше, т.к. компрессируется уже tar целиком, но в самом таре куча лишней информации. Rar, конечно, эффективнее. Поэтому, повторюсь, выигрыш может быть только при сжатии файлов sdb или, возможно, блобов (понятия не имею, можно ли их сжимать и что получится).

(0009357) zed (manager) 09-10-2012 06:17	>Да даже закинуть директорию с тайлами в зип - размер получается больше C png? У меня получается сжатие 10%. Если скопом. Блоб - это тайл + совсем чуть-чуть служебной информации (не более 100 байт), т.е. можно смело говорить, что блоб = тайл.

(0009358) Parasite (administrator) 09-10-2012 06:20	>на "той стороне" интернета сидят не дураки Тогда отсюда два вопроса: 1. Чем вызвано ОТЛИЧНОЕ сжатие беркли-кэша именно с гуглогибридом в шапке, и соответственно - чем заняты 2\3...1\2 базы того беркли? 2. Что мы с этой пухлостью будем делать? PS: карты, где PNG уже утоптан с макс.сжатием - это частность. Дефолтово он утоптан с 60%, оно же -6 (если склероз не изменяет). И таки да, даже те максимально-сжатые PNG дают какую-то экономию при гзиповке сверху - просто юзайте нормальные пакеры. В шапке: 1. Максимально заполненный и максимально сжатый PNG от HillShade, который нашел: 101 509 байт. 2. Он же после расово верного правильного гзипа (безо всяких ваших ВинЗипов и прочего): 101 183 байт. 3. Экономия: 326 байт\тайл. Всего-то миллион таких тайлов, какой-то 11й уровень - триста мегов экономии "за просто так". 4. Максимально заполненный и максимально сжатый PNG от Yandex, который нашел: 32 981 байт. 5. Он же после гзипа: 32 975 байт. 6. Экономия: 7 байт\тайл. Миллион таких тайлов - 7 мегов экономии. 7. Максимально заполненный GIF от StreetDirectory, который нашел: 44 598 байт. 8. Он же после гзипа: 44 067 байт. 9. Экономия: 531 байт\тайл. Миллион таких тайлов - 531 мег экономии. 10. Максимально заполненный JPG от GoogleSat, который нашел: 19 999 байт. 11. Он же после гзипа: 19 881 байт. 12. Экономия: 118 байт\тайл. Миллион таких тайлов - 118 мег экономии. Это, повторяю - тайлы с максимально найденной заполненностью. Пустышки должны пожаться много лучше.

(0009359) Parasite (administrator) 09-10-2012 06:25	>Сожми каждый тайл в отдельный архив Легко. В шапке. >Да даже закинуть директорию с тайлами в зип - размер получается больше Выкинь свой зип, что еще могу сказать. Кстати, WinZip != GZIP. Первый пихает всякую ненужную дополнительную хрень.

(0009360) zed (manager) 09-10-2012 06:33	>Всего-то миллион таких тайлов, какой-то 11й уровень - триста мегов экономии "за просто так". При кэше в 100Гб, экономия в 300Мб это просто смех. Не находишь? А теперь представь сколько это мороки, прикодить сжатие тайлов и поддерживать 2 версии кэша Беркли. И это ради экономии менее 1% на винте? Да ну нафиг!

(0009361) vdemidov (manager) 09-10-2012 06:35	Итого для PNG от HillShade 0,3% экономия места и ХЗ сколько потеря процессора. для PNG от Yandex 0,02% экономия места и ХЗ сколько потеря процессора. для GIF от StreetDirectory 1.2% экономия места и ХЗ сколько потеря процессора. для JPG от GoogleSat 0,6% экономия места и ХЗ сколько потеря процессора. ИМХО нафиг никому не нужно.

(0009362) zed (manager) 09-10-2012 06:36	>Пустышки должны пожаться много лучше. Не факт. Потому и просил пожать папку с тайлами и каждый тайл положить в отдельный архив. Чтобы был более-менее средний показатель сжатия.

(0009363) vdemidov (manager) 09-10-2012 06:36	Единственный вариант, где потайловое сжатие имело бы смысл это kml. Но его уже сейчам можно использовать зазипованным в виде kmz.

(0009366) Tolik (reporter) 09-10-2012 06:47	> Выкинь свой зип, что еще могу сказать. Кстати да, разные архивваторы дают разный результат. Я пользую встроенный в total commander и им же смотрю общий объём (показывает, если нажать пробел на директории) Однако Yandex.png.gz у меня получился на 1 байт меньше :) Все провверять не стал, лень.

(0009369) Parasite (administrator) 09-10-2012 07:15 edited on: 09-10-2012 07:20	>При кэше в 100Гб, экономия в 300Мб это просто смех. Не находишь? Не нахожу. Я не сказал "при кэше в 100гиг" - я сказал "миллион тайлов, какой-то 11й уровень". 11й уровень гуглогибрида у меня занимает 980 мегов в беркли, скрин - в шапке еще со вчера. Если оно станет занимать еще на 300 мегов меньше - это будет гуд. При просто тупой архивации беркли - оно занимает меньше на пятьсот, но нужна доп.архивация (долгая и нудная операция, после которой кэш напрямую не поюзать - нужна разархивация). >А теперь представь сколько это мороки, прикодить сжатие тайлов В скрипте - это одна строчка вызова пакера (стороннего или модулем - не суть важно) перед покладанием в беркли, и одна строчка - при взятии оттуда. Итого, Вi не поверите - две. В дельфи - не знаю. >Потому и просил пожать папку с тайлами А зачем ты у меня это просил? У тебя разве нет папки с тайлами, чтобы сплясать как душе угодно на своей стороне? Или ты думаешь что при отмеченном сжатии любого произвольно взятого тайла, помноженному на условно миллион таких же - вся папка в итоге каким-то фантастическим образом распухнет? А 2 вопроса о пухлом беркли остались без ответа тем временем. >нафиг никому не нужно. Отучаемся говорить за всех. Нужно как минимум тикетстартеру - архивирующему много, хорошо, ежедневно и нудно. Если кэш будет "ужиматься сам", при этом оставаясь юзабельным как кэш - то это сильно упростит и хранение, и манипуляции с оным, и в итоге материальное положение вопрошающего (ибо занятое место на купленных на свои деньги винтах он считать умеет очень хорошо. До +\- мегабайта, да.). :) Еще раз: весь тикет будет иметь смысл при БОЛЬШИХ кэшах (разных регионов и разной наполненности соответственно). На десятке-другом тайлов эффект будет единично-байтовым, ага. Ну дак и не про них разговор. PS: в мобильных мап-приложениях с сервера весь контент идет в gzipped-контейнерах. Зри в корень: что, в гугле идиоты сидят - и не умеют считать единицы байт трафика (в данном случае), или не могут себе его позволить? Один байт экономии, помноженный на миллион юзеров и на миллион запросов -> PROFIT. О чем тут и просится применительно к винтам и тем же миллионным кэшам\байтам. :)

(0009370) Parasite (administrator) 09-10-2012 07:19	>в API Беркли БД была какая-то встроенная опция, которая разрешает автоматическое сжатие всех данных, но как-то я её поостерёгся включать. Кстати, а почему?

(0009398) zed (manager) 09-10-2012 11:42 edited on: 09-10-2012 11:53	>11й уровень гуглогибрида у меня занимает 980 мегов в беркли Ну так и экономия будет 3Мб. >У тебя разве нет папки с тайлами, чтобы сплясать как душе угодно на своей стороне? Миллиона тайлов нету, к тому же, это всё время, а вопрошающий здесь ты. И я не думаю, что распухнет, я думаю, что будет экономия в 1% или меньше. И пока ты меня не убедишь, что будет экономия хотя бы процентов в 10% (с миллиона тайлов), я с места не двинусь :) Так что цифры в студию, и хотелось бы увидеть сравнительный анализ нескольких архиваторов (gzip, zip, 7zip) при сжатии нескольких типов данных из нескольких карт. Разговор должен быть предметным и основанным на цифрах, а не на должно быть и я думаю. >А 2 вопроса о пухлом беркли остались без ответа тем временем. А на что там отвечать? Тебе не понятно, почему куча почти одинаковых файлов прекрасно ужимается в один архив? Так то ж очевидно! А разговор о сжатии каждого в отдельности и экономии на каждом на доли процента. >>в API Беркли БД >Кстати, а почему? Вчера освежил память: дефолтное сжатие у них там работает только для ключей и для дублирующихся значение для одного ключа. Чтобы сжимать всё остальное, можно указывать свои функции компрессии/декомпрессии, но это порн и проще сжимать данные независимо от API (что, там кстати и рекомендовали). К тому же, в конце была приписка, что в файле БД сжатие должно включаться только в момент создания оного, а если файл был создан без сжатия, а потом мы вдруг откроем его с флагом сжатия, то оно всё упадёт с громким лязгом. Так что - не вариант.

(0009399) vdemidov (manager) 09-10-2012 12:15	> И пока ты меня не убедишь, что будет экономия хотя бы процентов в 10% (с миллиона тайлов), я с места не двинусь :) Сто процентов согласен. Причем для экспериментов нужно сжимать не всю папку в один архивный файл, а каждый тайлик в отдельный архив. И сравнивать суммарный размер. Пока же ожидаемая польза меньше 1%

(0009400) zed (manager) 09-10-2012 12:18	>а каждый тайлик в отдельный архив Об этом и разговор.

(0009401) vasketsov (manager) 09-10-2012 12:22	>ожидаемая польза меньше 1% И она скорее всего будет сильно нивелирована внутренним форматом БД, всякими выравниваниями и т.п. Нет такого закона, что если в БД проапдейтили блоб в 19 999 байт блобом в 19 881, то размер всей БД уменьшился на 118 байт.

(0009402) zed (manager) 09-10-2012 12:28	Да, в Беркли ж ещё используется страница в 1k, так что и там, есть свободные хвосты, как в файловой системе.

(0009409) Tolik (reporter) 09-10-2012 13:59	> и там, есть свободные хвосты А я-то думал... :( Это тоже объясняет, почему рар его хорошо жмёт.

(0009422) Parasite (administrator) 09-10-2012 15:24	>>11й уровень гуглогибрида у меня занимает 980 мегов в беркли >Ну так и экономия будет 3Мб. 326 байт х миллион тайлов = 3Мб? Ммда...и эти люди делают нам САС. :) >Разговор должен быть предметным и основанным на цифрах Цифры в шапке, целых 4 варианта. По всем 4м видно наличие сжатия разной степени тяжести, а не распухания - что и требовалось доказать. Что изменится от помноженья на миллион, кроме написания сюда конкретной цифирки которая никому не нужна в этой ее точной точности и о которой все забудут ровно через секунду после ее просмотра - я даже и не знаю, пардон. Ну или подождать, пока я сподоблюсь на написание скрипта, перебирающего тайлы и пакующего каждый отдельно - бо в штатном этого нет, а мне такой изврат до сих пор не был нужен и готового посему тоже нет. :) >Тебе не понятно, почему куча почти одинаковых файлов прекрасно ужимается в один архив? Мне непонятно, почему столь большая разница на ОДНОМ И ТОМ ЖЕ наборе данных, но сперва голых а потом в БД. Либо БД распухает на целых 2\3 от размера контента, на которые потом и ужимается архиватором практически в ноль (и распухание вне зависимости от контента - нам не нужно, и с этим наверное можно\нужно чего-то сделать), либо см.1. И если база ТАК распухает, и с этим ничего сделать нельзя - то сабжевый тикет тут есть экономия на спичках. О чем к тебе вопросы и были. >в Беркли ж ещё используется страница в 1k, так что и там, есть свободные хвосты Ууу.........Вот в этом все и дело скорее всего. :(((( Особенно учитывая то что в гибриде - куча пустышек, а они - по 191 байту если память не изменяет... Компенсировать 800 байт хвоста на каждый такой тайл сжатием не получится даже в теории. :(((( Может поменьше дефолтную страницу сделать? 256 байт например. Реально?

(0009423) zed (manager) 09-10-2012 16:02	>326 байт х миллион тайлов = 3Мб? Ммда...и эти люди делают нам САС. :) Мля, нет слов. Если ты берёшь экономию 326 байт, то и считай, что тайлы у тебя по 100k. Умножь и то и то на миллион и получишь, что кэш 100Гб, а экономия 300М. Абсурд. >По всем 4м видно наличие сжатия разной степени тяжести, а не распухания - что и требовалось доказать. Я тебя не просил доказать распухание. Докажи мне реальную экономию, а не 0,3% что следует из твоих примеров в шапке. Ты говоришь, что у тебя на 11 зуме 900Мб, ну так и получишь экономию в 0,3% от них (в лучшем случае), а не 30, на которые ты прицелился. >Может поменьше дефолтную страницу сделать? 256 байт например. Реально? Нет. Минимум 512, но когда я тестировал это дело и выбирал размер страницы, этот минимум работал медленнее чем 1k. Если память не изменяет. Страницы более 1k в какой-то момент, по-моему, тоже начинали работать медленнее, но и пухли заметно сильнее. Между 1k, 4k и 8k заметных изменений в производительности замечено небыло.

(0009426) Parasite (administrator) 09-10-2012 16:29	>то и считай, что тайлы у тебя по 100k А, блин. Там же HillShade был с его огроменными тайлами...Признаю, был неправ. :( >Докажи мне реальную экономию Так если она сжирается хвостами в базе данных, которые больше экономии - то и доказывать нечего, экономь не экономь - хвосты будут. Знать бы ранее, что оно так же "кластеризировано" как и ФС - и всего тикета не было б. Я с беркли не работал, и первый раз ее увидел как раз в САСе. А что там даже в САСовом унутри - не знаю до сих пор. Эхх...Можно закрывать.

(0012043) vasketsov (manager) 11-07-2013 13:33	>Но его уже сейчам можно использовать зазипованным в виде kmz Виктор, поясни пожалуйста, если для вики поставить в zmp формат kmz, тайлы автоматом будут падать в хранилище зазипованными? И единственный косяк - это неверная работа проверка размера тайла при закачке и при удалении (будет браться размер kmz)? Я столкнулся как раз с желанием загзипить все викитайлы в хранилище. >опцию следует воспринимать как: "Сожми, если умеешь". В общем то да, включено - сжимаем при записи, если размер увеличился - сохраняем оригинал, а при чтении пробуем разжать, не получилось - возвращаем оригинал. На тайлах типа kml должен быть прирост производительности из-за уменьшения IO, на тайлах типа jpg включивший ССЗБ.

(0012045) vdemidov (manager) 11-07-2013 14:06	>Виктор, поясни пожалуйста, если для вики поставить в zmp формат kmz, тайлы автоматом будут падать в хранилище зазипованными? И единственный косяк - это неверная работа проверка размера тайла при закачке и при удалении (будет браться размер kmz)? Да, все именно так.

(0012046) vasketsov (manager) 11-07-2013 14:15	Соответственно в таком случае 7zip там или KaZip, но получается что тратится место на заголовок (чтобы doc.kml записать в zip и на диск упал честный zip),m а мне места жалко (((. Тогда выходит что ради экономии заголовков имеет смысл гзиповать вручную внутри хранилища, и инфу отдавать честную о размере (для SQlite и СУБД есть поле размера тайла, для беркли не знаю, а для файлового кэша или забить, или распаковывать ради честного размера). Походу надо подумать, как покрасивше сделать, чтобы не дублировать код.

(0012048) vdemidov (manager) 11-07-2013 14:29	Ну на тайлах Викимапии даже с заголовком разница получается очень заметной 257801 байт kml и 32453 байт kmz например.

(0012050) vasketsov (manager) 11-07-2013 14:44	>даже с заголовком разница получается очень заметной Ага. Но мне бы хотелось: а) ещё выиграть размерчику: я не считал сколько тайлов накопилось (кроме tne), но интуитивно понятно, что дофига их, и выигрыш будет ощутим, особенно в БД; б) чтобы размер тайла для программы был правильным. В общем-то вики - последняя карта, которая у меня не в БД (исключая тестовые, а также старые доверсионные vesat и google для истории), так что хотелось бы при переносе в неверсионную базу заодно и утоптать. Почему ещё размер важен: если KML от panoramio не меняется, скорее всего и фотки там не поменялись. То есть не только для вики, но размер имеет значение ))

(0012052) vdemidov (manager) 11-07-2013 14:53	Ну, почему бы и не сделать для некоторых хранилищ такую фитчу. Будет весьма полезно.

(0012060) vasketsov (manager) 11-07-2013 19:19 edited on: 11-07-2013 19:38	А gzip можно брать из ALZLibExGZ, или есть более быстрая реализация? Хм. Лучше наверное взять ZLib. А вот от гугла какая-то поделка http://www.linux.org.ru/news/opensource/6054950 Кстати http://zlib.net/ zlib 1.2.8 April 28, 2013 обновиться бы наверное стоило.

(0012063) vasketsov (manager) 11-07-2013 20:12	Потестил сжатие при миграции выделенной области из файлового кэша в неверсионный sqlite (алгоритм из ZLib): 1. Без gzip - 225 МБ (236 639 232 байт) 2. С gzip - 41.1 МБ (43 130 880 байт) Причём второе из-за впятеро меньшего IO ещё и сильно быстрее сохраняется )))

(0012128) vasketsov (manager) 19-07-2013 08:11	Погонял сравнительные тесты алгоритмов Zlib (который внутренний) vs ALZLibExGZ (который zlib1.dll). Подсовывал файлики типа XML разного размера (реальные kml или gpx). Одно сжание и много (10000) разжатий. Почему так - понятно, ибо ключевые параметры - это сжатый размер и скорость декомпрессии (для отображения из хранилища). Скорость сжатия некритична, ибо сжатие выполняется либо при скачке тайла, либо при копировании его из другого хранилища. Результаты: Original size = 5974 ZLib: Compressed size = 1567 Decompressing = 936 ALZLibExGZ: Compressed size = 1581 Decompressing = 624 ------------------------- Original size = 227079 ZLib: Compressed size = 86412 Decompressing = 37690 ALZLibExGZ: Compressed size = 86461 Decompressing = 25818 ------------------------- Original size = 1650131 ZLib: Compressed size = 482216 Decompressing = 264390 ALZLibExGZ: Compressed size = 483011 Decompressing = 179651 ------------------------- Original size = 780 ZLib: Compressed size = 337 Decompressing = 276.1 ALZLibExGZ: Compressed size = 349 Decompressing = 165.4 В последнем случае пришлось увеличить в 10 раз число прогонов, и потом поделить на 10. Итого - увеличение скорости в 1.45-1.67 раз может быть критичным. Походу надо будет предусмотреть AllowGZipTiles=2 для включения компрессии и декомпрессии ALZLibExGZ. Кстати, при декомпрессии, поскольку имеет смысл различать только их заголовки, можно будет сразу определять, чем распаковываться, так что по идее при декомпрессии падение скорости не прогнозируется. Может ещё чего потестить имеет смысл?

(0012131) zed (manager) 19-07-2013 09:20	>Zlib (который внутренний) vs ALZLibExGZ (который zlib1.dll) А по-моему оба используют прекомпилированные объектные файлы. Только у ALZLib они возможно по-свежее. >Может ещё чего потестить имеет смысл? Потести самую свежую zlib1.dll, скачанную с сайта производителя. И можешь ещё сравнить с 7z - интерфейс в ArchiveReadWrite лежит. Он по-моему zlib поддерживает, но я его в САС не прокидывал. Ради интереса можешь сравнить скорость и размеры самого 7z vs zlib.

(0012132) vasketsov (manager) 19-07-2013 10:49	>оба используют прекомпилированные объектные файлы Точно, ты прав, DLL не подцепляется. ZLib 1.0.4. ALZLibExGZ 1.2.7. Итого - тест разных версий реализаций для разных алгоритмов, а замена DLL ничего не даст ((( >Потести самую свежую zlib1.dll Как её подцепить? Качнул delphizlib.128.zip отсюда: http://www.base2ti.com/?id=delphi.zlib И теперь её надо в AL* как-то вкорячить? >сравнить с 7z - интерфейс в ArchiveReadWrite лежит У меня создалось ощущение, что он недопилен. По крайней мере внутри constructor TArchiveReadBy7Zip.Create( const AStream: TStream; const AArchiveType: TArchiveType ); из-за отсутствия FArch := CreateArchive(AArchiveType); доступ к FArch вызывает мгновенную смерть всем надеждам его поюзать.

(0012134) vasketsov (manager) 19-07-2013 12:24	Хм. Заодно обнаружил критичный баг: отсутствие распаковки тайлов при чтении из источника в менеджере кэша.

(0012138) zed (manager) 19-07-2013 16:32	>И теперь её надо в AL* как-то вкорячить? Нет, теперь надо взять заголовочник из исходников zlib и перевести его на паскаль. Не обязательно весь, а только необходимые функции и типы. За основу можно взять тот же встроенный Zlib. Ну, или в интернетах поискать - может уже кто делал такое. >У меня создалось ощущение, что он недопилен. Допилен и работает со всеми заявленными форматами. Либу брать из релизной версии 7z 9.20. >из-за отсутствия >FArch := CreateArchive(AArchiveType); Всё там есть.

(0012139) zed (manager) 19-07-2013 16:35	>из-за отсутствия >FArch := CreateArchive(AArchiveType); А, точно - в перегруженном конструкторе не хватает этой строчки. Надо добавить.

(0012149) vasketsov (manager) 19-07-2013 20:23	http://www.compression.ru/arctest/cctg/r-doc.htm Как раз почти наш случай (xml) 7zip 2.30b2 7z LZMAbt234 всех рвёт в клочья

(0012165) vasketsov (manager) 22-07-2013 13:57	Погонял немного 7z (LZMA) с разными растройками по слою wiki (как главному претенденту на сжатие, хотя panoramio сжимается ещё лучше))). Картина вырисовывается не очень приятная. Во-первых, при работе программы (то есть, при декомпрессии) наблюдатся заметно бОльшая нагрузка на CPU (по сравнению с gzip). Во-вторых, так и не удалось заставить 7z распаковывать быстрее zlib и gzip. Хотя выигрыш в размере архива 7z и значительный, хотелось бы как-нибудь обогнать хотя бы zlib.

(0012171) vasketsov (manager) 23-07-2013 10:05	По окончанию работ по добавлению тайлокомпрессии в TileStorage_DBMS.dll решил обновить номер версии DLL до 1.0.2.0. Брать традиционно тут: https://bitbucket.org/vasketsov/tilestorage_dbms/downloads Итого: Версия 1.0.1.6 - последняя, которая вообще без тайлокомпрессии. Версия 1.0.2.0 - с возможной тайлокомпрессией (поддерживаются три описанных выше метода). Ну и чтобы в одном месте всё было - итоговое описание: Тайлокомпрессия включается в zmp параметром TileCompressionMode. Возможные значения: 0 - Нет (по умолчанию) 1 - Deflate (через zlib, встроенная фукциональность) 2 - Gzip (встроенная фукциональность) 3 - Lzma (требует 7z) Соотношение между методами обычно такое (на тайлах wiki): Сила сжатия - 3 - 1 - 2 - Скорость распаковки. Причём между 1 и 2 разница по размеру небольшая, а вот 3 сжимает куда сильнее. Пример силы сжатия на тестовом тайле wiki z8 северо-восток Москвы: 0 - 1293424 1 - 364348 2 - 365042 3 - 245945 В качестве примера скорости распаковки - время (total по счётчикам производительности) вытаскивания тайлов из хранилища SQLite для всего экрана при включении слоя wiki на z8 с центром в Москве. Пример крайне субъективный, хотя бы даже потому что число тайлов на экране у всех разное и хранилища разные и диски разные и процы разные и ..., но в качестве относительной оценки времени декомпрессии вполне сойдёт. Минимально достигнутые значения: 1 - 0.67 2 - 0.52 3 - 0.87 Тайлокомпрессия поддерживается хранилищами в SQLite3 и в СУБД (при использовании указанной выше DLL). На этом тикет закрывается, всё прочее - отдельными доработками.

(0012172) vasketsov (manager) 23-07-2013 10:20	А вот так сжимается kml от panoramio: наугад взятый тайл panoramio (z14 юго-восточная часть Рубского озера в Ивановской области) размером 75018 алгоритм Lzma утоптал например аж до 2954 байт - то есть более чем в 25 раз.

(0012190) vasketsov (manager) 24-07-2013 22:52	>Сжал для проверки тайл гугл мапса размером 18391 байт, получилось 18427 А вот примерчики, как жмут тайлы 7z, LZ4 и Snappy: 1. bing jpg z18 (как известно, без exif) - 14.9 КБ (15 262 байт): 7z: 14.9 КБ (15 296 байт) - бессмысленно LZ4: 14.8 КБ (15 165 байт) - ??????? Snappy: 14.7 КБ (15 097 байт) - !!!!!!! 2. rosreestr png z8 - 31.4 КБ (32 187 байт) 7z: 31.8 КБ (32 649 байт) - бессмысленно LZ4: 31.5 КБ (32 310 байт) - бессмысленно Snappy: 31.4 КБ (32 193 байт) - !!!!!!! (+4 байта) 3. wiki z8 kml - 1.23 МБ (1 294 044 байт) 7z: 240 КБ (246 122 байт) - референсное сжатие LZ4: 468 КБ (479 862 байт) - возможно, терпимый размер, если нужна гигантская скорость Snappy: 618 КБ (632 983 байт) - фэйл

(0012238) vasketsov (manager) 26-07-2013 22:23	Ещё инфа для маньяков по поводу разных компрессоров. 1. LZHam https://code.google.com/p/lzham/ Запросто может оказаться существенно быстрее 7z/Lzma. Сыроват. 2. BALZ http://balz.sourceforge.net/ wiki z8 kml - 1.23 МБ (1 294 044 байт) сжал в 314 КБ (322 344 байт) bing jpg z18 - 14.9 КБ (15 262 байт) сжал в 15.3 КБ (15 707 байт) 3. LZPXJ http://sourceforge.net/projects/lzpx/ wiki z8 kml - 1.23 МБ (1 294 044 байт) сжал в 281 КБ (288 205 байт) - лучше только 7z bing jpg z18 - 14.9 КБ (15 262 байт) сжал в 14.7 КБ (15 075 байт) - новый чемпион, сжал даже сильнее Snappy. Итого потенциально для тайлов разного типа если и имеет смысл добавлять новые компрессоры, то: а) Snappy и LZPXJ (и сравнить реальную скорость на реальных тайлах); б) BALZ - только если будет гигантская скорость декомпрессии; в) LZHam - только после того как полноценно отрелизится, сравнить с 7z/Lzma; г) LZ4 - пока что неактуален.

Users who viewed this issue
User List	Anonymous (3682x), VadimK (1x)
Total Views	3683
Last View	20-04-2024 14:47

Issue History
Date Modified	Username	Field	Change
08-10-2012 14:11	Parasite	New Issue
08-10-2012 14:26	zed	Note Added: 0009301
08-10-2012 14:31	vdemidov	Note Added: 0009302
08-10-2012 16:04	Tolik	Note Added: 0009311
08-10-2012 16:16	Parasite	Note Added: 0009314
08-10-2012 16:19	Parasite	Note Edited: 0009314	View Revisions
08-10-2012 16:22	Parasite	Note Edited: 0009314	View Revisions
08-10-2012 16:30	Tolik	Note Added: 0009319
08-10-2012 16:40	Parasite	Note Added: 0009321
08-10-2012 16:42	Tolik	Note Added: 0009322
08-10-2012 16:42	Parasite	Note Edited: 0009321	View Revisions
08-10-2012 16:46	Parasite	Note Added: 0009323
08-10-2012 16:47	Parasite	File Added: Clipboard01.jpg
08-10-2012 16:48	Parasite	Note Edited: 0009323	View Revisions
08-10-2012 16:49	Parasite	Note Edited: 0009323	View Revisions
08-10-2012 16:50	Tolik	Note Added: 0009324
08-10-2012 16:54	Parasite	Note Added: 0009325
08-10-2012 17:18	Parasite	Note Added: 0009326
08-10-2012 17:19	Parasite	File Added: Clipboard02.jpg
08-10-2012 17:21	Parasite	Note Edited: 0009326	View Revisions
08-10-2012 19:11	vdemidov	Note Added: 0009331
09-10-2012 01:26	Parasite	Note Added: 0009335
09-10-2012 04:42	zed	Note Added: 0009340
09-10-2012 04:47	Dima2000	Note Added: 0009341
09-10-2012 05:04	Tolik	Note Added: 0009342
09-10-2012 05:22	zed	Note Added: 0009345
09-10-2012 05:40	Parasite	Note Added: 0009350
09-10-2012 06:02	zed	Note Added: 0009355
09-10-2012 06:12	Tolik	Note Added: 0009356
09-10-2012 06:13	Tolik	Note Edited: 0009356	View Revisions
09-10-2012 06:14	Tolik	Note Edited: 0009356	View Revisions
09-10-2012 06:17	zed	Note Added: 0009357
09-10-2012 06:20	Parasite	Note Added: 0009358
09-10-2012 06:20	Parasite	File Added: GoogleSat.jpg
09-10-2012 06:21	Parasite	File Added: GoogleSat.jpg.gz
09-10-2012 06:21	Parasite	File Added: Hillshade.png
09-10-2012 06:21	Parasite	File Added: HillShade.png.gz
09-10-2012 06:21	Parasite	File Added: StreetDirectory.gif
09-10-2012 06:22	Parasite	File Added: StreetDirectory.gif.gz
09-10-2012 06:22	Parasite	File Added: Yandex.png
09-10-2012 06:22	Parasite	File Added: Yandex.png.gz
09-10-2012 06:25	Parasite	Note Added: 0009359
09-10-2012 06:33	zed	Note Added: 0009360
09-10-2012 06:35	vdemidov	Note Added: 0009361
09-10-2012 06:36	zed	Note Added: 0009362
09-10-2012 06:36	vdemidov	Note Added: 0009363
09-10-2012 06:36	vdemidov	Status	new => resolved
09-10-2012 06:36	vdemidov	Resolution	open => won't fix
09-10-2012 06:36	vdemidov	Assigned To	=> vdemidov
09-10-2012 06:36	vdemidov	Status	resolved => closed
09-10-2012 06:47	Tolik	Note Added: 0009366
09-10-2012 07:15	Parasite	Note Added: 0009369
09-10-2012 07:16	Parasite	Note Edited: 0009369	View Revisions
09-10-2012 07:19	Parasite	Note Added: 0009370
09-10-2012 07:19	Parasite	Status	closed => feedback
09-10-2012 07:19	Parasite	Resolution	won't fix => reopened
09-10-2012 07:20	Parasite	Note Edited: 0009369	View Revisions
09-10-2012 11:42	zed	Note Added: 0009398
09-10-2012 11:53	zed	Note Edited: 0009398	View Revisions
09-10-2012 12:15	vdemidov	Note Added: 0009399
09-10-2012 12:18	zed	Note Added: 0009400
09-10-2012 12:22	vasketsov	Note Added: 0009401
09-10-2012 12:28	zed	Note Added: 0009402
09-10-2012 13:59	Tolik	Note Added: 0009409
09-10-2012 15:24	Parasite	Note Added: 0009422
09-10-2012 15:24	Parasite	Status	feedback => assigned
09-10-2012 16:02	zed	Note Added: 0009423
09-10-2012 16:29	Parasite	Note Added: 0009426
09-10-2012 16:35	zed	Assigned To	vdemidov =>
09-10-2012 16:35	zed	Status	assigned => closed
09-10-2012 16:35	zed	Resolution	reopened => won't fix
11-07-2013 13:33	vasketsov	Note Added: 0012043
11-07-2013 14:06	vdemidov	Note Added: 0012045
11-07-2013 14:15	vasketsov	Note Added: 0012046
11-07-2013 14:15	vasketsov	Assigned To	=> vasketsov
11-07-2013 14:15	vasketsov	Status	closed => confirmed
11-07-2013 14:16	vasketsov	Project	SAS.Планета => SACS.Планета
11-07-2013 14:17	vasketsov	Summary	Добавить безусловное сжатие на бинарный контент в Беркли-кэше => Добавить условное сжатие на бинарный контент в кэше
11-07-2013 14:17	vasketsov	Additional Information Updated	View Revisions
11-07-2013 14:29	vdemidov	Note Added: 0012048
11-07-2013 14:44	vasketsov	Note Added: 0012050
11-07-2013 14:53	vdemidov	Note Added: 0012052
11-07-2013 19:19	vasketsov	Note Added: 0012060
11-07-2013 19:25	vasketsov	Note Added: 0012062
11-07-2013 19:37	vasketsov	Note Edited: 0012060	View Revisions
11-07-2013 19:37	vasketsov	Note Deleted: 0012062
11-07-2013 19:38	vasketsov	Note Edited: 0012060	View Revisions
11-07-2013 20:12	vasketsov	Note Added: 0012063
11-07-2013 21:17	vasketsov	Note Added: 0012068
11-07-2013 21:18	vasketsov	Status	confirmed => resolved
11-07-2013 21:18	vasketsov	Fixed in Version	=> .Nightly
11-07-2013 21:18	vasketsov	Resolution	won't fix => fixed
19-07-2013 08:11	vasketsov	Note Added: 0012128
19-07-2013 09:20	zed	Note Added: 0012131
19-07-2013 10:49	vasketsov	Note Added: 0012132
19-07-2013 12:21	vasketsov	Status	resolved => assigned
19-07-2013 12:24	vasketsov	Note Added: 0012134
19-07-2013 16:32	zed	Note Added: 0012138
19-07-2013 16:35	zed	Note Added: 0012139
19-07-2013 18:58	vasketsov	Note Added: 0012148
19-07-2013 20:23	vasketsov	Note Added: 0012149
20-07-2013 08:31	vasketsov	Note Deleted: 0012068
20-07-2013 08:34	vasketsov	Note Added: 0012150
20-07-2013 22:04	vasketsov	Note Added: 0012152
22-07-2013 13:57	vasketsov	Note Added: 0012165
23-07-2013 10:05	vasketsov	Note Added: 0012171
23-07-2013 10:05	vasketsov	Note Deleted: 0012152
23-07-2013 10:05	vasketsov	Note Deleted: 0012150
23-07-2013 10:06	vasketsov	Note Deleted: 0012148
23-07-2013 10:08	vasketsov	Status	assigned => resolved
23-07-2013 10:20	vasketsov	Note Added: 0012172
24-07-2013 22:52	vasketsov	Note Added: 0012190
26-07-2013 22:23	vasketsov	Note Added: 0012238
09-08-2013 14:53	vasketsov	Product Version	.Nightly => 130803
09-08-2013 14:55	vasketsov	Product Version	130803 => .Nightly
09-08-2013 14:55	vasketsov	Fixed in Version	.Nightly => 130803
09-08-2013 14:55	vasketsov	Target Version	=> 130803
09-08-2013 15:13	vasketsov	Status	resolved => closed

Relationships

SASGIS