Dus ik gebruik een app die afbeeldingen zwaar opslaat in de DB. Wat is uw kijk hierop? Ik ben meer een type om de locatie in het bestandssysteem op te slaan, dan om het direct in de DB op te slaan.
Wat zijn volgens jou de voor- en nadelen?
Antwoord 1, autoriteit 100%
Ik heb de leiding over een aantal applicaties die veel TB aan afbeeldingen beheren. We hebben ontdekt dat het het beste is om bestandspadenop te slaan in de database.
Er zijn een aantal problemen:
- databaseopslag is meestal duurder dan bestandssysteemopslag
- u kunt de toegang tot het bestandssysteem supersnel versnellen met standaard kant-en-klare producten
- bijvoorbeeld, veel webservers gebruiken de systeemaanroep sendfile()van het besturingssysteem om asynchroon een bestand rechtstreeks van het bestandssysteem naar de netwerkinterface te verzenden. Afbeeldingen die zijn opgeslagen in een database profiteren niet van deze optimalisatie.
- dingen zoals webservers, enz., hebben geen speciale codering of verwerking nodig om toegang te krijgen tot afbeeldingen in het bestandssysteem
- databases winnen waar de transactie-integriteit tussen de afbeelding en metadata belangrijk is.
- het is ingewikkelder om de integriteit tussen db-metadata en bestandssysteemgegevens te beheren
- het is moeilijk (binnen de context van een webtoepassing) om te garanderen dat de gegevens op het bestandssysteem naar de schijf zijn weggespoeld
Antwoord 2, autoriteit 40%
Zoals bij de meeste problemen, is het niet zo eenvoudig als het klinkt. Er zijn gevallen waarin het zinvol zou zijn om de afbeeldingen in de database op te slaan.
- Je slaat afbeeldingen op die
dynamisch veranderen, zeg facturen en je wilde
om een factuur te krijgen zoals deze was op 1 januari
2007? - De regering wil dat je 6 jaar geschiedenis in stand houdt
- Afbeeldingen die in de database zijn opgeslagen, vereisen geen andere back-upstrategie. Afbeeldingen opgeslagen op bestandssysteem doen
- Het is gemakkelijker om de toegang tot de afbeeldingen te controleren als ze zich in een database bevinden. Inactieve beheerders hebben toegang tot elke map op schijf. Er is een vastberaden beheerder voor nodig om in een database te gaan snuffelen om de afbeeldingen te extraheren
Aan de andere kant zijn er problemen verbonden
- Aanvullende code nodig om te extraheren
en stream de afbeeldingen - Latentie kan zijn
langzamer dan directe bestandstoegang - Zwaardere belasting van de databaseserver
Antwoord 3, autoriteit 28%
Bestandsopslag. Facebook-ingenieurs hadden er een goed gesprek over. Een van de dingen die je moest doen, was om de praktische limiet van bestanden in een map te kennen.
Naald in een hooiberg: efficiënte opslag van miljarden foto’s
Antwoord 4, autoriteit 16%
Dit is misschien wat langdradig, maar als u SQL Server 2008 gebruikt (of van plan bent te gebruiken) raad ik u aan de nieuwe FileStreamgegevenstype.
FileStream lost de meeste problemen op rond het opslaan van bestanden in de DB:
- De blobs worden feitelijk als bestanden in een map opgeslagen.
- De blobs zijn toegankelijk via ofweleen databaseverbinding ofvia het bestandssysteem.
- Back-ups zijn geïntegreerd.
- Migratie “werkt gewoon”.
De “Transparante gegevenscodering” van SQL versleutelt echter geen FileStream-objecten, dus als dat een overweging is, kunt u ze misschien beter als varbinary opslaan.
Uit het MSDN-artikel:
Transact-SQL-instructies kunnen FILESTREAM-gegevens invoegen, bijwerken, opvragen, zoeken en back-uppen. Win32-bestandssysteeminterfaces bieden streamingtoegang tot de gegevens.
FILESTREAM gebruikt de NT-systeemcache voor het cachen van bestandsgegevens. Dit helpt elk effect dat FILESTREAM-gegevens kunnen hebben op de prestaties van de Database Engine te verminderen. De bufferpool van SQL Server wordt niet gebruikt; daarom is dit geheugen beschikbaar voor het verwerken van query’s.
Antwoord 5, autoriteit 11%
Bestandspaden in de DB is zekerde juiste keuze – ik heb verhaal na verhaal gehoord van klanten met TB aan afbeeldingen dat het een nachtmerrie werd om een significante hoeveelheid afbeeldingen op te slaan in een DB – de prestatiehit alleen is te veel.
Antwoord 6, autoriteit 10%
In mijn ervaring is de eenvoudigste oplossing soms om de afbeeldingen een naam te geven volgens de primaire sleutel. Het is dus gemakkelijk om de afbeelding te vinden die bij een bepaald record hoort, en vice versa. Maar tegelijkertijd slaat u nietsop over de afbeelding in de database.
Antwoord 7, autoriteit 9%
De truc hier is om geen ijveraar te worden.
Een ding om op te merken is dat niemand in het pro-bestandssysteemkamp een bepaald bestandssysteem heeft vermeld. Betekent dit dat alles van FAT16 tot ZFS handig elke database verslaat?
Nee.
De waarheid is dat veel databases veel bestandssystemen verslaan, zelfs als we het alleen hebben over onbewerkte snelheid.
De juiste manier van handelen is om de juiste beslissing te nemen voor uw precieze scenario, en om dat te doen, heeft u enkele cijfers en enkele gebruiksscenario’s nodig.
Antwoord 8, autoriteit 9%
Op plaatsen waar u de referentiële integriteit en ACID-compliance MOET garanderen, is het opslaan van afbeeldingen in de database vereist.
U kunt niet op transactiebasis garanderen dat de afbeelding en de metagegevens over die afbeelding die in de database zijn opgeslagen, naar hetzelfde bestand verwijzen. Met andere woorden, het is onmogelijk om te garanderen dat het bestand op het bestandssysteem alleen ooit wordt gewijzigd op hetzelfde moment en in dezelfde transactie als de metadata.
Antwoord 9, autoriteit 8%
Zoals anderen al hebben gezegd, wordt SQL 2008 geleverd met een Filestream-type waarmee je een bestandsnaam of identifier als een aanwijzer in de db kunt opslaan en de afbeelding automatisch op je bestandssysteem kunt opslaan, wat een geweldig scenario is.
Als je een oudere database gebruikt, zou ik zeggen dat als je deze opslaat als blob-gegevens, je echt niets uit de database haalt wat betreft het zoeken naar functies, dus het is waarschijnlijk het beste om een adres op een bestandssysteem op te slaan en de afbeelding op die manier op te slaan.
Op die manier bespaart u ook ruimte op uw bestandssysteem, omdat u alleen de exacte hoeveelheid ruimte, of zelfs gecomprimeerde ruimte op het bestandssysteem gaat besparen.
U kunt ook besluiten om op te slaan met een bepaalde structuur of elementen waarmee u door de onbewerkte afbeeldingen in uw bestandssysteem kunt bladeren zonder db-hits, of de bestanden in bulk over te brengen naar een ander systeem, harde schijf, S3 of een ander scenario – bijwerken de locatie in je programma, maar behoud de structuur, opnieuw zonder veel succes om de afbeeldingen uit je db te halen wanneer je probeert de opslag te vergroten.
Waarschijnlijk zou het je ook in staat stellen om een cache-element, gebaseerd op veelgebruikte afbeeldings-urls, in je webengine/programma te gooien, dus je bespaart jezelf daar ook.
Antwoord 10, autoriteit 8%
Kleine statische afbeeldingen (niet meer dan een paar meg) die niet vaak worden bewerkt, moeten in de database worden opgeslagen. Deze methode heeft verschillende voordelen, waaronder eenvoudigere portabiliteit (afbeeldingen worden overgedragen met de database), eenvoudiger back-up/herstel (van afbeeldingen wordt een back-up gemaakt met de database) en betere schaalbaarheid (een bestandssysteemmap met duizenden kleine miniatuurbestanden klinkt als een schaalbaarheidsnachtmerrie voor ik).
Het aanbieden van afbeeldingen uit een database is eenvoudig, implementeer gewoon een http-handler die de byte-array die door de DB-server wordt geretourneerd als een binaire stroom dient.
Antwoord 11, autoriteit 7%
Hier is een interessant witboek over dit onderwerp.
To BLOB of Not To BLOB: Large Objectopslag in een database of een bestandssysteem
Het antwoord is: “Het hangt ervan af.” Het hangt zeker af van de databaseserver en de benadering van blobopslag. Het hangt ook af van het type gegevens dat in blobs wordt opgeslagen en van de manier waarop toegang tot die gegevens moet worden verkregen.
Kleinere bestanden kunnen efficiënt worden opgeslagen en afgeleverd met de database als opslagmechanisme. Grotere bestanden kunnen waarschijnlijk het beste worden opgeslagen met behulp van het bestandssysteem, vooral als ze vaak worden gewijzigd/bijgewerkt. (blob-fragmentatie wordt een probleem met betrekking tot prestaties.)
Hier is nog een extra punt om in gedachten te houden. Een van de redenen die het gebruik van een database ondersteunen om de blobs op te slaan, is ACID-compliance. De benadering die de testers in het witboek gebruikten (Bulk Logged-optie van SQL Server), die de SQL Server-doorvoer verdubbelde, veranderde de ‘D’ in ACID echter in een ‘d’, omdat de blobgegevens niet waren vastgelegd met de eerste schrijft voor de transactie. Als volledige ACID-compliance een belangrijke vereiste is voor uw systeem, halveer dan de SQL Server-doorvoercijfers voor databaseschrijfacties bij het vergelijken van bestands-I/O met database-blob-I/O.
Antwoord 12, autoriteit 7%
Eén ding dat ik nog niemand heb zien noemen, maar zeker het vermelden waard is, is dat er ook problemen zijn met het opslaan van grote hoeveelheden afbeeldingen in de meeste bestandssystemen. Als u bijvoorbeeld de hierboven genoemde benadering volgt en elk afbeeldingsbestand een naam geeft naar de primaire sleutel, zult u op de meeste bestandssystemen problemen tegenkomen als u alle afbeeldingen in één grote map probeert te plaatsen zodra u een zeer groot aantal afbeeldingen bereikt ( bijvoorbeeld in de honderdduizenden of miljoenen).
Een gebruikelijke oplossing hiervoor is om ze te hashen in een uitgebalanceerde boomstructuur van submappen.
Antwoord 13, autoriteit 6%
Iets dat niemand heeft genoemd, is dat de DB atomaire acties, transactie-integriteit en gelijktijdigheid garandeert. Zelfs referentiële integriteit is uit het raam met een bestandssysteem – dus hoe weet je dat je bestandsnamen echt nog steeds correct zijn?
Als u uw afbeeldingen in een bestandssysteem hebt en iemand leest het bestand terwijl u een nieuwe versie schrijft of zelfs het bestand verwijdert, wat gebeurt er dan?
We gebruiken blobs omdat ze ook gemakkelijker te beheren zijn (back-up, replicatie, overdracht). Ze werken goed voor ons.
Antwoord 14, autoriteit 6%
Het probleem met het opslaan van alleen bestandspaden naar afbeeldingen in een database is dat de integriteit van de database niet langer kan worden afgedwongen.
Als de daadwerkelijke afbeelding waarnaar wordt verwezen door het bestandspad niet meer beschikbaar is, heeft de database onbewust een integriteitsfout.
Aangezien de afbeeldingen de eigenlijke gegevens zijn waarnaar wordt gezocht, en dat ze gemakkelijker kunnen worden beheerd (de afbeeldingen zullen niet plotseling verdwijnen) in één geïntegreerde database in plaats van te moeten communiceren met een soort bestandssysteem (als het bestandssysteem is onafhankelijk toegankelijk, de afbeeldingen KUNNEN plotseling “verdwijnen”), ik zou ze direct opslaan als een BLOB of iets dergelijks.
Antwoord 15, autoriteit 5%
Bij een bedrijf waar ik vroeger werkte, hebben we 155 miljoen afbeeldingen opgeslagen in een Oracle 8i (toen 9i) database. 7,5 TB waard.
Antwoord 16, autoriteit 4%
Normaal gesproken ben ik er fel tegen om het duurste en moeilijkst te schalen deel van uw infrastructuur (de database) te nemen en er alle belasting in te steken. Aan de andere kant: het vereenvoudigt de back-upstrategie aanzienlijk, vooral wanneer u meerdere webservers heeft en de gegevens op de een of andere manier gesynchroniseerd moet houden.
Zoals de meeste andere dingen, hangt het af van de verwachte grootte en het budget.
Antwoord 17, autoriteit 4%
We hebben een document-imaging-systeem geïmplementeerd dat alle afbeeldingen opslaat in SQL2005-blobvelden. Er zijn momenteel enkele honderden GB en we zien uitstekende responstijden en weinig of geen prestatievermindering. Bovendien hebben we, vanwege naleving van de regelgeving, een middleware-laag die nieuw geposte documenten archiveert in een optisch jukebox-systeem dat ze als een standaard NTFS-bestandssysteem beschikbaar stelt.
We zijn erg blij met de resultaten, vooral met betrekking tot:
- Gemak van replicatie en back-up
- Mogelijkheid om eenvoudig een documentversiesysteem te implementeren
Antwoord 18, autoriteit 3%
Als dit een webtoepassing is, kan het voordelen hebben om de afbeeldingen op te slaan op een opslagnetwerk van derden, zoals Amazon’s S3 of het Nirvanix-platform.
Antwoord 19, autoriteit 3%
Aanname: applicatie is web-enabled/web-based
Het verbaast me dat niemand dit echt heeft genoemd … delegeer het aan anderen die specialisten zijn -> gebruik een externe hostingprovider voor afbeeldingen/bestanden.
Bewaar uw bestanden op een betaalde online service zoals
Nog een StackOverflow-thread hierover hier.
Deze threadlegt uit waarom u een externe hostingprovider zou moeten gebruiken.
Het is het zo waard. Ze slaan het efficiënt op. Geen bandbreedte die wordt geüpload van uw servers naar clientverzoeken, enz.
Antwoord 20, autoriteit 3%
Als u geen SQL Server 2008 gebruikt en u heeft een aantal goede redenen om specifieke afbeeldingsbestanden in de database te plaatsen, dan kunt u de “beide”-benadering nemen en het bestandssysteem gebruiken als tijdelijke cache en de database gebruiken als het masterdepot.
Uw bedrijfslogica kan bijvoorbeeld controleren of een afbeeldingsbestand op de schijf bestaat voordat het wordt opgediend, en zo nodig uit de database ophalen. Hierdoor krijgt u de mogelijkheid van meerdere webservers en minder synchronisatieproblemen.
Antwoord 21, autoriteit 2%
Ik weet niet zeker in hoeverre dit een ‘echte wereld’-voorbeeld is, maar ik heb momenteel een applicatie die details voor een ruilkaartspel opslaat, inclusief de afbeeldingen voor de kaarten. Toegegeven, het aantal records voor de database is tot nu toe slechts 2851 records, maar gezien het feit dat bepaalde kaarten meerdere keren zijn uitgebracht en alternatieve illustraties hebben, was het qua grootte efficiënter om het “primaire vierkant” van het kunstwerk te scannen en vervolgens dynamisch genereer de rand en diverse effecten voor de kaart wanneer daarom wordt gevraagd.
De oorspronkelijke maker van deze afbeeldingsbibliotheek heeft een gegevenstoegangsklasse gemaakt die de afbeelding weergeeft op basis van het verzoek, en het doet het vrij snel voor weergave en individuele kaart.
Dit vereenvoudigt ook de implementatie/updates wanneer nieuwe kaarten worden uitgebracht, in plaats van een hele map met afbeeldingen in te pakken en deze naar beneden te sturen en ervoor te zorgen dat de juiste mapstructuur wordt gemaakt, werk ik gewoon de database bij en laat de gebruiker deze downloaden opnieuw. Dit kan momenteel oplopen tot 56 MB, wat niet geweldig is, maar ik werk aan een incrementele updatefunctie voor toekomstige releases. Daarnaast is er een “geen afbeeldingen”-versie van de applicatie waarmee mensen via inbelverbinding de applicatie kunnen krijgen zonder de downloadvertraging.
Deze oplossing heeft tot nu toe prima gewerkt, aangezien de toepassing zelf als een enkele instantie op de desktop is gericht. Er is een website waar al deze gegevens worden gearchiveerd voor online toegang, maar ik zou op geen enkele manier dezelfde oplossing hiervoor gebruiken. Ik ben het ermee eens dat bestandstoegang de voorkeur verdient, omdat dit beter zou worden aangepast aan de frequentie en het volume van de verzoeken om de afbeeldingen.
Hopelijk is dit niet te veel geklets, maar ik zag het onderwerp en wilde wat mijn inzichten geven van een relatief succesvolle kleine/middelgrote toepassing.
Antwoord 22, autoriteit 2%
SQL Server 2008 biedt een oplossing die het beste van twee werelden biedt: De bestandsstream gegevenstype.
Beheer het als een gewone tabel en profiteer van de prestaties van het bestandssysteem.
Antwoord 23, autoriteit 2%
Het hangt af van het aantal afbeeldingen dat u gaat opslaan en ook van hun afmetingen. Ik heb in het verleden databases gebruikt om afbeeldingen op te slaan en mijn ervaring was redelijk goed.
IMO, Voordelen van het gebruik van een database om afbeeldingen op te slaan zijn,
A. Je hebt geen FS-structuur nodig om je afbeeldingen te bewaren
B. Database-indexen presteren beter dan FS-bomen wanneer er meer items moeten worden opgeslagen
C. Slim afgestemde database presteert goed bij het cachen van de queryresultaten
D. Back-ups zijn eenvoudig. Het werkt ook goed als u replicatie hebt ingesteld en inhoud wordt geleverd vanaf een server in de buurt van de gebruiker. In dergelijke gevallen is expliciete synchronisatie niet vereist.
Als uw afbeeldingen klein zullen zijn (zeg < 64k) en de opslag-engine van uw db inline (in record) BLOB’s ondersteunt, verbetert dit de prestaties verder omdat er geen indirectheid vereist is (plaats van referentie wordt bereikt).
Het opslaan van afbeeldingen kan een slecht idee zijn als je te maken hebt met een klein aantal grote afbeeldingen. Een ander probleem met het opslaan van afbeeldingen in db is dat metadata, zoals creatie, wijzigingsdatums door uw toepassing moeten worden afgehandeld.
Antwoord 24, autoriteit 2%
Ik heb onlangs een PHP/MySQL-app gemaakt die PDF’s/Word-bestanden opslaat in een MySQL-tabel (tot nu toe maar liefst 40 MB per bestand).
Voors:
- Geüploade bestanden worden samen met al het andere gerepliceerd naar de back-upserver, er is geen aparte back-upstrategie nodig (gemoedsrust).
- Het instellen van de webserver is iets eenvoudiger omdat ik geen uploads/map nodig heb en al mijn applicaties moet vertellen waar deze zich bevindt.
- Ik mag transacties gebruiken voor bewerkingen om de gegevensintegriteit te verbeteren – ik hoef me geen zorgen te maken over verweesde en ontbrekende bestanden
Nadelen:
- mysqldump duurt nu erg lang omdat er 500 MB aan bestandsgegevens in een van de tabellen staat.
- Over het algemeen niet erg efficiënt qua geheugen/cpu in vergelijking met bestandssysteem
Ik zou mijn implementatie een succes noemen, het zorgt voor back-upvereisten en vereenvoudigt de lay-out van het project. De prestaties zijn prima voor de 20-30 mensen die de app gebruiken.
Antwoord 25, autoriteit 2%
Mijn ervaring was dat ik beide situaties moest beheren: afbeeldingen opgeslagen in database en afbeeldingen op het bestandssysteem met pad opgeslagen in db.
De eerste oplossing, afbeeldingen in de database, is wat “schoner” omdat uw gegevenstoegangslaag alleen met database-objecten te maken heeft; maar dit is alleen goed als je te maken hebt met lage aantallen.
Het is duidelijk dat de prestaties van de databasetoegang afnemen wanneer u te maken hebt met binaire grote objecten, en de databasedimensies zullen veel groter worden, wat opnieuw prestatieverlies veroorzaakt… en normaal gesproken is databaseruimte veel duurder dan bestandssysteemruimte.
Aan de andere kant zal het hebben van grote binaire objecten die zijn opgeslagen in het bestandssysteem ervoor zorgen dat u back-upplannen hebt die rekening moeten houden met zowel de database als het bestandssysteem, en dit kan voor sommige systemen een probleem zijn.
Een andere reden om voor een bestandssysteem te gaan, is wanneer u uw afbeeldingsgegevens (of geluiden, video, wat dan ook) moet delen met toegang van derden: tegenwoordig ontwikkel ik een web-app die afbeeldingen gebruikt die moeten worden geopend van “buiten” mijn webfarm op een zodanige manier dat een databasetoegang om binaire gegevens op te halen eenvoudigweg onmogelijk is. Dus soms zijn er ook ontwerpoverwegingen die u tot een keuze zullen leiden.
Overweeg bij het maken van deze keuze ook of u te maken heeft met toestemming en authenticatie bij het benaderen van binaire objecten: deze vereisten kunnen normaal gesproken eenvoudiger worden opgelost wanneer gegevens worden opgeslagen in db.
Antwoord 26
Ik heb ooit aan een beeldverwerkingsprogramma gewerkt. We hebben de geüploade afbeeldingen opgeslagen in een map die zoiets was als /images/[datum van vandaag]/[id-nummer]. Maar we hebben ook de metadata (exif-data) uit de afbeeldingen gehaald en opgeslagen in de database, samen met een tijdstempel en dergelijke.
Antwoord 27
In een vorig project heb ik afbeeldingen op het bestandssysteem opgeslagen, en dat veroorzaakte veel kopzorgen met back-ups, replicatie en het bestandssysteem dat niet meer synchroon liep met de database.
In mijn laatste project sla ik afbeeldingen op in de database en sla ik ze op in het bestandssysteem, en het werkt echt goed. Ik heb tot nu toe geen problemen gehad.
Antwoord 28
Ten tweede de aanbeveling over bestandspaden. Ik heb aan een aantal projecten gewerkt die omvangrijke activaverzamelingen moesten beheren, en alle pogingen om dingen rechtstreeks in de database op te slaan, resulteerden op lange termijn in pijn en frustratie.
De enige echte “pro” die ik kan bedenken met betrekking tot het opslaan in de DB, is de mogelijkheid om individuele afbeeldingsmiddelen gemakkelijk te maken. Als er geen bestandspaden zijn om te gebruiken en alle afbeeldingen rechtstreeks uit de database worden gestreamd, bestaat er geen gevaar dat een gebruiker bestanden vindt waartoe ze geen toegang zouden moeten hebben.
Dat lijkt echter beter te kunnen worden opgelost met een intermediair script dat gegevens ophaalt uit een op het web ontoegankelijke bestandsopslag. Dus de DB-opslag is niet ECHT nodig.
Antwoord 29
Het woord op straat is dat tenzij je een databaseverkoper bent die probeert te bewijzen dat je database het kan (zoals, laten we zeggen dat Microsoft opschept over Terraserver die een groot aantal afbeeldingen opslaat in SQL Server), het geen erg goed idee is. Als het alternatief – het opslaan van afbeeldingen op bestandsservers en paden in de database zoveel gemakkelijker is, waarom zou u zich dan druk maken? Blob-velden zijn een beetje zoals de offroad-capaciteiten van SUV’s – de meeste mensen gebruiken ze niet, degenen die wel in de problemen komen, en dan zijn er nog die dat wel doen, maar alleen voor de lol.
Antwoord 30
Het opslaan van een afbeelding in de database betekent nog steeds dat de afbeeldingsgegevens ergens in het bestandssysteem terechtkomen, maar verborgen zijn, zodat u er niet rechtstreeks toegang toe hebt.
+ves:
- database-integriteit
- het is gemakkelijk te beheren, omdat u zich geen zorgen hoeft te maken over het synchroon houden van het bestandssysteem wanneer een afbeelding wordt toegevoegd of verwijderd
-ves:
- prestatieverlies — het opzoeken van een database is meestal langzamer dan het opzoeken van het bestandssysteem
- je kunt de afbeelding niet rechtstreeks bewerken (bijsnijden, formaat wijzigen)
Beide methoden zijn gebruikelijk en worden toegepast. Kijk eens naar de voor- en nadelen. Hoe dan ook, je zult moeten nadenken over hoe je de nadelen kunt overwinnen. Opslaan in de database betekent meestal het aanpassen van databaseparameters en het implementeren van een soort caching. Het gebruik van bestandssysteem vereist dat je een manier vindt om bestandssysteem+database synchroon te houden.