SQL versus NoSQL voor een voorraadbeheersysteem

1. Wachtrijen om voorraadupdates voor elk kanaal te beheren.

Dit is niet noodzakelijk een databaseprobleem. Het is misschien beter om naar een berichtensysteem te kijken (bijv. RabbitMQ)

1. Inventaristabel met een juiste momentopname van de toewijzing op elk kanaal.
2. Sessie-ID's en andere snelle toegangsgegevens in een cache bewaren.

sessiegegevens moeten waarschijnlijk in een aparte database worden geplaatst die meer geschikt is voor de taak (bijvoorbeeld memcached, redis, enz.) Er is geen one-size-fits-all DB

1. Een Facebook-achtig dashboard (XMPP) bieden om de verkoper zo snel mogelijk op de hoogte te houden.

Mijn beperkingen zijn:1. Voorraadupdates kunnen niet verloren gaan.

Er zijn 3 manieren om deze vraag te beantwoorden:

1. Deze functie moet worden geleverd door uw toepassing. De database kan garanderen dat een slecht record wordt afgewezen en teruggedraaid, maar kan niet garanderen dat elke zoekopdracht wordt ingevoerd. De app moet slim genoeg zijn om te herkennen wanneer er een fout optreedt en het opnieuw te proberen.

2. sommige DB's slaan records op in het geheugen en spoelen het geheugen vervolgens periodiek naar de schijf, dit kan leiden tot gegevensverlies in het geval van een stroomstoring. (Mongo werkt bijvoorbeeld standaard op deze manier, tenzij u journaal inschakelt. CouchDB wordt altijd toegevoegd aan de records (zelfs een verwijdering is een vlag die aan de record wordt toegevoegd, dus gegevensverlies is buitengewoon moeilijk))

3. Sommige DB's zijn ontworpen om extreem betrouwbaar te zijn, zelfs als een aardbeving, orkaan of andere natuurramp toeslaat, blijven ze duurzaam. deze omvatten Cassandra, Hbase, Riak, Hadoop, enz.

Welk type duurzaamheid bedoel je?

1. Opdrachtwachtrijen moeten in volgorde worden uitgevoerd en bij voorkeur nooit verloren gaan.

De meeste noSQL-oplossingen werken het liefst parallel. dus je hebt hier twee opties.1. gebruik een database die de hele tabel vergrendelt voor elke query (langzamer)2. bouw uw app om slimmer of evented te zijn (client side sequentiële wachtrijen)

1. Eenvoudige/snelle ontwikkeling en toekomstig onderhoud.

over het algemeen zult u merken dat SQL in het begin sneller te ontwikkelen is, maar wijzigingen kunnen moeilijker te implementeren zijn, geen SQL vereist misschien wat meer planning, maar het is gemakkelijker om ad-hocquery's of schemawijzigingen uit te voeren.

De vragen die je jezelf waarschijnlijk moet stellen zijn meer als:

1. "Moet ik intensieve vragen of diepgaande analyses hebben waarvoor een Map/Reduce beter geschikt is?"

2. "moet ik mijn schema vaak wijzigen?

3. "zijn mijn gegevens zeer relationeel? op welke manier?"

4. "heeft de verkoper achter mijn gekozen database voldoende ervaring om me te helpen wanneer ik het nodig heb?"

5. "heb ik een speciale functie nodig, zoals GeoSpatial-indexering, zoeken in volledige tekst, enz?"

6. "Hoe dicht bij realtime heb ik mijn gegevens nodig? doet het pijn als ik pas 1 seconde later de nieuwste records in mijn zoekopdrachten zie verschijnen? Welk latentieniveau is acceptabel?"

7. "wat heb ik echt nodig qua fail-over"

8. "hoe groot zijn mijn gegevens? past het in het geheugen? past het op één computer? is elk afzonderlijk record groot of klein?

9. "hoe vaak zullen mijn gegevens veranderen? is dit een archief?"

Als u meerdere klanten (kanalen?) gaat hebben met elk hun eigen inventarisschema's, kan een op documenten gebaseerde database voordelen hebben. Ik herinner me een keer dat ik naar een e-commercesysteem met voorraad keek en het had bijna 235 tabellen! Aan de andere kant, als je bepaalde relationele gegevens hebt, kan een SQL-oplossing ook echt voordelen hebben.

Ik kan zeker zien hoe ik een oplossing zou kunnen bouwen met behulp van mongo, bank, riak of orientdb met de gegeven beperkingen. Maar wat is het beste? Ik zou proberen rechtstreeks met DB-leveranciers te praten en misschien de nosql-tapes bekijken