Passer des fichiers plats à SQLite

En décembre, janvier et février, j'ai publié une courte série de blogs sur les systèmes de fichiers plats. Cette série de blogs se concentre sur l'utilisation continue des fichiers plats et sur les raisons pour lesquelles ils ne sont plus viables à l'avenir.

La première partie était consacrée aux fichiers plats et aux raisons pour lesquelles les développeurs d'applications logicielles Embarqué les ont facilement adoptés. Dans la deuxième partie, j'ai expliqué pourquoi les développeurs d'Embarqué sont réticents à l'égard des bases de données. Dans la troisième partie, j'ai examiné les raisons pour lesquelles les développeurs s'accrochent aux systèmes de fichiers plats. La dernière partie a fourni une liste de contrôle pour les développeurs Embarqué qui migrent hors des fichiers plats.

Pour cette nouvelle série, j'aimerais porter mon attention sur la prochaine étape dans le parcours de nombreux développeurs Embarqué qui s'éloignent des fichiers plats, SQLite. Bien qu'il s'agisse d'un progrès, j'aimerais vous convaincre que vous devriez enjamber cette pierre ou sauter si vous êtes encore sur le point de le faire.

Peut-être devrions-nous commencer par expliquer pourquoi et comment il s'agit d'une étape positive par rapport aux fichiers plats. Pour cela, il faudrait bien sûr savoir où et comment il est appliqué aux exigences du monde réel. Selon les responsables de SQLite eux-mêmes, comme indiqué sur le site web de SQLite, Utilisations appropriées de SQLite: "SQLite n'est pas en concurrence avec les bases de données client/serveur. SQLite est en concurrence avec fopen()". Cette déclaration est liée à leur principe fondamental selon lequel ils ne sont pas destinés à être comparés aux moteurs de base de données SQL, car ces derniers sont destinés à être un dépôt partagé pour les données de l'entreprise. Pour être un dépôt partagé, selon le site de SQLite et donc la communauté, un moteur de base de données SQL a besoin d'évolutivité, de simultanéité, de centralisation et de contrôle. SQLite, quant à lui, se concentre sur le stockage de données locales pour des applications et des appareils individuels où l'administration de la base de données doit être nulle (il fournit ensuite la liste standard des appareils IoT typiques).

Les responsables de SQLite affirment également qu'il serait formidable, dans les environnements Embarqué , de disposer d'un format de fichier compact unique pour support transfert de données entre plates-formes, ainsi que des ensembles de données ad hoc, créés par les utilisateurs eux-mêmes, et composés de plusieurs types de données. En fait, SQLite a réalisé des analyses comparatives montrant qu'il est 35 % plus rapide que les systèmes de fichiers pour la lecture et l'écriture de ce type de données via fread() ou fwrite().¹.

Nous sommes d'accord avec l'essentiel de ce que disent les gens de SQLite : oui, les moteurs de base de données SQL doivent répondre aux exigences énumérées ci-dessus. Oui, il est nécessaire d'avoir une gestion des données locale gestion des données qui soit portable sur toutes les plateformes et qui puisse support plusieurs types de données ; et, enfin, il n'y a absolument aucun moyen d'éviter un environnement d'administration zéro à la périphérie pour les mobiles et l'IoT.

Cela étant dit, "U" sait ce qui va suivre, ce mot de trois lettres qui commence par un "B" et se termine par un "T" : Mais que se passerait-il si vous pouviez avoir le beurre et l'argent du beurre ? Et si vous pouviez obtenir toutes les fonctionnalités et tous les avantages des caractéristiques d'un datastore partagé d'entreprise à partir d'un moteur de base de données SQL, tout en ayant la possibilité de le réduire et de l'Embarquer directement dans une application mobile ou IoT locale, en prenant en charge plusieurs types de données, la portabilité sur plusieurs plateformes et en ne nécessitant aucune administration de la base de données ?

