Блог

Основная суть того, что я пытаюсь выполнить, — это настройка сервера обработки изображений. Поскольку код страницы создается в Coldfusion, возможно, потребуется изменить размер нескольких изображений на странице и придать им миниатюры соответствующих размеров, возможно, разного размера и, возможно, с использованием другого алгоритма.

Основная суть того, как это работает, заключается в использовании простого тега img, атрибут src будет указывать на сервер изображений в соответствии со следующими строками.

<img src="http://imageserver.com/<clientname>/<primarykey>.jpg">

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

Когда сервер обработки изображений получает вызов, он сначала проверяет, существует ли этот файл, если Apache определяет, что файл существует, он сразу же его обслуживает, в противном случае он вызывает Coldfusion, который считывает запись из базы данных, используя переданный ему первичный ключ, чтобы получить URL обрабатываемого изображения и любые связанные параметры (в данном случае width, height, method, url, client, но, возможно, больше в будущем).

В настоящее время я делаю это, используя хэш-систему, где параметры упорядочены в алфавитном порядке, а затем хэшируются. Является ли это разумной системой, или в конечном итоге возникнут коллизии хэшей, даже если хэшируемые данные довольно малы (от 50 до 200 символов). Каждый клиент, вероятно, мог бы хранить до 10 000 изображений (в своей собственной папке, поэтому столкновение хэшей не было бы проблемой для разных клиентов).

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

Не связаны ли коллизии хэшей с этим размером выборки (10 тыс. изображений на клиента, генерируемых строками из 50-200 символов)? Что, если бы я сделал что-нибудь простое, например, <width>_<height>_<hash>.jpg или поместил изображения в папки, подобные /<client>/<width>x<height>/<hash>.jpg , потому что это еще больше уменьшило бы вероятность коллизий хэшей (хотя и не удалило бы их)?

Любой совет?

Как выполняется хеширование? Используйте SHA-512 для алгоритма хеширования, и вы получите строку длиной 128 символов. Возможно, вам не нужен такой длинный URL, но идея здесь в том, что вы можете минимизировать коллизии с помощью более сложных алгоритмов.

http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7c52.html

Хотя я сомневаюсь, что вам придется беспокоиться о коллизиях хэшей, вы можете захотеть просто использовать UUID.

http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-70de.html

РЕДАКТИРОВАТЬ: Или используйте uniqueidentifer в качестве первичного ключа таблицы, в которую вы сохраняете файл. Затем после вставки вы можете использовать предложение OUTPUT запроса, чтобы вернуть ключ, который будет использоваться так, как вы хотите.

Метод, которым я решил эту проблему, заключался в хэшировании не только имени файла, но и его параметров, таких как ширина и высота. Таким образом, вероятность коллизий хэшей в основном равна 0, пока мы не достигнем миллионов (миллиардов?) записей. Пока у нас нет коллизий хэшей.