=$

|

praktycznie od zawsze na listach dyskusyjnych bazo danowych, forach, grupach i kanałach ircowych pojawia się jeden temat: “czy i jak przechowywać w bazie obrazki?". oczywiście nie chodzi tylko o obrazki. chodzi o wszelkiego typu pliki binarne – obrazki, filmy, muzykę, pliki z danymi (excel, word itd.).

osobiście jestem przeciwnikiem trzymania tego typu rzeczy w bazie. ale zrobiłem ostatnio mały research aby wypisać często pojawiające się argumeny za i przeciwko takiemu rozwiązaniu.

te argumenty postaram się skomentować, choćby po to by samemu mieć pewność, że mój wybór jest lepszy.

podstawowymi argumentami “za" trzymaniem plików w bazie danych są:

1. trzymanie ich w bazie upraszcza zarządzanie. praca z np. 100 obrazkami nie jest problemem tak czy inaczej, ale jak poradzić sobie jak jest ich kilka milionów?
2. wystarcza jeden prosty backup. w tym backupie jest wszystko co konieczne do wznowienia pracy.
3. bezpieczeństwo – posiadanie danych w bazie umożliwia proste filtrowanie dostępu.
4. pliki poza bazą danych są narażone na rozsynchronizowanie z bazą – skasujemy rekord z bazy, a pliku nie, albo odwrotnie i katastrofa gotowa.
5. zapisanie pliku do bazy jest prostsze niż wydzielanie oddzielnego api do zapisywania na filesystemie

podstawowymi (dla mnie) argumentami przeciwko trzymaniu ich w bazie są:

1. obrazki zajmują zazwyczaj sporo więcej miejsca niż pozostałe dane. to powoduje pewne utrudnienia przy korzystaniu z baz danych które wymagają prealokacji przestrzeni dyskowej.
2. przesyłanie obrazków wykrzystuje bardzo nieetektywnie połączenia do bazy – połączenie trwa długo i praktycznie nic nie robi
3. przechowywanie obrazków w bazie praktycznie nic nam nie daje od strony bazodanowej. inne typy danych są użyteczne przy budowaniu warunków wyszukania, łączenia czy sortowania – i w ten sposób “zarabiają" na to by umieścić je w bazie. obrazków (ich plików) nie da się do tego wykorzystać.
4. systemy plików w nowych systemach operacyjnych są mocno zoptymalizowane w celu szybkiego dostarczania i cache'owania plików. dodatkowo – nowoczesne serwery http potrafią korzystać z mechanizmów systemu operacyjnego do dalszego przyspieszenia wysłania obrazka.

dodatkowo czasem pojawia się jeszcze jeden argument, który jest używany przez zwolenników trzymania plików w bazie, mimo, że jest argumentem “negatywnym" – wykazującym jedynie brak sensu jednego z argumentów przeciwników.
chodzi o to, że zwolennicy twierdzą, że co prawda trzymanie plików w bazie zwalnia bazę, ale obecnie stosowane serwery są i tak bardzo szybkie, pamięć jest tania, dyski też, więc to nie problem.

argument ten traktuję bardziej jako “wyznanie wiary" niż stwierdzenie faktu. pamięć może i jest tania gdy mówimy o pamięcy do pecetów czy do serwerów tak do 8 giga ramu. każda osoba która korzysta z większych maszyn wie, że ceny pamięci rosną lawinowo powyżej tej granicy – w szczególności 16 giga ramu kosztuje dużo więcej niż 2x koszt 8 giga ramu. a co do dysków – fakt robią się coraz tańsze, ale też wymagamy od nich więcej. macierz którą ostatnio się bawiłem kosztowała około $55000. to nie są “grosze".wróćmy więc do bardziej sensownych argumentów.

argumenty “za":
1. to jest istotny problem. bazy danych świetnie sobie radzą z tabelami mającymi kilka milionów rekordów. natomiast katalog z kilkoma milionami plików to porażka.ale wydaje mi się, że problem jest rozdmuchany. wystarczy wymyśleć sensowną konwencję nazewnictwa katalogów/plików i problem znika. przykładowo – w systemie nad którym ostatnio sporo siedzę, nazwy plików są stworzone przez taką transformatę:

