Forum » Programiranje » [SQL] Trajanje queryja
[SQL] Trajanje queryja
sverde21 ::
Koliko dolgo bi trajala izvršitev queryja, če imam v bazi (teoretično) zapolnjene vse ID-je, ID je polje tipa BIGINT (lahko zavzema vrednosti od 0 do 18446744073709551615), imam tudi polje podatek, ki je tipa VARCHAR(20). Torej query za ustvarjenje baze je:
Iskalni query bi zgledal nekako takole:
Torej koliko časa bi moral čakati, da se mi pojavi pred očmi številka 56348796751238478 (recimo da je tukaj moj iskan rezultat).
Na razpolago imam eno dobro mašinco z Xeon procesorjem, disk v RAID polju, uglavnem top oprema
CREATE TABLE `podatki` ( `id` bigint(20) unsigned NOT NULL auto_increment, `podatek` varchar(20) NOT NULL, UNIQUE KEY `id` (`id`) );
Iskalni query bi zgledal nekako takole:
SELECT id FROM podatki WHERE podatek = 'moj iskan podatek';
Torej koliko časa bi moral čakati, da se mi pojavi pred očmi številka 56348796751238478 (recimo da je tukaj moj iskan rezultat).
Na razpolago imam eno dobro mašinco z Xeon procesorjem, disk v RAID polju, uglavnem top oprema
<?php echo `w`; ?>
- spremenil: sverde21 ()
jvolk ::
Verjetno je tudi dosti odvisno kak server boš uporabljal. Probaj na kakem manjšem primeru pa stopnjuj na več. Po moje kar dooooosti časa ... Ampak me pa vseeno zanima kaj boš hranil v tej bazi.
frudi ::
vprašaj še enkrat čez 10 ali 20 let, ko bomo imeli na svetu dovolj diskovja za takšno bazo...
1ACDoHVj3wn7N4EMpGVU4YGLR9HTfkNhTd... in case I've written something useful :)
sverde21 ::
Ja ok samo podatke bi iskal po stolpcu podatki, ki je VARCHAR se pravi je tam nek naključen set znakov.
10-20let? Mislim, da je že zj dost diskovja za tako bazo.
Hranil hmm nič za tako bazo bi rabu tolk financ, da bankrotiram miljonkrat predn jo sploh spravm skum
. Ampak vseeno iz čiste radovednosti me zanima, koliko časa bi trajalo iskanje, če bi imel nekakšen password lookup service z A-Za-z naborom znakov dolžine 1-7 se prav od A pa do zzzzzzz. Ubistvu bi tam imel 3 stolpce: id|hash|plaintext iskal bi pa po hashu. Glede na to, da je tuki kar dosti kombinacij bi rabu kar velik index. In če iščem po hash-u moram čekirati vsak hash, če se ujema, dokler ne najdem pravega in izpišem plaintext.
Sej vem da je to praktično nemogoče (za sedaj) oz. bi rabu kak super računalnik da bi to količino podatkov obraču ampak vseeno
10-20let? Mislim, da je že zj dost diskovja za tako bazo.
Hranil hmm nič za tako bazo bi rabu tolk financ, da bankrotiram miljonkrat predn jo sploh spravm skum
. Ampak vseeno iz čiste radovednosti me zanima, koliko časa bi trajalo iskanje, če bi imel nekakšen password lookup service z A-Za-z naborom znakov dolžine 1-7 se prav od A pa do zzzzzzz. Ubistvu bi tam imel 3 stolpce: id|hash|plaintext iskal bi pa po hashu. Glede na to, da je tuki kar dosti kombinacij bi rabu kar velik index. In če iščem po hash-u moram čekirati vsak hash, če se ujema, dokler ne najdem pravega in izpišem plaintext.Sej vem da je to praktično nemogoče (za sedaj) oz. bi rabu kak super računalnik da bi to količino podatkov obraču ampak vseeno
<?php echo `w`; ?>
dmok ::
Če sem dobro izračunal: velikost posamezne vrstice je max. 39 bytov (BIGINT = 8 bytov, varchar(20) = max 20 byteov + overhead, ... ). Na page velikosti 8192 bytes gre 196 zapisov. Število pageov za tak record count je približno 93.703.353.511.771.600. To pomeni velikost tabele najmanj 767.617.871.968.433.000.000 byteov oz. boš potreboval diskovja za slabih 700 EB. Potreboval bi približno 953.199.804 diskov kapacitete 750GB, cena enega je okoli 100.000 SIT vrednost vseh pa bi bila 95.319.980.379.000 SIT. No, verjetno pa lahko računaš na kakšen popust, če naročiš takšno količino.
d.
d.
sverde21 ::
Ne, ker sprašujem iz čistega firbca . Ker tudi, če bi hotu nafilat bi jo filu kr en cajt, pa še diskovja bi šlo preveč .
OK. Še eno (pod)vprašanje. Kako so računal/ugotavlal md5 collision? Torej tam moraš za vse možne inpute preverit, če se kdaj pojavi pri različnih inputih enak hash, jst si predstavlam to preverjanje, kot eno veliko bazo, po kateri se potem za vsak zgeneriran hash preverja, če se ujema z kakšnim v bazi. Se mogoče motim?
. Ker tudi, če bi hotu nafilat bi jo filu kr en cajt, pa še diskovja bi šlo preveč .OK. Še eno (pod)vprašanje. Kako so računal/ugotavlal md5 collision? Torej tam moraš za vse možne inpute preverit, če se kdaj pojavi pri različnih inputih enak hash, jst si predstavlam to preverjanje, kot eno veliko bazo, po kateri se potem za vsak zgeneriran hash preverja, če se ujema z kakšnim v bazi. Se mogoče motim?
<?php echo `w`; ?>
jeti51 ::
Seveda ne. To bi bilo nesmiselno, saj je že samo po sebi jasno, da obstaja neskončno mnogo stringov, katerih md5 hash je enak hashu nekega izbranega stringa. Skratka vsak generiran hash je enak nekemu drugemu iz baze (če imaš - teoretično - v bazi vse možne hashe).
No, če bi za nek konreten string iskali kolizijo s poskušanjem, ne bi v doglednem času nikamor pršili, torej je odgovor na tvoje vprašanje negativen. So zato potem odkrili drugačne postopke, s katerimi lahko collision najdejo bistveno bistveno hitreje.
No, če bi za nek konreten string iskali kolizijo s poskušanjem, ne bi v doglednem času nikamor pršili, torej je odgovor na tvoje vprašanje negativen. So zato potem odkrili drugačne postopke, s katerimi lahko collision najdejo bistveno bistveno hitreje.
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | SQL vprasanje (strani: 1 2 )Oddelek: Programiranje | 8333 (5012) | BivšiUser2 |
| » | java in mysql -> preveri gesloOddelek: Programiranje | 1240 (1090) | Goldee |
| » | MySql Vprasanje - problem dupliciranih kljucevOddelek: Izdelava spletišč | 1428 (1250) | KernelPanic |
| » | baze podatkovOddelek: Programiranje | 1555 (1474) | urkrajnc |
| » | anketa z vec moznostmiOddelek: Izdelava spletišč | 1611 (1490) | Packač |