Objectstore best practices

[storeman]

Voor een webapplicatie lijkt het gebruik van een objectstore me erg handig om de volgende redenen:
- Geen back-up zorgen meer
- Geen load op webserver
- Geen/minder zorgen met integriteit.

Mijn idee is om in de applicatie op een formulier bestanden te kunnen uploaden, al dan niet gekoppeld in de DB aan iets. De browser upload dit naar de webserver alwaar PHP de upload afhandelt. Zoals ik het voor me zie gebeurt er dan ongeveer het volgende:

- Check of upload correct is
- Upload naar het juiste project/container
- Bewaar URL in database

Ik ben van plan gebruik te gaan maken van OpenStack met de php implementatie php-opencloud.

Ik vind het allemaal niet erg transparant om er goed mee aan de slag te gaan. Wellicht kan iemand me een kant op sturen?

Op basis waarvan zeg je dat iets een project (lijkt me tamelijk duidelijk) of container moet.

Stel ik wil een auto opslaan in mijn database, met wat standaard velden, maar daarnaast wil ik er afbeeldingen aan koppelen:
- interieur
- voorkant
- zijkant
- achterkant

[Hydra]

Mist er een stuk van je post?

Wij gebruiken Amazon S3 en daar maken we gewoon voor elke klant een bucket aan. Binnen die bucket is het gewoon een url, dus iets als:

http://<bucket>.s3.amazon.com/cars/<carid>/parts/<partid>

Je kunt dan aan de hand van een car id en een part id (plaatje interieur, e.d.) de URL construeren.

[storeman]

Er mist geen deel van mijn post, maar nu ik er zo naar kijken, snap ik dat je dat denkt. Het is nogal een abrupt einde.

Zoals ik het bij openstack zie, kun je geen containers binnen containers maken. Ik zou dan een container maken:
cars/car/<car id>

en in die container stop ik dan verschillende parts.

Ergens heb ik het gevoel dat ik nog iets mis, maar ik zal er gewoon eens mee aan de slag gaan. Wellicht dat ik er zonder problemen uit kom.


Ik heb natuurlijk een ontwikkelomgeving en straks ook een productieomgeving. Wat is dan wijsheid, voor iedere omgeving een ander project, of alleen een andere container?

[ Voor 16% gewijzigd door storeman op 17-03-2014 13:16 ]

[Hydra]

Je stelt nu meer OpenStack specifieke vragen, daar kan ik je verder niet echt mee van dienst zijn. In S3 bestaan 'containers' niet echt, die zijn impliciet in de delen van een URL (je hebt in mijn voorbeeld een 'cars' container, maar dat is niks meer dan een deel van de URL voor het plaatje). Ik ken de limieten van openstack niet, ik weet niet hoe het omgaat met urls e.d.

Wat je altijd nog kunt doen is gewoon ieder plaatje opslaan met een UUID en dan in je database gewoon de UUID onthouden. Dan heb je sowieso geen gedoe met urls e.d. Alleen kun je er dan minder makkelijk doorheen browsen.

Wat betreft productie versus dev: wij maken voor een klant gewoon een productie en een dev bucket aan. Dus vertaald zou ik dan voor een <klant> en een <klant>-dev 'project' gaan.

[storeman]

Een uuid vind ik een goed idee. Het geeft natuurlijk geen inzicht in hoe alles heet, maar dit kan wat mij betreft juist een voordeel zijn. OpenStack heeft de mogelijkheid tot opslaan van meta-data, hiermee kan ik de data nog enigszins structureren.

Je zegt alleen het UUID opslaan. Ik zat echter te denken aan de volledige URL, maar dat maak het geheel natuurlijk minder flexibel. Bij het verhuizen van de data zou ik, in het geval van slechts de UUID, alleen een config aan hoeven te passen en alles draait weer. Al zou een query dit ook op kunnen lossen, het is minder mooi.

[Hydra]

Dat laatste is dus precies de reden dat je niet de hele url opslaat.

[storeman]

Bij nader inzien ga ik toch voor de volledige URL. Er zijn meerdere applicaties die de data gebruiken. Een volledige URL is in een dergelijke situatie een stuk transparanter.

[Styxxy]

storeman schreef op dinsdag 18 maart 2014 @ 09:32:
Bij nader inzien ga ik toch voor de volledige URL. Er zijn meerdere applicaties die de data gebruiken. Een volledige URL is in een dergelijke situatie een stuk transparanter.

Dan kan je beter een algemene "component" voorzien die de juiste URL terug geeft.

[EagleTitan]

Kijk ook eens naar Gaufrette, die abstract de hele ObjectStore container weg, zodat je het gewoon als een filesystem kan benaderen. Dan hoef je vervolgens alleen nog maar op te slaan in welk filesystem het bestand staat onder welke key.