Nous sommes ravis de partager qu'après avoir ajouté le SQL ANSI, les index secondaires, le schéma en étoile et les capacités d'affichage à la base de données opérationnelle de Cloudera, nous introduirons la prise en charge des transactions distribuées dans les mois à venir.
Qu'est-ce que l'ACIDE ?
Le modèle ACID de conception de base de données est l'un des concepts les plus importants dans les bases de données. ACID est synonyme d'atomicité, de cohérence, d'isolation et de durabilité. Pendant très longtemps, le strict respect de ces quatre propriétés a été nécessaire pour une base de données commercialement réussie. Cependant, ce modèle a créé des problèmes lorsqu'il s'agissait d'évoluer au-delà d'une base de données à un seul serveur. Pour tenir compte de cette limitation, les clients ont fait évoluer le matériel sur lequel les bases de données ont été déployées.
Les bases de données NoSQL ont assoupli une ou plusieurs de ces 4 propriétés pour obtenir des améliorations spectaculaires de l'évolutivité - Cloudera Operational Database (Powered by Apache HBase) était l'une de ces bases de données. Nous avons fait des compromis sur l'atomicité - en particulier, Cloudera a fourni l'atomicité sur une seule ligne. Pour compenser, nous avons pris en charge des tables très larges (avec potentiellement des millions de colonnes). Cela a permis aux clients de dénormaliser leurs schémas en étoile et de les représenter sous forme de lignes uniques afin d'effectuer des validations atomiques dans une seule ligne de ce qui était auparavant représenté sous forme de plusieurs tables.
Depuis la naissance de HBase, nous nous efforçons de créer des fonctionnalités qui réduisent l'écart de fonctionnalités avec les RDBM traditionnels tout en conservant les avantages de l'évolutivité, de la cohérence, de la durabilité et de l'isolation NoSQL.
Plus tôt cette année, nous avons pris en charge ANSI SQL, les index secondaires, le schéma en étoile et les vues en plus d'Apache HBase, apportant une interface et des fonctionnalités familières à tous les développeurs d'applications qui ont déjà créé une application utilisant MySQL ou PostGres.
Nous sommes maintenant sur le point de fournir la possibilité d'effectuer des validations atomiques sur des données qui traversent les lignes et les tables du cluster.
Qu'est-ce qu'une transaction atomique ?
Une transaction comprend un ensemble d'opérations dans une base de données qui sont gérées de manière atomique, de sorte que toutes les opérations doivent être entièrement terminées (validées) ou n'avoir aucun effet (abandonnées).
Actuellement, nous ne prenons en charge que les transactions atomiques à une seule ligne. Cela signifie que lorsque les développeurs cherchent à adopter la base de données opérationnelle de Cloudera, ils doivent penser différemment leur schéma.
Nous introduisons maintenant la possibilité d'avoir des transactions complexes qui s'étendent sur plusieurs lignes et tables, ce qui signifie que les développeurs peuvent implémenter un schéma en étoile traditionnel ou tirer parti de colonnes larges ou les deux en fonction de leurs besoins. Cette flexibilité, combinée à l'approche de schéma évolutif de Cloudera Operational Database, permet aux développeurs de tirer parti d'une base de données évolutive moderne tout en mettant à profit leurs compétences existantes.
Une chose importante à noter est que la prise en charge des transactions dans Cloudera Operational Database est « sans verrouillage » et fournit des garanties d'isolement d'instantané. Les bases de données traditionnelles implémentent un "verrou" sur toutes les données associées à une transaction afin que les autres clients accédant aux données ne les modifient pas avant qu'elles ne soient validées dans la base de données. Cependant, cela pourrait entraîner des conditions de concurrence qui se termineraient par des dépendances circulaires et se bloqueraient. Les verrous étaient également la cause de performances extrêmement médiocres de la part d'une application, car les applications s'attendaient les unes sur les autres pour pouvoir obtenir un verrou et continuer.
Notre approche permet à la première transaction qui se termine d'avancer et aux autres qui essayaient d'apporter des modifications au même ensemble de données devront réessayer. Cela évite tout ralentissement de l'ensemble de l'écosystème d'applications s'exécutant simultanément sur la base de données. En d'autres termes, notre approche permet une évolutivité linéaire tout en offrant l'atomicité que les bases de données transactionnelles traditionnelles sont capables de fournir.
Résultats des performances préliminaires
Notre fonctionnalité de prise en charge des transactions est actuellement en version bêta et est soumise à des tests de performances approfondis.
Les tests actuels incluent le benchmark TPC-C standard de l'industrie utilisant l'application OLTP Bench. Le benchmark TPC-C simule plusieurs achats effectués simultanément dans plusieurs entrepôts. Les schémas utilisés dans TPC-C sont représentés dans le diagramme entité-relation suivant :
Les nombres dans les blocs d'entités représentent la cardinalité des tables (nombre de lignes). Ces nombres sont factorisés par W, le nombre d'entrepôts, pour illustrer la mise à l'échelle de la base de données. Les nombres à côté des flèches de relation représentent la cardinalité des relations (le nombre moyen d'enfants par parent). Le symbole + représente le nombre de petites variations de la population de la base de données.
Un placement de commande nécessite que les 10 requêtes suivantes soient exécutées comme une seule transaction atomique :
1.SELECT c_discount, c_last, C_creditFROM customerWHERE c_w_id =? ET c_d_id =? ET c_id =? 2. SÉLECTIONNEZ w_taxFROM entrepôtWHERE w_id = ?3. SELECT d_next_o_id, D_taxFROM districtWHERE d_w_id =? ET d_id =?4. UPSERT INTO district (d_next_o_id, d_w_id, d_id)SELECT d_next_o_id + 1, d_w_id, D_idFROM districtWHERE d_w_id =? ET d_id =? 5. UPSERT INTO new_order (no_o_id, no_d_id, no_w_id)VALUES (?,?,?)6. Upsert en ordre (O_ID, O_D_ID, O_W_ID, O_C_ID, O_ENTRY_D, O_OL_CNT, O_ALL_LOCAL) VALEURS (? ,? ,? ,? 7. SELECT i_price, i_name, i_data FROM item WHERE i_id =? 8. Sélectionnez S_Quantity, S_DATA, S_DIST_01, S_DIST_02, S_DIST_03, S_DIST_04, S_DIST_05, S_DIST_06, S_DIST_07, S_DIST_08, S_DIST_09, S_DIST_10 From Stock Where S_I_ID =? ET s_w_id =? 9. Upsert in Stock (S_Quantity, S_YTD, S_Order_Cnt, S_Remote_Cnt, S_I_ID, S_W_ID) SELECT?, S_YTD +?, S_ORDE_CNT + 1, S_Remote_cnt +?, S_I_ID, S_W_IDFROM Stockwhere S_i_id =? ET s_w_id =?10. Insérer dans ORDER_LINE (OL_O_ID, OL_D_ID, OL_W_ID, OL_NUMBER, OL_I_ID, OL_SUPPLY_W_ID, OL_QUANTITY, OL_AMOUNT, OL_DIST_INFO) VALEURS (? ,? ,?,?,?,?Une transaction de paiement nécessite que les 6 requêtes suivantes soient exécutées comme une seule transaction atomique :
1. UPSERT INTO warehouse (w_ytd, w_id) SELECT w_ytd + w_id FROM warehouse WHERE w_id =? 2. SÉLECTIONNEZ w_street_1, w_street_2, w_city, w_state, w_zip, w_nameFROM warehouseWHERE w_id =?3. Upsert dans le district (d_ytd, d_w_id, d_id) sélectionnez d_ytd + ?, d_w_id, d_id dans le district où d_w_id =? ET d_id =? 4. SELECT d_street_1, d_street_2, d_city, d_state, d_zip, d_name DE district WHERE d_w_id = d_zip, d_name DE ET d_id =? 6. Upsert dans le client (c_balance, c_ytd_payment, c_payment_cnt, c_w_id, c_d_id, c_id) select? ,? ,?, c_w_id, c_d_id, c_idfrom client where c_w_id =? ET c_d_id =? ET c_id =? 7. Insérez dans l'histoire (H_C_D_ID, H_C_W_ID, H_C_ID, H_D_ID, H_W_ID, H_DATE, H_AMOUNT, H_DATA) VALEURS (?Avec 3 serveurs régionaux exécutés sur des nœuds Dell PowerEdge R440, nous avons pu obtenir les résultats suivants :
Dans ce graphique, l'axe Y représente le nombre de commandes pouvant être entièrement traitées (y compris la création de nouvelles commandes, le paiement, la livraison, etc.) par minute et est exprimé dans le benchmark tpm-C. L'axe X représente le nombre d'entités exécutant des transactions en parallèle.
Ces résultats préliminaires indiquent que le système atteint un débit de transactions de pointe quelque part entre 150 et 300 agents et des tests supplémentaires sont nécessaires pour identifier ce pic.
Au fur et à mesure que cette capacité mûrira, le débit d'OpDB et notre capacité à mesurer le débit s'amélioreront.
Conclusion
La plupart des applications tirent parti des transactions pour répondre à la myriade de besoins auxquels les entreprises sont confrontées. Cependant, lorsque les SGBDR traditionnels ne peuvent pas évoluer, les clients sont obligés de partitionner manuellement la base de données et de gérer chaque base de données partitionnée comme une base de données indépendante.
Lorsque cela devient trop lourd à gérer, les clients doivent envisager de migrer cette application vers la base de données opérationnelle de Cloudera. La prise en charge des transactions complexes combinée à la prise en charge ANSI SQL et à la nature évolutive d'Apache HBase offre une combinaison qui peut réduire considérablement la complexité opérationnelle de la gestion de la croissance.
Si vous en avez assez de gérer des bases de données partitionnées et que vous cherchez à réduire le TCO de la base de données, contactez votre équipe de compte Cloudera pour voir comment nous pouvons vous aider.
