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

[Alexander]

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

На стороне сервера никак никогда не отследить (если нет закономерности в каких то свойствах картики (но если необходимо анализировать изображение сервер будет сильно загружен)). Это можно решить на стороне клиента, но в любом варианте криворукие или недоброжелательные пользователи смогут испортить это, чтобы вы не придумали.

[Parasite]

С учётом всех требований сервер без беркли сделать не удастся.

Почему?

[Parasite]

Всё-таки легче добавить хэш-сумму и знать размер тайлов.

А размер зачем? Если он изменится - изменится и хэш.

[Parasite]

Два инта сравнить быстрее чем 16байт, например по этому.

При среднестатистической скорости скачки тайлов - это абсолютно некритично.

Если в системе дата неправильная то пользователь сам виновать, также как если у него часовой пояс неправильно прописан ))

То есть для корректной работы с данным приложением я (именно я, а не машина) должен буду безусловно держать в уме необходимость синхронизированного времени? Что за чушь! Да я лучше с гугля тогда склею - БЕЗ дополнительной нагрузки на моск...

[Parasite]

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

Передать УРЛ на сервер, откуда по факту был скачан тайл (там кроме всего прочего будет и гуглеверсия).

[Parasite]

чем длинее хэш, тем меньше коллизий (на MD5 например вполне сканает).

Это крайне медленный и крайне ресурсоемкий алгоритм. Нагрузку на сервер во многопользовательском режиме представляем, да?

[Alexander]

Два инта сравнить быстрее чем 16байт, например по этому.

При среднестатистической скорости скачки тайлов - это абсолютно некритично.

Если в системе дата неправильная то пользователь сам виновать, также как если у него часовой пояс неправильно прописан ))

То есть для корректной работы с данным приложением я (именно я, а не машина) должен буду безусловно держать в уме необходимость синхронизированного времени? Что за чушь! Да я лучше с гугля тогда склею - БЕЗ дополнительной нагрузки на моск...

Моск тут не при чём, просто если у пользователя дата на месяц назад отмотана, то он просто увидит не самые свежие тайлы, если у него примерно правильное время +- час, то всё будет отлично.

Передать УРЛ на сервер, откуда по факту был скачан тайл (там кроме всего прочего будет и гуглеверсия).

Ага, если версия у всех стоит 99, то что в этом дельного?

чем длинее хэш, тем меньше коллизий (на MD5 например вполне сканает).

Это крайне медленный и крайне ресурсоемкий алгоритм. Нагрузку на сервер во многопользовательском режиме представляем, да?

Вполне представляю, а какой у Вас предполагается канал? Может 100Гбит/с, или 1Тбит/с? Тогда наверное не хватит сервера. Если полагать что канал порядка 1Гбит/с то вполне хватит, правда будет нагружен прилично, но это уже проблема хостера. Если домашний комп под сервак, то скорости порядка 100Мбит/с. И его тоже хватит.
Я же предложил наименее подверженный коллизиям алгоритм хэширования для своего очень малого размера (16байт). Можно броситься в крайность и использовать CRC первых 512 байт, на ваше усмотрение.

Всё-таки легче добавить хэш-сумму и знать размер тайлов.

А размер зачем? Если он изменится - изменится и хэш.

Вы так уверены? Ваша фраза неверна, скажу точнее существует достаточно большое множество картинок разного объёма с одинаковым хэшем. Вероятность подобной коллизии для тайла гугла по определённому месту стремится к 0, но это не оправдание сказанному. =)

[Parasite]

Моск тут не при чём, просто если у пользователя дата на месяц назад отмотана, то он просто увидит не самые свежие тайлы, если у него примерно правильное время +- час, то всё будет отлично.

У меня в частности (и в масштабах страны - вообще) сейчас 2551 год. На всех компьютерах (в масштабах страны!) в том числе. Что увижу _я_ при заходе в базу? Правильно, устаревшие на ~500 лет тайлы. Бугога.

Ага, если версия у всех стоит 99, то что в этом дельного?

А кто сказал, что "версия у всех стоит 99" - это правильно? На гугле стоит НЕ 99я версия, и этим все сказано.

Вполне представляю, а какой у Вас предполагается канал? Может 100Гбит/с, или 1Тбит/с?

Просьба не обсуждать в ветках меня - но сабж. Спасибо.
Десяток параллельных клиентов с приличным каналом вполне поставят на колени это решение. Про сотню уж и подавно молчу.
PS: у меня - оптика до кластера.

правда будет нагружен прилично, но это уже проблема хостера.

На самом деле, это проблема _решения_. Любой вменяемый хостер пошлет в дупу неоптимизированный проект на скриптах, систематически кладущий ему сервер в DDOS. И будет прав.

