Faut-il avoir des bases de données SQL NoSQL séparées pour les documents, les séries temporelles ?

La gestion et l'analyse de données hétérogènes constituent un défi pour la plupart des entreprises, que la vague imminente d'ensembles de données générés par l'informatique de pointe n'a fait qu'exacerber. Ce défi découle d'un "décalage entre les types de données" assez important, ainsi que de la manière dont les données ont été intégrées dans les applications et les processus d'entreprise, et de l'endroit où elles l'ont été. Comment en sommes-nous arrivés là ?

À une époque, les données étaient essentiellement transactionnelles et les systèmes de traitement transactionnel en ligne(OLTP) et de planification des ressources de l'entreprise (ERP) les traitaient en ligne, et elles étaient fortement structurées. Les systèmes de gestion de bases de données relationnellesSGBDR) géraient principalement les besoins de ces systèmes et ont finalement évolué vers des entrepôts de données, stockant et administrant le traitement analytique en ligne (OLAP) pour l'analyse des données historiques de diverses sociétés, telles que Teradata, IBM, SAP et Oracle.

Lorsque la plupart des processus manuels utilisant le papier sont passés à la gestion des documents numériques, les systèmes de gestion de contenu sont apparus comme un moyen de gérer tous les documents non structurés provenant des travailleurs du savoir ou générés automatiquement par les fonctionnalités étendues des systèmes ERP et des systèmes informatiques personnels. Ces systèmes contiennent des données documentaires semi-structurées et non structurées stockées dans des formats XML (eXtensible Markup Language) et JSON (JavaScript Object Notation).

Parallèlement, et plus encore au cours des dernières années avec la révolution de l'internet des objets (IdO), la troisième vague de numérisation des données est à nos portes, opérant à la périphérie dans les capteurs, la vidéo et d'autres dispositifs IdO. Ils génèrent toute la gamme des données structurées et non structurées, mais les deux tiers d'entre elles se présentent sous la forme de séries chronologiques. Aucun de ces derniers ensembles de données ne se prête aux systèmes SGBDR qui sous-tendent les entrepôts de données en raison de la manière dont les données sont traitées et analysées, des formats de données utilisés et de la taille croissante des jeu de données .

Par conséquent, des bases de données de stockage de documents distinctes, telles que MongoDB et Couchbase, ainsi que plusieurs bases de données de séries temporelles, dont InfluxDB et une multitude d'historiens sur mesure, ont vu le jour pour gérer ces ensembles de données très distincts. Chacune dispose d'une interface de programmation d'application (API) distincte, regroupée sous l'appellation NoSQL, c'est-à-dire tout ce qui n'est pas du langage de requête structuré (SQL).

Ces trois vagues de types de données et de structures de base de données ont eu pour conséquence que les architectes de données doivent maintenant mettre en œuvre des bases de données distinctes pour chaque type de données et de cas d'usage ou essayer de fusionner et d'agréger tous les différents types de données dans une seule base de données. Jusqu'à récemment, le seul point d'agrégation significatif ou à l'échelle de l'entreprise pour plusieurs bases de données et types de données était l'entrepôt de données traditionnel. L'entrepôt de données traditionnel est toutefois à la traîne en tant que point d'agrégation, et ce pour deux raisons.

Premièrement, nombre d'entre eux sont basés sur des architectures peu flexibles en termes de capacité à gérer des données JSON et des séries temporelles et de coût d'extension pour gérer des ensembles de données plus importants ou la complexité des analyses modernes, telles que l'intelligence artificielle (IA) et l'apprentissage automatique (ML). Deuxièmement, leur envoyer toutes les données en un seul endroit centralisé sur site peut être coûteux et entraver la prise de décision au point d'action à la périphérie du réseau.

À l'ère de l'informatique en périphérie et du basculement complet de la majorité des données créées et émanant de la périphérie plutôt que du centre de données ou d'une image virtualisée dans le nuage, les applications et plateformes spécialisées ont un rôle essentiel à jouer dans la mise en œuvre des processus d'entreprise. Tout comme chaque processus d'entreprise est unique, les exigences en matière de données pour que la technologie support ces processus sont également uniques. Bien qu'il puisse sembler que la meilleure technologie de base de données pour le stockage de documents, les séries chronologiques ou les données transactionnelles traditionnelles entièrement structurées puisse éliminer les contraintes liées à l'utilisation de la technologie au sein d'une entreprise, il convient d'être très prudent avant de s'engager dans cette voie.

En général, plus il y a d'API, d'architectures de bases de données sous-jacentes, de différences dans les formats de fichiers de support, de systèmes de gestion et de surveillance et de changements dans ceux que vous utilisez en fonction du cas d'usage , plus les architectures de données de votre entreprise sont complexes. C'est particulièrement le cas si vous proposez ou mettez en œuvre plusieurs produits, technologies et méthodologies d'intégration avec ce pot-pourri de bases de données. Cette complexité a tendance à avoir un effet domino sur le cycle de vie de votre support pour tout logiciel exploitant ces bases de données - et même sur l'acquisition des bases de données.

Pour autant que vous puissiez trouver une base de données unique offrant des performances similaires et prenant en charge tous les types de données et SQL, ainsi que la manipulation directe des données via une API NoSQL, il est bien plus judicieux de fusionner et d'agréger des données hétérogènes dans une structure de base de données commune, en particulier dans les cas d'utilisation de l'Edge Computing. Par exemple, si vous examinez des données de vidéosurveillance, des réseaux de capteurs et des journaux pour la sécurité, les combinaisons de ces ensembles de données et d'autres ensembles de données disparates doivent être agrégés pour des analyses interfonctionnelles.

Si vous devez analyser, créer des rapports et des tableaux de bord basés sur des données de différents types et dans différents systèmes sources, vous aurez besoin d'une certaine capacité de normalisation des données, de sorte qu'elles puissent être interrogées sur place ou à distance à partir d'un seul ensemble de données.

Les exigences ont évolué au cours des 30 dernières années et Actian a construit une nouvelle base de données modulaire spécialement conçue pour les technologies et les cas d'utilisation edge-computing et capable de traiter tous les ensembles de données via une API NoSQL unique, tout en offrant une conformité SQL complète. Dans les fonctions SQL et NoSQL, les résultats de notre benchmark^tiers montrent des performances bien supérieures à celles des principaux magasins de documents, des séries chronologiques ou des bases de données SQL traditionnelles capables de gérer les mobiles et l'IoT.

À propos d'Actian Corporation

Actian facilite l'accès aux données. Notre plateforme de données simplifie la façon dont les gens connectent, gèrent et analysent les données dans les environnements cloud, hybrides et sur site . Avec des décennies d'expérience dans la gestion des données et l'analyse, Actian fournit des solutions de de haute performance qui permettent aux entreprises de prendre des décisions basées sur les données. Actian est reconnu par les principaux analystes et a reçu des prix de l'industrie pour sa performance et son innovation. Nos équipes partagent des cas d'utilisation éprouvés lors de conférences (par exemple, Strata Data) et contribuent à des projets à code source ouvert. Sur le blog d'Actian, nous couvrons des sujets allant de l'ingestion de données en temps réel à l'analyse pilotée par l'IA.