Setelah membaca semua pertanyaan Anda ( batasan unik membuat hash tidak berguna? , hash 512 bit vs 4 hash 128bit dan kompresi teks url (tidak memperpendek ) dan menyimpan di mysql ), saya mengerti bahwa masalah Anda kurang lebih sebagai berikut:
Apakah itu?
Poin-poin berikut ini penting:Bagaimana format URL yang akan Anda simpan? Apakah Anda perlu membaca kembali URL, atau hanya memperbarui informasi tentangnya, tetapi tidak pernah menelusuri berdasarkan sebagian URL, dll?
Dengan asumsi URL ="http://www.somesite.com.tv/images/picture01 .jpg " dan bahwa Anda ingin menyimpan semuanya, termasuk nama file. Jika berbeda, berikan detail lebih lanjut atau perbaiki asumsi jawaban saya .
-
Jika dapat menghemat ruang dengan mengganti beberapa kelompok karakter di URL. Tidak semua karakter ASCII valid dalam URL, seperti yang Anda lihat di sini:RFC1738 , sehingga Anda dapat menggunakannya untuk mewakili (dan mengompres) URL. Misalnya:menggunakan karakter 0x81 untuk mewakili "http://" dapat membuat Anda menyimpan 6 karakter, 0x82 untuk mewakili ".jpg" dapat menghemat 3 byte lagi, dll.
-
Beberapa kata mungkin sangat umum (seperti "gambar", "gambar", "video", "pengguna"). Jika Anda memilih karakter pengguna 0x90 hingga 0x9f + karakter lain (jadi, 0x90 0x01, 0x90 0x02, 0x90 0xfa) untuk mengkodekan kata-kata tersebut, Anda dapat memiliki 16 * 256 =4.096 "entri kamus" untuk mengkodekan kata-kata yang paling sering digunakan. Anda akan menggunakan 2 byte untuk mewakili 4 - 8 karakter.
Sunting: seperti yang dapat Anda baca di RFC yang disebutkan, di atas, di URL Anda hanya dapat memiliki karakter ASCII yang dapat dicetak. Ini berarti bahwa hanya karakter 0x20 hingga 0x7F yang harus digunakan, dengan beberapa pengamatan dilakukan di RFC. Jadi, karakter apa pun setelah 0x80 (notasi heksadesimal, akan menjadi karakter 128 desimal dalam tabel ASCII) tidak boleh digunakan. Jadi, jika dapat memilih satu karakter (katakanlah 0x90) menjadi satu bendera untuk menunjukkan "byte berikut adalah indikasi dalam kamus, indeks yang akan saya gunakan". Satu karakter (0x90) * 256 karakter (0x00 hingga 0xFF) =256 entri dalam kamus. Tetapi Anda juga dapat memilih untuk menggunakan karakter 0x90 hingga 0x9f (atau 144 hingga 159 dalam desimal) untuk menunjukkan bahwa karakter tersebut adalah tanda bagi kamus, sehingga memberi Anda 16 *256 kemungkinan...
2 metode ini dapat menghemat banyak ruang dalam database Anda dan dapat dibalik, tanpa perlu khawatir tentang tabrakan, dll. Anda cukup membuat kamus di aplikasi Anda dan menggunakan encode/decode URL, sangat cepat, membuat database Anda jauh lebih ringan.
Karena Anda sudah memiliki +50 juta URL, Anda dapat membuat statistik berdasarkan URL tersebut, untuk menghasilkan kamus yang lebih baik.
Menggunakan hash :Hash, dalam hal ini, adalah tradeoff antara ukuran dan keamanan. Seberapa buruk jadinya jika Anda mendapatkan tabrakan? Dan dalam hal ini Anda dapat menggunakan paradoks ulang tahun untuk membantu Anda.
Baca artikel untuk memahami masalahnya:jika semua input (kemungkinan karakter dalam URL) setara, Anda dapat memperkirakan kemungkinan tabrakan. Dan dapat menghitung kebalikannya:dengan kemungkinan tabrakan yang dapat diterima, dan jumlah file Anda, seberapa luas jangkauan Anda? Dan karena jangkauan Anda benar-benar terkait dengan jumlah bit yang dihasilkan oleh fungsi hash...
Sunting: jika Anda memiliki fungsi hash yang memberi Anda 128 bit, Anda akan memiliki 2^128 kemungkinan hasil. Jadi, "rentang" Anda dalam paradoks ulang tahun adalah 2^128:sepertinya tahun Anda memiliki 2^128 hari, bukan 365. Jadi, Anda menghitung probabilitas tabrakan ("dua file sedang lahir di hari yang sama, dengan tahun yang memiliki 2^128 hari bukannya 365 hari). Jika Anda memilih untuk menggunakan hash yang memberi Anda 512 bit, rentang Anda akan berubah dari 0 hingga 2^512...
Dan, sekali lagi, ingatlah RFC:tidak semua byte (256 karakter) valid di dunia internet/URL. Jadi, kemungkinan tumbukan berkurang. Lebih baik untukmu :).
