CQRS avec cockroachdb en configuration polyglotte

Question

J'envisageais d'utiliser cockroachdb pour écrire des données en 3e forme normale avec des garanties ACID. Donc toutes les écritures seront détournées vers cockroachdb.

Les lectures peuvent toutes être une recherche de point basée sur une clé de ligne à Cassandra. Je crois qu'une telle configuration de lecture éliminera le besoin de mise en cache redis puisque Cassandra donnera des lectures rapides par elle-même. Ainsi, les tables Cassandra seront dénormalisées en fonction des chemins d'accès.

Il peut y avoir une synchronisation basée sur les événements à partir de insert/update/delete dans le schéma normalisé cockroachdb pour insérer/mettre à jour/supprimer dans le schéma cassandra denormalzied.

Question 1:

Est-ce en lecture/écriture en forme de séparation dans un usecase valide pour l'utilisation cockroachdb? L'intention est de réduire les jointures et d'avoir des lectures rapides ainsi que des écritures. Cockroachdb devient une source unique de vérité en ingérant des données de type Event Sourcing. Et d'autres bases de données comme cassandra et elasticsearch deviennent des projections de requêtes qui sont finalement synchronisées.

Question 2:

Est-ce bon d'installation avec les transactions financières où les déclarations N doivent faire atomiquement? D'après ce que je comprends, supposons qu'il y ait N instructions SQL qui sont faites transactionnellement dans le schéma 3NF de cockroachdb. Après cela, les lectures arrivent de Cassandra/ElasticSearch qui ne sera pas encore synchronisé en raison de la latence de synchronisation. Dans ce scénario de cohérence éventuel, si l'utilisateur envoie une autre commande pour obtenir le même résultat de l'autre machine en parallèle, cela ira au gestionnaire de commandes qui recherchera dans cockroachdb. Je pense que puisque CockroachDb est conforme ACID, nous allons invalider la commande lors de l'étape de validation de la commande après la recherche de cockroachdb. Je crois que ce cockroachdb lancera une exception de verrou optimiste car une transaction qui écrit sur la même table est déjà en cours. Donc la question est - dans de tels scénarios, devrions-nous lire aussi bien de CockroachDB au lieu de Cassandra/ElasticSearch?

Question 3

usecase dernière, j'avais à l'esprit était d'avoir cockroachdb jouer le rôle ce qu'un groupe d'étincelle fera avec cassandra par rapport à agrégations. Nous pouvons faire l'agrégation à l'intérieur de cockroachdb qui a toutes les données et stocker dans des tables pré-agrégées dans Cassandra. Bien qu'ElasticSearch soit aussi capable de faire de l'agrégation, voici une question: cette fonctionnalité semble-t-elle également correcte à l'aide de cockroachdb au lieu de elasticsearch pour l'agrégation?

Answer 1

En règle générale, je recommande de concevoir le système à partir de zéro au lieu de commencer avec une architecture aussi complexe. Si vous commencez avec CockroachDB comme votre "source unique de vérité", jusqu'où pouvez-vous aller avec CockroachDB seul? Avez-vous des exigences de performance qui ne peuvent être satisfaites qu'avec une couche de mise en cache? Avez-vous besoin d'un système séparé pour l'agrégation/le reporting? Si la réponse est "oui", puis vous pouvez commencer à réfléchir à la forme que ces composants devraient prendre. Il peut y avoir une synchronisation basée sur les événements à partir de insert/update/delete dans le schéma normalisé cockroachdb pour insérer/mettre à jour/supprimer dans le schéma cassandra dénormalzied. Notez que CockroachDB ne dispose pas encore d'un bon moyen de diffuser des mises à jour dans un système externe, donc ce ne sera pas facile à faire.

Pour vos questions spécifiques:

1. Un cache de lecture peut être un ajout précieux à un système, mais il ajoute aussi beaucoup de complexité afin de ne pas introduire jusqu'à ce que vous savez que vous avez besoin. Vous pouvez également dénormaliser des éléments dans une base de données SQL, et des fonctionnalités telles que interleaved tables de CockroachDB peuvent réduire le besoin de dénormalisation.

2. Vous avez seulement des garanties transactionnelles pour les lectures qui vont à CockroachDB dans une transaction. Le comportement exact ici va dépendre de la façon dont votre transaction est écrite. Par exemple, deux transactions "Ajouter un commentaire" peuvent s'appliquer sans conflit entre elles, en fonction de votre schéma. Vous devrez peut-être vous prémunir contre cela en donnant des ID uniques appropriés ou en effectuant un SELECT au début de votre transaction pour vous assurer que l'état de la base de données est conforme à vos attentes. (De plus, ne faites pas trop de suppositions sur les "exceptions de verrouillage optimistes".) La concurrence de CockroachDB est un mélange de modèles optimistes et pessimistes)

3. Encore une fois, cela dépend. ElasticSearch peut faire beaucoup de choses que CockroachDB ne peut pas faire, et CockroachDB ne fait pas (encore) beaucoup de pré-agrégation. Mais SQL est un langage très flexible pour l'agrégation et la création de rapports. Vous pouvez donc faire ce dont vous avez besoin dans CockroachDB.