SQL vs NoSQL för ett lagerhanteringssystem

1. Köer för att hantera lageruppdateringar för varje kanal.

Detta är inte nödvändigtvis ett databasproblem. Du kanske är bättre att titta på ett meddelandesystem (t.ex. RabbitMQ)

1. Inventeringstabell som har en korrekt ögonblicksbild av allokering på varje kanal.
2. Behåller sessions-ID och andra snabbåtkomstdata i en cache.

sessionsdata bör förmodligen placeras i en separat databas som är mer lämpad för uppgiften (t.ex. memcached, redis, etc) Det finns ingen enhetlig databas

1. Tillhandahålla en Facebook-liknande instrumentpanel (XMPP) för att hålla säljaren uppdaterad så fort som möjligt.

Mina begränsningar är:1. Lageruppdateringar kan inte gå förlorade.

Det finns tre sätt att svara på den här frågan:

1. Denna funktion måste tillhandahållas av din applikation. Databasen kan garantera att en dålig post avvisas och rullas tillbaka, men inte garantera att varje fråga kommer in. Appen måste vara smart nog att känna igen när ett fel inträffar och försöka igen.

2. vissa DBs lagrar poster i minnet och spola sedan minnet till disken peridokalt, detta kan leda till dataförlust vid strömavbrott. (t.ex. Mongo fungerar på detta sätt som standard om du inte aktiverar journalföring. CouchDB läggs alltid till i posterna (även en radering är en flagga som läggs till i posten så dataförlust är extremt svårt))

3. Vissa DB:er är designade för att vara extremt pålitliga, även om en jordbävning, orkan eller annan naturkatastrof inträffar, förblir de hållbara. dessa inkluderar Cassandra, Hbase, Riak, Hadoop, etc

Vilken typ av hållbarhet syftar du på?

1. Jobbköer ska köras i ordning och helst aldrig gå förlorade.

De flesta noSQL-lösningar föredrar att köra parallellt. så du har två alternativ här.1. använd en DB som låser hela tabellen för varje fråga (långsammare)2. skapa din app för att vara smartare eller händelserik (sekventiell kö på klientsidan)

1. Enkel/snabb utveckling och framtida underhåll.

generellt sett kommer du att upptäcka att SQL är snabbare att utveckla till en början, men förändringar kan vara svårare att implementeranoSQL kan kräva lite mer planering, men det är lättare att göra ad hoc-frågor eller schemaändringar.

Frågorna du förmodligen behöver ställa dig själv är mer som:

1. "Behöver jag ha intensiva frågor eller djup analys som en Map/Reduce är bättre lämpad för?"

2. "kommer jag att behöva ändra mitt schema ofta?

3. "är mina data mycket relationella? På vilket sätt?"

4. "har leverantören bakom min valda DB tillräckligt med erfarenhet för att hjälpa mig när jag behöver det?"

5. "behöver jag speciella funktioner som GeoSpatial indexering, fulltextsökning, etc?"

6. "hur nära realtid kommer jag att behöva min data? Kommer det att göra ont om jag inte ser de senaste posterna i mina frågor förrän 1 sek senare? Vilken fördröjningsnivå är acceptabel?"

7. "vad behöver jag egentligen när det gäller fail-over"

8. "hur stor är min data? får den plats i minnet? får den plats på en dator? är varje enskild post stor eller liten?

9. "hur ofta kommer mina data att ändras? är detta ett arkiv?"

Om du ska ha flera kunder (kanaler?) var och en med sina egna lagerscheman, kan en dokumentbaserad DB ha sina fördelar. Jag minns en gång jag tittade på ett e-handelssystem med inventering och det hade nästan 235 tabeller! Och om du har vissa relationsdata kan en SQL-lösning verkligen ha vissa fördelar också.

Jag kan verkligen se hur jag kunde bygga en lösning med mongo, soffa, riak eller orientdb med de givna begränsningarna. Men vad är det som är bäst? Jag skulle försöka prata direkt med DB-leverantörer och kanske titta på nosql-banden