Типичные длины URL для расчета хранилища (URL-сокращатель)

Question

После прочтения нескольких совпадений в быстром поиске Google кажется, что при определении средней длины URL-адреса не так много последовательности.

Я знаю, что IE имеет максимальную длину URL-адреса в 2083 символа (от здесь ), поэтому у меня есть хороший максимум для работы с ним.

Меня беспокоит то, что я пишу сокращающий URL-адрес в PHP ( аналогично некоторым другим вопросам по SO) и хочу убедиться, что я не могу превысить возможность хранения сервера, на котором он размещен.

Если все URL-адреса максимальны для IE, то 2^32 никуда не поместится удобно - для этого потребуется 2K x 4B ~= 8TB хранилища: нереальное ожидание.

Без добавления функции обрезки (т. Е. Очистки «старых» сокращенных URL-адресов), каков самый безопасный способ подсчета использования хранилища приложением?

~ 34 символов безопасное предположение? Если это так, то полностью заполненная база данных (с использованием типа int для первичного ключа) будет жевать 292 ГБ пространства (удвоение 146 ГБ для любых метаданных, которые могут потребоваться для хранения).

Какова лучшая догадка для такого приложения?

Answer 1

Это, вероятно, невозможно узнать без индексации всего Интернета, но согласно анализу Кельвина Тана по набору данных из 6 627 999 уникальных URL-адресов из 78 764 уникальных доменов , ответ: 76,97

Среднее: 76,97

Стандартное отклонение: 37,41

95-й% доверительный интервал: 157

99,5% доверительный интервал: 218

Answer 2

Я не уверен, что типично, но из 11 000 URL в нашей базе данных запросов средняя длина составляет 62 символа.Мы можем быть исключением, потому что каждый месяц мы получаем сотни запросов от наших клиентов на товары из Японии.Наша база данных включает в себя сотни URL-адресов с несколькими сотнями символов.Самая длинная - это ссылка на Google Translate на 1689 символов.

10 лучших лен (producturl): 1689 792 707 693 647 606 574 569 562 560

пример URL 647 символов:

http://www.amazon.co.jp/%E9%AD%94%E7%95%8C%E6%88%A6%E8%A8%98%E3%83%87%E3%82%A3%E3%82%B9%E3%82%AC%E3%82%A4%E3%82%A24-%E5%88%9D%E5%9B%9E%E9%99%90%E5%AE%9A%E7%89%88-%E5%A0%95%E5%A4%A9%E4%BD%BF%E3%83%95%E3%83%AD%E3%83%B3-%E3%83%97%E3%83%AD%E3%83%80%E3%82%AF%E3%83%88%E3%82%B3%E3%83%BC%E3%83%89%E4%BB%98%E3%81%8D%E7%89%B9%E8%A3%BD%E3%82%AB%E3%83%BC%E3%83%89-%E3%83%88%E3%83%AC%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%AB%E3%83%BC%E3%83%89%E3%80%8C%E3%83%B4%E3%82%A1%E3%82%A4%E3%82%B9%E3%82%B7%E3%83%A5%E3%83%B4%E3%82%A1%E3%83%AB%E3%83%84%E3%80%8D%E9%99%90%E5%AE%9APR%E3%82%AB%E3%83%BC%E3%83%89%E4%BB%98%E3%81%8D/dp/B0043RT8UO/ref=pd_rhf_p_t_1

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

Answer 3

С RFC 2068 раздел 3.2.1:

Протокол HTTP не устанавливает никаких априорных ограничений на длину URI.Серверы ДОЛЖНЫ иметь возможность обрабатывать URI любого ресурса, который они обслуживают, и ДОЛЖНЫ иметь возможность обрабатывать URI неограниченной длины, если они предоставляют формы на основе GET, которые могут генерировать такие URI.Сервер ДОЛЖЕН вернуть статус 414 (Request-URI Too Long), если URI длиннее, чем может обработать сервер (см. Раздел 10.4.15).

Примечание. Серверы должны соблюдать осторожность в зависимости от длины URI выше 255байт, потому что некоторые старые реализации клиента или прокси могут не поддерживать эти длины должным образом.

Хотя IE (и, вероятно, большинство других браузеров) поддерживают гораздо более длинные длины URI, я не верю, что большинство форм или клиентскихсторонние приложения полагаются на то, что работает больше 255 байт.Журналы вашего сервера должны содержать некоторую статистику о том, какие URL вы видите.

Answer 4

Ну, вам не нужно знать среднюю длину URL.Это предположение, но я полагаю, что сокращение URL в основном используется для сокращения длинных URL.Зачем сокращать тот, который уже короткий?:)

Тем не менее, есть еще одна проблема.У базы данных тоже будут некоторые накладные расходы, поэтому вы не можете просто рассчитать среднее значение и сказать, что это средний размер байта.

Я сам написал сокращатель URL, и он уже содержит около 45 элементов.Поэтому я бы посоветовал вам написать свой, и к тому времени, когда он на самом деле содержит 2 ^ 32 URL-адресов, покупка жесткого диска объемом 8 ТБ, вероятно, больше не будет проблемой.; -)