L'architecture sans serveur de SQLite ne sert pas bien l'IdO

Troisième partie : SQLite, le "fichier plat" des bases de données

Au cours des derniers articles, notre série de blogs SQLite s'est penchée sur l'architecture SQLite Serverless et sur son inadaptation aux environnements IoT. Ceux d'entre vous qui ont suivi peuvent sauter à la section suivante, mais si vous êtes nouveau dans cette discussion, vous voudrez peut-être revoir les parties précédentes.

• Dans la première partie, mobile may be IoT, but IoT is not mobile when it comes to data, nous avons examiné le fait que, bien que SQLite soit la base de données la plus populaire de la planète - en grande partie grâce à son déploiement omniprésent sur les smartphones et les tablettes, où elle prend en charge les applications Embarqué pour un seul utilisateurne peut pas support exigences de multi-connexion, utilisateur, multi-application des cas d'utilisation de l'IoT qui prolifèrent avec une férocité virale dans chaque secteur d'activité. Dans un monde qui exige les performances des guépards et des faucons pèlerins, SQLite est une limace de banane.
• Dans la deuxième partie, Repenser ce que signifie le client-serveur pour la gestion des données en périphérie, nous avons examiné les principales fonctions et caractéristiques de l'architecture sans serveur SQLite (portabilité, peu ou pas de configuration, faible encombrement, API SQL, et une version initialement gratuite pour amorcer l'adoption) à la lumière des besoins de la gestion des données moderne gestion des données en périphérie et nous avons discuté des lacunes de l'architecture SQLite en termes de capacité d'intégration avec les fonctions critiques des bases de données client-serveur traditionnelles (principalement les qualificatifs multi-points ci-dessus).

Dans notre analyse finale de cette architecture sans serveur, j'aimerais beaucoup explorer (lire : clarifier) ce qui se passera si un développeur ignore ces mises en garde et s'appuie sur SQLite pour gérer les cas d'utilisation de l'IdO.

Ne confondez pas la multi-connexion et le multi-threading avec le client-serveur.

À la fin des années 90, les applications devenaient de plus en plus sophistiquées, généraient et ingéraient davantage de données et effectuaient des opérations plus complexes sur ces données en interne. Par conséquent, les développeurs d'applications ont dû développer de nombreuses solutions de contournement pour faire face aux limites des services de gestion de fichiers habituels, basés sur le système d'exploitation. Plutôt que de consacrer du temps à tous ces efforts de bricolage, les développeurs d'applications réclamaient une base de données dédiée qu'ils pourraient Embarquer dans une application pour support leurs besoins spécifiques en matière de gestion des données .

Au tournant du^21e siècle, SQLite est apparu et semblait taillé sur mesure pour répondre à ces besoins. SQLite permettait l'indexation, l'interrogation et d'autres fonctionnalités de gestion des données par le biais d'une série d'appels SQL standard qui pouvaient être insérés dans le code de l'application, l'ensemble de la base de données étant regroupé dans un ensemble de bibliothèques qui faisaient partie de l'exécutable final déployé. Il ne faut pas oublier que la majorité de ces applications étaient des applications monolithiques, à but unique et à utilisateur unique, conçues pour les architectures de processeur plus simples utilisées à l'époque. Elles n'étaient pas conçues pour exécuter des processus multiples, et encore moins des threads multiples. L'utilisateur utilisateur et la sécurité des données n'étaient pas encore des priorités aussi importantes qu'aujourd'hui. Et pour ce qui est des performances dans un environnement en réseau ? Les réseaux sans fil étaient au mieux réactifs et ponctuels. Les connexions de données multiples, externes et à large bande passante étaient rares.

Il n'est donc pas surprenant que SQLite n'ait pas été en mesure de répondre aux demandes simultanées de lecture et d'écriture pour une seule connexion (et encore moins pour des connexions multiples) lors de sa conception. Les concepteurs étaient ravis de disposer d'une base de données intégrable permettant à plusieurs processus d'avoir un accès séquentiel en lecture et en écriture à une table de données au sein d'une application. Ils ne recherchaient pas des capacités client-serveur de niveau entreprise. Ils ne concevaient pas de systèmes de base de données autonomes capables de support plusieurs applications simultanément. Ils avaient simplement besoin de plus qu'un accès à un fichier plat géré par un système d'exploitation.

