Blog Divante.pl

Często planując różne aspekty skalowalności systemów informatycznych nikt nie zwraca uwagi, nie szuka zbliżonych rozwiązań które są używane w rzeczywistym świecie.

Przykładem rozwiązania które można wprost skopiować z rzeczywistości jest kodowanie nazw plików ułatwiające skalowanie systemów storage.

Kody pocztowe to dobry odpowiednik dla tego problemu.

Zwróćmy uwagę  – kod pocztowy: 64-140  -

• 6 – województwo wielkopolskie,
  4 – miasto Leszno, w województwie Wielkopolskim
• 140 – numer indeks urzędu pocztowego podlegającego pod Urząd Pocztowy Leszno – prawdopodobnie 140 można podzielić jeszcze na mniejsze jednostki logiczne.

List na każdym etapie może znać tylko następną cyfrę kodu pocztowego – 6 oznacza, że wrzucamy przesyłkę do listów jadących do wielkopolski, 4 w oznacza że list powinien wysiąść w Lesznie, a 140 kieruje nas pod adres konkretnego, lokalnego urzędu pocztowego – który zna już Ulicę czy Nazwisko adresata i wysyła listonosza.

Często w witrynach przechowujących wiele plików stosuje się podobne kodowanie nazw – dla pliku o ID (np. w bazie) 3450 tworzona jest nazwa pliku na przykład: /files/3/45/3450. Z pozoru błahostka – w rzeczywistości  – możemy każdy z katalogów na ścieżce umieścić na innym zasobie NFS i skalować nasz system bardzo prosto w poziomie. To duża siła.

Dodając dalsze składniki do identyfikatorów możemy w funkcji zwracającej adres URL na podstawie identyfikatora,  rozróżniać np. wiele serwerow plików statycznych.

Zapraszam do podawania w komentarzach innych przykładów skalowalności w świecie rzeczywistym.

Źródeł inspiracji jest wiele: Koleje, poczta / telekomunikacja, ZUS, US …

Natrafiłem niedawno na ciekawy projekt o nazwie Pyshards (http://code.google.com/p/pyshards/wiki/Pyshards).

Biblioteka jest projektem stosunkowo młodym, a cele które autorzy przed nim stawiają w dużej mierze pokrywają się z tymi które ma przed sobą nasz Ganglib.

Po krótce – pyshards zapewnia mechanizm partycjonowania poziomego – tworzenia shardów za pomocą Pythona i MySQL. Pyshards nie korzysta z mechanizmów ORM-o podobnych, a stara się zapewnić stosunkowo dużą zgodność ze standardowym sqlem.

Ciekaw jestem jak projekt się rozwinie i jakie będą jego docelowe możliwości (czy obsługa natywnego sqla będzie obejmowała także JOINy, subkwerendy i złączenia?).

ps. Z Gangliba korzysta pierwsza,  komercyjna witryna sporych rozmiarów (jeszcze w trakcie tworzenia – więcej informacji za jakiś czas )