Technologie
Ce texte combine des conseils pratiques et une réflexion pour le lecteur.
Conseil : Lorsque vous développez une nouvelle application nécessitant un stockage de données persistant, comme c’est souvent le cas pour les applications web, votre choix par défaut devrait être Postgres.
Pourquoi éviter sqlite ?
sqlite est une base de données assez performante, mais elle stocke toutes ses données dans un seul fichier.
Cela signifie que votre application fonctionne sur une seule machine, ou au moins sur un système de fichiers partagé.
Pour une application de bureau ou mobile, cela peut convenir parfaitement. En revanche, pour un site web, cela peut poser problème.
Il existe de nombreuses réussites utilisant sqlite pour des sites web, mais elles concernent principalement des utilisateurs ayant mis en place leur propre serveur et infrastructure. Les plateformes de type service comme Heroku, Railway, Render, etc., s’attendent généralement à ce que vous utilisiez une base de données accessible via un réseau. Il n’est pas erroné de renoncer à certains avantages de ces plateformes, mais il est important de peser si les bénéfices de sqlite valent la peine de renoncer à des sauvegardes automatiques de base de données fournies par la plateforme et à la possibilité de provisionner plusieurs serveurs d’application.
La documentation officielle propose un bon guide avec des détails supplémentaires.
Pourquoi éviter DynamoDB, Cassandra ou MongoDB ?
Où que soit Ray Houlihan, j’espère qu’il passe une bonne journée.
Je regarde beaucoup de conférences, mais sa présentation de 2018 sur DynamoDB est celle que j’ai probablement visionnée le plus souvent. Je sais que peu d’entre vous prendront le temps de regarder une conférence d’une heure, mais cela en vaut vraiment la peine.
Le message principal est que les bases de données comme DynamoDB, qui incluent Cassandra et MongoDB, sont excellentes si – et c’est un point crucial :
- Vous savez exactement ce que votre application doit faire dès le départ
- Vous connaissez à l’avance vos schémas d’accès
- Vous avez un besoin avéré de gérer de très grandes quantités de données
- Vous êtes prêt à sacrifier un certain niveau de cohérence
Ces bases de données fonctionnent essentiellement comme une grande carte de hachage distribuée. Les seules opérations qui fonctionnent sans avoir besoin de scanner l’ensemble de la base de données sont les recherches par clé de partition et les scans utilisant une clé de tri.
Pour chaque requête, vous devez intégrer cette connaissance dans l’un de ces index avant de stocker vos données. Si vos schémas d’accès changent de manière significative, vous pourriez avoir besoin de retraiter toutes vos données.
C’est frustrant, car, surtout avec MongoDB, les utilisateurs sont souvent attirés par l’idée d’une base de données plus « flexible ». Oui, vous n’avez pas besoin de lui fournir un schéma. Oui, vous pouvez simplement insérer des JSON non typés dans des collections. Non, ce n’est pas une base de données flexible. C’est une base de données efficace.
Avec une base de données relationnelle, vous pouvez facilement passer d’une requête pour obtenir tous les animaux d’une personne à une requête pour obtenir tous les propriétaires d’un animal en ajoutant un ou deux index à vos tables. Avec ce type de NoSQL, cela peut devenir compliqué.
Ce n’est pas non plus idéal si vous devez exécuter des requêtes analytiques. Des questions comme « Combien d’utilisateurs se sont inscrits le mois dernier » peuvent être facilement résolues par une requête SQL, peut-être sur une réplique de lecture si vous craignez d’exécuter une requête coûteuse sur la même machine qui gère le trafic client. Cela dépasse les capacités de ce type de base de données. Vous devez extraire vos données pour les traiter.
Si vous voyez un étudiant ou un jeune diplômé utiliser MongoDB, arrêtez-le. Il a besoin d’aide. Il a été mal orienté.
Pourquoi éviter Valkey ?
L’outil anciennement connu sous le nom de Redis est surtout reconnu pour son efficacité en tant que cache hors processus. Vous effectuez un calcul coûteux une fois et le stockez dans Valkey pour que vos serveurs HTTP n’aient pas à le recalculer.
Cependant, vous pouvez l’utiliser comme base de données principale. Il stocke toutes ses données en RAM, ce qui le rend assez rapide dans ce cas.
Problèmes évidents :
- La capacité de RAM est limitée. Vous pouvez en avoir plus que vous ne le pensez, mais cela reste bien inférieur à ce que peuvent offrir les disques durs.
- Comme pour les bases de données de type
DynamoDB, vous devez faire des concessions sur la manière de modéliser vos données.
Pourquoi éviter Datomic ?
Si vous connaissiez déjà cette base de données, vous méritez une étoile d’or.
Datomic est une base de données NoSQL, mais elle est relationnelle. Les problèmes de « conception préalable » n’existent pas, et elle possède des propriétés intéressantes.
Les données ne sont pas stockées dans des tables. Tout est sous forme de paires « entité-attribut-valeur-temps » (EAVT). Au lieu d’une ligne de personne avec id, nom et âge, vous stockez 1 :person/name "Beth" et 1 :person/age 30. Vos requêtes fonctionnent alors sur des index « universels ».
Vous n’avez pas besoin de coordonner avec les rédacteurs lors de l’exécution de requêtes. Vous interrogez la base de données « à un moment donné ». Les nouvelles données, même les suppressions (ou ce qu’ils appellent « rétractations »), ne suppriment pas réellement les anciennes données.
Cependant, il existe des problèmes significatifs :
- Elle ne fonctionne qu’avec des langages JVM.
- En dehors de
Clojure, un langage relativement de niche, son API est peu conviviale. - Si vous structurez mal une requête, les messages d’erreur que vous recevez sont déplorables.
- L’ensemble des outils existants pour SQL n’est pas disponible.
Pourquoi éviter XTDB ?
Les développeurs de Clojure créent de nombreuses bases de données.
XTDB est spirituellement similaire à Datomic, mais :
- Il dispose d’une API HTTP, donc vous n’êtes pas limité à la JVM.
- Il a deux axes temporels que vous pouvez interroger. « Temps système » – quand les enregistrements ont été insérés – et « Temps valide ».
- Il propose une API SQL.
Les principaux inconvénients sont :
- C’est une technologie récente. Son API SQL a été introduite l’année dernière. Son modèle de stockage a récemment changé. L’entreprise derrière elle survivra-t-elle encore dix ans ? Qui sait !
Bien sûr, c’est juste un point. Je pourrais en trouver d’autres, mais considérez cela comme un substitut pour toute base de données récemment développée. Le meilleur indicateur de la pérennité d’une technologie est sa longévité. COBOL existe depuis des décennies et continuera probablement d’exister encore longtemps.
Si vous avez besoin d’un stockage persistant, vous souhaitez un support aussi long que possible. Vous pouvez choisir une base de données plus récente ou expérimentale pour votre application, mais, indépendamment des propriétés techniques, c’est un choix risqué. Ce ne devrait pas être votre option par défaut.
Pourquoi éviter Kafka ?
Kafka est un journal en mode ajout. Il peut gérer des To de données. C’est un excellent journal en mode ajout. Il fonctionne remarquablement bien si vous souhaitez effectuer des opérations de sourcing d’événements avec des données provenant de plusieurs services gérés par différentes équipes.
Cependant :
- Jusqu’à une certaine échelle, une table dans Postgres fonctionne très bien comme journal en mode ajout.
- Il est peu probable que vous ayez des centaines de personnes travaillant sur votre produit ni des To d’événements à traiter.
- Créer un consommateur Kafka est plus sujet aux erreurs que prévu. Vous devez garder une trace de votre position dans le journal.
- Même lorsqu’il est géré par un fournisseur cloud (et il existe de bons services Kafka gérés), c’est une autre infrastructure à surveiller.
Pourquoi éviter ElasticSearch ?
La recherche de données est-elle la fonction principale de votre produit ?
Si oui, ElasticSearch vous apportera de réels avantages. Vous devrez extraire vos données et gérer tout ce processus, mais ElasticSearch est conçu pour la recherche. Il excelle dans ce domaine.
Si non, Postgres fera l’affaire. Un peu de ilike et la recherche en texte intégral intégrée suffisent amplement pour la plupart des applications. Vous pouvez toujours ajouter un outil de recherche dédié plus tard.
Pourquoi éviter MSSQL ou Oracle DB ?
Une question légitime à se poser : ces bases de données valent-elles leur prix ?
Je ne parle pas seulement du coût de la licence, mais aussi du coût de l’enfermement. Une fois vos données dans Oracle DB, vous paierez Oracle pour toujours. Vous devrez former vos développeurs à ses particularités, indéfiniment. Vous devrez choisir entre des fonctionnalités d’entreprise et votre budget, éternellement.
Je sais qu’il est très peu probable que vous contribuiez à Postgres, donc je ne vais pas prétendre qu’il y a une magie liée à l’open source, mais je pense que vous devez avoir un besoin très spécifique en tête pour choisir une base de données propriétaire. Si vous n’avez pas une fonctionnalité MSSQL incontournable, ne l’utilisez pas.
Pourquoi éviter MySQL ?
C’est un point sur lequel j’ai besoin de l’aide du public.
MySQL appartient à Oracle. Certaines fonctionnalités sont réservées à leurs éditions professionnelles. Dans une certaine mesure, vous rencontrerez des problèmes d’enfermement similaires à ceux des autres bases de données.
Cependant, l’édition gratuite de MySQL a été utilisée dans une très large gamme d’applications. Elle existe depuis longtemps. De nombreuses personnes savent comment l’utiliser.
Mon problème est que je n’ai passé qu’environ six mois de ma carrière professionnelle à travailler avec. Je ne sais pas assez pour la comparer intelligemment à Postgres.
Je suis convaincu qu’elle n’est pas secrètement bien meilleure au point de désavantager ceux à qui je recommande Postgres, et je me souviens avoir lu que Postgres a généralement un meilleur support pour l’application d’invariants dans la base de données elle-même, mais je serais ravi d’apprendre davantage à ce sujet.
Pourquoi éviter une base de données vectorielle AI ?
- La plupart sont nouvelles. N’oubliez pas les risques liés à l’utilisation de quelque chose de nouveau.
- L’IA est une bulle. Une bulle qui pèse lourd, mais une bulle. Ne construisez pas votre maison dessus si vous pouvez l’éviter.
- Même si votre entreprise est une autre arnaque liée à l’IA, vous n’avez probablement besoin que de
import openai.
Pourquoi éviter Google Sheets ?
Vous avez raison. Je ne peux penser à aucun inconvénient. Allez-y.