Et c'est là que réside le cœur du problème avec SQLite. Il n'a jamais été conçu pour gérer plusieurs applications externes ou leurs connexions de manière asynchrone, comme le ferait une base de données client-serveur traditionnelle. Les applications modernes en réseau ont souvent plusieurs processus et/ou plusieurs fils d'exécution. Lorsque vous lancez SQLite dans une situation avec de multiples connexions et le potentiel de multiples requêtes simultanées de lecture et d'écriture, vous rencontrez rapidement la possibilité de conditions de course et de corruption de données.

Pour être juste, SQLite a essayé de répondre à ces demandes en constante évolution. La version actuelle de SQLite gère les connexions multiples grâce à ses options de mode thread : single-thread, multi-thread et serialized. Single-thread est le mode de traitement original de SQLite, gérant une transaction à la fois, qu'il s'agisse d'une lecture ou d'une écriture à partir d'une seule et unique connexion. Le mode multithread support plusieurs connexions, mais toujours une seule à la fois pour la lecture ou l'écriture. Sérialisé - le mode par défaut des versions les plus récentes de SQLite - peut support plusieurs connexions simultanées (et, par conséquent, peut support une application multithread ou multiprocessus), mais il ne peut pas les gérer toutes simultanément. SQLite peut gérer des connexions en lecture simultanée dans les modes multithread et sérialisé, mais il verrouille les tables de données pour empêcher les tentatives d'écriture simultanée. SQLite ne peut pas non plus gérer l'orchestration des écritures à partir de plusieurs connexions.

Comparez cela à l'architecture d'une véritable base de données client-serveur conçue pour gérer des écritures simultanées. La base de données client-serveur évalue chaque demande de service d'écriture et, si des tentatives sont faites pour écrire sur les mêmes données d'une table, elle bloque la demande jusqu'à ce que l'opération en cours sur ces données soit terminée. Si les tentatives portent sur des parties différentes de la table de données, le serveur les autorise à continuer. Il s 'agit là d'une véritable orchestration. Verrouiller l'ensemble de la table et bloquer les écritures (ou faire semblant que des écritures séquentielles se produisent en même temps que des lectures multiples avec WAL) n'est pas la même chose.

Pourquoi est-ce un obstacle pour SQLite dans un environnement IoT ? L'une des opérations les plus élémentaires avec les appareils et les passerelles IoT consiste à écrire des données provenant de divers appareils dans votre dépôt données, et les verrous d'écriture imposés lors des opérations multithreads/multi-connexions rendent cette opération non viable dans un environnement de production. En outre, une deuxième opération de base se déroulant dans un environnement IoT implique l'exécution de traitements de données et d'analyses sur des ensembles de données collectés précédemment. Bien qu'il puisse s'agir d'opérations à forte intensité de lecture exécutées indépendamment (en tant que processus séparés ou threads séparés) des opérations à forte intensité d'écriture décrites ci-dessus, elles ne peuvent pas se dérouler simultanément dans un environnement SQLite et maintenir la conformité ACID.

Au fur et à mesure que vos déploiements s'étendent ou que la complexité du système augmente - disons que vous voulez instrumenter de plus en plus dans un environnement, qu'il s'agisse d'une voiture autonome ou d'un bâtiment intelligent - vous ajouterez invariablement plus de points de connexion de données en aval ou à l'intérieur de votre environnement local. Chacune de ces entités aura une ou plusieurs connexions de base de données supplémentaires, si ce n'est sa propre base de données qui nécessite une connexion. Vous pouvez essayer d' établir ces connexions, mais elles devront être gérées par une logique d'application supplémentaire qui entraînera probablement des temps de réponse en dehors des contraintes de conception de votre système IoT.

Des solutions de contournement conçues pour nier (ou défier) la réalité

