Vic : "Dap...clar directoare."
stealth : "directoare ... inclusiv mysql recomanda."
shakabut : "Directoare!"
Eu zic ca toate aceste afirmatii sunt cit se poate de eronate ca sa nu spun ca sunt timpenii. Principalul argument e viteza...
Ei bine va informez ca Google va contrazice flosind propriul sistem de stocare distribuit Bigtable care nu este altceva decit o baza de date foarte sofisticata ... e adevarat nu MySQL
. Aveti mai jos spatiul ocupat de catre bazele de date ale diverselor aplicatii google:
- Google Earth (imagini satelit) 70 Terra Bytes (celule in baza de date 9 bilioane)
- Google Crawl 800 Terra Bytes (celule in baza de date 1000 de bilioane)
- Google Analytics 200 Terra Bytes (celule in baza de date 80 de bilioane)
Acum haideti sa vedem ce a patit Youtube. Initial au folosit Lighttpd pentru servit thumbnail-urile filmuletelor (sunt in medie 4 thumbnail-uri per movie la Youtube). S-au trezit ca numarul enorm de fisiere unde erau stocate thumbnail-urile punea intreg sistemul la pamint. Prima oara au incercat sa rezolve problema modificind serverul Lighthttpd care nu mai era nici el deajuns de "light" cind lucra cu milioane de thumbnail-uri. Au esuat in incercarea lor singura solutie temporara dupa cum povesteste un administrator Youtube fiind sa adauge noi si noi servere la clusterele lor atunci cind tot sistemul incremenea incapabil sa serveasca atitea imagini.
Aveti mai jos un citat care incepe amuzant si descrie cu ce s-au confruntat cei de la Youtube pentru ca au ales solutia idioata a stocarii imaginilor in directoare:
Cuong joked about “The Windows approach of scaling: restart everything”
Thumbnails turn out to be surprisingly hard to serve efficiently. Because there, on average, 4 thumbnails per video and many thumbnails per pages, the overall number of thumbnails per second is enormous. They use a separate group of machines to serve thumbnails, with extensive caching and OS tuning specific to this load.
YouTube was bit by a “too many files in one dir” limit: at one point they could accept no more uploads (!!) because of this. The first fix was the usual one: split the files across many directories, and switch to another file system better suited for many small files.
Lighttpd turned out to be poor for serving the thumbnails, because its main loop is a bottleneck to load files from disk; they addressed this by modifying Lighttpd to add worker threads to read from disk. This was good but still not good enough, with one thumbnail per file, because the enormous number of files was terribly slow to work with (imagine tarring up many million files).
Their new solution for thumbnails is to use Google’s BigTable, which provides high performance for a large number of rows, fault tolerance, caching, etc. This is a nice (and rare?) example of actual synergy in an acquisition.
YouTube uses MySQL to store metadata. Early on they hit a Linux kernel issue which prioritized the page cache higher than app data, it swapped out the app data, totally overwhelming the system. They recovered from this by removing the swap partition (while live!). This worked.
Acum sa vedem ce solutii au gasit alte companii la problema stocarii imaginilor sau al altui tip de continut:
- Oracle - Real Application Cluster database
- IBM - DB2 Parallel Edition similara sistemului de stocare distribuit Google BigTable
Am aratat asadar ca la cele mai dure teste stocarea fisierelor in directoare se dovedeste o solutie dezastroasa.
La final o sa argumentati well eu nu o sa am niciodata necesitatile Google sau Youtube! Ei bine chiar si pentru site-uri mai mici in cazul meu stocarea imaginilor intr-o baza de date s-a dovedit o solutie mult mai buna decit in sistemul de fisiere din urmatoarele motive:
- drepturi de access la imagini cotrolate (la imaginile din directoarele publice
toata lumea are access)
- securitate sporita datorita faptului ca nu exista directoare cu drepturi de scriere
- securitate sporita datorita faptului ca indiferent ce ar incerca sa uploadeze un atacator fisierul va fi stocat in baza de date si nu intr-un director public acolo unde atacatorul spera sa uploadeze ceva
- backup foarte usor, multiple posibilitati de a opera cu imaginile in baza de date, mutarea site-ului de pe un server pe altul joaca de copil
- foarte usor de contruit un sistem de clustere failover via MySQL replication ... cind un server pica intra in scena altul
- o data construit sistemul il puteti folosi la toate site-urile dumneavoastra la final mai putina munca si mai putin timp pierdut
- la toate aceste avantaje puteti adauga dupa imaginatia fiecaruia folosirea mod_rewrite astfel incit browser-ul va crede ca primeste imagini din sistemul de fisiere ceea ce va va ajuta sa beneficiati fara probleme de cache-ul oricarui browser sau alte traznai
La final singurul argument pro dupa parerea mea ar fi
comoditatea scunsa in spatele argumentelor de alt tip cuma ca viteza e de vina. Sa creezi un astfel de sistem ia ceva timp dar satisfactiile in simplitatea utilizarii lui mai tirziu vor fi pe masura!
Asadar alegerea mea:
Imagini in baza de date!