Baza de date pentru blob-uri

Caut un sistem de baze de date in care sa stochez fisiere (bloburi). Fisierele pot fi de la 100K la 100Mb.

De ce as vrea un engine de baza de date in loc de sistemul de fișiere? As vrea sa beneficiez de toate jucariile din jurul unei tehnlogii existente

  • api
  • replicare si shard-uire
  • backup total si incremental
  • performanta
  • securitate
  • migrare

Observațiile mele de novice în domeniul DB:

  • performanță: Pentru a accesa un fișier se va citi de pe disc, fie că ai fișiere stocate în DB fie că sunt în sistemul de fișiere. Un layer în plus sigur nu aduce performanță.
  • back-up: nu cred că a ține 100 file de 100Mb într-o „arhivă” este mai sigur (din punct de vedere al integrității datelor) de a ține 100 file distincte, accesibile oricând.

Cum aș face eu? O combinație între DB și FS: în DB aș ține doar informații despre fișier (mărime, locație etc). Astfel ai avea acces la toate jucăriile menționate mai sus fără bătăi prea mari de cap.


Shard înseamnă un fel de RAID 0 al mai multor DB, nu? (adică mai multe DB sunt „văzute” ca una singură)

1 Like

Cu siguranta ca nu aduce performanta. Dar asta nu inseamna ca poate sa aduca mari probleme de perofrmanta.

Cred ca se poate avea grija. Sunt multe baze de date de cativa giga, plus ca se pot face setari la split cand fisierul ajunge la 10Gb

Asta am acum :slight_smile:

Inseamna si asta. Eu ma refer la urmatoarea situatie: am X servere, informatia e tinuta duplicat (blackbox pentru user) pe o parte din servere si replicat cu nopoint of failure.

1 Like

In acest caz riscurile sunt mai mari decat beneficiile. Va merge bine la inceput dar pe masura ce baza de date se va umfla cu bloburi va deveni tot mai lenta. De aceea toate softurile CMS cunoscute folosesc numai sistemul de fisiere pentru stocare imagini sau alte fisiere (Wordpress, Moodle, Opencart, etc.).

1 Like

Or fi situații în care stocarea fișierelor în DB este o idee bună. Eu însă nu văd nici o astfel de situație practică (dar, cum am zis mai sus, sunt oarecum novice).

Încă o chestie ce m-a trăznit acum: un fișier îl link-uiești și atât. Un fișier din db trebuie procesat înainte de a fi servit. Înca un layer :smiley:


Cumva related:

și

Desi nu e cazul meu, uite ce probleme poti avea pe windows cu 1 milion de fisiere, pe windows (unele valabile si pe *nix):
http://akashkava.com/blog/127/huge-file-storage-in-database-instead-of-file-system/

ps1: windows - nu e cazul meu. La numarul de fisiere ma gandesc la vreo 2-3 milioanre de fisiere
ps2: momentan folosesc varianta de db + fs si incerc sa ma gandesc in ce directie sa merg in continuare

1 Like

Am folosit, cu succes, longblob in mysql. Nu a fost cea mai eleganta solutie, dar a fost o combinatie reusita intre cerintele clientului: viteza de finalizare a proiectului si viteza de acces a datelor. Proiectul a avut zeci de mii de accesari din primele zile si nu au fost probleme privind modul in care se misca aplicatia.

2 Likes

Cred ca in articol s-a scapat din vedere limitarea numarului de fisiere dintr-un folder astfel:
FAT32 - 65,534 fisiere, NTFS - 4,294,967,295, Linux ext4 - 4 miliarde, Mac OS X (HFP) - 2,1 miliarde
Asta in teorie, dar in practica se pare ca un folder deja rasufla din greu la peste 100,000 de fisiere continute.
Asta explica de ce Wordpress-ul le sparge in foldere lunare:
/wp-content/uploads/2014/08/image.png

Interesant este ca pana la urma a ales o solutie de mijloc, stocare in DB dar cu bloburi mai mici de 512 Kb.

After reading various articles, we came to conclusion that storing entire file in one blob or image doesnt make sense as it will deteriorate performance like anything.
So we came with easy solution, which is already used by existing file systems. Thats “Breaking down file into smaller blobs, max 512kb”.

Si eu sunt putin impotriva directiei pe care vrei sa o iei. Cand am facut sistemul la filebox.ro noi am facut o combinatie de MySQL cu redundanta semi-manuala.
Dar stiu ca atunci ne-am uitat si la GlusterFS si la cateva similare. Nu stiu nici o baza de date care sa se comporte bine la lucrul cu fisierele pentru ca o baza de date este facuta sa lucreze cu date, dar la tine fisierul este doar un blob. Eu sincer de fiecare data cand ma gandesc sa salvez blob in baza de date ma intreb daca nu cumva gandesc gresit.

Acorda o sansa sectiunii Distributed parallel fault-tolerant file systems

Trebuie sa recunosc ca pana la urma nu am folosit un filesystem din aceasta lista pentru ca ne-a fost putin frica si am folosit RAID si redundanta din programare facuta.

2 Likes

Salvarea unui blob intr-o baza de date sql e clar ca are un coding smell.

Incercam sa vad daca exista totusi ceva care sa ma scape de implementarea toolurilor pentru filesystem. Mergem inainte cu ce avem.

Si eu le sparg in foldere. Amazon S3 face la fel… si cam toti o fac.

1 Like

MongoDB are GridFS, nu este mai rapid ca Nginx daca vrei sa-l folosesti ca CDN, dar e util pt. anumite aplicatii.

1 Like