Une base de donnée type Graph basée sur du JSON.

Ils affichent des performances équivalentes voir meilleurs que MongoDB et Postgres sur des opérations tels que:

• single write
• single read

Sinon côté features d'une DB graph, à priori ils font beaucoup mieux que Neo4J, le principal concurrent.

Leur langage de recherche ressemble à du pseudo-code:

FOR doc IN users
  FILTER doc._key == "phil"
  RETURN doc

Explication sur les différents systèmes de gestion des permissions pour une application.

Role Based Access Control (RBAC)

Définition d'un ensemble de rôle ayant le droit d'exécuter des actions sur l'application puis attribution de ces rôles à des utilisateurs.

Exemple: le rôle device-manager permet de créer les Devices d'une plateforme IoT

Access Control List (ACL)

Définition de listes de permissions rattachées à chaque entitée de l'application. Une permission définie les actions possible sur l'entitée correspondante pour un utilisateur ou un groupe d'utilisateur.

Exemple: l'ACL rattaché au Device abc123 donne le droit à l'utilisateur aschen de le modifier

Attribute Based Access Control (ABAC)

Définition des permissions en fonction des attributs des entités. Les permissions sont accordées à des utilisateurs ou groupes d'utilisateurs en fonction des valeurs de ces attributs.

Exemple: une règle ABAC autorise la lecture des informations d'un Device uniquement si l'attribut creator du Device est égal à l'identifiant unique d'un utilisateur

L'histoire de l'adoption de Kafka chez Cloudflare en tant que message bus inter-services.

Ils l'ont déployé pour optimiser le développement de leur architecture micro-service (découplage) mais aussi:

• réduire les silos de données
• rendre les communications inter-services plus claires
• avoir un format de communication auto-documenté

Pour cela, ils ont notamment développé un client Kafka interne qui abstrait la plupart de la configuration et de la logique compliqué.

Le schéma de communication n'est pas JSON ou Avro (ouf!) mais l'excellent Protobuf qui en plus d'avoir une taille réduite, assure le typage fort de chaque champ afin d'identifier les breakings changes.

Niveau observabilité, le plus important pour eux est le "lag", qui est le temps entre le dernier message produit et le dernier message lu.

Cette seule métrique permet d'identifier de nombreux problèmes:

• le consumer est down
• le consumer n'arrive pas à ingérer tous les messages
• un nombre inhabituel de messages est produit
• le consumer n'acquitte plus les messages

Bref, un super retour d'expérience et pleins de bons conseils pour construire son infrastructure applicative avec Kafka.

Le début de l'article explique très clairement le fonctionnement de Kafka avec une vulgarisation accessible à tous et des schémas.

Un article sur l'insertion spéculative dans Postgres et les améliorations de performances qu'elle apporte.

L'insertion spéculative est faite avec la construction INSERT… ON CONFLICT.

Cette variante vérifie d'abord que l'insert peut être réalisé, ce qui évite la création de "dead tuples" qui sont des lignes n'ayant pu être insérées mais quand présentes jusqu'au prochain garbage collect (vacuum).

Sur une table ayant 1 millions de dead tuples, il y a une différence de perfs de presque 8000% au SELECT ! (0.7 ms vs 54 ms)

Les insert ayant échoués vont aussi incrémenter les ID de transaction et après 200 millions, cela va déclencher le garbage collector pour un nettoyage mais aussi ralentir toute la base de données.

Finalement, tous ces dead tuples consomment aussi de l'espace de stockage.

Bref, il est temps de passer à INSERT… ON CONFLICT DO NOTHING 😄

(Merci Gaël pour le partage)

Tous les conseils pour bien choisir sa clé primaire.

Dans la plupart des cas, un entier auto-incrémenté (serial) est suffisant, cependant il a quelques désavantages:

• prédictible: il est facile d'énumérer les ID et de deviner des choses comme le nombre d'utilisateurs sur un site (yoursite.com/users/41 renvoi le profil mais yoursite.com/users/42 renvoi une 404)
• ce n'est pas un standard SQL

Une autre possibilité est d'utiliser un UUID v4 car ceux ci sont totalement aléatoires. Par contre on a d'autres problèmes:

