Validez un journal comme la base de données Kafka + avec les propriétés ACID?

Question

Je prévois dans l'essai comment faire ce genre d'architecture pour travailler:

http://www.confluent.io/blog/turning-the-database-inside-out-with-apache-samza/

Lorsque toutes les données sont stockées sous forme de faits dans un journal, mais les quand posté un validations changement doit être à une table . Par exemple, si j'envoie un "Créer une facture avec le client 1", je devrai valider si le client existe et d'autres choses, puis quand la validation passera dans le journal et mettra la modification en cours dans la table, ainsi la table aura le la plupart des informations à jour mais j'ai tout l'historique des changements.

Je pourrais mettre les journaux dans la base de données dans une table (j'utilise PostgreSQL). Cependant, je suis préoccupé par l'évolutivité de faire cela, aussi, je souhaite m'abonner au flux d'événements de plusieurs clients et PG ni d'autres SGBDR que je connais me permettent de le faire sans interrogation.

Mais si j'utilise Kafka, je m'inquiète de l'ACID entre les deux stockages, donc Kafka pourrait obtenir des données erronées que PG rollback ou quelque chose de similaire.

Alors:

1- Est-ce possible de maintenir la cohérence entre un SGBDR et un stockage journal OU 2- Est-ce possible en temps réel Abonnez-vous et réglez PG (ou autre SGBDR) pour le stockage d'événements rapide?

Answer 1

Facile (1) réponses aux questions fournies:

1. Configuration de votre transaction isolation level peut bien être suffisant pour assurer la cohérence et ne pas se soucier de DB rollbacks. Vous pouvez toujours créer des incohérences, sauf si vous définissez le niveau d'isolation sur "sérialisable". Même alors, vous êtes assuré d'être cohérent, mais pourrait toujours avoir des comportements indésirables. Par exemple, le client crée un client et met rapidement une facture en utilisant une API asynchrone, et l'événement de facture frappe d'abord votre système sauvegardé. Dans ce cas, l'événement de facture serait invalidé et un client devra réessayer en espérant que le client a été créé à ce moment-là. Facile à éviter si vous contrôlez des clients et leur demandez d'utiliser l'API de synchronisation.

2. La possibilité de stocker des événements dans une base de données relationnelle dépend de la taille de l'ensemble de données, du matériel et des modèles d'accès attendus. Je suis un grand fan de Postgres et il y a beaucoup de choses que vous pouvez faire pour que les recherches d'événements soient rapides. Ma règle d'or - si la taille de votre table d'opération est inférieure à 2300-300 Go et que vous disposez d'un serveur décent, Postgres est un excellent choix. Avec l'approvisionnement d'événements, il n'y a généralement pas de jointures et un modèle d'accès commun consiste à obtenir tous les événements par ID (éventuellement limité par l'horodatage). Postgres excelle dans ce type de requêtes, à condition d'indexer intelligemment. Cependant, les abonnés aux événements devront extraire ces données, ce qui peut ne pas être bon si vous avez des milliers d'abonnés, ce qui est rarement le cas en pratique.

réponse « correcte Conceptuellement »: Si vous voulez continuer à poursuivre l'approche de streaming et de résoudre fondamentalement les conditions de course, vous devez fournir des garanties de commande d'événements à travers tous les événements du système. Par exemple, vous devez être en mesure de commander un événement "ajouter un client 1" et un événement "créer une facture pour un client 1" afin de garantir la cohérence à tout moment. C'est un problème vraiment difficile à résoudre en général pour un système distribué (voir par exemple des horloges vectorielles). Vous pouvez l'atténuer avec quelques astuces qui fonctionneraient pour votre cas particulier, par ex. Dans l'exemple ci-dessus, vous pouvez partitionner vos événements par 'customerId' au début, car vous pouvez avoir la garantie que tous les événements liés au même client seront traités (grossièrement) dans l'ordre où ils ont été créés.

Serait heureux de clarifier mes points si nécessaire.

(1) Facile vs simple: mandatory link