Conception orientée données (2018)
(dataorienteddesign.com)- L’édition en ligne de Data-Oriented Design est une ressource mise à disposition pour permettre aux lecteurs souhaitant apprendre la conception orientée données d’en parcourir gratuitement les points essentiels
- Certaines sections non essentielles du livre complet ont été retirées, mais le contenu est structuré autour des éléments indispensables à l’apprentissage
- Le document ayant été converti automatiquement de LaTeX vers HTML, il peut subsister des erreurs de mise en forme, des images cassées et des listes de code source endommagées
- Pour les listes de code source cassées, le code de référence peut être consulté dans un dépôt GitHub séparé
- L’achat du livre papier permet de lire l’ouvrage dans un meilleur format tout en contribuant au maintien de l’édition en ligne pour les lecteurs qui ne peuvent pas l’acheter
Nature de l’édition en ligne
- Data-Oriented Design est proposé comme une version abrégée gratuite en ligne consacrée à la conception orientée données
- Certaines sections non essentielles ont été exclues, mais le fil directeur nécessaire à l’apprentissage est bien inclus
- Cette ressource s’adresse aux lecteurs qui veulent apprendre une approche de la conception centrée sur les données elles-mêmes
Qualité de conversion du document et référence du code
- Le document en ligne est généré automatiquement, ce qui peut rendre certains éléments de mise en forme maladroits
- L’outil de conversion de LaTeX vers HTML n’étant pas parfait, certaines images ou listes de code source peuvent être corrompues
- Si une liste de code source est cassée, le code référencé peut être trouvé sur GitHub
Livre papier et retours
- Le livre papier offre un meilleur format de lecture que l’édition en ligne
- Son achat aide aussi à maintenir la version en ligne pour les lecteurs qui n’ont pas les moyens de l’acheter
- Les retours peuvent être envoyés à support@dataorienteddesign.com
1 commentaires
Avis sur Hacker News
L’un des meilleurs conseils que j’aie reçus pour écrire du code composable et performant était « structure of arrays plutôt qu’array of structures », et on retrouve beaucoup cet écho dans cet article
En y regardant de plus près, l’architecture entité-composant convient bien non seulement aux jeux, mais aussi aux applications métier
Beaucoup de développeurs en entreprise restent toutefois figés dans des modèles CRUD de conservation d’enregistrements, ont du mal à penser en colonnes plutôt qu’en lignes, et l’idée de mettre l’ID d’une entité dans une table
publishedau lieu de passer un booléenpublishedàtruene leur paraît souvent pas naturelleMais une fois qu’on comprend à quel point cette approche s’étend facilement de manière polymorphe, on a envie de l’appliquer à toutes les données. Cela ouvre de nouvelles possibilités de réutilisation croisée des données de composants, et on commence à se demander pourquoi il est permis qu’une interface réseau ait une date d’anniversaire, qu’une facture porte une adresse IPv6, qu’un chat entre dans un pool DHCP, que limegreen soit supprimé, et que le mardi vaille 5 dollars — et c’est la moitié du plaisir
Je ne suis pas d’accord avec l’idée que cette approche soit totalement incompatible avec l’orienté objet. Je l’ai déjà utilisée avec Active Record de Ruby, et cela fonctionnait bien même dans des domaines auxquels on n’associe généralement pas le mot « haute performance ». Cela convenait particulièrement bien parce que le système objet de Ruby est plus proche de Smalltalk que de C++/Java et privilégie fortement la composition plutôt que l’héritage
Dans les langages orientés objet, on se concentre généralement sur un « objet auquel on veut penser » — utilisateur, billet de blog, transaction financière — qu’on implémente séparément du reste, puis on masque les données avant de se demander quelles méthodes exposer au reste du système. La notion d’encapsulation est très forte
Dans une conception orientée données, il est plus courant que des données de domaines différents soient accessibles, et que les sous-systèmes sélectionnent ce dont ils ont besoin pour faire leur travail. Java ou Ruby ne l’empêchent pas, mais il existe clairement une barrière psychologique pour les programmeurs
Il aborde aussi le support logiciel qui permet d’accéder au SoA comme à de l’AoS, comme les data frames de R, Pandas en Python ou DataFrames.jl en Julia
J’aime beaucoup Snowflake et je pense qu’il va manger le déjeuner de ses concurrents. Le fait que Snowflake « prenne en charge » les clés étrangères sans les imposer est aussi intéressant. Autrement dit, Snowflake est le degré de « NoSQL » que je suis prêt à tolérer
Le second consiste à renoncer à l’encapsulation, à séparer les données des méthodes qui les manipulent, et à penser l’application entière à partir de la manière dont les données circulent, afin de la modéliser pour qu’elle soit plus facile à comprendre et à modifier. Pour plus de rigueur, on peut utiliser des structures de données immuables et des fonctions pures
Pour les curieux, voici une très courte introduction à l’ECS : https://dev.to/ovid/the-unknown-design-pattern-1l64
« La disposition des données est-elle définie par une interprétation unique issue d’un seul point de vue ? » est peut-être la question la plus importante au moment des choix techniques et de l’architecture. En général, pour y répondre, il faut parler avec le métier et les clients
Si l’on est certain qu’il existe exactement une seule « vue » valide des données pour l’ensemble du système, alors il est logique de l’inscrire dans le code. S’il y a le moindre doute, un modèle de style relationnel a de fortes chances d’être plus adapté. Beaucoup d’entreprises finissent par revenir à SQL une fois qu’elles comprennent la théorie des jeux du problème
Tout le monde se demande pourquoi tant d’acteurs semblent s’éloigner d’une grande base de données SQL unique. Il existe bien des cas limites de « web scale » qui menacent la scalabilité verticale en écriture, mais selon moi, la plupart des entreprises, y compris les groupes du Fortune 100, ne s’en approcheront jamais
Cela n’avait rien à voir avec la meilleure façon de modéliser un dataset donné ni avec les meilleures performances, mais uniquement avec l’historique d’incidents causés par la flexibilité du schéma et les échecs de migration de schéma. Dans les conceptions NoSQL, ce problème ne survenait pas, et les avantages des bases SQL ne compensaient pas le grand bénéfice du NoSQL sans schéma rigide
Bien sûr, on peut aussi très mal utiliser un magasin clé-valeur et ruiner fortement les performances comme les coûts. Sur des plateformes cloud comme DynamoDB, j’ai souvent vu des données mal structurées qui forçaient d’énormes volumes de scans et faisaient exploser la facture
Comme il s’agit d’une vieille grande entreprise, il arrive souvent que des solutions techniques créées autrefois par du personnel non technique se figent et doivent continuer à être maintenues. Il existe cinq étapes de transformation des données SQL : on part de la base opérationnelle, puis, à chaque changement de type d’activité, on ajoute une nouvelle génération de modèle de données
À mesure que les couches s’accumulent, on continue simplement à empiler sur les précédentes. Si une application construite il y a 10 ans au-dessus de la couche d’abstraction 2 a maintenant besoin de données de la couche 4, on écrit des scripts pour rétroporter ces données vers les couches antérieures, puis on continue. Au final, cela devient un énorme amas de tables et de vues interdépendantes qui lisent les données d’une manière étrange et peu intuitive, et un projet de nettoyage a été jugé trop coûteux, donc repoussé aux années 2030
Je comprends que les gens voient ce genre de problème et se demandent comment il aurait pu être évité. Mais pour une raison que j’ignore, il semble impossible d’appliquer aux ingénieurs logiciels le type de discipline nécessaire, et il faut donc les empêcher d’une manière ou d’une autre de fabriquer du spaghetti. C’est là qu’intervient la séparation. Si l’on ne peut pas lire les données d’un autre service, on ne peut pas construire un spaghetti qui ralentit les deux côtés
La séparation verticale des applications devient une solution logicielle à un problème humain : la faiblesse de la discipline d’ingénierie dans les entreprises
J’ai récemment publié un framework open source entièrement fondé sur la conception orientée données, et beaucoup m’ont dit que cette approche leur convenait parfaitement. Le simple fait d’avoir toutes les données au même endroit rend énormément de choses plus faciles
https://sql.ophir.dev
Une énorme DB contenait beaucoup de résidus que personne n’utilisait, dont personne ne savait pourquoi ils étaient là, mais dont on n’était pas encore sûr qu’ils pouvaient être supprimés, et il fallait des stratégies d’optimisation différentes pour la lecture et l’écriture
Les équipes devaient aussi avoir la propriété de leurs bases et magasins de données pour avancer vite, sans attendre qu’un DBA réponde à un ticket
Quand je travaillais dans une grande vieille entreprise, la plupart des problèmes étaient politiques et administratifs. Une seule grande base SQL est efficace, mais dès que l’organisation qui la possède n’est plus alignée avec la nouvelle stratégie du CTO ou avec une autre activité clé, cela devient un problème
Si l’on ajoute à cela une panne qui met en évidence la faible résilience de ce modèle, cela devient rapidement un casse-tête politique, et les solutions techniques, même si elles paraissent évidentes à tout le monde, deviennent difficiles à faire avancer
L’ensemble de ce conseil est dépendant du contexte
Les jeux ont simplement beaucoup d’opérations qui nécessitent une approche en colonnes, mais ce n’est pas le cas de tous les domaines. Appliquer aveuglément les bonnes pratiques du jeu vidéo à d’autres domaines ne fait que compliquer la vie de tout le monde et aggraver la plupart des systèmes
Les champs booléens d’une struct peuvent devenir des bitsets, les champs nullable peuvent devenir des maps clairsemées ou denses, et les champs pointeur ou référence peuvent devenir des tableaux d’entiers de plus petite largeur indexant un pool
Dans un environnement où le CPU est souvent bloqué sur les accès mémoire, on ne peut pas sous-estimer l’impact de ces changements. L’écart de latence entre le cache L3 et la RAM peut être de l’ordre de 10x
Pour tout programme où la performance est ne serait-ce qu’un peu importante, il y a de fortes chances que ce soit l’un des moyens de garantir de bonnes performances
La seule chose dont on peut s’attendre à ce qu’elle continue à s’améliorer sur le matériel moderne, c’est la densité logique. La SRAM et la taille des caches ne se scalent plus très bien avec les lithographies récentes, et la bande passante RAM n’a plus beaucoup augmenté depuis longtemps. La bande passante par cœur a peut-être même diminué. Les accès mémoire sont un goulot d’étranglement depuis un bon moment
La conception orientée données est très pertinente à l’intérieur de certains sous-systèmes, mais dans le code de gameplay de haut niveau, sauf pour certains genres, ce n’est pas forcément le cas
Je pense que la présentation Data-Oriented Design and C++ de Mike Acton à la CppCon 2014 est la meilleure présentation sur la programmation jamais faite à ce jour. Vraiment incontournable : https://youtu.be/rX0ItVEVjHc
Il a aussi auparavant piloté Unity DOTS, mais malheureusement Unity semble aujourd’hui vaciller. Le travail sur DOTS lui-même, même inachevé, reste solide
J’ai passé l’essentiel de ma carrière à écrire des applications web, et c’est cette présentation qui m’a fait comprendre « pourquoi quelqu’un utiliserait le C »
Andrew Kelley a donné une présentation à la fois instructive et amusante expliquant comment la conception orientée données a influencé son travail sur le compilateur Zig : https://vimeo.com/649009599
Même les débutants peuvent apprendre à programmer selon une approche orientée données dès le départ
Parmi les livres qui enseignent ce style aux débutants, on peut citer How to Design Programs et A Data-Centric Introduction to Computing
https://htdp.org/
https://dcic-world.org/
J’ai trouvé une critique en ligne du livre : https://gist.github.com/seece/25ed1b2108cf5782718b026382f2c5...
« L’un des principaux responsables des problèmes et des retards qui accablent de nombreux projets a été l’insistance sur le fait qu’il ne fallait pas optimiser prématurément. Si l’optimisation tardive est si difficile, c’est parce qu’une grande partie des logiciels est construite en disséminant partout des instances d’objets, même quand elles ne sont pas nécessaires. »
Il existe clairement des applications où les performances sont la priorité absolue, et d’autres où ce n’est pas le cas. Cela m’amène à me demander si, dans les applications où les performances comptent, une optimisation précoce peut aussi être acceptable. Je me demande si c’est bien ainsi qu’il faut le comprendre
Il existe aussi le Data-Oriented Programming : https://www.manning.com/books/data-oriented-programming
Je me demande si ces deux concepts sont les mêmes
La conception orientée données est adaptée aux débutants. Parce qu’elle traite seulement de la pureté de la modélisation des données, plutôt que des personnes et des activités de l’entreprise
Quand j’étais plus jeune, la première étape d’un nouveau projet consistait à dessiner le modèle entité-relation, et c’était la base de tout
Aujourd’hui, avant même de commencer le modèle de données, on cherche d’abord à comprendre le problème et le domaine, puis on réfléchit aux capacités, à la manière de les regrouper et de définir leurs frontières
Cela dit, ce texte semble vouloir dire que si l’on se concentre dès le départ sur la collecte des besoins en données, la discussion sur les exigences métier elles-mêmes pourrait devenir moins nécessaire
L’un des concepts clés quand on utilise le DoD, c’est de ne pas cacher les données derrière des abstractions. L’idée est plutôt que moins il y en a, mieux c’est
Pourtant, en parcourant rapidement l’article d’introduction, j’ai eu l’impression inverse. Il parle trop et finit par abstraire le concept central. Je me demande si je suis le seul à trouver ironique qu’il ne boive pas son propre vin
Le paragraphe d’introduction est assez remarquable. Son écriture fluide et ses idées intéressantes donnent envie de continuer à lire
« Les données sont tout ce que nous avons. Les données sont ce que nous transformons pour créer l’expérience utilisateur. Ce que nous lisons quand nous ouvrons un document, ce sont des données. Les graphismes à l’écran, l’impulsion des boutons de la manette, la cause qui pousse les haut-parleurs à produire des ondes dans l’air, la manière dont on monte de niveau, la façon dont un ennemi connaît votre position et vous tire dessus, tout cela est de la donnée. Le temps qu’il faut à la dynamite pour exploser, le nombre d’anneaux perdus quand on tombe sur des pics, ce sont aussi des données. La position et la vitesse actuelles de chaque particule dans la magnifique scène finale du jeu sont des données, et tout cela, lu depuis le disque puis introduit dans votre vie, est le résultat des transformations d’un code source donné au compilateur, des instructions prescrites par l’assembleur, et de la machine exécutant les instructions décodées. »
Comme « douche froide » pour planter le décor et faire sortir de la manière de penser en abstractions orientées objet, cela peut être utile. Mais au-delà, cela me semble à peu près aussi utile qu’un ingénieur disant : « Regardez autour de vous ! Tout est fait d’atomes ! L’ingénierie consiste fondamentalement à déplacer des atomes ! »
Ce n’est pas faux, mais cela n’aide pas vraiment à faire de l’ingénierie au quotidien.