Если домашний комп под сервак, то скорости порядка 100Мбит/с. И его тоже хватит.

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

Я же предложил наименее подверженный коллизиям алгоритм хэширования для своего очень малого размера (16байт). Можно броситься в крайность и использовать CRC первых 512 байт, на ваше усмотрение.

Те первые байты, в которых большей частью стандартный и неизменный жпег-заголовок? Нет, спасибо, не подходит.

Вы так уверены? Ваша фраза неверна, скажу точнее существует достаточно большое множество картинок разного объёма с одинаковым хэшем.

Вероятность одинакового МД5 хэша при разных входных данных (помноженную на вероятность не именно ЭТОГО хэша вообще в базе, а именно этого хэша на именно этот "столбец тайлов по версиям" - сами просчитаете? Мне, если честно - лень.

[Alexander]

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

У меня в программе сейчас вычисляется полный MD5 тайла перед тем как тот добавляется в кэш, скорость скачивания от 100Кб/с до 150Кб/с, операционка(Vista) с моей программой создаёт нагрузку на процессор в среднем 2% (среднее по диаграмме), сама программа менее 1%. Если посмотреть на алгоритм MD5 хэширования, то станет понятно что для хэширования нужно произвеси порядка 560 примитивных операций (которые занимаю <= 4 тактов процессора) на каждые 64байта, пусть будет 36 тактов на 1 байт, тогда более 50 Мбайт/с может хэшировать средний проц для ПК (При 100% загрузке). А MD5 10Кб/с может любой калькулятор сейчас =)
Как это делается на скриптах я не знаю, может и не так эффективно.

Просьба не обсуждать в ветках меня - но сабж. Спасибо.

Хорошо. )

У меня в частности (и в масштабах страны - вообще) сейчас 2551 год.

Увидите последние тайлы.

Те первые байты, в которых большей частью стандартный и неизменный жпег-заголовок? Нет, спасибо, не подходит.

Мне кажется заголовок меньше.

Вероятность одинакового МД5 хэша при разных входных данных (помноженную на вероятность не именно ЭТОГО хэша вообще в базе, а именно этого хэша на именно этот "столбец тайлов по версиям" - сами просчитаете? Мне, если честно - лень.

Вы же отказались от MD5, дак зачем такая статистика теперь.

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

И все они одновременно будут закачивать тайлы на сервер? Здорово конечно, но когда такой найти можно будет )

П.С. зачем так привязываться к алгоритму кэширования, есть более интересные проблемы при реализации.

[Parasite]

для хэширования нужно произвеси порядка 560 примитивных операций (которые занимаю <= 4 тактов процессора) на каждые 64байта, пусть будет 36 тактов на 1 байт, тогда более 50 Мбайт/с может хэшировать средний проц для ПК (При 100% загрузке). А MD5 10Кб/с может любой калькулятор сейчас =)

Я не говорил что не может. Я говорил, что медленно (по сравнению почти со всеми другими).

PS: цикл с вычислением MD5 от 32х байт на Перле занимал ~150 пересчетов/сек на Пне4 2.4ГГц (стандартным {Digest::MD5} без специального распараллеливания на физ.процессоры\ядра). Это собственно "в уме" - без каких-то дисковых операций, баз и прочих вводов-выводов - и от исходных 32х байт, в которых изменялись только младшие разряды сообразно с циклом.
При организации веб-сервера выбор будет крайне "богат": либо ПХП (там эта операция еще немного медленнее), либо Перл, либо (для мазохистов) - ASP.

PPS: так чем же плох "стандартный" и быстрый CRC? Мало разрядов? Тогда CRC32...?

У меня в частности (и в масштабах страны - вообще) сейчас 2551 год.

Увидите последние тайлы.

...зато мои - никто не увидит еще как минимум 5 веков.

Те первые байты, в которых большей частью стандартный и неизменный жпег-заголовок? Нет, спасибо, не подходит.

Мне кажется заголовок меньше.

Мне кажется я сказал "большей частью" (куска файла от начала и до указанной длины).

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

И все они одновременно будут закачивать тайлы на сервер? Здорово конечно, но когда такой найти можно будет )

Что-то мне подсказывает, что при выпуске новой версии САСа ее скачают и начнут пробовать намного больше 100 человек (практически одновременно). И даже намного больше нескольких тысяч и десятков тысяч. Напоровшись же на 503 Service unavailable - скажут "Ффу, какая лажа!" и откатятся на предыдущую версию (в лучшем случае).

П.С. зачем так привязываться к алгоритму кэширования, есть более интересные проблемы при реализации.

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