Moet ik afbeeldingen bewaren op EBS of S3?

Ik migreer mijn Java,Tomcat, Mysql-server naar AWS EC2.

Ik heb al een EBS-volume aangesloten voor het opslaan van MySql-gegevens. In mijn webapplicatie kunnen mensen afbeeldingen uploaden. Dus ik zou ze moeten volhouden. Er zijn 2 alternatieven in mijn gedachten:

1. Geuploade afbeeldingen opslaan op EBS-volume.
2. Gebruik de S3-service.

De volgende zijn mijn aantekeningen, wees er sceptisch over, aangezien mijn expertise niet op servers ligt, maar op softwareontwikkeling.

• EBS plus: S3-opslag is duurder. (0,15 $/Gb > 0,1$/Gb)

• S3 plus: Statistieken van EBS kunnen de prestaties van mijn webserver negatief beïnvloeden. Is dit waar? Heeft het presenteren van afbeeldingen met name invloed op de serverprestaties? Voor S3 is mijn server niet verantwoordelijk voor het weergeven van statistieken.

• S3 plus: het weergeven van statische gegevens van EBS kan I/O-kosten tot gevolg hebben, waarschijnlijk zijn deze gering.

• EBS plus: mensen zeggen dat EBS sneller is.

• S3 plus: mensen zeggen dat S3 veiliger is voor persistentie.

• EBS plus: het is niet nodig om API te leren, het is eenvoudig om de afbeeldingen op te slaan op EBS-volume.

Ik kan namelijk niet beslissen, ik zal blij zijn als je begeleidt.

Bedankt

Antwoord 1, autoriteit 100%

De prijsvergelijking klopt niet helemaal:
S3-kosten zijn $ 0,14 per GEBRUIKTE GB, terwijl EBS-kosten $ 0,10 per GELEVERDE GB zijn (de grootte van uw EBS-volume), of u het nu gebruikt of niet. Als gevolg hiervan kan S3 al dan niet goedkoper zijn dan EBS.

Antwoord 2, autoriteit 92%

Ik gebruik momenteel S3 voor een project en het werkt buitengewoon goed.

EBS betekent dat u een volume + machines moet beheren om het aan te koppelen. Je moet ruimte toevoegen terwijl het vol raakt en back-ups maken (waarmee ik niet wil zeggen dat je geen back-up van je S3-gegevens moet maken, alleen dat het niet zo belangrijk is).

Het maakt het ook moeilijker om te schalen: als je extra machines wilt toevoegen, moet je ofwel de afbeeldingen naar een aparte machine halen of de afbeeldingen naar alle apparaten klonen. Dit betekent ook dat u een knelpunt toevoegt: u moet uw eigen uploadproces beheren dat ofwel naar alle machines uploadt, ofwel door één enkele machine wordt beheerd.

Ik raad S3 aan: het is ingesteld en vergeet het. Een willekeurig aantal machines kan parallel uploads uitvoeren en u hoeft andere machines niet echt op de hoogte te stellen van de upload.

Bovendien kun je Amazon Cloudfront gebruiken als een goedkoop CDN voor de afbeeldingen in plaats van direct te downloaden van S3.

Antwoord 3, autoriteit 23%

Ik heb oplossingen ontwikkeld voor AWS voor stockfotosites die miljoenen afbeeldingen opslaan die TB’s aan gegevens beslaan. Ik zou graag enkele van de beste praktijken in AWS willen delen voor uw behoefte:

P1) Sla het originele afbeeldingsbestand op in de S3 Standard-optie

P2) Sla de reproduceerbare afbeeldingen zoals duimen enz. op in de S3 Reduced Redundancy-optie (RRS) om kosten te besparen

P3) Metagegevens over afbeeldingen, inclusief de S3-URL, kunnen worden opgeslagen in Amazon RDS of Amazon DynamoDB, afhankelijk van de complexiteit van de zoekopdracht. Vraag de vermeldingen van Amazon RDS op. Als uw zoekopdracht complex is, is het ook gebruikelijk om de metagegevens op te slaan in Amazon CloudSearch of Apache Solr.

P4) Lever uw duimen aan gebruikers met een lage latentie met behulp van Amazon CloudFront.

P5) Zet ​​uw afbeeldingsconversie in de wachtrij via SQS of RabbitMQ op Amazon EC2

P6) Als u van plan bent om EBS te gebruiken, dan zijn ze niet schaalbaar met uw EC2. Dus idealiter kunt u GlusterFS gebruiken als uw gemeenschappelijke opslagpool voor al uw afbeeldingen. Meerdere Amazon EC2 in Auto Scaled-modus kunnen er nog steeds verbinding mee maken en afbeeldingen openen/schrijven.

Antwoord 4, autoriteit 15%

Je hebt de voor- en nadelen van beide al geschetst.

Als u van plan bent om terabytes aan afbeeldingen op te slaan, waarbij de opslagvereisten elke dag toenemen, S3zal waarschijnlijk de beste keuze zijn, omdat het speciaal voor dit soort situaties is gebouwd. U krijgt onbeperkte opslagruimte, zonder dat u zich zorgen hoeft te maken over het sharden van uw gegevensover vele EBS-volumes.

De terugkerende kosten van S3 zijn dat het 50% duurder is dan EBS. Je zult ook de API moeten leren en implementeren in je applicatie, maar dat is een eenmalige uitgave die je volgens mij heel snel moet kunnen absorberen.

Antwoord 5, autoriteit 9%

Verwacht u dat de afbeeldingen voor onbepaalde tijd meegaan?

De Amazon EBS FAQ is vrij duidelijk; het jaarlijkse uitvalpercentage is niet “in wezen nul”; ze citeren 0,1% tot 0,5%. Het is beter dan de schijf onder je bureau, maar er is een soort back-up voor nodig.