HTTP-сервер-обменник для тайлового кеша

[Parasite]

Закрытый сервер это действительно плохо и не инетерсно А если еще и обменивающийся информацией по своему самописному протоколу через сокеты, то и вообще бессмысленно.

Вот. Но программеру это пока что неочевидно.

А вот какую хеш-функцию использовать, так это уже исключительно дело того, кто будет реализовывать сервер.

Если сервер будет скриптовым - сий вопрос будет решать юзер, путем вставки той или иной строчки в скрипт (это можно документировать даже).
Опять же, до сих пор никто не обосновал именно за MD5 - в который раз уж прошу.

Просто на этой задаче скорость вычисления хеша очень мало повлияет на общую производительность сервера.

Заблуждение, вызванное отсутствием опыта работы с действительно многопользовательскими средами.
Для "сервера только для локалхоста на той же машине" Ваше утверждение верно, и повышение быстродействия\скорости работы клиента как правило дает то же самое и серверной части, и проблема несколько нивелируется. В истинно же многопользовательской среде при разработке и дальнейшем использовании любой распределенной клиент-серверной системы наступает момент, когда при неизменности собственно функционала решения - его банально начинает не хватать (обычно это связано либо с увеличением обрабатываемых решением данных в единицу времени на каждого клиента, либо с ростом числа клиентов "на единицу сервера", либо обоих сразу). В нашей задаче будет как раз вариант "оба сразу".

Не стоит как-то специально приближать этот миг (путем необоснованной изначально избыточной загрузки сервера например), уверяю Вас. Наоборот - самым грамотным было бы именно как можно более РАЗгружать и оптимизировать алгоритмы, особенно server-side как ядра всей системы - и все решение прослужит чем дольше, чем меньше "бутылочных горлышек" будет в его составе. Это же банальная системотехника, нек.образом.... Посему я и предлагаю максимально облегчать жизнь каждому компоненту, заранее прорабатывая и обосновывая каждый функционал, а не городя лишний огород просто потому, что оно "красиво звучит" - хотя бы для серверной части. Хочется MD5? Извольте: что Вам даст именно MD5 неа фоне других более "легких" конкурентов? Хочется сокетов? Извольте тот же вопрос. Хочется гуевой морды на серверную часть? Опять же тот же вопрос, итд итп..........

PS: задумайтесь над тем, что самые функциональные и вылизанные серверные (и не только) решения как правило не обвешаны ничем, кроме голого фунционала - при почти линейной обратной зависимости. Пример - тот же Апач, на котором собрано подавляющее большинство инетных веб-серверов (он даже гуя не имеет, конфигурится Блокнотом в единственном текстовом файле и сам по себе занимает пару мег. Открытый. Крайне легкий и "бронебойный" в многопользовательской среде - в противовес монстрообразному закрытому IIS от мелкософта, который под нагрузкой много больше лежит, чем работает - и НИЧЕГО с этим не сделать кроме как слать комплейны в службу поддержки производителя, ибо он закрыт и негибок, да еще и платен - в составе той или иной оси).

Примерно так.

[svp]

Дабы прекратить этот флейм постараюсь внести ясность.
1. Для сравнения двух тайлов с одинаковыми координатами достаточно CRC32. Использование md5 только для этой цели не эффективно.
2. Для уникального индексирования тайлов во внутренней базе CRC32 недостаточно. Не хватает избыточности. Здесь md5 сгодился бы, НО(!) смысла в этом тоже мало, ибо уникальный ключ позиции тайла можно сделать мнемоничным, построив его из типа карты, зумма, координат тайла, и его номера в стопке версий. Это будет полноценным уникальным ключом тайла.
Если в этом случае хранить за каждым тайлом ещё и его CRC, то можно убить дополнительных зайцев:
-- при добавлении новго тайла в стопку, достаточно просмотреть CRC хеши тайлов стопки для сравнения. Хеш придётся считать только для нового (добавляемого) тайла. Естественно, используя при этом md5 мы не потеряем практически ничего, ибо считать хеш придётся только для одного добавляемого тайла. А это не сопоставимо по времени с другими накладными расходами. Единственное, md5 занимает больше места.
-- при загрузке тайла легко контролировать его целостность.

Выходит спор ни о чем. MD5 несколько избыточен по функционалу и затратен по объёму, но принципиальной разницы в этом приложении не будет. И такой пустяковой проблеме посвященог столько сломанных копий. Народ, не тратьте попусту время и нервы!

[Parasite]

1. Для сравнения двух тайлов с одинаковыми координатами достаточно CRC32. Использование md5 только для этой цели не эффективно.
2. Для уникального индексирования тайлов во внутренней базе CRC32 недостаточно. Не хватает избыточности.

