Ce billet introduit l'architecture RAG (Récupération Augmentée par Génération) comme solution aux hallucinations des LLM (Large Language Models). Les hallucinations, résultant du fonctionnement probabiliste des LLM, sont des réponses inventées par l'IA en l'absence de données suffisantes. L'architecture RAG propose de remédier à ce problème en combinant la capacité des LLM à générer du texte avec une base de données fiable et contrôlée. Ainsi, l'IA peut générer des réponses plus précises et sourcées, évitant ainsi les inventions non fondées.
Cet article présente une approche pragmatique pour construire une application SaaS multi-tenant avec Symfony, en utilisant une base de données partagée et une seule codebase pour plusieurs clients (tenants). L’article s’appuie sur l’expérience de l’auteur, qui a développé une plateforme pour des marques de retail, chacune ayant ses propres magasins, utilisateurs et règles d’accès.
Points clés :
- Résolution du tenant : Identification du client actif via la session (back-office) ou le sous-domaine (front-office), stockée dans un service
TenantContextaccessible partout dans l’application. - Isolation des données : Toutes les entités liées à un client incluent un
brand_id, et les requêtes sont automatiquement filtrées par ce contexte. - Contrôle d’accès (ACL) : Gestion des fonctionnalités et permissions par client via des listes de contrôle d’accès (ACL) et des voters Symfony, permettant d’activer/désactiver des fonctionnalités par marque.
- Architecture unifiée : Le même
TenantContextest utilisé pour le back-office (session) et le front-office (domaine), garantissant une cohérence et une sécurité optimale.
L’article insiste sur la simplicité, la maintenabilité et l’évolutivité de cette solution, idéale pour les SaaS nécessitant une isolation des données sans complexité infrastructurelle.
La multi-location (multi-tenancy) en base de données désigne une architecture où une seule instance d’application et d’infrastructure sert plusieurs clients (tenants), tout en garantissant une isolation logique de leurs données. Ce modèle, largement adopté dans le cloud, permet une meilleure scalabilité, une réduction des coûts de maintenance et une optimisation des ressources. L’article détaille quatre approches principales : base unique avec schéma partagé (simple mais risqué en cas d’oubli de filtrage par tenant), base unique avec schémas séparés (meilleure isolation mais complexité accrue), base dédiée par tenant (isolation maximale mais coûteuse en gestion), et plusieurs bases avec tenants partagés (compromis entre coût et performance). Chaque méthode présente des avantages et des inconvénients selon les besoins en sécurité, performance et maintenance
L'article explique comment Apache Iceberg offre une solution robuste pour la gestion des données volumineuses, avec des capacités ACID complètes, une évolution de schéma flexible et des performances optimisées. Son intégration native avec l'écosystème AWS, incluant des services comme Amazon Data Firehose pour l'ingestion de données en temps réel, en fait un choix idéal pour les architectures de données modernes de type Lakehouse nécessitant fiabilité, scalabilité et performance. L'article explore également l'utilisation de Spark (PySpark) pour manipuler des données et exploiter les capacités d'Iceberg, illustrant ainsi son efficacité dans un environnement cloud comme AWS.
Une base de données graphe intégrée, à la SQLite - (depuis https://bsky.app/profile/did:plc:4q4wdaknunskbt47bzsi2qbv/post/3lnezxpunas2w?ref_src=embed )
Tout est dans le titre
Un article passionnant sur la recherche d'un bug : une BD qui ne répond plus, un import qui paraît être le coupable idéal... et un rebondissement final. L'auteur donne de précieux conseils en matière de TDD
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Un tour assez complet de la question
Passionnant
Des réflexions sur la nécessité du métier de DBA
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Il s'agit d'un retour d'expérience dans l'apprentissage de Kubernetes, avec quelques conseils pratiques : réglage d'ETCD, réseau avec utilisation d'un ingress ou d'un Load Balancer, stockage de données persistantes, et trucs et astuces pour le shell
Tout est dans le titre... L'auteur parle surtout de PostgreSQL mais ça doit pouvoir s'adapter à d'autres systèmes