Diseño centrado en datos (2018)
(dataorienteddesign.com)- La edición en línea de Data-Oriented Design es un material publicado para que los lectores que quieran aprender diseño centrado en datos puedan revisar gratis el contenido esencial
- Aunque faltan algunos capítulos no esenciales del libro completo, está organizada en torno al contenido imprescindible para aprender
- Como es un documento convertido automáticamente de LaTeX a HTML, puede contener errores de formato, imágenes rotas y listados de código fuente dañados
- Los listados de código rotos pueden consultarse en un repositorio de GitHub aparte para ver el código de referencia
- Comprar la edición impresa es una mejor manera de leerlo por su formato, y además ayuda a mantener la edición en línea para lectores a quienes les resulta difícil comprarlo
Naturaleza de la edición en línea
- Data-Oriented Design se ofrece como una versión resumida gratuita en línea sobre diseño centrado en datos
- Aunque se omitieron algunos capítulos no esenciales, incluye el flujo central necesario como material de aprendizaje
- Está pensada para lectores que quieren aprender un enfoque de diseño centrado en los propios datos
Calidad de la conversión del documento y referencia del código
- El documento en línea se genera automáticamente, por lo que parte del formato puede verse extraño
- Como la herramienta que convierte de LaTeX a HTML no es perfecta, algunas imágenes o listados de código fuente pueden romperse
- Si los listados de código fuente están dañados, el código referenciado puede encontrarse en GitHub
Edición impresa y comentarios
- La edición impresa puede leerse en un formato mejor que la versión en línea
- Comprar la edición impresa ayuda a seguir manteniendo la versión en línea para lectores que no tienen posibilidad de comprarla
- Los comentarios pueden enviarse a support@dataorienteddesign.com
1 comentarios
Opiniones de Hacker News
Uno de los mejores consejos que he recibido para escribir código combinable y de alto rendimiento fue: "estructura de arreglos, no arreglo de estructuras", y este artículo transmite mucho de esa misma idea
Resulta que la arquitectura entidad-componente no solo encaja bien en juegos, sino también en aplicaciones empresariales
Aun así, muchos desarrolladores corporativos están tan acostumbrados al modelo CRUD de almacenamiento de registros que les cuesta pensar en columnas en vez de filas, y muchas veces no les resulta natural la idea de meter el ID de la entidad en una tabla
publisheden lugar de cambiar atrueun campo booleanopublishedAun así, una vez que te das cuenta de lo fácil que este enfoque se expande de manera polimórfica, te dan ganas de usarlo para todos los datos. Entonces aparecen nuevas oportunidades para reutilizar datos de componentes de forma cruzada, y empiezas a preguntarte por qué se permite que una interfaz de red tenga cumpleaños, que una factura lleve una dirección IPv6, que un gato entre al pool de DHCP, que se elimine limegreen y que los martes valgan 5 dólares; y eso es la mitad de la diversión
No estoy de acuerdo con la idea de que este enfoque sea completamente incompatible con la programación orientada a objetos. He usado este enfoque incluso con Active Record de Ruby, y funcionó bien incluso en ámbitos a los que normalmente no se les asocia la palabra “alto rendimiento”. Encajó especialmente bien porque el sistema de objetos de Ruby está más cerca de Smalltalk que de C++/Java, y por eso favorece mucho más la composición que la herencia
En los lenguajes orientados a objetos, normalmente te enfocas en un “objeto sobre el que quieres pensar” —como un usuario, una entrada de blog o una transacción monetaria—, lo implementas separado del resto y luego ocultas los datos mientras decides qué métodos exponer al resto del sistema. La idea de la encapsulación es muy fuerte
En el diseño orientado a datos, es más común que los datos de distintos dominios estén accesibles y que cada subsistema tome lo que necesita para hacer su trabajo. Java o Ruby no lo impiden, pero para el programador sí existe una barrera psicológica clara
También habla del soporte de software que permite acceder a SoA como si fuera AoS, como los data frames de R, Pandas de Python y DataFrames.jl de Julia
Me gusta muchísimo Snowflake y creo que le va a quitar el almuerzo a los demás competidores. También es interesante que Snowflake “soporte” claves foráneas sin forzarlas. En otras palabras, Snowflake es todo el “NoSQL” que estoy dispuesto a tolerar
El otro es renunciar a la encapsulación, separar los datos de los métodos que los manipulan y pensar en toda la app según cómo fluyen los datos, para modelarla de una forma que sea fácil de entender y cambiar. Si se quiere más rigor, se pueden usar estructuras de datos inmutables y funciones puras
Para quien tenga curiosidad, aquí va una introducción muy breve a ECS: https://dev.to/ovid/the-unknown-design-pattern-1l64
"¿La disposición de los datos está definida por una única interpretación surgida desde una sola perspectiva?" puede ser la pregunta más importante al momento de elegir tecnología y arquitectura. Normalmente, para responderla hay que hablar con el negocio y con los clientes
Si tienes la certeza de que existe exactamente una sola "vista" válida de los datos para usar en todo el sistema, entonces tiene sentido plasmar eso en el código. Si no tienes aunque sea una mínima certeza, es muy probable que un modelo de estilo relacional encaje mejor. Muchas empresas, cuando se dan cuenta de la teoría de juegos de este problema, al final terminan en SQL
Todos se preguntan por qué parece que todos se alejaron de una sola gran base de datos SQL. Existen casos límite de "escala web" que amenazan la escalabilidad vertical de las escrituras, pero creo que la mayoría de las empresas, incluidas las Fortune 100, ni siquiera llegan a eso
No tenía nada que ver con la mejor forma de modelar cierto conjunto de datos ni con el mejor rendimiento; se debía por completo al historial de caídas provocadas por la flexibilidad del esquema y por fallas en migraciones de esquema. En diseños NoSQL ese problema no aparecía, y las ventajas de las bases de datos SQL no compensaban la gran ventaja de NoSQL de no tener esquemas rígidos
Claro, si usas mal un almacén clave-valor, el rendimiento y el costo pueden salir muy mal. En plataformas cloud como DynamoDB, he visto muchos casos donde los datos quedaron mal estructurados, se hacían montones de escaneos y los costos se disparaban
Como es una empresa grande y antigua, muchas veces quedan endurecidas soluciones técnicas creadas en el pasado por personal no técnico y hay que seguir manteniéndolas. Existe una transformación de datos SQL en 5 etapas que empieza en la base de datos operativa y continúa hacia modelos de datos de distintas generaciones cada vez que cambia el tipo de negocio
A medida que se apilan capas, se sigue construyendo sobre las anteriores. Si una aplicación hecha hace 10 años sobre la capa de abstracción 2 ahora necesita datos de la capa 4, se hace un script para devolver esos datos a las capas anteriores y se sigue adelante. Al final terminó siendo una masa enorme de tablas y vistas interdependientes que leen datos de maneras extrañas y poco intuitivas, y se decidió que un proyecto para ordenar eso sería demasiado caro, así que se pospuso hasta la década de 2030
Entiendo que la gente vea este problema y piense cómo podría haberse evitado. Pero, por alguna razón, parece imposible aplicar formas que requieran disciplina a los ingenieros de software, así que hay que impedir de algún modo que puedan producir espagueti. Ahí es donde entra la separación. Si no puedes leer los datos de otro servicio, no puedes crear espagueti que frene la velocidad de ambos lados
La separación vertical de aplicaciones se convierte en una solución de software a un problema humano: la pobre disciplina de ingeniería en las empresas
Hace poco publiqué un framework open source basado por completo en diseño orientado a datos, y mucha gente reaccionó diciendo que este enfoque les quedaba perfecto. De verdad hay muchas cosas que se vuelven más fáciles cuando todos los datos están en un solo lugar
https://sql.ophir.dev
En una DB enorme había mucho residuo que nadie usaba y ni siquiera sabía por qué estaba ahí, pero tampoco tenía claro si todavía hacía falta, y se necesitaban estrategias de optimización distintas para lectura y escritura
Además, para que los equipos pudieran moverse rápido, tenían que asumir la propiedad de sus bases de datos y almacenes de datos sin esperar a que un DBA respondiera un ticket
Cuando trabajaba en una empresa grande y antigua, la mayoría de los problemas eran políticos y administrativos. Una sola gran base de datos SQL es eficiente, pero el problema aparece en el momento en que la organización dueña de ella no está de acuerdo con una nueva estrategia del CTO o con otra unidad clave del negocio
Si a eso le sumas una caída que demuestra la baja resiliencia de este modelo, rápidamente se convierte en un dolor de cabeza político, y aunque las soluciones técnicas sigan pareciendo obvias para todos, impulsarlas se vuelve difícil
Todo este consejo es dependiente del contexto
En los juegos simplemente hay muchas operaciones que requieren un enfoque orientado a columnas, y no todos los dominios son así. Empujar a ciegas las mejores prácticas del mundo de los juegos a otros dominios solo hace la vida más difícil para todos y empeora la mayoría de los sistemas
Los campos booleanos de una estructura pueden convertirse en bitsets, los campos anulables pueden convertirse en mapas dispersos o densos, y los campos de punteros o referencias pueden pasar a ser arreglos de enteros de menor ancho que indexan pools
En entornos donde la CPU se detiene con frecuencia por accesos a memoria, no se puede subestimar el impacto de estos cambios. La diferencia de latencia entre caché L3 y RAM puede ser de alrededor de 10x
Si es un programa donde el rendimiento importa aunque sea un poco, es muy probable que esta sea una de las formas de garantizar buen rendimiento
Lo único que se espera que siga escalando en hardware moderno es la densidad lógica. SRAM y el tamaño de caché ya no escalan bien con la litografía moderna, y el ancho de banda de RAM tampoco ha aumentado mucho desde hace bastante tiempo. Incluso creo que el ancho de banda por núcleo puede haber disminuido. El acceso a memoria ha sido un cuello de botella desde hace tiempo
El diseño orientado a datos es muy razonable dentro de ciertos subsistemas, pero en código de gameplay de alto nivel no necesariamente lo es, salvo en ciertos géneros
Creo que la charla de Mike Acton en CppCon 2014, Data-Oriented Design and C++, es la mejor presentación de programación que se ha hecho hasta ahora. De verdad vale la pena verla: https://youtu.be/rX0ItVEVjHc
Antes también lideró Unity DOTS, pero tristemente ahora Unity parece estar tambaleándose. El trabajo de DOTS en sí, aunque incompleto, es sólido
Pasé la mayor parte de mi carrera escribiendo aplicaciones web, y fue esta charla la que me hizo entender “por qué alguien usaría C”
Andrew Kelley dio una charla útil y entretenida explicando cómo el diseño orientado a datos influyó en su trabajo en el compilador Zig: https://vimeo.com/649009599
Incluso un principiante puede aprender a programar con un enfoque orientado a datos desde el principio
Algunos libros para enseñar este estilo a principiantes son How to Design Programs y A Data-Centric Introduction to Computing
https://htdp.org/
https://dcic-world.org/
Encontré una reseña en línea del libro: https://gist.github.com/seece/25ed1b2108cf5782718b026382f2c5...
“El principal culpable que atormentó y retrasó a muchos proyectos fue la insistencia en que no se debe optimizar prematuramente. La razón por la que la optimización en etapas tardías es tan difícil es que gran parte del software se construye poniendo instancias de objetos por todas partes, incluso cuando no son necesarias.”
Claramente hay aplicaciones donde el rendimiento es la prioridad máxima, y otras donde no lo es. Esto me hace pensar si, en apps donde el rendimiento importa, la optimización temprana también puede estar bien. Me pregunto si esta es una lectura correcta
También existe Data-Oriented Programming: https://www.manning.com/books/data-oriented-programming
Me pregunto si estos dos conceptos son lo mismo
El diseño orientado a datos es amigable para principiantes. Porque trata solo de la pureza del modelado de datos, en lugar de lidiar con personas y negocios
Cuando era joven, el primer paso de un proyecto nuevo era dibujar un modelo entidad-relación, y eso se convertía en la base de todo
Hoy en día, antes de empezar con el modelo de datos, primero intento entender el problema y el dominio, y pensar en las capacidades, en cómo agruparlas y dónde poner sus límites
Aun así, creo que este texto intenta decir que, si te concentras desde el principio en reunir los requisitos de datos, quizá haga menos falta discutir los requisitos del negocio en sí
Al usar DoD, una de las ideas clave es no esconder los datos detrás de abstracciones. Va más por la línea de que menos es mejor
Pero al leer rápidamente el texto introductorio, sentí más bien lo contrario. Habla demasiado y termina abstrayendo las ideas centrales. Me pareció irónico, como si no bebiera su propio vino; me pregunto si fui el único en sentirlo
El párrafo de apertura es bastante bueno. La prosa fluye muy bien y las ideas son interesantes, así que da ganas de seguir leyendo
“Los datos son todo lo que tenemos. Los datos son aquello que debemos transformar para crear la experiencia del usuario. Lo que cargamos al abrir un documento también son datos. Los gráficos en pantalla, el pulso de un botón del gamepad, la causa de que el altavoz produzca ondas en el aire, la forma en que subes de nivel y el modo en que un enemigo detecta tu posición para dispararte también son datos. El tiempo que tarda en explotar una carga de dinamita y la cantidad de anillos que pierdes al caer sobre púas también son datos. La posición y velocidad actuales de cada partícula en la hermosa escena con la que terminaste el juego, y aquello que fue leído desde el disco y entró en tu vida, son el resultado de transformaciones de la máquina impulsadas por el código fuente que diste al compilador, las instrucciones que indicó el ensamblador y las instrucciones decodificadas.”
Puede ser útil como una especie de “ducha de agua fría” que te ayude a salir del modo de pensar en abstracciones orientadas a objetos. Pero fuera de eso, me parece tan útil como un ingeniero diciendo “¡Mira a tu alrededor! ¡Todo está hecho de átomos! ¡La ingeniería consiste, en el fondo, en mover átomos!”
No es falso, pero en la práctica no ayuda mucho a hacer ingeniería