Baza hashów md5, sha1, itp

[BlueMan 69]

1. Działa już wysyłanie hashy po ENTERze. Teraz nagle mi zadziałało... . Ustawić, aby po enterze wymazywało pole, aby nowe słowo wpisać?

2. crazyluk - już nie masz największej bazy :]

3. http://pl.php.net/manual/pl/function.mb-strcut.php i inne nie pomogły na to moje kodowanie :|

4. Co do wydajności to zejdzie mi na tym dłużej. Ma już sposób jak z 1.8sec zapytania zrobić 0.0006 sec, ale mały problem z przekazywaniem zmiennych jest.

5. Co do # to myślę jak to rozwiązać... .

[crazyluki 114]

mi enter nadal nie działa (FF3);-)

 

PS. znów jestem pierwszy;-)

[regdos 1848]

@crazyluki

Działa tylko odśwież stronę za pomocą ctrl+F5 (lub ctrl i myszką guzik odśwież)

FF3 trzyma w cache plik *.js a z ctrl-em odświeża się też cache.

 

@BlueMan

W kwestii kodowania pokaż kawałek kodu i napisz co ma zrobić.

[BlueMan 69]

$strLength = mb_strlen($word);
		$slowa = array();
		for ($i=1; $i<=$strLength; $i++) {
			//$slowo = substr($word, 0, $i);
			//$slowo = mb_strcut($word, 0, $i);
			$slowo = mb_substr($word, 0, $i);
			$slowa[] = $slowo;
			//$slowa[] = strrev($slowo);
		}

Próbowałem ustawić kodowanie w mb_strlen() na utf8/latin1/latin2 ale nic nie pomogło.

[regdos 1848]

W efekcie chcesz otrzymać tablicę z pojedynczymi znakami , które są podane jako ciąg wejściowy ?

Kodowanie ciągu i znaków ma być w UTF-8 ?

[MiSi3kK 16]

użyj iconv

 

EDIT:

 

po co na stronie głównej przy sprawdź słowo >> hash masz wybór jaki hash pokazać. Nie lepiej wyświetlać oba?

 

A jak już chcesz mieć dużą bazę to zacznij kodować wszystkie możliwe ciągi do n znaków i z czasem tylko n zwiększaj.

[regdos 1848]

użyj iconv

A co to da ?

Z utf-a na co ma przekodować ? Na nasze ISO ? a co jak ktoś wklei znaki narodowe czeskie, niemiecki lub inne ?

 

@BlueMan

 

   <?php
  $word = "zażółć gęślą jaźń";
  echo $strLength = mb_strlen($word,'UTF-8');

  $slowa = array();
  for ($i=0; $i<$strLength; $i++) {
	$slowa[] = mb_substr($word,$i,1,'UTF-8');
  }
  print_r($slowa);

  ?>

 

efekt:

 

 17

Array(
	[0] => z
	[1] => a
	[2] => ż
	[3] => ó
	[4] => ł
	[5] => ć
	[6] =>  
	[7] => g
	[8] => ę
	[9] => ś
	[10] => l
	[11] => ą
	[12] =>  
	[13] => j
	[14] => a
	[15] => ź
	[16] => ń
)

[zoozool 0]

strona załaduje się -> odświeża --> załaduje i odświeża i tak w kółko

[BlueMan 69]

@regdos - działa :] problem tylko z ostatnim znakiem się pojawił

http://www.hashcode.eu/pl/word/560747

a na stronie z listą hashów był krzak... .

[MiSi3kK 16]

A co to da ?

Z utf-a na co ma przekodować ? Na nasze ISO ? a co jak ktoś wklei znaki narodowe czeskie, niemiecki lub inne ?

 

Przeoczyłem angielską wersję strony i tym samym założyłem, że jest to strona na której wpisywane będą Polskie, ew. Angielskie ciągi znaków.

 

Dobrze, że już poprawione

[BlueMan 69]

@ragdos - ok, optymalizacja wprowadzona. Teraz za kliknięciem będą wczytywać się kolejne strony.

[BlueMan 69]

Zmiany od poprzedniej wersji:

• dodałem 4,5,6 znakowe wyrazy ze słownika j.angielskiego
  