Зачем Вам MD5 сравнивать по всей базе? Нужно же только сравнивать этот тайл с нижележащим тайлом с тем же Х, У и Z, но в предыдущей версии (а это, как я уже сказал - не более 289 тайлов на наст.момент теоретически (v.2.89 на гугле текущая), много меньше - фактически). Ведь каждый тайл будет\должен иметь строго уникальное место на карте и только своего зума, и вариации могут быть ТОЛЬКО В ВЕРСИЯХ этого тайла, но уж никак не в его местоположении на карте и тем более где-то там на соседних зумах (от этого-то зоопарка как раз мы и желаем избавиться). Зачем Вам подобная избыточность о тайле по всей карте - непонятно...Вам не хватит размерности CRC32 для 289 вариантов (да даже для 2899 вариантов)? Чушь!

Здесь md5 сгодился бы, НО(!) смысла в этом тоже мало, ибо уникальный ключ позиции тайла можно сделать мнемоничным, построив его из типа карты, зумма, координат тайла, и его номера в стопке версий. Это будет полноценным уникальным ключом тайла.

Зачем добавлять X+Y+Z+CRC==ID и хранить эту пачку IDов в базе, когда можно хранить ТОЛЬКО CRC - а X,Y,Z и так существуют и в открыве от хранения в базе, и активно используются в работе? Когда приспичит - X,Y,Z элементарно можно прибавить к CRC (хранимой в базе) на лету, но именно когда приспичит - а не для всех файлов оптом и заранее, ибо это избыточно. Ведь в любом случае придется лезть в базу как минимум единожды - либо чтобы вынуть полный ID, либо чтобы вынуть просто CRC (причем во втором методе нет необходимости считать полный ID для всех тайлов заранее. И если ID придется считать массово и разово, то делание этого на лету по необходимости - более "размазано" по времени и соответственно не столь ресурсоемко).

Если в этом случае хранить за каждым тайлом ещё и его CRC, то можно убить дополнительных зайцев:

Хранить CRC нужно в безусловном порядке, да.

-- при добавлении новго тайла в стопку, достаточно просмотреть CRC хеши тайлов стопки для сравнения. Хеш придётся считать только для нового (добавляемого) тайла. Естественно, используя при этом md5 мы не потеряем практически ничего, ибо считать хеш придётся только для одного добавляемого тайла. А это не сопоставимо по времени с другими накладными расходами.

Опять двадцать пять....
Сто юзеров, каждый кладет по 10 тайлов\сек по 10Кб каждый тайл, и еще тысяча просто смотрят по 20 тайлов\сек (без хеширования, но ресурсы сервера и базы это таки ест). Посчитайте абсолютно необоснованные временные затраты, если MD5 например в три раза медленнее и в 10 раз более ресурсоемко чем CRC32. Помножьте (прогрессивно! ведь мы ожидаем увеличения числа юзеров со временем!) на ожидаемый TTL всего решения. Подумайте, что ещё можно было бы сделать серверу за это потерянное время, чем просто тупо греть воздух в серверной.

[Alexander]

Никто так и не предложил алгоритм CRC32 для сравнения скорости ))
Просто когда сказали что MD5 супер медленный я возразил, когда мне сказали что он медленнее чем CRC/CRC32 я предложил сравнить, но почему то я опять сам должен реализовать его...
Все давно отказались от связки моего сервера с САС, как и я впрочем.

Зачем Вам MD5 сравнивать по всей базе? Нужно же только сравнивать этот тайл с нижележащим тайлом с тем же Х, У и Z, но в предыдущей версии (а это, как я уже сказал - не более 289 тайлов на наст.момент теоретически (v.2.89 на гугле текущая), много меньше - фактически). Ведь каждый тайл будет\должен иметь строго уникальное место на карте и только своего зума, и вариации могут быть ТОЛЬКО В ВЕРСИЯХ этого тайла, но уж никак не в его местоположении на карте и тем более где-то там на соседних зумах (от этого-то зоопарка как раз мы и желаем избавиться). Зачем Вам подобная избыточность о тайле по всей карте - непонятно...Вам не хватит размерности CRC32 для 289 вариантов (да даже для 2899 вариантов)? Чушь!

Зачем добавлять X+Y+Z+CRC==ID и хранить эту пачку IDов в базе, когда можно хранить ТОЛЬКО CRC - а X,Y,Z и так существуют и в открыве от хранения в базе, и активно используются в работе? Когда приспичит - X,Y,Z элементарно можно прибавить к CRC (хранимой в базе) на лету, но именно когда приспичит - а не для всех файлов оптом и заранее, ибо это избыточно. Ведь в любом случае придется лезть в базу как минимум единожды - либо чтобы вынуть полный ID, либо чтобы вынуть просто CRC (причем во втором методе нет необходимости считать полный ID для всех тайлов заранее. И если ID придется считать массово и разово, то делание этого на лету по необходимости - более "размазано" по времени и соответственно не столь ресурсоемко).

