Ceci est le quatrième article d’une série du CTO de Rockset Dhruba Borthakur sur Concevoir la prochaine génération de systèmes de données pour l’analyse en temps réel. Nous publierons plus d’articles dans la série dans un proche avenir, donc abonnez-vous à notre weblog pour ne pas les rater !
Messages publiés jusqu’à présent dans la série :
- Pourquoi la mutabilité est essentielle pour l’analyse de données en temps réel
- Gestion des données dans le désordre dans les purposes d’analyse en temps réel
- Gestion du trafic en rafale dans les purposes d’analyse en temps réel
- SQL et des requêtes complexes sont nécessaires pour l’analyse en temps réel
- Pourquoi l’analyse en temps réel nécessite à la fois la flexibilité de NoSQL et les schémas stricts des systèmes SQL
Les entreprises d’aujourd’hui axées sur les données doivent non seulement des réponses rapides dérivées des données les plus récentesmais ils doivent également effectuer des requêtes complexes pour résoudre des problèmes métier compliqués.
Par exemple, les systèmes de personnalisation des purchasers doivent combiner des ensembles de données historiques avec des flux de données en temps réel pour fournir instantanément les recommandations de produits les plus pertinentes aux purchasers. Il en va de même pour les systèmes d’analyse opérationnelle fournissant une observabilité commerciale en temps réel critique, comme dans le cas d’un fournisseur de paiements en ligne qui doit surveiller ses transactions dans le monde entier pour détecter les anomalies qui pourraient signaler une fraude financière.
Ou imaginez un plateforme d’apprentissage en ligne qui doit fournir des informations actualisées sur l’utilisation des étudiants et des enseignants pour les purchasers du district scolaire et les équipes internes en contact avec les purchasers. Ou un fournisseur d’informations sur le marché qui doit surveiller et s’assurer que ses purchasers financiers reçoivent des mises à jour précises et pertinentes dans les fenêtres étroites pour des transactions rentables.
Limites de NoSQL
SQL prend en cost les requêtes complexes automotive il s’agit d’un langage très expressif, mature langue. Les requêtes SQL complexes sont depuis longtemps monnaie courante dans l’informatique décisionnelle (BI). Et lorsque des systèmes tels que Hadoop et Hive sont arrivés, ils ont pour la première fois associé des requêtes complexes à des mégadonnées. Hive a implémenté une couche SQL sur le paradigme de programmation MapReduce natif de Hadoop. Le compromis de ces systèmes de Huge Knowledge basés sur SQL de première génération était qu’ils augmentaient le débit de traitement des données au détriment d’une latence de requête plus élevée. En conséquence, les cas d’utilisation sont restés fermement en mode batch.
Cela a changé lorsque les bases de données NoSQL telles que les magasins de clé-valeur et de paperwork sont apparues. L’objectif de conception était une latence et une échelle faibles. Désormais, les entreprises peuvent prendre un ensemble de données massif, l’organiser en simples paires de valeurs clés ou de paperwork et effectuer instantanément des recherches et d’autres requêtes simples. Les concepteurs de ces magasins de valeurs-clés ou bases de données de paperwork massifs et évolutifs ont décidé que l’échelle et la vitesse n’étaient possibles que si les requêtes étaient simples par nature. La recherche d’une valeur dans un magasin de valeurs-clés peut être rendue très rapide. En revanche, une requête SQL, en raison de la complexité inhérente des filtres, des tris et des agrégations, serait techniquement trop difficile à exécuter rapidement sur de grandes quantités de données, ont-ils décidé.
Ne faites pas consideration à cet homme derrière le rideau
Malheureusement, en raison de ce qui précède, les bases de données NoSQL ont tendance à rencontrer des problèmes lorsque les requêtes sont complexes, imbriquées et doivent renvoyer des réponses précises. Ce n’est volontairement pas leur fort. Leurs langages de requête, qu’il s’agisse de variantes de kind SQL telles que CQL (Cassandre) et Druid SQL ou des langages entièrement personnalisés tels que MQL (MongoDB), supportent mal les jointures et autres commandes de requête complexes qui sont normal pour SQL, s’ils les soutiennent du tout.
Les fournisseurs de bases de données NoSQL sont comme le magicien d’Oz, vous distrayant avec de la fumée et des miroirs et parlant de définitions étroites de la vitesse afin que vous ne remarquiez pas les faiblesses réelles des bases de données NoSQL en matière d’analyse en temps réel. Les développeurs travaillant avec des bases de données NoSQL finissent par être obligés d’intégrer des jointures et d’autres logiques de données dans leur propre code d’software, de la récupération de données à partir de tables séparées à l’optimisation des jointures et à d’autres tâches analytiques.
S’il est potential d’emprunter la voie NoSQL, c’est lourd et lent. Prenez un particulier qui demande un prêt hypothécaire. Pour analyser leur solvabilité, vous créeriez un demande de données qui analyse des données, telles que les antécédents de crédit de la personne, les prêts en cours et l’historique de remboursement. Pour ce faire, vous auriez besoin de combiner plusieurs tables de données, dont certaines pourraient être normalisé, dont certains ne le sont pas. Vous pouvez également analyser les taux hypothécaires actuels et historiques pour déterminer le taux à offrir.
Avec SQL, vous pouvez simplement joindre des tables d’historiques de crédit et de remboursements de prêts et agréger des ensembles de données historiques à grande échelle, tels que les taux hypothécaires quotidiens. Cependant, utiliser quelque selected comme Python ou Java pour recréer manuellement les jointures et les agrégations multiplierait les lignes de code dans votre software par des dizaines voire une centaine par rapport à SQL.
Plus de code d’software prend non seulement plus de temps à créer, mais cela entraîne presque toujours des requêtes plus lentes. Sans accès à un optimiseur de requêtes basé sur SQL, l’accélération des requêtes est difficile et prend du temps automotive il n’y a pas de démarcation entre la logique métier de l’software et les chemins d’accès aux données basés sur les requêtes utilisés par l’software. Quelque selected d’aussi commun qu’un desk de jointure intermédiaireque SQL peut gérer efficacement et élégamment, peut devenir un gros consommateur de mémoire dans d’autres langages.
Enfin, une requête écrite en code applicatif est également plus fragile, nécessitant une upkeep et des assessments constants, et d’éventuelles réécritures si les volumes de données changent. Et la plupart des développeurs manquent de temps et d’experience pour effectuer cette upkeep constante.
Il n’y a qu’un seul système NoSQL que je considérerais raisonnablement compétent pour les requêtes complexes : GraphQL. Les systèmes GraphQL peuvent associer des varieties de données à des champs de données spécifiques et fournir des fonctions pour récupérer des champs sélectionnés d’un doc. Son API de requête prend en cost des opérations complexes, telles que le filtrage de paperwork en fonction d’un ensemble de champs correspondants et le renvoi sélectif d’un sous-ensemble de champs à partir de paperwork correspondants. Le principal défaut d’analyse de GraphQL est son manque de pouvoir expressif pour joindre deux ensembles de données disparates en fonction de la valeur de champs spécifiques dans ces deux ensembles de données. La plupart des requêtes analytiques ont besoin de cette capacité pour joindre plusieurs sources de données au second de la requête.
Choisir le meilleur outil pour le travail – SQL
Dans la technologie comme dans la vie, chaque travail a un outil qui est le mieux conçu pour lui. Pour les requêtes analytiques complexes, SQL est incontestablement le meilleur outil. SQL dispose d’un riche ensemble de commandes puissantes développées au cours d’un demi-siècle. Il est facile de créer des requêtes, et encore plus facile de les régler et de les optimiser afin d’accélérer les résultats, de réduire les tables intermédiaires et de réduire les coûts des requêtes.
Il y a quelques mythes sur les bases de données SQL, mais ils sont basés sur des systèmes relationnels hérités des années 1990. La vérité est que les bases de données SQL natives du cloud modernes prennent en cost toutes les fonctionnalités clés nécessaires à l’analyse en temps réely compris:
- Données modifiables pour une ingestion de données incroyablement rapide et une gestion fluide des événements tardifs.
- Des schémas flexibles qui peuvent s’ajuster automatiquement en fonction de la construction des données de streaming entrantes.
- Mise à l’échelle instantanée des écritures de données ou des requêtes pour gérer des rafales de données.
SQL reste incroyablement populaire, se classant parmi les langages de programmation les plus demandés. Comme nous l’avons vu, il prend en cost les requêtes complexes, qui sont une exigence pour l’analyse de données moderne en temps réel. En revanche, les bases de données NoSQL sont faibles pour exécuter des jointures et d’autres commandes de requête complexes. De plus, trouver un professional dans un langage de requête personnalisé moins connu peut prendre du temps et coûter cher.
L’essentiel est que vous n’aurez aucun problème à trouver des ingénieurs de données et des opérateurs de données qualifiés qui connaissent SQL et ses capacités avec des requêtes complexes. Et ils seront en mesure de mettre ces connaissances et cette puissance à revenue, propulsant le saut de votre organisation de l’analyse par heaps à l’analyse en temps réel.
Dhruba Borthakur est CTO et co-fondateur de Rockset et est responsable de la route approach de l’entreprise. Il était ingénieur au sein de l’équipe de base de données de Fb, où il était l’ingénieur fondateur du RochesDB magasin de données. Auparavant chez Yahoo, il a été l’un des ingénieurs fondateurs du Système de fichiers distribué Hadoop. Il a également contribué à l’open supply Apache HBase projet.
Fusée est le chief analyse en temps réel plate-forme conçue pour le cloud, fournissant des analyses rapides sur des données en temps réel avec une efficacité surprenante. En savoir plus sur rockset.com.
