- Warteschlangen zum Verwalten von Bestandsaktualisierungen für jeden Kanal.
Dies ist nicht unbedingt ein Datenbankproblem. Vielleicht ist es besser, wenn Sie sich ein Messaging-System ansehen (z. B. RabbitMQ)
- Bestandstabelle, die einen korrekten Snapshot der Zuordnung auf jedem Kanal enthält.
- Speichern von Sitzungs-IDs und anderen Schnellzugriffsdaten in einem Cache.
Sitzungsdaten sollten wahrscheinlich in einer separaten Datenbank abgelegt werden, die für die Aufgabe besser geeignet ist (z. B. Memcached, Redis usw.). Es gibt keine Einheitsdatenbank
- Bereitstellung eines Facebook-ähnlichen Dashboards (XMPP), um den Verkäufer so schnell wie möglich auf dem Laufenden zu halten.
Meine Einschränkungen sind:1. Bestandsaktualisierungen können nicht verloren gehen.
Es gibt drei Möglichkeiten, diese Frage zu beantworten:
-
Diese Funktion muss von Ihrer Anwendung bereitgestellt werden. Die Datenbank kann garantieren, dass ein fehlerhafter Datensatz abgelehnt und rückgängig gemacht wird, aber nicht garantieren, dass jede Abfrage eingegeben wird. Die App muss intelligent genug sein, um zu erkennen, wenn ein Fehler auftritt, und es erneut zu versuchen.
-
Einige DBs speichern Datensätze im Speicher und leeren den Speicher dann periodisch auf die Festplatte, dies könnte im Falle eines Stromausfalls zu Datenverlust führen. (z. B. funktioniert Mongo standardmäßig auf diese Weise, es sei denn, Sie aktivieren das Journaling. CouchDB hängt immer an die Datensätze an (sogar ein Löschvorgang ist ein Flag, das an den Datensatz angehängt wird, sodass Datenverlust extrem schwierig ist))
-
Einige DBs sind auf extreme Zuverlässigkeit ausgelegt, selbst wenn ein Erdbeben, ein Hurrikan oder eine andere Naturkatastrophe zuschlägt, bleiben sie langlebig. Dazu gehören Cassandra, Hbase, Riak, Hadoop usw.
Auf welche Art von Haltbarkeit beziehen Sie sich?
- Auftragswarteschlangen sollten der Reihe nach ausgeführt werden und möglichst nie verloren gehen.
Die meisten noSQL-Lösungen ziehen es vor, parallel zu laufen. Sie haben hier also zwei Möglichkeiten.1. Verwenden Sie eine DB, die die gesamte Tabelle für jede Abfrage sperrt (langsamer)2. Bauen Sie Ihre App intelligenter oder ereignisgesteuert auf (clientseitige sequenzielle Warteschlangenbildung)
- Einfache/schnelle Entwicklung und zukünftige Wartung.
Im Allgemeinen werden Sie feststellen, dass SQL zunächst schneller zu entwickeln ist, aber Änderungen können schwieriger zu implementieren sein. noSQL erfordert möglicherweise etwas mehr Planung, ist aber einfacher, Ad-hoc-Abfragen oder Schemaänderungen durchzuführen
Die Fragen, die Sie sich wahrscheinlich stellen müssen, lauten eher wie folgt:
-
„Benötige ich intensive Abfragen oder tiefgreifende Analysen, für die ein Map/Reduce besser geeignet ist?“
-
"Muss ich mein Schema häufig ändern?
-
"Sind meine Daten stark relational? Inwiefern?"
-
„Hat der Anbieter hinter meiner gewählten Datenbank genug Erfahrung, um mir zu helfen, wenn ich sie brauche?“
-
"Benötige ich spezielle Funktionen wie GeoSpatial-Indizierung, Volltextsuche usw.?"
-
„Wie echtzeitnah brauche ich meine Daten? Tut es weh, wenn die neuesten Datensätze erst 1 Sekunde später in meinen Abfragen angezeigt werden? Welche Latenz ist akzeptabel?“
-
"Was brauche ich wirklich in Bezug auf Failover"
-
„Wie groß sind meine Daten? Passen sie in den Arbeitsspeicher? Passen sie auf einen Computer? Ist jeder einzelne Datensatz groß oder klein?
-
"Wie oft ändern sich meine Daten? Ist das ein Archiv?"
Wenn Sie mehrere Kunden (Kanäle?) mit jeweils eigenen Bestandsschemata haben, könnte eine dokumentenbasierte DB ihre Vorteile haben. Ich erinnere mich, dass ich mir einmal ein E-Commerce-System mit Inventar angesehen habe und es fast 235 Tabellen hatte! Andererseits kann eine SQL-Lösung auch wirklich einige Vorteile haben, wenn Sie über bestimmte relationale Daten verfügen.
Ich kann mir durchaus vorstellen, wie ich eine Lösung mit Mongo, Couch, Riak oder Orientdb mit den gegebenen Einschränkungen erstellen könnte. Aber was ist das Beste? Ich würde versuchen, direkt mit DB-Anbietern zu sprechen, und mir vielleicht die Nosql-Bänder ansehen