Предполагаю что это было предложено для баз Беркли в качестве уникального ключа тайла в базе.


П.С. если вы также напишите подсчёт CRC из файла без буферизации то тоже будет медленно. Всё зависит от прямоты рук кодера. Впрочем я не понимаю как тайл который нам предложили добавить может попась в файл на сервере, странно, ведь он вначале размещается в памяти, а потом добавляется в базу.

[!] MODERATED:OFFTOPIC

[Alexander]

Разница в скорости MD5 и CRC32 получилась 610 раз, если кого интересует.

[svp]

Я говорил, что чисто теоретически использовать можно и md5, но НЕОДНОКРАТНО сказал, что это не эффективно. Но можно. А насчёт сравнительных затрат ресурсов на MD5 и CRC я говорил в свете небезызвестного моего частного и скромного мнения о том, что больше 30 онлайн коннектов к шкуре этого неубитого сервера за раз не будет никогда. И это, повторюсь, моё частное скромное мнение. Не надо его оспаривать. Время покажет.
Ещё раз: составной индекс нужен для базы беркли. В составной индекс нельзя включать CRC ибо получение индекса станет неоднозначным, зато в него можно добавить версию или номер тайла в стопке.

Зачем Вам MD5 сравнивать по всей базе?

Затем, что я смотрю на проблему в целом, а не впадаю в пространные споры по частностям. Насчёт того, что MD5 это будет или CRC, то я уже сказал, что лучше CRC (легче сравнивать и хранить один INT, чем массив).
"По всей базе" потому, что я понимаю нечто конкретное под базой. Речь идёт о беркли, ибо база на основе файловой системы -- это смешно, а использовать в качестве контейнера MySQL не эффективно. А что понимаете под "базой" Вы? Хотя это скорее риторический вопрос.

[!] MODERATED:OFFTOPIC

[Parasite]

Никто так и не предложил алгоритм CRC32 для сравнения скорости ))

А своих идей у Вас нет? Тогда возьмите любой готовый семпл про CRC32. Перловый был взят из семплов по работе с Digest::MD5 (найденных за минуту в гугле, чтобы не тратить время и два раза не изобретать общеизвестный велосипед).

Просто когда сказали что MD5 супер медленный я возразил, когда мне сказали что он медленнее чем CRC/CRC32 я предложил сравнить

Он таки супермедленный по сравнению с CRC. Возражения и оспаривания данного общеизвестного факта просто неуместны по их бессмысленности, а сравнения и убеждение себя любимого в очевидном Вы вполне в состоянии сделать и сами - было бы желание.

Предполагаю что это было предложено для баз Беркли в качестве уникального ключа тайла в базе.

А зачем нужен уникальный ключ отдельно взятого тайла во всей базе?
Который день вопрошаю в пустоту.

[Parasite]

Ещё раз: составной индекс нужен для базы беркли. В составной индекс нельзя включать CRC ибо получение индекса станет неоднозначным, зато в него можно добавить версию или номер тайла в стопке.

Что это даёт? По стандартам Беркли каждый элемент обязан иметь подобный уникальный индекс? Я, если честно, с Беркли особо не работал и оный нигде по форуму более-менее подробно не обсуждал.

"По всей базе" потому, что я понимаю нечто конкретное под базой. Речь идёт о беркли, ибо база на основе файловой системы -- это смешно, а использовать в качестве контейнера MySQL не эффективно.

1. Нигде выше и ранее не было слов "база на основе файловой системы". Насколько я понимаю, под этим термином имелась ввиду кучка папок с тайлами, как оно сейчас в САСе? Это неэффективное решение начального уровня - но оно, замечу, работает уже прямо сейчас, в отличие от демагогий (и не далее) всех без исключения ораторов - включая и меня, да - по поводу сервера.
2. Не вижу особой разницы в эффективности хранения в Беркли и в MySQL. Обоснуйте свои слова?

А что понимаете под "базой" Вы? Хотя это скорее риторический вопрос.

Ответ столь же риторичен и выдается ПОИСКом - под базой в данном случае имеется ввиду активно пропихиваемый предыдущим оратором вариант ФТП+базовод (в частности MySQL), из коей ветки Вами же справедливо была выделена данная тема про HTTP (с той же базой).
Беркли же, согласно Вашего же поста, обсуждается как раз там, а не в этой ветке. Запутались?

