SQLite : Pas plus rapide, pas meilleur, mais moins cher ?

Comprendre le coût total de possession (TCO) de SQLite

Au cours des trois derniers mois, cette série de blogs a exploré les raisons pour lesquelles les développeurs se sont tournés vers SQLite pour Embarqué gestion des données. Certains développeurs ont choisi SQLite parce que des membres de l'équipe élargie connaissaient le langage SQL et voulaient tirer parti de ces connaissances pour support gestion des données ou l'extraction de données pour la visualisation et la création de rapports. La plupart des développeurs l'ont cependant adopté pour surmonter les limites des systèmes de gestion de fichiers plats existants.

Avec le recul, tout cela se justifie. L'adoption de nouveaux produits et de nouvelles technologies dépend très souvent de la réponse à une question simple : ce remplacement constitue-t-il une amélioration par rapport à ce que j'ai maintenant ? De manière encore plus catégorique, la nouvelle chose est-elle plus rapide, meilleure ou moins chère ? Un remplacement idéal serait plus rapide, meilleur et moins cher, mais c'est un triplé qui nous échappe généralement. Il est cependant rare qu'un changement soit proposé sans qu'au moins l'une de ces caractéristiques soit présente. Qu'est-ce qui a motivé l'adoption de SQLite ? Était-il plus rapide, meilleur ou moins cher que les autres solutions disponibles ? Et si c 'était l' une ou l'autre de ces caractéristiques, est-il toujours plus rapide, meilleur ou moins cher que les bases de données alternatives disponibles aujourd'hui ?

Plus vite ?

Autrefois, oui, SQLite était plus rapide que les opérations impliquant un fichier plat. Aujourd'hui ? Pas vraiment.

SQLite est positivement léthargique sur plusieurs fronts. Dans une comparaison directe entre SQLite et Actian Zen Core, l'accès aux données via SQL peut être comparable, mais l'accès aux mêmes données en utilisant l'API NoSQL d'Actian Zen offre une amélioration des performances d'un ordre de grandeur par rapport à SQLite. Ou encore, considérez la vitesse en termes de types d'interactions client-serveur optimisées exigées par les applications dans le domaine de la gestion des données moderne gestion des données. Les interactions client-serveur dans les scénarios IoT et mobiles dépendent de la collecte de données de de haute performance et du traitement en ligne des transactions, à partir de multiples canaux externes. Mais comme SQLite fonctionne exclusivement en mode sans serveur, les données doivent être transformées (le "T" de ETL) avant de pouvoir être transférées vers ou depuis n'importe quel compagnon basé sur un serveur, tel que Microsoft SQL Server. Cette étape entraîne non seulement une baisse mesurable des performances, mais elle crée également un point d'étranglement potentiel qui peut limiter l'évolutivité l'application. Si l'on ajoute à cela la nécessité de crypter et de décrypter les données dans le cadre de cette transformation client-serveur - et se pose-t-on vraiment la question de savoir si le cryptage sera nécessaire dans tout scénario moderne de gestion des données - on peut voir le compteur de vitesse du tableau de bord SQLite reculer encore un peu plus vers zéro.

SQLite était un démon de la vitesse à l'époque, mais l'architecture Intel 80×86 l'était aussi. Est-il besoin d'en dire plus ?

Mieux ?

Eh bien, à moins que vous n'interagissiez encore exclusivement avec le système de fichiers sous-jacent, la réponse est un autre "non" facile. Nous avons examiné en détail les limites de l'architecture sans serveur SQLite dans les articles 5, 6 et 7 de cette série. Bien que l'architecture ait constitué une percée à l'époque, elle l'était aussi pour son temps. Elle répondait au besoin émergent d'un simple cache de données pour les applications mobiles et web. Mais ce n'est pas le cas aujourd'hui. Les scénarios mobiles et IoT d'aujourd'hui nécessitent une architecture conçue pour des applications à grande vitesse, multicanal, multiprocessus et multithread. Si certaines des premières applications IoT ont été conçues en partant du principe que la grande majorité des données seraient envoyées dans le nuage pour y être traitées et analysées - un scénario dans lequel SQLite semblait viable en tant que cache de données local - il est devenu évident que l'hypothèse sous-jacente était elle-même erronée. Avec l'émergence d'une topologie moderne de gestion des données en périphérie dans laquelle l'analyse et le traitement des transactions peuvent avoir lieu en périphérie plutôt que dans le nuage, une architecture client-serveur optimisée conçue pour des performances rationalisées tout au long du continuum de l'appareil à la périphérie au nuage/centre de données redéfinit le concept de " mieux ".

