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 de jeux 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é incorporé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 certaine époque, les données étaient essentiellement transactionnelles ; les systèmes de traitement transactionnel en ligne (OLTP) et de planification des ressources d'entreprise (ERP) les traitaient en temps réel, et elles étaient fortement structurées. Au départ, les systèmes de gestion de bases de données relationnelles (SGBDR) répondaient aux besoins de ces systèmes et ont fini par évoluer vers des entrepôts de données, assurant le stockage et la gestion traitement analytique en ligne OLAP) pour l'analyse des données historiques de diverses entreprises, telles que Teradata, IBM, SAP et Oracle.
À mesure que la plupart des processus manuels reposant sur le papier ont cédé la place à la gestion numérique des documents, les systèmes de gestion de contenu se sont imposés comme un moyen de gérer l'ensemble des documents non structurés produits par les travailleurs du savoir ou générés par les fonctionnalités étendues des systèmes ERP et des ordinateurs personnels. Ces systèmes contiennent des données documentaires semi-structurées et non structurées stockées aux formats XML (eXtensible Markup Language) et JSON (JavaScript Object Notation).
Parallèlement, et plus encore ces dernières années avec la révolution de l'Internet des objets (IoT), la troisième vague de numérisation des données est en marche, opérant en périphérie au niveau des capteurs, des systèmes vidéo et d'autres appareils IoT. Ceux-ci 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 forme de séries chronologiques. Aucun de ces derniers jeux de données aux 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 jeu de données croissante jeu de données .
C'est ainsi que des bases de données de type « Document Store », telles que MongoDB et Couchbase, ainsi que plusieurs bases de données de séries chronologiques, notamment InfluxDB et une multitude de systèmes d'archivage sur mesure, ont vu le jour pour traiter ces jeux de données très distincts. Chacune dispose d'une interface de programmation d'application (API) distincte, regroupées sous l'appellation NoSQL, c'est-à-dire tout ce qui n'utilise pas 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.
D'une part, bon nombre d'entre elles reposent sur des architectures peu flexibles en termes de capacité à gérer les données JSON et les séries chronologiques, et leur extension pour gérer jeux de données plus volumineux jeux de données la complexité des analyses modernes, telles que l'intelligence artificielle (IA) et l'apprentissage automatique (ML), s'avère coûteuse. D'autre part, le fait de leur transmettre toutes les données vers un emplacement unique et centralisé sur site s'avérer coûteux et entraver prise de décision 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 gérer tous les jeux de données par le biais d'une API NoSQL unique, tout en assurant une conformité totale à SQL. Dans les fonctions SQL et NoSQL, les résultats de nos benchmarkstiers 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.
Restez connecté
Des informations exploitables à votre disposition.
(par exemple, sales@..., support)
