- Code per gestire gli aggiornamenti dell'inventario per ogni canale.
Questo non è necessariamente un problema di database. Potrebbe essere meglio guardare un sistema di messaggistica (ad es. RabbitMQ)
- Tabella dell'inventario che ha un'istantanea corretta dell'allocazione su ciascun canale.
- Mantenimento di ID sessione e altri dati di accesso rapido in una cache.
i dati della sessione dovrebbero probabilmente essere inseriti in un database separato più adatto per l'attività (ad es. memcached, redis, ecc.) Non esiste un DB valido per tutti
- Fornire una dashboard simile a Facebook (XMPP) per mantenere il venditore aggiornato il prima possibile.
I miei vincoli sono:1. Gli aggiornamenti dell'inventario non possono essere persi.
Ci sono 3 modi per rispondere a questa domanda:
-
Questa funzione deve essere fornita dall'applicazione. Il database può garantire che un record errato venga rifiutato e ripristinato, ma non garantisce che tutte le query vengano inserite. L'app dovrà essere abbastanza intelligente da riconoscere quando si verifica un errore e riprovare.
-
alcuni DB archiviano i record in memoria e quindi scaricano periodicamente la memoria sul disco, ciò potrebbe causare la perdita di dati in caso di interruzione dell'alimentazione. (ad es. Mongo funziona in questo modo per impostazione predefinita, a meno che non si abiliti il journaling. CouchDB si aggiunge sempre ai record (anche un'eliminazione è un flag aggiunto al record, quindi la perdita di dati è estremamente difficile))
-
Alcuni DB sono progettati per essere estremamente affidabili, anche se si verificano terremoti, uragani o altri disastri naturali, rimangono durevoli. questi includono Cassandra, Hbase, Riak, Hadoop, ecc
A quale tipo di durabilità ti riferisci?
- Le code di lavoro devono essere eseguite in ordine e preferibilmente mai perse.
La maggior parte delle soluzioni noSQL preferisce essere eseguita in parallelo. quindi hai due opzioni qui.1. utilizzare un DB che blocchi l'intera tabella per ogni query (più lenta)2. crea la tua app per essere più intelligente o con eventi (accodamento sequenziale lato client)
- Sviluppo facile/veloce e manutenzione futura.
in genere, all'inizio scoprirai che SQL è più veloce da sviluppare, ma le modifiche possono essere più difficili da implementarenoSQL potrebbe richiedere un po' più di pianificazione, ma è più facile eseguire query ad hoc o modifiche allo schema.
Le domande che probabilmente ti devi porre sono più simili a:
-
"Avrò bisogno di query intense o analisi approfondite a cui Map/Reduce è più adatto?"
-
"avrò bisogno di cambiare frequentemente il mio schema?
-
"i miei dati sono altamente relazionali? in che modo?"
-
"il fornitore dietro il mio DB scelto ha abbastanza esperienza per aiutarmi quando ne ho bisogno?"
-
"avrò bisogno di funzionalità speciali come l'indicizzazione geospaziale, la ricerca full-text, ecc?"
-
"quanto vicino al tempo reale avrò bisogno dei miei dati? Farà male se non vedo gli ultimi record mostrati nelle mie query fino a 1 secondo dopo? quale livello di latenza è accettabile?"
-
"di cosa ho veramente bisogno in termini di failover"
-
"quanto sono grandi i miei dati? Si adattano alla memoria? Si adattano a un computer? Ogni singolo record è grande o piccolo?
-
"ogni quanto cambieranno i miei dati? è un archivio?"
Se hai più clienti (canali?) Ciascuno con i propri schemi di inventario, un DB basato su documenti potrebbe avere i suoi vantaggi. Ricordo che una volta ho guardato un sistema di e-commerce con inventario e aveva quasi 235 tabelle! Inoltre, se hai determinati dati relazionali, anche una soluzione SQL può davvero avere dei vantaggi.
Posso certamente vedere come potrei costruire una soluzione usando mongo, couch, riak o orientdb con i vincoli indicati. Ma per quanto riguarda quale è il migliore? Proverei a parlare direttamente con i fornitori di DB e forse a guardare i nastri nosql
