Notes |
|
(0009301)
|
zed
|
08-10-2012 14:26
|
|
По-моему, в API Беркли БД была какая-то встроенная опция, которая разрешает автоматическое сжатие всех данных, но как-то я её поостерёгся включать.
Да и как быть с уже накопленным кэшем? |
|
|
|
Не. Эту штуку если и включать, то только отдельным типом кэша. |
|
|
(0009311)
|
Tolik
|
08-10-2012 16:04
|
|
Каждый тайл сжимать? Тогда получится не экономия, а только потеря!
Сжал для проверки тайл гугл мапса размером 18391 байт, получилось 18427. |
|
|
(0009314)
|
Parasite
|
08-10-2012 16:16
(edited on: 08-10-2012 16:22) |
|
>автоматическое сжатие всех данных
А я не про все, а про блобы. Индексы, координаты и проч-сжимать не надо (от этого будет вред).
>Сжал для проверки тайл гугл мапса размером 18391 байт, получилось 18427.
А теперь сожми _массив_ гибрида в зип.
z12: было 3++Гб, стало 960Mb
>как быть с уже накопленным кэшем?
Можно проверять ряд "Compressed" (который и ввести в новом кэше). Если не найдео - значит без компрессии, если найдено и равно единице - то гзип, если двойке - то lz2, итд......классическая обратная совместимость.
|
|
|
(0009319)
|
Tolik
|
08-10-2012 16:30
|
|
Вы не поверите. Взял кусок гугло-мапс кэша в 64.9 МБ (без учёта кластеров, конечно), сжал в зип с макс. компрессией - получилось 65.8 МБ. Так что смысла сжимать картинки (в базе данных) нет никакого. |
|
|
(0009321)
|
Parasite
|
08-10-2012 16:40
(edited on: 08-10-2012 16:42) |
|
>Так что смысла сжимать картинки
Про жпег было сказано в начале тикета - и это всего лишь частный вариант юзания кэша. Выше я просил пожать массив _гибрида_, если что.
Опять же, Ваш жпег нигде не назван по параметрам - практически любой жпег, утоптанный в зип - будет занимать МЕНЬШЕ оригинального жпега хотя бы из-за компрессии жпег-заголовка, помноженного на число тайлов.
И да, гзип - это не зип, это еще меньше.
|
|
|
(0009322)
|
Tolik
|
08-10-2012 16:42
|
|
Я сжимал именно png.
Твой кэш 3++Гб - это сумма размеров файлов или размер на диске? |
|
|
(0009323)
|
Parasite
|
08-10-2012 16:46
(edited on: 08-10-2012 16:49) |
|
>это сумма размеров файлов или размер на диске?
Мне сегодня лениво доказывать очевидное, пардон.
Аттач. Хоть и в RAR под руку попалось - да не суть важно, смысл в том же. Это как раз вполне конкретный гуглогибрид, лежащий на раздаче на торренте. И нет, это еще ДО потерьь на кластеризацию\фрагментацию ФС - это таки голые размеры RAW-контента по отношению к утоптанному.
|
|
|
(0009324)
|
Tolik
|
08-10-2012 16:50
|
|
64 файла - 3 ГБ - так ты файлы Беркли сжимаешь (а не тайлы) - это меняет дело! |
|
|
|
>файлы Беркли сжимаешь (а не тайлы) - это меняет дело!
1. Тикет был как раз про беркли.
2. Сжатие голых тайлов - еще больше, ибо ужмет еще и пути\названия.
PS: тайлы я жму чуть менее чем ежедневно. Насмотрелся. |
|
|
(0009326)
|
Parasite
|
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% к архиву в моем случае, если склероз не изменяет.
|
|
|
|
Не путай сжатие кучи файлов в один и сжатие каждого файла по отдельности. Более того не путай сжатие файла базы со сжатием блобов внутри базы. |
|
|
|
>Не путай сжатие кучи файлов в один и сжатие каждого файла по отдельности.
Разница минимальна (ну будет на доли процентов больше из-за необходимости хидера к каждому файлу. Сжатие боди будет тем же самым, подозреваю - до байта, а гзип как таковой можно вообще без хидеров юзать - как поток).
>Более того не путай сжатие файла базы со сжатием блобов внутри базы.
Блобы внутри базы - как раз просятся тут.
Сжатие базы (чуть менее чем полностью состоящей из блобов по своему размеру) было приведено просто для примера степени выигрыша места, коль скоро механизма продемонстрировать сжатие только блобов пока что нет. Он и просится, повторяю.
Ты же не хочешь мне сказать, что 2\3 размера базы беркли из примера выше занималось НЕ блобами - кое столь хорошо и пожалось? :)
PS: а на гифовых тайлах сжатие будет еще больше - они изначально несжаты... |
|
|
(0009340)
|
zed
|
09-10-2012 04:42
|
|
Сжатие сделать можно, только, конечно, не безусловное, а по галочке в настройках карты. И такая опция будет полезна не только для Беркли, но и например, для разрабатываемого сейчас vasketsov'ым СУБД и в теории для любого будущего файлового кэша. Причём, опцию следует воспринимать как: "Сожми, если умеешь".
Не знаю, удастся ли это прикрутить к Беркли ввиду необходимости поддержания старого формата, но подумать можно. |
|
|
|
>PS: а на гифовых тайлах сжатие будет еще больше - они изначально несжаты...
Вот тут вы чуток неправы, gif-ы внутри тоже сжаты, алгоритмом lzw.
Из gif,jpg,png,bmp без сжатия разве что bmp, да и то, того, не всегда, там rle вполне может быть ... |
|
|
(0009342)
|
Tolik
|
09-10-2012 05:04
|
|
> Таки не поленился и сжал в ЗИП на примере z11 того же беркли того же гуглогибрида.
Это опять-таки сжатие больших файлов базы данных, внутри которых куча одинаковых пустышек или почти пустышек (прозрачных квадратов с несколькими буквами). А я всё толкую про то, что сжимать каждый тайл перед сохранением в беркли-кэш (как написано в техзадании) не имеет смысла, т.к. каждый файл только увеличивается за счёт разных хедеров, а сама картинка уже сжата.
А вот насчёт блобов ничего не могу сказать. |
|
|
(0009345)
|
zed
|
09-10-2012 05:22
|
|
Кстати да, проверил сейчас на случайно-взятом тайле гугло-гибрида (png). Тайл архиватором (zip) не сжимается, а наоборот, увеличивается в размерах. Т.е. и на "той стороне" интернета сидят не дураки (в большинстве) и используют возможности форматов для уменьшения размеров тайлов. |
|
|
|
>Сжатие сделать можно, только, конечно, не безусловное, а по галочке в настройках карты.
А зачем? Имхо, тонкости хранения в базе - уже сугубо системная фишка и 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
|
09-10-2012 06:02
|
|
>>а сама картинка уже сжата.
>В массе тайлов кэша - сжатый всегда весит меньше, чем несжатый.
Докажи. Сожми каждый тайл в отдельный архив и сравни занимаемое место с пачкой несжатых тайлов. |
|
|
(0009356)
|
Tolik
|
09-10-2012 06:12
(edited on: 09-10-2012 06:14) |
|
Да даже закинуть директорию с тайлами в зип - размер получается больше (без учёта потерь на кластеры), т.к. зип пакует каждый по отдельности.
Если в tgz - чуть лучше, т.к. компрессируется уже tar целиком, но в самом таре куча лишней информации. Rar, конечно, эффективнее.
Поэтому, повторюсь, выигрыш может быть только при сжатии файлов sdb или, возможно, блобов (понятия не имею, можно ли их сжимать и что получится).
|
|
|
(0009357)
|
zed
|
09-10-2012 06:17
|
|
>Да даже закинуть директорию с тайлами в зип - размер получается больше
C png? У меня получается сжатие 10%. Если скопом.
Блоб - это тайл + совсем чуть-чуть служебной информации (не более 100 байт), т.е. можно смело говорить, что блоб = тайл. |
|
|
|
>на "той стороне" интернета сидят не дураки
Тогда отсюда два вопроса:
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 мег экономии.
Это, повторяю - тайлы с максимально найденной заполненностью. Пустышки должны пожаться много лучше. |
|
|
|
>Сожми каждый тайл в отдельный архив
Легко. В шапке.
>Да даже закинуть директорию с тайлами в зип - размер получается больше
Выкинь свой зип, что еще могу сказать.
Кстати, WinZip != GZIP. Первый пихает всякую ненужную дополнительную хрень. |
|
|
(0009360)
|
zed
|
09-10-2012 06:33
|
|
>Всего-то миллион таких тайлов, какой-то 11й уровень - триста мегов экономии "за просто так".
При кэше в 100Гб, экономия в 300Мб это просто смех. Не находишь? А теперь представь сколько это мороки, прикодить сжатие тайлов и поддерживать 2 версии кэша Беркли. И это ради экономии менее 1% на винте? Да ну нафиг! |
|
|
|
Итого
для PNG от HillShade 0,3% экономия места и ХЗ сколько потеря процессора.
для PNG от Yandex 0,02% экономия места и ХЗ сколько потеря процессора.
для GIF от StreetDirectory 1.2% экономия места и ХЗ сколько потеря процессора.
для JPG от GoogleSat 0,6% экономия места и ХЗ сколько потеря процессора.
ИМХО нафиг никому не нужно. |
|
|
(0009362)
|
zed
|
09-10-2012 06:36
|
|
>Пустышки должны пожаться много лучше.
Не факт. Потому и просил пожать папку с тайлами и каждый тайл положить в отдельный архив. Чтобы был более-менее средний показатель сжатия. |
|
|
|
Единственный вариант, где потайловое сжатие имело бы смысл это kml. Но его уже сейчам можно использовать зазипованным в виде kmz. |
|
|
(0009366)
|
Tolik
|
09-10-2012 06:47
|
|
> Выкинь свой зип, что еще могу сказать.
Кстати да, разные архивваторы дают разный результат. Я пользую встроенный в total commander и им же смотрю общий объём (показывает, если нажать пробел на директории)
Однако Yandex.png.gz у меня получился на 1 байт меньше :)
Все провверять не стал, лень. |
|
|
(0009369)
|
Parasite
|
09-10-2012 07:15
(edited on: 09-10-2012 07:20) |
|
>При кэше в 100Гб, экономия в 300Мб это просто смех. Не находишь?
Не нахожу.
Я не сказал "при кэше в 100гиг" - я сказал "миллион тайлов, какой-то 11й уровень". 11й уровень гуглогибрида у меня занимает 980 мегов в беркли, скрин - в шапке еще со вчера. Если оно станет занимать еще на 300 мегов меньше - это будет гуд. При просто тупой архивации беркли - оно занимает меньше на пятьсот, но нужна доп.архивация (долгая и нудная операция, после которой кэш напрямую не поюзать - нужна разархивация).
>А теперь представь сколько это мороки, прикодить сжатие тайлов
В скрипте - это одна строчка вызова пакера (стороннего или модулем - не суть важно) перед покладанием в беркли, и одна строчка - при взятии оттуда. Итого, Вi не поверите - две.
В дельфи - не знаю.
>Потому и просил пожать папку с тайлами
А зачем ты у меня это просил? У тебя разве нет папки с тайлами, чтобы сплясать как душе угодно на своей стороне? Или ты думаешь что при отмеченном сжатии любого произвольно взятого тайла, помноженному на условно миллион таких же - вся папка в итоге каким-то фантастическим образом распухнет?
А 2 вопроса о пухлом беркли остались без ответа тем временем.
>нафиг никому не нужно.
Отучаемся говорить за всех. Нужно как минимум тикетстартеру - архивирующему много, хорошо, ежедневно и нудно. Если кэш будет "ужиматься сам", при этом оставаясь юзабельным как кэш - то это сильно упростит и хранение, и манипуляции с оным, и в итоге материальное положение вопрошающего (ибо занятое место на купленных на свои деньги винтах он считать умеет очень хорошо. До +\- мегабайта, да.). :)
Еще раз: весь тикет будет иметь смысл при БОЛЬШИХ кэшах (разных регионов и разной наполненности соответственно). На десятке-другом тайлов эффект будет единично-байтовым, ага. Ну дак и не про них разговор.
PS: в мобильных мап-приложениях с сервера весь контент идет в gzipped-контейнерах. Зри в корень: что, в гугле идиоты сидят - и не умеют считать единицы байт трафика (в данном случае), или не могут себе его позволить? Один байт экономии, помноженный на миллион юзеров и на миллион запросов -> PROFIT. О чем тут и просится применительно к винтам и тем же миллионным кэшам\байтам. :)
|
|
|
|
>в API Беркли БД была какая-то встроенная опция, которая разрешает автоматическое сжатие всех данных, но как-то я её поостерёгся включать.
Кстати, а почему? |
|
|
(0009398)
|
zed
|
09-10-2012 11:42
(edited on: 09-10-2012 11:53) |
|
>11й уровень гуглогибрида у меня занимает 980 мегов в беркли
Ну так и экономия будет 3Мб.
>У тебя разве нет папки с тайлами, чтобы сплясать как душе угодно на своей стороне?
Миллиона тайлов нету, к тому же, это всё время, а вопрошающий здесь ты. И я не думаю, что распухнет, я думаю, что будет экономия в 1% или меньше. И пока ты меня не убедишь, что будет экономия хотя бы процентов в 10% (с миллиона тайлов), я с места не двинусь :) Так что цифры в студию, и хотелось бы увидеть сравнительный анализ нескольких архиваторов (gzip, zip, 7zip) при сжатии нескольких типов данных из нескольких карт.
Разговор должен быть предметным и основанным на цифрах, а не на должно быть и я думаю.
>А 2 вопроса о пухлом беркли остались без ответа тем временем.
А на что там отвечать? Тебе не понятно, почему куча почти одинаковых файлов прекрасно ужимается в один архив? Так то ж очевидно! А разговор о сжатии каждого в отдельности и экономии на каждом на доли процента.
>>в API Беркли БД
>Кстати, а почему?
Вчера освежил память: дефолтное сжатие у них там работает только для ключей и для дублирующихся значение для одного ключа. Чтобы сжимать всё остальное, можно указывать свои функции компрессии/декомпрессии, но это порн и проще сжимать данные независимо от API (что, там кстати и рекомендовали). К тому же, в конце была приписка, что в файле БД сжатие должно включаться только в момент создания оного, а если файл был создан без сжатия, а потом мы вдруг откроем его с флагом сжатия, то оно всё упадёт с громким лязгом. Так что - не вариант.
|
|
|
|
> И пока ты меня не убедишь, что будет экономия хотя бы процентов в 10% (с миллиона тайлов), я с места не двинусь :)
Сто процентов согласен. Причем для экспериментов нужно сжимать не всю папку в один архивный файл, а каждый тайлик в отдельный архив. И сравнивать суммарный размер. Пока же ожидаемая польза меньше 1% |
|
|
(0009400)
|
zed
|
09-10-2012 12:18
|
|
>а каждый тайлик в отдельный архив
Об этом и разговор. |
|
|
|
>ожидаемая польза меньше 1%
И она скорее всего будет сильно нивелирована внутренним форматом БД, всякими выравниваниями и т.п. Нет такого закона, что если в БД проапдейтили блоб в 19 999 байт блобом в 19 881, то размер всей БД уменьшился на 118 байт. |
|
|
(0009402)
|
zed
|
09-10-2012 12:28
|
|
Да, в Беркли ж ещё используется страница в 1k, так что и там, есть свободные хвосты, как в файловой системе. |
|
|
(0009409)
|
Tolik
|
09-10-2012 13:59
|
|
> и там, есть свободные хвосты
А я-то думал... :(
Это тоже объясняет, почему рар его хорошо жмёт. |
|
|
|
>>11й уровень гуглогибрида у меня занимает 980 мегов в беркли
>Ну так и экономия будет 3Мб.
326 байт х миллион тайлов = 3Мб? Ммда...и эти люди делают нам САС. :)
>Разговор должен быть предметным и основанным на цифрах
Цифры в шапке, целых 4 варианта. По всем 4м видно наличие сжатия разной степени тяжести, а не распухания - что и требовалось доказать.
Что изменится от помноженья на миллион, кроме написания сюда конкретной цифирки которая никому не нужна в этой ее точной точности и о которой все забудут ровно через секунду после ее просмотра - я даже и не знаю, пардон.
Ну или подождать, пока я сподоблюсь на написание скрипта, перебирающего тайлы и пакующего каждый отдельно - бо в штатном этого нет, а мне такой изврат до сих пор не был нужен и готового посему тоже нет. :)
>Тебе не понятно, почему куча почти одинаковых файлов прекрасно ужимается в один архив?
Мне непонятно, почему столь большая разница на ОДНОМ И ТОМ ЖЕ наборе данных, но сперва голых а потом в БД. Либо БД распухает на целых 2\3 от размера контента, на которые потом и ужимается архиватором практически в ноль (и распухание вне зависимости от контента - нам не нужно, и с этим наверное можно\нужно чего-то сделать), либо см.1.
И если база ТАК распухает, и с этим ничего сделать нельзя - то сабжевый тикет тут есть экономия на спичках. О чем к тебе вопросы и были.
>в Беркли ж ещё используется страница в 1k, так что и там, есть свободные хвосты
Ууу.........Вот в этом все и дело скорее всего. :(((( Особенно учитывая то что в гибриде - куча пустышек, а они - по 191 байту если память не изменяет... Компенсировать 800 байт хвоста на каждый такой тайл сжатием не получится даже в теории. :((((
Может поменьше дефолтную страницу сделать? 256 байт например. Реально? |
|
|
(0009423)
|
zed
|
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 заметных изменений в производительности замечено небыло. |
|
|
|
>то и считай, что тайлы у тебя по 100k
А, блин. Там же HillShade был с его огроменными тайлами...Признаю, был неправ. :(
>Докажи мне реальную экономию
Так если она сжирается хвостами в базе данных, которые больше экономии - то и доказывать нечего, экономь не экономь - хвосты будут. Знать бы ранее, что оно так же "кластеризировано" как и ФС - и всего тикета не было б. Я с беркли не работал, и первый раз ее увидел как раз в САСе. А что там даже в САСовом унутри - не знаю до сих пор. Эхх...Можно закрывать. |
|
|
|
>Но его уже сейчам можно использовать зазипованным в виде kmz
Виктор, поясни пожалуйста, если для вики поставить в zmp формат kmz, тайлы автоматом будут падать в хранилище зазипованными? И единственный косяк - это неверная работа проверка размера тайла при закачке и при удалении (будет браться размер kmz)?
Я столкнулся как раз с желанием загзипить все викитайлы в хранилище.
>опцию следует воспринимать как: "Сожми, если умеешь".
В общем то да, включено - сжимаем при записи, если размер увеличился - сохраняем оригинал, а при чтении пробуем разжать, не получилось - возвращаем оригинал. На тайлах типа kml должен быть прирост производительности из-за уменьшения IO, на тайлах типа jpg включивший ССЗБ. |
|
|
|
>Виктор, поясни пожалуйста, если для вики поставить в zmp формат kmz, тайлы автоматом будут падать в хранилище зазипованными? И единственный косяк - это неверная работа проверка размера тайла при закачке и при удалении (будет браться размер kmz)?
Да, все именно так. |
|
|
|
Соответственно в таком случае 7zip там или KaZip, но получается что тратится место на заголовок (чтобы doc.kml записать в zip и на диск упал честный zip),m а мне места жалко (((.
Тогда выходит что ради экономии заголовков имеет смысл гзиповать вручную внутри хранилища, и инфу отдавать честную о размере (для SQlite и СУБД есть поле размера тайла, для беркли не знаю, а для файлового кэша или забить, или распаковывать ради честного размера).
Походу надо подумать, как покрасивше сделать, чтобы не дублировать код. |
|
|
|
Ну на тайлах Викимапии даже с заголовком разница получается очень заметной 257801 байт kml и 32453 байт kmz например. |
|
|
|
>даже с заголовком разница получается очень заметной
Ага. Но мне бы хотелось:
а) ещё выиграть размерчику: я не считал сколько тайлов накопилось (кроме tne), но интуитивно понятно, что дофига их, и выигрыш будет ощутим, особенно в БД;
б) чтобы размер тайла для программы был правильным.
В общем-то вики - последняя карта, которая у меня не в БД (исключая тестовые, а также старые доверсионные vesat и google для истории), так что хотелось бы при переносе в неверсионную базу заодно и утоптать.
Почему ещё размер важен: если KML от panoramio не меняется, скорее всего и фотки там не поменялись. То есть не только для вики, но размер имеет значение )) |
|
|
|
Ну, почему бы и не сделать для некоторых хранилищ такую фитчу. Будет весьма полезно. |
|
|
(0012060)
|
vasketsov
|
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
обновиться бы наверное стоило.
|
|
|
|
Потестил сжатие при миграции выделенной области из файлового кэша в неверсионный sqlite (алгоритм из ZLib):
1. Без gzip - 225 МБ (236 639 232 байт)
2. С gzip - 41.1 МБ (43 130 880 байт)
Причём второе из-за впятеро меньшего IO ещё и сильно быстрее сохраняется ))) |
|
|
|
Погонял сравнительные тесты алгоритмов 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
|
19-07-2013 09:20
|
|
>Zlib (который внутренний) vs ALZLibExGZ (который zlib1.dll)
А по-моему оба используют прекомпилированные объектные файлы. Только у ALZLib они возможно по-свежее.
>Может ещё чего потестить имеет смысл?
Потести самую свежую zlib1.dll, скачанную с сайта производителя.
И можешь ещё сравнить с 7z - интерфейс в ArchiveReadWrite лежит. Он по-моему zlib поддерживает, но я его в САС не прокидывал. Ради интереса можешь сравнить скорость и размеры самого 7z vs zlib. |
|
|
|
>оба используют прекомпилированные объектные файлы
Точно, ты прав, 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 вызывает мгновенную смерть всем надеждам его поюзать. |
|
|
|
Хм. Заодно обнаружил критичный баг: отсутствие распаковки тайлов при чтении из источника в менеджере кэша. |
|
|
(0012138)
|
zed
|
19-07-2013 16:32
|
|
>И теперь её надо в AL* как-то вкорячить?
Нет, теперь надо взять заголовочник из исходников zlib и перевести его на паскаль. Не обязательно весь, а только необходимые функции и типы. За основу можно взять тот же встроенный Zlib. Ну, или в интернетах поискать - может уже кто делал такое.
>У меня создалось ощущение, что он недопилен.
Допилен и работает со всеми заявленными форматами. Либу брать из релизной версии 7z 9.20.
>из-за отсутствия
>FArch := CreateArchive(AArchiveType);
Всё там есть. |
|
|
(0012139)
|
zed
|
19-07-2013 16:35
|
|
>из-за отсутствия
>FArch := CreateArchive(AArchiveType);
А, точно - в перегруженном конструкторе не хватает этой строчки. Надо добавить. |
|
|
|
http://www.compression.ru/arctest/cctg/r-doc.htm
Как раз почти наш случай (xml)
7zip 2.30b2 7z LZMAbt234 всех рвёт в клочья |
|
|
|
Погонял немного 7z (LZMA) с разными растройками по слою wiki (как главному претенденту на сжатие, хотя panoramio сжимается ещё лучше))). Картина вырисовывается не очень приятная.
Во-первых, при работе программы (то есть, при декомпрессии) наблюдатся заметно бОльшая нагрузка на CPU (по сравнению с gzip).
Во-вторых, так и не удалось заставить 7z распаковывать быстрее zlib и gzip. Хотя выигрыш в размере архива 7z и значительный, хотелось бы как-нибудь обогнать хотя бы zlib. |
|
|
|
По окончанию работ по добавлению тайлокомпрессии в 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).
На этом тикет закрывается, всё прочее - отдельными доработками. |
|
|
|
А вот так сжимается kml от panoramio: наугад взятый тайл panoramio (z14 юго-восточная часть Рубского озера в Ивановской области) размером 75018 алгоритм Lzma утоптал например аж до 2954 байт - то есть более чем в 25 раз. |
|
|
|
>Сжал для проверки тайл гугл мапса размером 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 байт) - фэйл |
|
|
|
Ещё инфа для маньяков по поводу разных компрессоров.
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 - пока что неактуален. |
|