La réponse que vous devriez donner est oui. Toutefois, vous pouvez opposer les positions raisonnables suivantes :

Tout d'abord, SQLite et les systèmes de fichiers sont libres et populaires. Les moteurs de base de données SQL open source (MySQL, Postgres, MariaDB, etc.) ne sont pas en mesure de fonctionner à l'échelle de l'IoT ou de l'empreinte mobile. Je ne peux pas non plus les utiliser de Embarqué dans mes applications.

Deuxièmement, pourquoi les gens utilisent-ils une analogie aussi stupide que celle qui consiste à dire que l'on peut avoir le beurre et l'argent du beurre ? C'est plutôt comme si j'avais besoin d'une voiture, pas d'un camion, c'est exagéré, alors pourquoi s'en préoccuper ?

Eh bien, je vous répondrais que c'est tellement 2015 (d'ailleurs, c'est la dernière fois que SQLite a mis à jour sa page "utilisation appropriée"). Le fait est qu'en 2020 et certainement en 2025, vous aurez besoin de la fonctionnalité d'une voiture et d'un camion avec n'importe quelle application que vous créez de toute façon. Oui, vous devez stocker et analyser beaucoup plus de données localement, même avec la bande passante WiFi-6 et 5G. Cependant, l'augmentation pure et simple du volume de données et la nécessité de gérer les appareils de pair à pair et de périphérie à nuage, le partage des données contextuelles pour la gouvernance, les images opérationnelles communes et autres, dicteront tout ce qui est possible et devront toujours avoir lieu localement pour éviter les temps de latence.

En outre, de nombreuses opérations peer-to-peer et edge-to-cloud - sans parler des opérations de passerelle pour lesquelles les données proviennent de plusieurs sources en aval - nécessitent une simultanéité et un contrôle de ces sources de données en aval. Les passerelles et les datastores périphériques nécessiteront également de l'évolutivité afin de pouvoir utiliser la même architecture et la même portabilité des données sur toutes les plateformes. Enfin, au fur et à mesure que vous transférez vers cette passerelle des fonctionnalités qui se trouvaient auparavant dans le centre de données ou dans le nuage, ce qui était considéré comme une fonctionnalité de centralisation doit également être déplacé vers cette passerelle.

En d'autres termes, votre voiture a besoin de deux roues motrices dans la plupart des cas, mais elle a besoin de l'option de la transmission intégrale dans les autres cas. Votre voiture peut également avoir besoin d'une capacité de remorquage. Mais pensez aussi à l'inverse : votre camion ne remorque pas toujours un bateau ou n'est pas utilisé pour faire du tout-terrain, il transporte peut-être des passagers supplémentaires et vous souhaitez bénéficier de tout le confort d'une voiture de luxe.

Pour résumer, en ce qui concerne la gestion des données et cette analogie, la périphérie en 2020 et dans les cinq prochaines années nécessite tout ce qui était nécessaire dans le centre de données pour un magasin de données SQL (les exigences de votre camion). Mais aussi, tout ce qui était nécessaire pour la gestion des données un appareil local lorsqu'il était autonome (les exigences de votre voiture).

En substance, vous avez besoin d'un véhicule utilitaire sport qui puisse évoluer d'un tout petit CRV à un véhicule de taille monstrueuse. Malheureusement, ce n'est pas ce que SQLite est capable de faire, et invariablement, lorsque vous utilisez SQLite, vous êtes obligé de le boulonner à une autre base de données à l'autre bout. Nous discuterons des inconvénients de ce mariage forcé dans le prochain blog.

Si vous êtes prêt à reconsidérer SQLite, renseignez-vous sur Actian Zen. Vous pouvez également vous familiariser gratuitement avec Zen Core, qui est libre de droits pour le développement et la distribution.

À 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 abordons des sujets tels que l'ingestion de données en temps réel, l'analyse de données, la gouvernance données, la gestion des données, la qualité des données, l'intelligence des données et l'analyse pilotée par l'IA.