• pas possible de les trier
• beaucoup plus gros que notre entier auto-incrémenté
• leur indexage par la base de donnée est très difficile

C'est pour ça que d'autre types d'UUID sont apparus (voir UUID v7 et ULID), cette dernière génération inclue un timestamp afin de pouvoir les trier par exemple.

L'article termine sur un benchmark sur la vitesse de génération dans PostgreSQL mais aussi de la taille de la table et de son index.

Niveau vitesse, tous sont plus ou moins équivalents à part pour pushid et nanoid qui sont significativement plus lents.

Au niveau de la taille, sans surprise les dernières version d'UUID font augmenter l'espace utilisé.

Un ensemble de guides très complets publiés par Prisma.

Vous trouverez des guides sur:

• le data modeling
• bases de données relationnelles
• bases de données NoSQL document
• PostgreSQL
• MongoDB
• SQLite
• Microsoft SQL Server (nan je déconne y'a presque rien)

Le club Med a profité de la crise covid et de la fermeture de ses 60 villages pour construire une stratégie Data flambant neuve !

Les objectifs principaux étaient d'augmenter les ventes (~2-3% estimés) et d'analyser en détails l'impact des budgets publicité et marketing injectés dans le cycle de vente.

Niveua technique, le groupe voulait de l'analyse temps réel donc il a fallut ingérer les données depuis une douzaine de sources (CRM, ERP, site web , appels téléphoniques, etc) dans un datalake.

Concrètement un broker Kafka reçoit les messages qui proviennent majoritairement d'une base de données DB2 et tout est écrit sur un PostgreSQL ou BigQuery (donc tout chez Google Cloud Platform)

Des outils de Business Intelligence comme Qlikview ou Google Analytics permettent ensuite aux différents métiers d'exploiter la donnée.

Ce que je connaissais pas c'est Zeenea, un catalogue de données pour comprendre quels sont les flux, d'où viennent les données, à quelle moment sont-elles disponibles etc.

Au niveau des volumes, ils annoncent quand même 5 millions d'événements par jour !

Un REX sur les limites de MongoDB.

Concrètement dans le cas de Malt, MongoDB leur a permis d'itérer rapidement au début mais par la suite son utilisation a ralenti les développements et le fonctionnement de l'application.

A noter que l'article porte beaucoup sur les anciennes versions de MongoDB, sans les transactions ou le mot clé $lookup.

Dans les problèmes rencontrés:

• le langage de requête en JSON qui n'est pas aussi clair que du SQL
• la modélisation nosql qui implique beaucoup de dénormalisation et de duplication
• la cohérence des données et les jointures qui doivent se faire dans le code

Bref, comme d'habitude il faut utiliser la bonne base de donnée pour le bon problème et lorsqu'il s'agit de la modélisation d'un système relationnel (90% des applications) alors une base de données relationnel est de mise.

Un REX sur la gestion des pics d'affluence à L'Équipe pendant les coupes du monde.

Plusieurs conseils:

• code freeze: aucun déploiement avant la coupe de monde
• auto-scaling: entre 10 et 120 pods sur leur cluster Kubernetes
• observabilité: Application Performance Management (APM) et une suite Elasticsearch, Logstash, Kibana (ELK)

A certains moments, ils ont encaissé plus de 1 million de pages vues à la minutes!

Explications sur le modèle de données utilisé par Notion en interne.

Tout repose sur un système de blocs organisés en arbre hiérarchique ou chaque bloc possède un type qui va définir la manière dont il est affiché par l'interface web.

Côté optimisations de leurs applications clientes, les modifications sont faites d'abord dans une DB locale (SQLite ou IndexedDB) puis synchronisées sur les serveurs de Notion.

Une histoire de dette technique sur un fond de migration d'architecture Kafka (😱)

Une remarque intéressante ici est que la dette technique s'est accumulée à cause du manque de mise à jour du cluster Kafka, par l'inaction donc.

Moralité: gardez vos framework et outils à jour

Un article qui explique pas à pas le fonctionnement d'une base de données relationnelle.

Il utilise l'algèbre relationnel pour décrire chaque opération.

Dans une DB relationnelle, chaque ligne peut-être considérée comme un vecteur à N dimensions (les dimensions sont les colonnes).

"Adrien", 29, "Minsk" est un vecteur à 3 dimension (nom, age, ville) qui représente une personne.

A partir du la on peut dérouler toutes les opérations comme la projection (SELECT), la selection (WHERE), le produit vectoriel (JOIN)

Une base de données pee-to-peer, c-a-d qui permet de communiquer avec d'autres clients pour se synchroniser sur l'état commun partagé.

ça m'a l'air plutôt compliqué à gérer, surtout avec des clients malicieux mais par contre le côté offline first est toujours bon à prendre :-)