• metadane obrazka są wpisywane do bazy
• obrazek dostaje swoje id – integera
• integera konwertujemy na wartość hexadecymalną
• dopełniamy opcjonalnym zerem do parzystej ilości cyfr
• wstawiamy “slashe" między pary cyfr
• i doklejamy rozszerzenie.

brzmi skomplikowanie. ale jest proste. przykład:

• obrazek o id: 1533672
• po konwersji na hex uzyskujemy: 1766e8
• ilośc cyfr jest parzysta więc nie muszę dopełniać (dostawiać z przodu 0)
• wstawiam slashe i uzyskuję: 17/66/e8
• dodaję rozszerzenie i mam: 17/66/e8.jpg
• i koniec.

dzięki temu na każdym poziomie katalogów z obrazkami mam maksymalnie 512 pozycji (256 plików i 256 katalogów). wyszukiwanie i serwowanie tego jest szybkie i proste.

2. jeden prosty backup może i tak. ale ten argument się w/g mnie mocno kłóci z milionami plików.

dużo prościej jest zbackupować bazę o wielkości x giga i do tego katalog z milionem plików niż bazę danych o wielkości x giga + ten milion plików.

czyli – prosty backup tak, ale dla relatywnie małych ilości plików. potem się okazuje, że zwykły dump staje się nierealny i trzeba używać rzeczy typu hot-backup.

3. argument celny o ile pliki są wystawione “po prostu" w documumentroot'cie apache'a.

ograniczanie dostępu na poziomie bazy jest oczywiście miłe i proste, ale zrobienie tego samego po stronie apache'a też nie jest trudne – są .htaccess'y, mod_perl, mod_rewrite, zarządzanie uprawnieniami “w locie". wymaga to trochę innego zestawu umiejętności niż zaprogramowania aplikacji, ale w końcu nie jest to jakiaś wiedza tajemna. są manuale, są przykłady.

dodatkowo – dla większości aplikacji kontrola dostępu do plików binarnych nie jest niezbędna. zazwyczaj (nie zawsze!) są one tylko dodatkiem do danych tekstowych.

sam znam kilka miejsc gdzie obrazki są w ogóle nie chronione – chroni się teksty. jak ktoś się domyśli jaki jest url do obrazka – fajnie. da się przeżyć. a jak się nie da – są metody naprawdę prostej ochrony takich danych.

4. to faktycznie jest problem. w sensie – nie da się zapewnić braku możliwości skasowania pliku z filesystemu. a i robienie triggera kasującego plik z filesystemu przy skasowaniu rekordu byłoby problematyczne (choćby kwestia konieczności użycia poleceń systemowych, co większość baz danych utrudnia, czy rollbacków).

natomiast realnie (mówiąc realnie mam na myśli serwisy którymi się zajmuję) – problem tak naprawdę nie występuje. pliki są wgrywane na filesystem. nikt ich ręcznie stamtąd nie kasuje. dostęp na roota jest limitowany do adminów, innych kont praktycznie na webserwerach nie ma.

jak plik zostanie skasowany z bazy (w sensie, jego metadane) – to przecież istnienie go na dysku nam nie przeszkadza – tzn. zajmuje trochę miejsca, ale to wszystko.

aby to zużycie miejsca przez skasowane pliki zminimalizować wystarcza naprawdę prosty automat który robi listę plików w filesystemie, listę plików z bazy, porównuje i kasuje te których nie powinno być. mały cron który np. raz dziennie robi porządki. nam ten cron zajął jakieś 20 minut pracy. to chyba nie jest za dużo?

5. ostatni argument nt. prostoty api muszę przyznać, że mnie zaskoczył.

spotkałem się z nim relatywnie najrzadziej, ale i tak pojawił się kilka razy. musiałem się nad nim chwilę zastanowić. efekt?

pomyślmy. api wpisu obrazka do bazy dla fajnych baz wygląda:

