największy klaster staje się jeszcze większy

zasoby serwerowe google'a są szacowane na około 450 tysięcy serwerów (microsoft jest szacowany na około 200 000). fakt, że każdy z nich to prościutki pecet nie zmniejsza ogromu skali w jakiej działa googleplex.

i google nadal rośnie. buduje nowe serwerownie: w rosji, chinach, a także u siebie – w stanach.

ostatnio słychać sporo o nowym centrum, w miejscowości dalles w oregonie (dalles, nie dallas). dalles to mała mieścina – ledwie 12000 ludzi.

ale ma sporo plusów – mieści się na granicy stanów więc bezproblemowo można sie połączyć do dwóch niezależnych sieci energetycznych, niedaleko jest zapora wodna dostarczająca tanią energię, no i na miejscu jest lotnisko.

google powstaiło tam już 2 duże hale na serwery (urządzenie chłodzące są w 4 piętrowych budynkach obok hal!), i ma pozwolenie na jeszcze jeden taki budynek. w całości będą się mieścić kolejne dziesiątki tysięcy procesorów i dysków i terabajty ramu.

poza google'em inni potentaci też się rozbudowują – zarówno microsoft jak i yahoo budują swoje supercentra (niedaleko od dalles, w  wenatchee (microsoft) i quincy (yahoo), jakieś 200 kilometrów na północ od dalles), ale oni “gonią" google'a, podczas gdy ten po prostu umacnia swoje prowadzenie.

co z tego wyniknie? oczywiście nowe serwery posłużą do tego by search działał szybciej dla większej ilości ludzi. ale czy tylko? niedawno jeden z pracowników google'a, mówić, że serwery obsługujące video.google.com są już mocno obciążone – jakby nie patrzyć danych jest dużo. może więc to nie na searcha a na video?

