След като прочетете всичките си въпроси ( уникалното ограничение прави хешовете безполезни? , 512-битов хеш срещу 4 128-битов хеш и компресиране на URL текста (не съкращаване ) и съхраняване в mysql ), разбрах, че проблемът ви е горе-долу следният:
Това ли е?
Следните точки са важни:Как е форматът на URL адреса, който ще запазите? Ще трябва ли да прочетете обратно URL адреса или просто да актуализирате информацията за него, но никога да не търсите въз основа на частични URL адреси и т.н.?
Приемайки, че URL ="http://www.somesite.com.tv/images/picture01 .jpg " и че искате да съхраните всичко, включително името на файла. Ако е различно, моля, предоставете повече подробности или коригирайте предположенията ми за отговор .
-
Ако може да спести място, като замените някаква група от знаци в URL адреса. Не всички ASCII знаци са валидни в URL, както можете да видите тук:RFC1738 , така че можете да ги използвате за представяне (и компресиране) на URL адреса. Например:използването на символ 0x81 за представяне на "http://" може да ви накара да спестите 6 знака, 0x82 за представяне на ".jpg" може да ви спести още 3 байта и т.н.
-
Някои думи може да са много често срещани (като "изображение", "картина", "видео", "потребител"). Ако изберете да използвате потребителски знаци от 0x90 до 0x9f + всеки друг знак (така че, 0x90 0x01, 0x90 0x02, 0x90 0xfa) за кодиране на такива думи, можете да имате 16 * 256 =4096 "речникови записи", за да кодирате най-използваните думи. Ще използвате 2 байта за представяне на 4 - 8 знака.
Редактиране: както можете да прочетете в споменатия RFC по-горе, в URL адреса можете да имате само ASCII знаците за печат. Това означава, че трябва да се използват само символи от 0x20 до 0x7F, с някои наблюдения, направени в RFC. Така че всеки знак след 0x80 (шестнадесетична нотация, би бил знак 128 десетичен в ASCII таблицата) не трябва да се използва. Така че, ако можете да изберете един знак (да кажем 0x90) да бъде един флаг, който да обозначава "следният байт е индикация в речника, индексът, който ще използвам". Един знак (0x90) * 256 знака (0x00 до 0xFF) =256 записа в речника. Но можете също да изберете да използвате знаци от 0x90 до 0x9f (или от 144 до 159 в десетичната запетая), за да посочите, че те са флаг към речника, като по този начин ви дават 16 *256 възможности...
Тези 2 метода могат да ви спестят много място във вашата база данни и са обратими, без да е необходимо да се притеснявате за сблъсъци и т.н. Вие просто ще създадете речник в приложението си и ще кодирате/декодирате URL адреси, като го използвате, много бързо, правейки вашата база данни е много по-лека.
Тъй като вече имате +50 милиона URL адреса, можете да генерирате статистически данни въз основа на тях, за да генерирате по-добър речник.
Използване на хешове :Хешовете в този случай са компромис между размер и сигурност. Колко лошо ще бъде, ако получите сблъсък? И в този случай можете да използвате парадокса за рождения ден за да ви помогна.
Прочетете статията, за да разберете проблема:ако всички входове (възможни знаци в URL адреса) бяха еквивалентни, бихте могли да оцените вероятността от сблъсък. И може да изчисли обратното:като се има предвид вашата приемлива вероятност за сблъсък и вашия брой файлове, колко широк трябва да бъде вашият обхват? И тъй като вашият диапазон е точно свързан с броя на битовете, генерирани от хеш функцията...
Редактиране: ако имате хеш функция, която ви дава 128 бита, ще имате 2^128 възможни резултата. И така, вашият "обхват" в парадокса на рождения ден е 2^128:сякаш годината ви има 2^128 дни, вместо 365. И така, вие изчислявате вероятностите за сблъсък ("два файла роден в същия ден, с година които имат 2^128 дни вместо 365 дни). Ако изберете да използвате хеш, който ви дава 512 бита, вашият диапазон ще премине от 0 до 2^512...
И отново, имайте предвид RFC:не всички байтове (256 знака) са валидни в света на интернет/URL адресите. Така вероятността от сблъсъци намалява. По-добре за теб :).