Comme pour faster, SQLite était autrefois meilleur que d'autres alternatives de bases de données lorsqu'il s'agissait d'applications mobiles à utilisateur utilisateur et de mise en cache de données locales. Mais les architectures sans serveur ne sont pas conçues pour répondre aux tâches de notre époque. Nous vivons dans un monde multiple, avec des interactions et des transactions de machine à machine et d'humain à machine qui se produisent en permanence. Ce monde exige plus que ce que SQLite peut fournir.

Moins cher ?

D'accord, c'est SQLite qui l'emporte. C'est un logiciel libre, gratuit. On ne peut pas faire moins cher. Pour les bricoleurs qui surveillent de près le coût des logiciels produits et achetés à l'extérieur, SQLite peut encore exercer un attrait. Il en va de même pour les décideurs d'entreprise lorsqu'ils apprennent que SQLite est gratuit. Cela pourrait signifier qu'il reste plus d'argent dans le budget pour d'autres postes de la nomenclature ou pour payer des heures de service supplémentaires.

Mais "gratuit" est aussi trompeur que "chiots gratuits". Si vous ne considérez que le coût initial de SQLite, vous ne pouvez pas le battre. Mais vous découplez cette évaluation de toute considération du coût interne de cette décision. Si vous prenez en compte les coûts de conception, de développement, de test, de mise à jour, de support continu, etc. du logiciel - qui, comme nous l'avons vu précédemment, impliquent un nombre important de sauts de puce, étant donné les limitations inhérentes à l'architecture - le calcul des coûts change radicalement.

Nous pourrions consacrer un blog entier à l'estimation des coûts de bricolage, c'est pourquoi nous n'irons pas plus loin ici. Quiconque possède encore des actifs Cobol ou d'autres outils et systèmes hérités comprend parfaitement à quel point il peut être difficile de maintenir et de support code qui a été conçu à l'origine pour répondre aux défis d'une époque antérieure. Si le coût le plus bas reste votre motivation première et si vous êtes déterminé à faire le travail pour étendre les capacités de SQLite afin de répondre aux besoins d'aujourd'hui, il existe plusieurs outils auxquels vous pouvez accéder pour modéliser le coût par nombre de lignes de code que cet effort entraînera. Les modèles varient en fonction de la taille du code, des orientations réglementaires, du cycle de vie prévu et de nombreux autres facteurs, mais ils peuvent vous aider à évaluer à l'avance le coût réel de cette folie - pardon, je veux dire de cet effort.

Bien sûr, vous pouvez sourire avec suffisance et penser que, non, vous n'allez pas le faire vous-même. Il existe toute une industrie de développeurs spécialisés dans les outils SQLite et les composants complémentaires, y compris les éditeurs de requête SQL, les utilitaires de cryptage des données au repos et en transit, les outils de transformation pour la synchronisation des données avec Microsoft SQL Server, et bien d'autres choses encore. Mais cette approche ne fait qu'introduire une autre dimension de coût dans votre entreprise. Non seulement ces compléments annulent effectivement l'aspect "gratuit" de SQLite (puisqu'ils ne sont pas gratuits), mais la dépendance à l'égard de ces petits fournisseurs introduit un élément de risque sur lequel vous n'avez aucun contrôle. Tout bogue ou défaut dans leur code devient une partie inhérente de votre application. Si le développeur de la boutique disparaît - et la majorité d'entre eux ont historiquement disparu dans un délai assez court - vous vous retrouvez soudain dans le modèle de bricolage que vous pensiez éviter. Cette fois, cependant, vous devez bricoler sans avoir une compréhension totale du code que vous avez incorporé, ce qui signifie souvent des correctifs sous-optimaux et l'extension d'un code que vous auriez probablement conçu différemment dès le départ s'il avait été le vôtre.

Oh, et entre les lignes ci-dessus - sans jeu de mots - vous pouvez clairement voir que vous devez toujours bricoler l'intégration de ces modules complémentaires de boutique dans la solution que vous développez. Faut-il encore creuser votre bulle en notant que la charge de la résolution des problèmes ou des conflits découlant de l'intégration de ces modules complémentaires vous incombe également ? Vous n'aurez pas nécessairement les connaissances nécessaires pour résoudre facilement ces problèmes, mais vous serez en fin de compte responsable de la solution que vous aurez fournie et c'est à vous que l'on s'adressera en cas de mécontentement des utilisateurs.

Il est temps de retirer ce numéro

En fin de compte, SQLite n'est ni plus rapide, ni meilleur, ni moins cher. Il ne l'est plus. SQLite a été un ajout brillant à l'équipe technique dans sa jeunesse, mais il est temps de hisser ce maillot aux chevrons et de retirer le numéro. S'il n'est pas plus rapide, meilleur ou moins cher, pourquoi l'adopteriez-vous encore ? Compte tenu des exigences de la gestion des données moderne gestion des données, Actian Zen s'impose comme la solution la plus rapide, la plus performante et la moins chère.

À 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.