• dodałem 13 dodatkowych typów kodowań
  
• 0-1'000'000 liczby są już w bazie (dla wszystkich 15 typów hashów)
  
• zoptymalizowałem zbieranie statystyk (teraz raz na 12 h)
  
• zoptymalizowałem dodawanie hashów (wcześniej miałem tworzone obiekty wewnątrz pętli, teraz jest to poza)
  

 

No, ale wynikły nowe problemy. Przy 19mln wpisów w bazie danych tabela ta ma ponad 4.7GB wielkości. Zbieranie statystyk z niej trwa kilka minut, a dodawanie nowych wartości jest równie pracochłonne dla systemu.

 

Na pewno problemem jest wąskie gardło dysku twardego i wielkość pliku. Jak rozwiązać ten kłopot?

Jedyne co przychodzi mi na myśl to podzielić na kilka(-naście) tabel hashe względem typu. W tym momencie miałbym 15 tabel po ~320MB, a więc totalny luz dla systemu.

 

Widzicie jakieś inne sensowniejsze rozwiązania? Bo co będzie później, kiedy także rozdrobnione tabele będą osiągać duże rozmiary... .

 

 

Z innych rozwiązań na jakie wpadłem ze znajomym to:

- każdy typ hasha w osobnej bazie danych

- podział na litery (24), cyfry (10), znaki specjalne (1), czyli ~35 tabel

 

Dzięki czemu, nawet jak jeden serwer nie będzie wyrabiać to mam możliwość rozproszenia tego na kilka maszyn.

[p 3]

No, ale wynikły nowe problemy. Przy 19mln wpisów w bazie danych tabela ta ma ponad 4.7GB wielkości. Zbieranie statystyk z niej trwa kilka minut, a dodawanie nowych wartości jest równie pracochłonne dla systemu.

Jakie nowe? Przeczytaj mój pierwszy post

 

- podział na litery (24), cyfry (10), znaki specjalne (1), czyli ~35 tabel

A co z mieszanymi ciągami znaków? Poza tym zdajesz sobie sprawę z tego, że litery są i małe i duże?

 

Jeżeli chcesz to jakoś sensownie podzielić to proponowałbym po hash'u i prefix'ie (czyli np. md5_aaa, md5_aab, itd). Ale generalnie trzymanie kombinacji klucz + wartość w tego typu bazach danych jest bez sensu. Jeżeli dodawałbyś hash'e po koleji (tzn. hash(a), hash(, itd) to na podstawie pozycji hash'a w bazie możesz odtworzyć oryginalny ciąg.

[BlueMan 69]

Z jakimi mieszanymi ciągmi znaków?

 

Podział na litery to miałem na myśli, że będzie tabela

md5_a - i w niej będą wyraz zaczynające się na literkę A

 

przetrzymywanie dużych/małych literek - u mnie baza danych nie jest case sensitive. Ogólnie nie myślałem nad tym...

 

Ale generalnie trzymanie kombinacji klucz + wartość w tego typu bazach danych jest bez sensu.

nie rozumiem?w sensie, że nie opłaca się trzymać ID? Zgodze się. Bo w tym wypadku kluczem głównym tabeli będzie słowo.

Dzięki usunięciu ID zaoszczędzamy trochę wolnego miejsca :]

[kafi 2425]

nie rozumiem?w sensie, że nie opłaca się trzymać ID? Zgodze się. Bo w tym wypadku kluczem głównym tabeli będzie słowo.

Nie w tym sensie.

W bazie powinieneś trzymać jak już, to same hashe uporządkowane wg ściśle określonego algorytmu.

Wtedy to pozycja hasha na liście pozwala na identyfikacje ciągu, do którego się odnosi.

 

 

Tylko jest jedna gwiazdka Jeśli komuś uda się opracować rozsądny algorytm do takich przyporządkowań... to właśnie okaże się, że złamał całkowicie algorytm MD5 i potrafi generować wspólne ciągi generujące kolizje

[p 3]

Z jakimi mieszanymi ciągmi znaków?

Już nie ważne, jakoś źle zinterpretowałem Twoją wcześniejszą wypowiedź.

 

przetrzymywanie dużych/małych literek - u mnie baza danych nie jest case sensitive. Ogólnie nie myślałem nad tym...

