- Files d'attente pour gérer les mises à jour d'inventaire pour chaque chaîne.
Ce n'est pas nécessairement un problème de base de données. Vous feriez peut-être mieux de regarder un système de messagerie (par exemple RabbitMQ)
- Tableau d'inventaire contenant un instantané correct de l'allocation sur chaque canal.
- Conservation des identifiants de session et d'autres données d'accès rapide dans un cache.
les données de session doivent probablement être placées dans une base de données séparée plus adaptée à la tâche (par exemple, memcached, redis, etc.) Il n'y a pas de base de données unique
- Fournir un tableau de bord de type Facebook (XMPP) pour tenir le vendeur informé dès que possible.
Mes contraintes sont :1. Les mises à jour d'inventaire ne peuvent pas être perdues.
Il y a 3 façons de répondre à cette question :
-
Cette fonctionnalité doit être fournie par votre application. La base de données peut garantir qu'un enregistrement incorrect est rejeté et annulé, mais ne garantit pas que chaque requête sera saisie. L'application devra être suffisamment intelligente pour reconnaître lorsqu'une erreur se produit et réessayer.
-
certaines bases de données stockent les enregistrements en mémoire, puis vident la mémoire sur le disque de manière périodique, ce qui peut entraîner une perte de données en cas de panne de courant. (par exemple, Mongo fonctionne de cette façon par défaut, sauf si vous activez la journalisation. CouchDB ajoute toujours aux enregistrements (même une suppression est un indicateur ajouté à l'enregistrement, la perte de données est donc extrêmement difficile))
-
Certaines bases de données sont conçues pour être extrêmement fiables, même si un tremblement de terre, un ouragan ou une autre catastrophe naturelle frappe, elles restent durables. ceux-ci incluent Cassandra, Hbase, Riak, Hadoop, etc
À quel type de durabilité faites-vous référence ?
- Les files d'attente de travaux doivent être exécutées dans l'ordre et de préférence jamais perdues.
La plupart des solutions noSQL préfèrent fonctionner en parallèle. vous avez donc deux options ici.1. utiliser une base de données qui verrouille toute la table pour chaque requête (plus lente)2. créez votre application pour qu'elle soit plus intelligente ou événementielle (file d'attente séquentielle côté client)
- Développement facile/rapide et maintenance future.
généralement, vous constaterez que SQL est plus rapide à développer au début, mais les modifications peuvent être plus difficiles à implémenter. NoSQL peut nécessiter un peu plus de planification, mais il est plus facile d'effectuer des requêtes ad hoc ou des modifications de schéma.
Les questions que vous devez probablement vous poser ressemblent plutôt à :
-
"Aurai-je besoin d'avoir des requêtes intenses ou une analyse approfondie pour laquelle un Map/Reduce est mieux adapté ?"
-
"aurai-je besoin de changer mon schéma fréquemment ?
-
"mes données sont-elles hautement relationnelles ? en quoi ?"
-
"Est-ce que le fournisseur derrière la base de données que j'ai choisie a suffisamment d'expérience pour m'aider quand j'en ai besoin ?"
-
"aurai-je besoin de fonctionnalités spéciales telles que l'indexation géospatiale, la recherche plein texte, etc ?"
-
"Dans quelle mesure aurai-je besoin de mes données en temps réel ? Cela me fera-t-il mal si je ne vois pas les derniers enregistrements apparaître dans mes requêtes jusqu'à 1 seconde plus tard ? Quel niveau de latence est acceptable ?"
-
"de quoi ai-je vraiment besoin en termes de basculement"
-
"Quelle est la taille de mes données ? Tient-elle en mémoire ? Tient-elle sur un seul ordinateur ? Chaque enregistrement individuel est-il grand ou petit ?
-
"à quelle fréquence mes données vont-elles changer ? est-ce une archive ?"
Si vous allez avoir plusieurs clients (canaux ?), chacun avec ses propres schémas d'inventaire, une base de données basée sur des documents peut avoir ses avantages. Je me souviens d'une fois où j'ai regardé un système de commerce électronique avec inventaire et il y avait près de 235 tables ! Là encore, si vous avez certaines données relationnelles, une solution SQL peut également avoir des avantages.
Je peux certainement voir comment je pourrais construire une solution en utilisant mongo, couch, riak ou orientdb avec les contraintes données. Mais quant à qui est le meilleur ? J'essaierais de parler directement aux fournisseurs de bases de données, et peut-être de regarder les bandes nosql