Les partisans de SQLite agiteront les mains avec une nonchalance dédaigneuse et vous diront que SQLite est suffisamment rapide (ce n'est pas le cas ; nous avons déjà discuté de la lenteur de SQLite) et que vous pouvez construire votre propre fonctionnalité pour gérer les lectures et écritures simultanées sur plusieurs connexions - en fait, en les synchronisant manuellement en fonction du cas d'usage traité. L'une des méthodes utilisées pour gérer ce scénario consiste à utiliser le mode sérialisé mentionné ci-dessus et à créer des fonctionnalités pour gérer la synchronisation et l'orchestration au sein des threads de l'application. Cette approche permet d'éviter la transmission de demandes de lecture et d'écriture sur plusieurs canaux (évitant ainsi les conditions de course et le risque de corruption des données). Cependant, cette approche requiert également un haut degré de compétence, la prise en charge de la responsabilité à long terme du code et la nécessité d'effectuer des tests et des validations approfondis pour s'assurer que les opérations se déroulent correctement.

Une autre approche consisterait à construire l'équivalent d'un front-end d'orchestration client-serveur et à utiliser l'option de thread unique dans SQLite, ce qui exclurait les conditions de course ou la corruption des données. Mais revenir à l'option "single-thread" reviendrait à regarder cette limace de banane se déplacer encore plus lentement. Cette approche n'est pas viable, compte tenu des opérations d'écriture parallèles à grande vitesse nécessaires pour prendre en charge plusieurs flux de données à haute résolution ou des grilles de capteurs à grande échelle. En outre, tout ce que vous avez fait, c'est pallier les faiblesses de l'architecture de la base de données en forçant l'application à faire quelque chose que la base de données devrait faire. Et vous devrez faire cela encore et encore, pour chaque application de votre portefeuille IoT.

Il existe plusieurs ensembles de codes et quelques petites entreprises qui ont essayé de produire cette dernière approche, mais avec un succès limité. Ils ne fonctionnent qu'avec certaines plateformes de développement sur quelques-unes des plateformes supportées par SQLite. Même si ces plateformes correspondent à votre cas d'usage, les problèmes de performance peuvent encore augmenter le risque et la difficulté de coder cette solution de contournement dans votre application.

Nous avons déjà vu cet iceberg

Cette mise en garde ne concerne pas seulement la quantité de bricolage qui sera encourue si l'on s'appuie indiscutablement sur SQLite pour une application donnée. À l'instar de l'IdO lui-même, il s'agit d'une question beaucoup plus vaste. Par exemple, si vous vous engagez à gérer cela dans votre propre code, comment gérerez-vous le mouvement des données d'un appareil vers le sur site l'IoT ? Comment allez-vous gérer le déplacement des données vers ou depuis le nuage ? Les exigences en matière d'interaction avec les serveurs sur les deux niveaux peuvent être différentes, ce qui vous oblige à écrire davantage de code pour effectuer des transformations de données (vous vous souvenez du blog sur SQLite et l'ETL?). Vous pourriez essayer d'éviter le goulot d'étranglement de l'ETL en utilisant SQLite aux deux extrémités, mais cela ne ferait que jeter un pavé dans la mare. Vous devrez toujours écrire du code pour gérer SQLite qui se fait passer pour une base de données basée sur un serveur sur la passerelle et dans le nuage.

En fin de compte, vous ne pouvez pas échapper à la nécessité d'écrire plus de code pour faire fonctionner SQLite dans n'importe lequel de ces scénarios. Et ce n'est que la partie émergée de l'iceberg. Vous devrez faire des comparaisons entre le bricolage et le bricolage partiel, plus des modules de code/librairies pour d'autres fonctionnalités - du cryptage des données et de la gestion des clés publiques à l'édition des requête SQL, et plus encore. La liste des fonctionnalités qu'une véritable infrastructure client-serveur apporte à la table - toutes absentes de SQLite - n'en finit pas.

À l'époque, SQLite permettait aux développeurs d'éviter une grande partie du bricolage qu'exigeait la gestion des fichiers plats. Pour les cas d'utilisation qui émergeaient à l'époque, c'était une solution idéale. Pour les cas d'utilisation d'aujourd'hui, cependant, il faudrait encore plus de bricolage pour que SQLite fonctionne - et même dans ce cas, il ne fonctionnerait pas si bien que cela. La grande majorité des cas d'utilisation de l'IdO nécessitent un niveau de fonctionnalité client-serveur que SQLite ne peut pas fournir sans entraîner des coûts importants en termes de performances, de temps de développement et de risques. En bref, c'est du déjà vu, mais SQLite est désormais le fichier plat dont nous devons laisser les défauts dans le passé.

Et si vous pensez que tout cela ne concerne que les développeurs, détrompez-vous. Dans le prochain et dernier blog de cette série, nous élargirons un peu l'objectif et examinerons ce que cela signifie pour l'entreprise et le résultat net.

Si vous êtes prêt à reconsidérer SQLite et à en apprendre davantage sur Actian Zen, vous pouvez 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 couvrons des sujets allant de l'ingestion de données en temps réel à l'analyse pilotée par l'IA. Faites connaissance avec l'équipe dirigeante https://www.actian.com/company/leadership-team/