a może na zupełnie nowe usługi? gbuy (google'owska wersja pay-pala) ma wystartować niedługo – co cieszy zwłaszcza tych którzy używają google base jako platformy do sprzedaży. a może jeszcze coś zupełnie innego? gdrive? publicznie dostępny writely?  czas pokaże.

ignoracja użytkowników największym zagrożeniem?

jakiś czas temu the register donosił o ty, że spora część ludzi jest gotowa oddać hasło w zamian za długopis czy wart $3 kupon na zniżkę w star bucks.

teraz się okazało, że nie trzeba nikogo o nic prosić. wystarczy zostawić gdzieś pendrive'a z wirusem, a już ktoś go znajdzie i sam użyje do zainfekowania.

prawie co tydzień pojawiają się informacje o tym, że ktoś tam zgubił firmowego laptopa i dane klientów są zagrożone.

czy niefrasobliwość i ignorancja użytkowników nie mają limitów? czy jedyną możliwością jest oddawanie do użytkowania nieruszalnych komputerów bez portów? z myszką i klawiaturą podłączoną na stałe?

naprawdę cenne dane?

masz jakieś naprawdę cenne dane? i potrzebujesz je przenieść? może ten produkt jest rozwiązaniem: wodo, ognio, kulo -odporny pen-drive, o pojemności od 32MB to 2GB. cena jeszcze nie ustalona, ale pewnie nie będzie niska 🙂

zmienna lista “cech”

przy wielu projektach pojawia się potrzeba przechowywania zmiennej listy “cech" jakichś obiektów.

weźmy na przykład sklep internetowy: mamy jakieś tam kategorie (struktura drzewiasta, moja ulubiona 🙂 ), w nich produkty. każdy produkt ma pewne cechy stałe – cena, tytuł, opis. natomiast produkty w określonych kategoriach mają swoje własne cechy dodatkowe.

np. dla samochodów możemy chcieć przechowywać:

  • ilość drzwi
  • pojemność silnika
  • typ paliwa
  • rodzaj skrzyni biegów

z drugiej strony, ogłoszenia w kategorii komputery będą miały pola takie jak:

  • ilość pamięci
  • wielkość dysku
  • typ procesora

najprostszym rozwiązaniem jest trzymanie produktów w każdej kategorii w oddzielnej tabelce – gdzie każda z tych tabelek ma różną strukturę (inna lista pól).

jest to rozwiązanie nieakceptowalne – osobiście uważam, że jakiekolwiek rozwiązanie zakładające modyfikacje struktury bazy danych w trakcie normalnego użytkowania jest błędne.

inną metodą jest zrobienie sobie tabelki typu:

 CREATE TABLE zmienne_cechy (
id         SERIAL PRIMARY KEY,
produkt_id INT  NOT NULL REFERENCES produkty(id),
cecha1     TEXT,
cecha2     TEXT,
cecha3     TEXT,
cecha4     TEXT,
...
);

i pilnowanie, że dla danego produktu kolumna cecha1 oznacza pojemność silnika, a dla innego jest to ilość pamięci.

takie rozwiązanie ma swoje zalety – najważniejszą jest to, że aby wyciągnąć informacje o wszystkich polach dla danego produktu wystarczy pobrać jeden rekord z bazy.

ale dopóki nie obsługujesz miliona page-views dziennie w swoim sklepie – ten problem jest mało istotny 🙂

zdecydowanie najskuteczniejszą metodą jest tabelka:

 CREATE TABLE zmienne_cechy (
id         SERIAL PRIMARY KEY,
produkt_id INT  NOT NULL REFERENCES produkty(id),
cecha      TEXT,
wartosc    TEXT
);

taka tabelka w jednej prostej strukturze pozwala na zapisanie wszystkich mozliwych cech i łatwe wyszukiwanie. no właśnie. czy na pewno łatwe?

tabelka pokazana taka jak tu – jest może i fajna, ale brakuje jej jeszcze jednej rzeczy:

create unique index ui_zmienne_cechy_pic on zmienne_cechy (produkt_id, cecha);

jeśli nie czytacie sql'i ze 100% zrozumieniem, to powyższe powoduje, że dany produkt może mieć tylko jedną wartość danej cechy. może mieć dowolnie wiele cech, ale żadna z cech nie może mieć wielu wartości.

zazwyczaj takie ograniczenie w niczym nie przeszkadza. zdarzają się czasem (ale bardzo rzadko) sytuacje, że istnieje potrzeba wielu wartości jednej cechy – sugeruję by wtedy nie kasować tego indeksu/klucza unikalnego tylko po prostu użyć ciut innych cech.

czemu?

otóż taka tabelka z pokazanym kluczem unikalnym pozwala nam w trywialny sposób zrobienie tego co bez klucza jest dużo trudniejsze (zasobochłonne): znalezienia produktów w/g kilku cech jednocześnie.

załóżmy, że chcemy znaleźć samochody o pojemności silnika 2000 z automatyczną skrzynią biegów.

bez klucza unikalnego jesteśmy skazani na coś takiego:

 SELECT zc1.produkt_id
FROM zmienne_cechy zc1 JOIN zmienne_cechy zc2 ON zc1.produkt_id = zc2.produkt_id
WHERE zc1.cecha='pojemnosc silnika' AND zc1.wartosc = '2000' AND zc2.cecha = 'skrzynia biegow' AND zc2.wartosc = 'automat';

nie jest to oczywiście takie złe. ale przy dużej ilości produktów stanie się problematyczne. nie mówiąc o tym jak będziemy chcieli sprawdzić produkty w/g np. 5 cech na raz. 5 joinów? jeśli w bazie jest np. 1000 produktów i każdy ma średnio 10 cech, to łączymy 5 razy ze sobą tabelę o 50000 rekordów. i szukamy na nich wszystkich. mało przyjemne.

dodanie wspomnianego wyżej klucza unikalnego pozwala na użycie w naszym select'cie rzadko używanej (i słabo znanej) klauzuli HAVING:

 SELECT produkt_id
FROM zmienne_cechy
WHERE
(cecha='pojemnosc silnika' AND wartosc='2000')
OR
(cecha='skrzynia biegow' AND wartosc = 'automat')
GROUP BY produkt_id
HAVING COUNT(*) = 2;

powstałe zapytanie ma kilka zalet:

  • jest trywialnie rozbudowywalne o kolejne cechy – bez konieczności dodatkowych joinów = wystarczy dodać dodatkowe warunki i podbić wartość w klauzuli having
  • jeśli używamy postgresql'a 8.1 i mamy dodatkowo indeks dwupoowy na (cecha, wartosc), to postgresql uzyje bardzo szybkich bitmap-or'ów

moje testy wykazały, że na postgresie 8.1 obie metody dają bardzo podobne wyniki (chodzi o czas zapytania) jeśli szukamy dwóch cech, natomiast już od 3 przewaga rozwiązania z having jest olbrzymia.

pociąga cię nauka? masz niestandardowe pomysły? a może chciałbyś na tym zarabiać?

mam prenumeratę takiego pisma: wired. w ostatnim numerze jest artykuł nt. crowdsourcingu.

w dużym skrócie – chodzi o zlecanie prac/zadań do wykonania ogółowi ludzi – w jakiś publiczny sposób. na zasadzie – zrobisz, dostaniesz kasę. bez umów i takich tam.

jednym z “działów" tego typu działalności jest (co mnie trochę zszokowało) r&d (research & development) w dużych firmach (procter & gamble, boeing, dupont).

powstał serwis gdzie biorące udział firmy publikują zadania – można je przejrzeć bez żadnej rejestracji – otwarte dla każdego.

za wykonanie jest kasa. i to całkiem spora.

np. teraz jest zadanie za $50000 (CATALYST SYSTEM FOR THE SYNTHESIS OF A MONORESORCINYL-TRIAZINE, cokolwiek by to nie znaczyło).

serwis zasadniczo tyczy się chemii i biologii, ale nie jest wymagane żadne doświadczenie. w artykule czytałem wręcz, że najlepsze rezultaty osiągają ludzie którzy nie mieli żadnego wykształcenia w danym kierunku, tylko po prostu mają szerokie zainteresowania.

dodatkowo – mimo, że zadanie jest np. “chemiczne" nie oznacza, że trzeba je chemicznie rozwiązać. np. jedno z zadań zostało wykonane przez odpowiednie doprowadzenie energii elektrycznej i uziemienia.

oczywiście nie każdy da radę się zmieżyć z problemami tam opisanymi. ale może warto spojrzeć i w wolnej chwili się zastanowić?

clerks (sprzedawcy) – część druga

firmy kevina smitha można kochać lub nienawidzieć.

należę do tych którzy je uwielbiają. podobał mi się nawet mallrats (za który kevin przeprosił fanów) i ostatni, mocno przesadzony jay i milczący bob kontratakują.

po tych 5 specyficznych filmach, kevin nakręcił jersey girl – zupełnie inny film, dużo bardziej stonowany, ale i tak z kilkoma charakterystycznymi dla jego filmów tekstami.

teraz – wrócił do korzeni – nakręcił kontynuację hitu sprzed lat – sprzedawców.

nie zdradzając fabuły – są i dante, i randal i para charakterystycznych dealerów 🙂 i teksty. fenomenalne (bazuję na tym co w trailerze, filmu jeszcze nie widziałem). po pokazie w cannes film dostał 8 minutową owację na stojąco. kiedy w polsce?