pdf datubāzē...

[goma smile]

Vai var kaut kā pdf glabāt datubāzē piemēram mysql, vai tas ir prāta darbs... ?

[jurchiks]

Protams, ka var, blob. Vai vajag, tas jau ir cits jautājums...

[briedis]

Tas ir parasts fails, nav jēga bāzt db.

[Kasspars]

Tak vienreiz jau tika nolemts, ka failus db glabāt ir ļoti pat ok

[codez]

Kaut kur lasīju, ka ja faili ir ļoti daudz un nav pārāk lieli un paralēli tiek strādāts ar daudz failiem, tad db dod pat labāku performanci, jo failu sistēmas lock mehānismi sāk bremzēt, bet db tie ir optimizētāki.

[jurchiks]

Tas ir diezgan specifisks gadījums.

[codez]

Mhm, tajā rakstā runa bija par miljoniem failu no kuriem tūkstošiem failu tiek izmantoti paralēli.

[jurchiks]

Kas tas vispār par projektu?

[codez]

Šķiet, ka rakstā pat nebija pieminēts, ko konkrēti projekts dara, tik tas, ka bija ļoti daudz failu pieprasījumu un par bootlnecku kļuva kaut kādi failu sistēmas locki.

[daGrevis]

Glabāt datubāzē var būt vislabākais risinājums, patiešām jau vienreiz šo izrunājām.

[jurchiks]

Bet ne vienmēr. Atkarīgs no tā, ko ar tiem failiem vajag darīt.

IMHO, ja tīri lietotāju avatarus glabāt, tad nafig.

Edited December 24, 2015 by jurchiks

[l27]

Īsti neredzu pmatu likt failus datubāzē:

1. faila saglabāšana datubāzē diezivai notiek ātrāk, nekā parasta faila izveidošana;
2. saglabājot failā klientam var padot tiešo linku uz failu un parlūks pats savāks failu - jebkurā gadījuma ātrāk strādās;
3. ja neliek publiskā direktorijā failu, var izmantot readfile(), lai padotu to klientam, kas jebkura gadijuma būs ātraks neka to izvilkt no datubāzes un padot klientam;
4. failu glabāšana datubāze var palielināt tās izmērus reizes 10, kas apgrūtinātu rezervju kopiju veidošanu, datubāzu kopēšanu, uzturēšanu.
5. failu pats vari atvērt pa tiešo un paskatīties, kas tad tur ir iekšā

Vienīgo izņēmumu redzu, ja ir ļoti maz failu un negribās problēmas ar to saglabāšanu uz diska.

Edited December 28, 2015 by l27

[Wuu]

Kaut kādas neadekvātas problēmas tev priekš 2015/2016. gada, kas man liekas ir vairāk saistītas ar PHP/MySql, nevis failu glabāšanu datubāzē.

Edited December 28, 2015 by Wuu

[Roze]

Par šo tēmu vienam vai otram variantam var nosaukt diezgan daudz gan pozitīvas gan negatīvas īpašības.

Protams, ja faili ir 100, 1k vai 10k, tad par to īpaši nav vērts lauzīt galvu un, ja vien nepārspīlēs ar "risinājumu" un nesapīsies meistarībā, strādās jebkura no izvēlētajām metodēm.

 

 faila saglabāšana datubāzē diezivai notiek ātrāk, nekā parasta faila izveidošana;

Ne vienmēr.
DBMS bieži vien ir dažādas specifiskas tehnoloģijas, kas var uzlabot rakstīšanas ātrumu vs "pliks wraits uz diska" (nu piemēram rakstīšana (uzreiz) nemaz (buffered write) nenotiek uz fiziskā dzelža (šo gan var panākt arī ar parastām failsistēmām)). 

Protams, jārēķinās arī ar to, ka dažos gadījumos, piemēram MySQL, rakstot failu ierakstāmais apjoms var pieaugt pat 3 reizes (datu tabula + innodb logs + binlogs).

 

 

ja neliek publiskā direktorijā failu, var izmantot readfile(), lai padotu to klientam, kas jebkura gadijuma būs ātraks neka to izvilkt no datubāzes un padot klientam;

Ja lieto readfile() (kas idejiski nav visai labs paņēmiens (labāk izmantot webserveru x-accel-redirect (analogi gan nginx gan apache) iespēju), tad starpība starp nolasīšanu no db un diska var arī nebūt nekāda. 

 

 

failu glabāšana datubāze var palielināt tās izmērus reizes 10, kas apgrūtinātu rezervju kopiju veidošanu, datubāzu kopēšanu, uzturēšanu.

DB apjomu jā, bet ar datu apjomu vispār var būt arī otrādi - praktiski visas DB sistēmas nodrošina šādu vai tādu kompresijas iespēju, kas turpretī ir reti kurai failsistēmai (no tām kuras esmu lietojis tāda ir tikai BTRFS, ZFS un uz win NTFS). Lielām failsistēmām rezerves kopiju veikšana ir krietni sarežģitāka nekā DB - īpaši, ja jāveic inkrementāli (kaut cik jēdzīgas snapshot iespējas no nekomerciāliem risinājumiem, manuprāt, ir tikai ZFS un LVM)

 

 

Otra lieta ir, ja ir daudz mazu failu, tad jāņem vērā arī tāds aspekts kā "vietas zaudēšana" dēļ failsistēmas block/stripe size, kur DB parasti viss tiek sapakots pāris lielos "klučos" kurus tas neietekmē.

 

Lielākais failsistēmu mīnuss ir tāds, ka ir salīdzinoši lēnas metadatu darbības (ar SSD situācija protams ir uzlabojusies, bet tomēr) t.i. lai nolasītu failu (un informāciju par to) ir jāveic diezgan daudz zema līmeņa darbības (jālasa direktoriju struktūra/jameklē innodes utt), kas daļēji atkrīt DB gadījumā (vai pareizāk DB sistēma ir optimizēta datu meklēšanai/atrašanai).

[ieleja]

- .pdf ir ar iedzimtu kompresiju, gan teksta palagi, gan ar krāsainām bildēm, ZIP saspiež par ~10%, pats BLOB, ja ir kompresēts, ir dekompresēts .pdf, kurš vēlreiz kompresēts?

- nolasīt ar "tiešo" linku ir ceļš, kas galīgi neved uz Romu