INSERT INTO obrazki (file) VALUES (‘?');

i wstawienie tak danych binarnych. to jest faktycznie proste. do czasu.

po przejści na inną (większą) bazę pojawiają się bloby których obsługa jest już zdecydowania inna. trzeba otworzyć, pisać, zamknąć – zupełnie jak przy pliku.

co do obsługi pliku, wystarcza trójca: open(); write(); close();. niezależnie od języka programowania wygląda to zasadniczo podobnie. dodatkowo część języków ma wbudowane mechanizmy do robienia tego jeszcze prościej – np. w perlu, można użyć modułu io::all, i potem takiej konstrukcji:

$dane > io(‘/tmp/some.file');

co zajmie się otwarciem, zapisaniem i zamknięciem. bezpiecznie. z obsługą sytuacji krytycznych.

i zadziała tak samo dla site'u mającego 400 wizyt tygodniowo i takiego co ma 400 wizyt na sekundę.

tak więc prostota api wydaje mi się być mocno dyskusyjna. ale ponieważ się pojawiła, trzeba było skomentować 🙂

zostały argumenty przeciwników zapisywania obrazków w bazie – z nimi pójdzie mi łatwiej, bo są to też moje argumenty:

1. na temat tego argumentu mam relatywnie najmniej do powiedzenia. do tej pory używałem dwóch baz wymuszającym prealokację przestrzeni (adabas d i oracle). w obu przypadkach uznałem pomysł za chybiony i maksymalnie upierdliwy. nie jestem specem od oracle'a czy adabasa. może się da to jakoś rozwiązać ładniej. ale jedna rzecz mnie “boli":

mając plik na dysku który ma 1 megabajt. zajmuje on na dysku fizycznie ten 1 megabajt plus wielkosć inode'a. łącznie powiedzmy 1 megabajt i 1 kilobajt.

plik w bazie podlega innym regułom. np. w postgresie – pole dłuższe niż 2 kilobajty jest dzielone i przechowywane w tabelach typu “toast". realnie oznacza to, że na każde 2 kilobajty jest zapisywane dodatkowo około 26 bajtów (plus 4 jeśli używamy oid'ów).

oznacza to, że nasz 1 megabajtowy obrazek w bazie zajmuje około 1megabajt i 13 kilobajtów.
12 dodatkowych kilobajtów to niedużo. a co jak obrazków jest milion?

2. z mojej dotychczasowej praktyki z bazami wynika, że jednego zasobu nigdy nie ma za dużo – są to połączenia do bazy. wystarczy jedno źle napisane zapytanie i potrafi zapchać serwer tak, że nawet najprostsze i najszybsze selecty się nie wykonają. z tego punktu widzenia obrazki to koszmar.

mały, prosty select, indeksowany – powinien być błyskawiczny. i faktycznie jest. dopóki czytamy dane lokalnie.

jeśli jednak request jest zdalny, to połączenie będzie wykorzystywane przez cały czas transmisji do klienta. czyli w skrajnym przypadku kilka minut. oops? czy widzicie ten problem?

nie ma znaczenia co zrobicie – wystarczy, że więcej ludzi zechce obejrzeć wasze obrazki korzystając z kiepskich łącz i system siada. a chyba nie o to chodziło?

3. to wydaje się być oczywiste. wrzucenie do bazy danych np. wielkości obrazka pozwala na proste filtrowanie. daty daje możliwość wyszukania najnowszych obrazków. a co nam daje wrzucenie samego obrazka? nic.

baza nie będzie filtrowała używając danych obrazka. nie założymy na tym indeksu. nie zrobimy order by czy nic takiego. po prostu dane do jednokrotnego wstawienia i selectowania. zero zysku przy dostępie.
4. ten argument wydaje mi się najistotniejszy.rozważmy co musi zrobić aplikacja aby zaserwować obrazek.

załóżmy, że nasza aplikacja jest w php, pracuje pod apache'em. baza danych – postgres.

• php otwiera połączenie do postgresa (albo korzysta z gotowego)
• wysyła zapytanie
• postgres szybko znajduje plik w tabeli
• odczytuje rekord
• zwraca do php
• znajduje nastepny blok
• odczytuje
• przesyła do php
• itd. aż do końca pliku.
• wtedy postgres informuje: to już koniec
• a php przesyła to do klienta.

skomplikowane. w dodatku – postgres nie ma i nie może mieć za bardzo zoptymalizowanego dostępu do tego pliku – w końcu – to dane jak inne.
co się dzieje gdy request o plik trafia do apache'a który serwuje pliki statyczne z filesystemu?

• mając otwarte połączenie do klienta
• apache otwiera plik który ma serwować
• a następnie wykonuje jednego syscalla: sendfile

ten syscall realizuje przesłanie zawartości jednego uchwytu pliku do drugiego. w tym przypadku całej zawartości pliku do klienta. całośc odbywa się w kernelu i jest niesamowicie szybka.
zgadza się, że nowe maszyny są szybsze niż kiedyś. ale wymagamy od nich więcej. i jeśli mam obsłużyć 2 miliony page-views dziennie, to nie będę poświęcał czasu maszyn na “durne" przerzucanie danych między procesami (baza, php, klient) skoro można po prostu przepompować dane na poziomie kernela. bez żadnych pętli, warunków itd.

do tego wszystkiego dochodzi jeszcze jeden argument – dla mnie istotny. w życiu każdego systemu pojawia się sytuacja, że kończy się wydajność sprzętu. trzymając wszystko w bazie musimy modyfikować serwer bazodanowy. a mając dane “rozrzucone" mamy większe marginesy bezpieczeństwa i więcej możlwości modyfikacji.

cały czas sensowne klastrowanie baz danych jest marzeniem. są produkty które to robią, ale kosztują horrendalne pieniądze.

natomiast klastrowanie apache'y czy innych fileserwerów jest proste, łatwe i praktycznie bezkosztowe (poza sprzętem oczywiście).

kończąc ten wpis – na pewno są sytuacje gdy względy różne (prawne czy biznesowe) wymuszają stosowanie przechowywania obrazków w bazie. wierzę, że są też takie sytuacje i takie powody o których ja nie wiem.
wiem jednak, że dla praktycznie wszystkich trzymanie obrazków w bazie jest dobrowolną rezygnacją z wydajności i skalowalności w imię mitycznych i łatwo obalalnych idei.

przeczytałem właśnie o interesującej sprawie.

bardzo dawno temu, w 1957 roku, niejaki paul reviczky wyemigrował z węgier do kanady (wtedy się pewnie inaczej nazywał).

w kanadzie pracował. kupił dom, miał rodzinę. szczęśliwy facet.

przywiązał się do domu w którym spędził tyle czasu – na tyle, że nawet zapisał w testamencie by go nie sprzedawać tylko wynajmować aby jego rodzina miała z niego jakieś dodatkowe pieniądze.

w 2005 został sam, bo zmarła mu żona. a ostatnio – okazało się, że dom sprzedał.

ale nie on.

podobno dom sprzedał jego wnuk, z tym, że facet wnuka nie posiada.

całkowicie legalna transakcja, z podpisami poręczonymi przez notariusza (podobno paul się pojawił i okazał prawo jazdy jako dowód tożsamości).

dom kupiło jakieś małżeństwo za 450000 dolarów (pewnie kanadyjskich, ale nie jestem pewien). z czego $337500 pochodziło z kredytu hipotecznego.

dom miał być inwestycją dla ich syna.

i tu zaczyna się “akcja".

starszy pan oczywiście domu nie sprzedał – nawet mu to przez myśl nie przeszło. okazuje się, że ktoś podszył się pod niego i, mówiąc wprost, ukradł rzeczone $450000.

wydawało by się sprawa oczywista. ale nie. okazuje się, że w kanadzie prawo chroni prawa nabywcy jeśli kupując nie wiedział o przestępstwie. czyli nabywcy mają większe prawa do domu niż facet który w nim mieszkał wiele lat i go nie sprzedał.

aktualnie sytuacja wygląda tak, że starszy pan wyniósł się do rodziny, adwokaci walczą, dom na nieustalony status prawny, więc nowi nabywcy też nie mogą się wprowadzić. i dom niszczeje.

w dodatku – nie jest to przypadek odosobniony. ostatnio takich sytuacji w kanadzie jest coraz więcej. na tyle, że ichniejszy parlament pracuje obecnie nad modyfikacją przepisów tak aby nie dochodziło do tak abstrakcyjnych sytuacji jak pozbawienie kogoś domu.

ross anderson napisał jakiś czas temu książkę “security engineering". książka ta została wydana 5 lat temu i można ją sobie było kupić na np. amazonie.

zdobyła pewne uznanie – w tym polecenie od samego bruce'a schneiera.

teraz – autor dostał od wydawnictwa zgodę na udostępnienie jest w sieci za darmo. tak więc zachęcam – ze strony książki można ściągnąć (legalnie!) każdy rozdział w pdf'ie i przeczytać. a jak się spodoba – kupić wydrukowane.

książka porusza temat projektowania i tworzenia systemów informatycznych w sposób bezpieczny. taki by powstały system zachowywał się przewidywalnie, oraz by przechowywane w nim dane nie były narażone na różnego rodzaju ataki.

na stronach gazeta.pl pojawił się wywiad z ivarem tallo – szefem agencji zajmującej się wprowadzaniem internetu do administracji publicznej w estonii.

jak może wiecie, estonia jest najbardziej zinternetyzowanym krajem z wszystkich państw byłego “bloku" komunistycznego. i jednym z najbardziej na świecie.

wywiad warto przeczytać. choćby po to by dowiedzieć się jak uzyskali np. to:

• dowód osobisty jest z chipem, po włożeniu do czytnika w komputerze i wpisaniu pinu – można zobaczyć wszystkie informacje jakie państwo o tobie posiada.
• deklaracje podatkowe składa przez internet 82 proc. podatników
• przez stronę www w kilka minut można zapłacić podatki, cło czy składkę emerytalną
• oceny i uwagi w szkołach wpisywane są w szkolne serwery i od razu udostępniane zainteresowanym
• darmowe punkty internetowe są w każdej miejscowości
• wystarczy wysłać SMS-a za 3 zł, by przez cały dzień móc surfować (wifi ma zasięg na prawie całej powierzchni kraju)

co jakiś czas czytam informację o tym, że gdzieś jest fajnie.

a to wimax w pociągu w kaliforni, a to coś fajnego w anglii. pocieszam się myślą, że oni mieli łatwiej, nie mieli komunizmu. ale estonia? dlaczego u nas tak nie ma?

jak może wiecie wahadłowce to dosyć stara technologia – zasadniczo z końca lat 70.

w tej chwili pozostały 2 w czynnej służbie, a ich utrzymanie jest skomplikowane i kosztowne.

nasa rozpisała przetarg na nowe pojazdy do podróży załogowych. zasadniczo wszyscy oczekiwali, że wygra konsorcum boinga i northop-grummanem – oni byli wykonawcami poprzednich statków i mają doświadczenie z lotami załogowymi.

nieoczekiwanie przetarg wygrała firma lockheed-martin. nie jest to firma nieznana. rzecz w tym, że do tej pory zajmowała się (jeśli chodzi o loty w kosmos) lotami bezzałogowymi.

a nowy plan jest imponujący. projekt “orion" zakłada, że pierwsze loty załogowe nowymi pojazdami odbędą się w 2014 roku. najpóźniej w 2020 ma odbyć się załogowy lot na księżyc – właśnie jednostką tego typu.

co interesujące – projekt ten zakłada, że te same pojazdy zostaną użyte w zupełnie nowej podróży – jakiej jeszcze żaden człowiek się nie podjął – podróży na inną planetę – marsa.

na razie termin podróży na marsa nie jest ustalony, ale sam rozmach przedsięwzięcia budzi respekt. czy im się uda? czy w 2030 (strzelam z tą datą) dowiemy się o pierwszym kroku człowieka na innej planecie? fajnie byłoby dożyć czegoś takiego.

niedawno pisałem o cięciach w aol i sun'ie. teraz o intelu. intel właśnie stwierdził, że zwolni 10.000 ludzi. głównie marketing.

nigdy za marketingowcami nie przepadałem, ale teraz mną trąciło. i nie dlatego, że 10000 ludzi “pójdzie na bruk". chodzi o motyw.

bynajmniej nie chodzi o problemy finansowe. nie chodzi o cięcie kosztów itd.

10000 ludzi straci pracę, bo ktoś stwierdził, że konkurencja (pewnie chodzi o amd) ma inny stosunek liczby marketingowców do sprzedawców. i nieźle im idzie. więc u nich trzeba też obciąć marketing.

zasadniczo niewiele mnie to powinno obchodzić – nie pracuję w intelu, nie znam (chyba) nikogo takiego. ale podawanie takiego powodu zwolnienia 10000 ludzi wydaje mi się być bardzo nie na miejscu.

miało ostatnio miejsce kilka interesujących zmian w wielkim biznesie.

osobiście zaciekawiły mnie dwie:

po pierwsze – ceo (chief executive officter, czyli taki szef szefów 🙂 google'a – eric schmidt, został członkiem zarządu apple'a.

oczywiście microsoft stwierdził, że to bez znaczenia, ale ich opinia była odosobniona. praktycznie wszyscy widzą w tym zacieśnienie więzi google i apple'a “wymierzone" w microsoft. co z tego wyjdzie na dłuższą metę – zobaczymy. może być ciekawie. dwie najdynamiczniejsze firmy, mające wiernych użytkowników połączone osobą ze ścisłego kierownictwa? coś z tego musi wyjść.

druga informacja jest newsem tylko częściowo.  31 sierpnia niejaki gerry smith, przestał pracować w dellu (w którym pracował od 1994 roku, ostatnio będąc na stanowisku vice-prezydenta!). i natychmiast zaczął pracę w konkurencyjnym lenovo.

sama ta informacja nie byłaby może taka ciekawa gdyby nie jedna informacja dodatkowa. smith, jest piątym, wysokiej rangi, pracownikiem della który przeszedł do lenovo w ciągu ostatniego roku!.

to wygląda na niemalże drenaż kadr. oczywiście dell ma zdecydowanie więcej pracowników, ale pracowników tego szczebla zdecydowanie mniej 🙂

czemu? po co? myślę, że głównym powodem jest fakt, iż lenovo nie wie co ma robić. kupili od ibm'a laptopy i pecety. tym jednym krokiem weszli do międzynarodowej ekstra-ligi. ale przedtem byli firmą lokalną. dużą, ale lokalną.

uważam, że te spektakularne przejścia są dowodem na to, że lenovo nie ma pomysłu jak sprzedawać swój sprzęt i szuka ludzi z doświadczeniem. teraz thinkpady jako/tako się jeszcze sprzedają. choć np. część firm (w tym rząd i agencje rządowe) w stanach nie chce “chińskiego" thinkpada i zmieniają wieloletnie przyzwyczajenia, przerzucając się na hp'ki czy delle. ale niedługo może się okazać, że bez solidnej strategii sprzedaż padnie.

na plus panom z lenovo trzeba zapisać to, że się nie boją. wydają pieniądze na najlepszych ludzi z branży. jak tak dalej pójdzie, to niedługo może się okazać, że nikt nie będzie pamiętał, że thinkpady były ibm'a.

nowe, a właściwie stare, tylko lepsze.

ford pracuje obecnie nad tym by w nowych samochodach przejść z systemu pasów 3-punktowych (takie standardowe) na 4 punktowe – coś takiego jak mają kierowcy rajdowi.

pasy takie byłyby bezpieczniejsze.

ale to nie koniec.

istotną innowacją ma być to, że w pasach, a dokładniej w ich części leżącej na klatce piersiowej pasażera/kierowcy mają być zamontowane małe poduszki powietrzne. ich zadaniem ma być lepsze przytrzymanie ciała w razie wypadku i ograniczenie uszkodzeń ciała przez same pasy.

szacuje się, że pasy uratowały więcej żyć niż wszystkie inne mechanizmy zabezpieczania razem wzięte. nowe pasy mają to jeszcze poprawić.

niestety – minie kilka lat zanim te pomysły wejdą faktycznie do produkcji wielkoseryjnej. a i wtedy nie wszyscy będą zapinać. ale mam nadzieję, że za te kilka(naście) lat dzięki takim i innym, nowym, zabezpieczeniom, śmiertelne ofiary wypadków będą rzadkością.