[svp]

Ещё раз: составной индекс нужен для базы беркли. В составной индекс нельзя включать CRC ибо получение индекса станет неоднозначным, зато в него можно добавить версию или номер тайла в стопке.

Что это даёт? По стандартам Беркли каждый элемент обязан иметь подобный уникальный индекс? Я, если честно, с Беркли особо не работал и оный нигде по форуму более-менее подробно не обсуждал.

Это даёт возможность выбрать из базы нужный тайл. Сейчас в САС тайлы хранятся в файловой системе. Её в данном случае можно также рассматривать как нереляционную БД. При этом мы имеем дело с парами [ключ, значение]. Значением здесь является тайл, а ключ -- это путь к файлу тайла. Этот путь представляет собой строку, соединяющую в себе так или иначе T+Z+X+Y (T -- тип карты). Для кеша TZXY -- это уникальный ключ тайла. Чтобы получить нужный тайл мы формируем его ключ и запрашиваем базу на предмет соответствующего значения (то бишь тайла).
Точно также работает и Беркли, только в её случае все записи будут храниться в одном или нескольких файлах. Ключом, вместо строки, может быть 80-битная структура (T - 1b, Z - 1b, X - 4b, Y - 4b). База Беркли внутри себя поддерживает актуальной специальную структуру (B-дерево), позволяющую быстро по значению ключа находить значение. Само собой, не стоит и говорить, насколько это работает быстрее файловой системы.

2. Не вижу особой разницы в эффективности хранения в Беркли и в MySQL. Обоснуйте свои слова?

Сами тайлы хранить в MySQL неэффективно. Движок технически не предназначен для этого. Хранение же тайлов в файловой системе -- это, по сути, использование строковых ключей с нефиксированной длиной и огромной избыточностью. Если вы, Parasite, так щепетильно отнеслись к выбору хеш-функции, то как же закрываете глаза на столь вопиющую неэффективность?

Беркли же, согласно Вашего же поста, обсуждается как раз там, а не в этой ветке. Запутались?

Нет, где спрашивают, там я и отвечаю. Через некоторое время, если кто-то из модераторов сочтёт необходимым, можно перенести некоторые посты в соответствующие темы. Хотя в данном случае такой формализм ни к чему, ибо темы взаимосвязаны.

[Parasite]

Точно также работает и Беркли, только в её случае все записи будут храниться в одном или нескольких файлах. Ключом, вместо строки, может быть 80-битная структура (T - 1b, Z - 1b, X - 4b, Y - 4b). База Беркли внутри себя поддерживает актуальной специальную структуру (B-дерево), позволяющую быстро по значению ключа находить значение. Само собой, не стоит и говорить, насколько это работает быстрее файловой системы.

Все это так, но насколько я понимаю данную тему - в ней обсуждается не CACHEvsBERKELEY_DB, а CACHEvsMySQL применительно к FTP-серверу (затем плавно мутировавшему в HTTP-сервер), и именно в данном ключе я и отвечал. Повторяю, что текущая тема была выделена из темы про "FTP+базовод" от оратора rokki, а не "Кэш+BERKELEY" от оратора svp.
Тема "cache+BERKELEY" изначально находилась несколько в стороне данного обсуждения, если я правильно помню - и по ней ничего вменяемого или разумного я пока что сказать не могу (ни там, ни тут).

2. Не вижу особой разницы в эффективности хранения в Беркли и в MySQL. Обоснуйте свои слова?

Сами тайлы хранить в MySQL неэффективно. Движок технически не предназначен для этого. Хранение же тайлов в файловой системе -- это, по сути, использование строковых ключей с нефиксированной длиной и огромной избыточностью. Если вы, Parasite, так щепетильно отнеслись к выбору хеш-функции, то как же закрываете глаза на столь вопиющую неэффективность?

Если брать во внимание тред выше (когда имелся ввиду "файловый кэш" OR "кэш в MySQL" - и не более этих двух) - я склонился к решению с MySQL ввиду очевидности (но не идеальности, да) выбора - по типу "из двух зол выбирают меньшее".

Если же ввести еще одно ранее несуществующее в диалоге "зло" (...OR "BERKELEY_DB") - то все сказанное мною мне надо будет пересмотреть (а до этого - поплотнее ознакомиться с BERKELEY_DB, с которой я на наст.момент знаком очень поверхностно).

Впрочем, всё понятно. Разобрались, где собачка порылась и из-за чего не достигался консенсус....

PS:Опять же, если разница между FileCACHEvsDATABASE (та или иная) будет велика изначально, то вот будет ли столь же ощутимой разница MySQLvsBERKELEY? Вопрос к знатокам одновременно обоих