E? Chyba sobie żartujesz... Teraz to mnie zupełnie załamałeś. Przecież to są zupełnie inne znaki.

p@alix:~$ md5 -s "a"
MD5 ("a") = 0cc175b9c0f1b6a831c399e269772661
p@alix:~$ md5 -s "A"
MD5 ("A") = 7fc56270e7a70fa81a5935b72eacbe29

nie rozumiem?w sensie, że nie opłaca się trzymać ID? Zgodze się. Bo w tym wypadku kluczem głównym tabeli będzie słowo.

Dzięki usunięciu ID zaoszczędzamy trochę wolnego miejsca :]

Nie w tym sensie.

W bazie powinieneś trzymać jak już, to same hashe uporządkowane wg ściśle określonego algorytmu.

Wtedy to pozycja hasha na liście pozwala na identyfikacje ciągu, do którego się odnosi.

Dokładnie tak jak napisał Fiercio. Czyli zamiast:

string | hash
a	  | hash(a)
b	  | hash(b)

Przetrzymujemy tylko:

hash(a)
hash(b)

Bo na podstawie długości alfabetu jesteśmy w stanie określić na której pozycji znajduje się hash każdego ciągu.

 

Tylko jest jedna gwiazdka Jeśli komuś uda się opracować rozsądny algorytm do takich przyporządkowań... to właśnie okaże się, że złamał całkowicie algorytm MD5 i potrafi generować wspólne ciągi generujące kolizje

E? Albo myślimy o czymś innym, albo coś Ci się pomieszało

[BlueMan 69]

Ja wiem, że "a" i "A" to zupełnie inne hashe, ale dla bazy danych a i A to to samo. I dlatego nakałdając klucz pominąłem te różnice.

 

 

Trzymanie samych hashy jest dobre i spoooooro MB zaoszędzimy, ale wystąpić może problem ze spójnością danych w kilku bazach.

W sensie - co jak baza danych z md5 doda hasha, sha1, sha512 także, ale crc323 się wysypie (timeout, strata pakietów, czy atak wikingów). Trzeba nad tym bardzo czuwać... .

Narazie mam sesje egzaminacyjną, więc dopiero w lipcu pomyślę o jakimś systemie spójności/tranzakcji danych w rozproszonych bazach danych... .

 

 

@Fiercio z tym uporządkowanie md5 coś źle napisał bo nie ma takiej możliwości. Nie jedna głowa nad tym pracowała

[Noone 19]

Te krzaki to nie problem z kodowaniem. Dla PHP wszystkie PL znaki to takie jakby podwójne znaki - ten krzak i jeszcze coś dodatkowego, co łącznie tworzy dobrą literkę.

Dlatego też strlen() nie zwraca poprawnej długości wyrazu z PL znakami

Dlatego jak po kolei dodaję znaki, to przy PL znaku najpierw doda się krzak, dopiero potem dopełnienie i powstanie normalna literka

http://pl2.php.net/manual/en/function.mb-strlen.php

 

Ja wiem, że "a" i "A" to zupełnie inne hashe, ale dla bazy danych a i A to to samo.

Jak przeczytasz o binary to nie będzie.

 

Przy okazji chciałbym zwrócić uwagę na brak suhosin u większości dostawców - doczytać w sieci co to daje dla crypt() i jakie luki łata. Osobiście uważam że instalacja powinna byc standardem ale dla większości hostingów "kupmy sobie DA i prowadźmy firmę"to oczywiste nie jest.

[regdos 1848]

http://pl2.php.net/manual/en/function.mb-strlen.php

A zadałeś sobie trud przeczytania całego wątka ?

Bo na 2 stronie padła ta podpowiedź a dodatkowo pojawiło się rozwiązanie tego problemu.

[Noone 19]

Żeby manual miał większe PR. Tego linka nikt nie dawał Lewa nóżka od rana? Drugiej odpowiedzi (binary) chyba jeszcze nie było?

[BlueMan 69]

Mi się sam Suhosin zainstalował xD pierwsze słysze, że łata dziury PHP Dobrze wiedzieć.

 

Z binary chodzi ci o to, aby zmienić tabeli/polu typz utf8 na to binary?