(Merci Pierre pour le partage)

Un manifest qui va dans le sens du KISS (Keep It Simple, Stupid)

Mes préférés:

Synthesis is the key of communication. We have to write code for humans not machines.

Keep it plain. Try to keep your designs with few layers of indirection.

Un très bonne comparaison entre les performances de recherches d'Elasticsearch et MongoDB et le résultat est sans appels.

Sur la recherche, Elasticsearch est jusqu'à 20x plus rapide que MongoDB.

Sur les aggrégations, Elasticsearch est jusqu'à 38x plus rapide que MongoDB.

Sur l'insertion, MongoDB est 1.20x plus rapide que Elasticsearch.

Sur le parcours des données, Elasticsearch offre des performances stables quand MongoDB passe de 5 à 60 sec pour récupérer les derniers documents d'une collection.

Sur l'espace disque, MongoDB occupait 2x plus d'espace avec les mêmes données. (sans index!)

Ces benchmarks ont été effectués sur de grosses collections (dizaines de millions) mais les différences performances se font aussi sentir sur de plus petites collections.

Les performances seules ne doivent pas guider le choix mais aussi les features, par exemple les limitations d'Elasticsearch sont les suivantes:

• Near Realtime Search: les documents ne sont pas disponible immédiatement dans le search après écriture
• Pas de modification possible du type d'un champs d'une collection (int vers string par exemple)
• Pas de transactions
• Pas de pseudo-relationnel comme en MongoDB

Utiliser correctement une base de donnée relationnelle reste un exercice compliqué car il y a beaucoup de subtilité à comprendre.

Le plus important reste le concept d'index de lecture qui sont des structures permettant de retrouver plus rapidement de la donnée en échange d'un temps d'écriture plus long.

Le plan d'exécution des requêtes est aussi très important, l'auteur présente un exemple simple:

-- compute "now() - interval 3 days" then execute a table scan
publish_date < now() - interval '3 days'

-- for each line, compute "publish_date + interval 3 days and compare to now()"

publish_date + interval '3 days' < now()

Dans le deuxième cas, on va devoir récupérer chaque ligne et faire un calcul pour executer la requête. Il ne faut pas oublier que les bases de données relationnelles sont ensemblistes et donc faites pour fonctionner sur des ensembles de lignes plutôt que sur des lignes individuelles.

Une bande dessinée qui explique les raisons d'utiliser un message broker comme Kafka et le fonctionnement de ce dernier.

(Merci Gaël pour le partage)

L'histoire d'une grosse migration backend chez LinkedIn et un retour d'expérience très intéressant.

Les sujets de migration sont toujours très sensibles car ils ont un impact fort et sont sujets à de nombreux risques.

L'équipe de LinkedIn donne quelques conseils:

• s'assurer que tout le monde comprenne l'intérêt de la migration et du nouveau système
• écrire des instructions étape par étape clair et précises
• faire des outils automatiques dès que c'est possible
• faciliter un accès au support pour répondre aux questions
• monitorer les progrès

Excellent article sur le fonctionnement de la vérification de d'authenticité des emails pour lutter contre le phishing.

Concrètement cela se base sur des enregistrement DNS pour un domaine. (e.g. gmail.com)

Il y a 3 mécanismes:

• Sender Policy Framework (SPF): adresses IP autorisées à envoyer des emails pour le domaine
• DomainKeys Identifier Mail (DKIM): clé publique et une signature cryptographique est ajoutée aux emails
• Domain-based Message Authentication Reporting and Conformance (DMARC): instructions pour traiter les emails non conforme