Estoy relativamente recién salido de la universidad, por lo que la mayor parte de mi familiaridad con las bases de datos relacionales proviene de mi curso de bases de datos, donde cualquier cosa que no esté en BCNF o 3NF es una parodia. Ciertamente, ese es un extremo del extremo, pero mi equipo en el trabajo realmente parece llevarlo al extremo opuesto.
En nuestros esquemas de microservicio db, las entidades rara vez tienen más de una tabla. Todo lo que normalmente normalizaría en otra tabla se almacena en una columna json. Si luego se descubre que es necesario consultar una de las propiedades de este json, se agrega una nueva columna y los datos se almacenan en ambos lugares (sí, en dos columnas diferentes en la misma tabla).
En muchos casos, estas columnas json definitivamente tienen una ventaja. Si nunca necesita consultar esos datos y si nunca tiene que hacer un cambio unilateral a esos datos (que es algo que obviamente no puede predecir), no es una mala idea. Además, muchos de nuestros servicios no ven el servidor o están alojados en máquinas con una cantidad obscena de espacio en disco para lo que necesitan, por lo que la duplicación de datos no es un gran problema. (Aunque es algo que generalmente me gustaría evitar por filosofía)
Actualmente estamos creando un servicio que coincide con las reglas en función de un conjunto de condiciones que poseen y luego realiza un conjunto de acciones asociadas con esas reglas cuando las reglas son verdaderas (por ejemplo, todas las condiciones son verdaderas). Mi sub equipo que está construyendo este servicio de manera más inmediata cree que hay un beneficio sustancial en la normalización de acciones y condiciones fuera de las reglas del esquema. Obviamente, esta tabla mantiene relaciones de clave externa con el ID de la regla. Desde nuestra perspectiva, podemos evitar la duplicación de datos en condiciones que nos permiten asegurarnos de que solo se evalúen una vez y es fácil encontrar las condiciones y reglas que necesitamos cuando las necesitamos sin necesidad de extraer cada regla y realizar la búsqueda en la memoria.
Al hablar hoy con uno de nuestros ingenieros principales, intentó alejarme de este esquema. Intentar argumentar de todas las formas que realmente no lo necesitamos va a causar problemas de rendimiento en el futuro, haciendo referencia a un viejo monolito que poseemos que es una parodia del diseño. Se refirió a lo que estamos haciendo como "la vieja forma" y las mesas planas con json como "la nueva forma". Argumentó que en lugares donde quiero atomicidad no la necesitamos y que en lugar de consultas deberíamos hacer más cosas en la memoria. Este es un principio de diseño que muchos de nuestros servicios siguen ahora. No anticipamos que el volumen de nuestros datos crecerá sustancialmente, lo que debería mantener nuestras consultas rápidas. Lo que anticipamos es mucho tiempo dedicado a la evaluación de reglas y a la realización de acciones.
Entiendo que las bases de datos no relacionales se han vuelto más populares en los últimos años, pero incluso cuando busco activamente información sobre las implicaciones de rendimiento de las relaciones de claves externas, no veo mucha información que haga su caso. Supongo que podrían tender a introducir grandes transacciones que pueden causar problemas, pero eso parece un problema independiente de la clave externa en sí.
¿Es esta mi ingenuidad? ¿O es esto realmente algo que yo y mi sub-equipo nos falta? No he dado explícitamente información detallada sobre nuestro problema porque no estoy necesariamente buscando una solución para eso. Dado que es una tendencia común en nuestro equipo más grande, tengo mucha curiosidad si tienen algo con esto.
fuente
Respuestas:
La palabra clave aquí para entender de dónde viene su equipo es "microservicios". Merecería la pena leer sobre ese concepto primero, particularmente para la siguiente información:
Como con cualquier forma relativamente nueva de hacer las cosas (y 5-10 años es relativamente nueva cuando se trata de arquitectura de software), encontrará que los ideales y la realidad son un poco diferentes.
Uno de los ideales es que cada microservicio debería tener su propio almacén de datos. NOTA: dije almacenamiento de datos, no base de datos. Hay casos en los que simplemente desea un motor de búsqueda, almacenamiento de blobs o almacenamiento en caché simple en lugar de una base de datos normal. Dependiendo de con quién hable, ¡ese ideal podría incluso ir a un almacén de datos por instancia de microservicio!
La conclusión es que cuando habla de ir a la escala de Internet, la seguridad y la familiaridad de las transacciones ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad) simplemente no se escalan cuando tiene millones de usuarios en una base de datos. Con el advenimiento de NoSQL, el paradigma se ha desplazado más hacia BASE (Básicamente disponible, estado suave, consistencia eventual). ( referencia )
Hay un impacto al cambiar el PH de cómo administra los datos:
No puedo responder por los detalles de su equipo o qué tan grandes pretenden que sea la solución, pero generalmente no tiene que tener una solución de todo o nada. No me voy a sentar aquí y juzgar si el equipo está tomando las decisiones correctas. Solo te estoy proporcionando un poco de contexto para que al menos puedas entender de dónde vienen.
fuente
OK, no siendo el ingeniero principal en el proyecto, realmente tienes que seguir sus instrucciones para este proyecto.
Le animo a que trabaje a través de su propio diseño del sistema y prototipo de que está en casa para que entienda cualquier compensación. Haga esto para su propia educación y solo menciónelo en el trabajo cuando pueda demostrar ejemplos de trabajo.
Mi experiencia ha sido que existe una afirmación de que las restricciones causan una desaceleración en el rendimiento de la base de datos. Y sí, tendrá que verificar esas restricciones. Sin embargo, es un problema mucho mayor cuando la base de datos es inconsistente y esto hará que escriba SQL y más código para compensar, a menudo aumentando la complejidad del sistema y ralentizándolo.
3nf, cuando se hace de manera adecuada, hará que la base de datos sea más rápida porque se puede almacenar más en caché ya que se almacenan menos datos redundantes. Sin embargo, en su trabajo actual, es posible que no haya un conjunto de datos lo suficientemente grande como para ver realmente la diferencia de rendimiento entre una base de datos normalizada y una no normalizada.
fuente
Creo que tienen miedo de volver a crear la misma "parodia" que había antes, en lugar de la integridad referencial misma.
Si puede hacer un caso sólido (también conocido como Requisito no funcional) para necesitar atomicidad, entonces necesitarán un contraargumento sólido y bueno para evitar proporcionarlo.
Esperemos que tengas razón. Sugeriría que confiar en que los datos se mantengan "lo suficientemente pequeños" para seguir siendo productivos es arriesgado.
Además, ¿cuál es la tasa de cambio en estas Reglas? Cuanta más duplicación tenga, más tiempo (también conocido como dinero) perderá actualizando lo mismo en varios lugares.
fuente
Los conceptos clave detrás de los RDBMS tienen más de 40 años. En aquel entonces, el almacenamiento era muy costoso y cualquier tipo de redundancia estaba mal visto. Si bien los conceptos detrás de los RDBMS aún son sólidos, la idea de la desnormalización para el rendimiento (para reducir las uniones) se ha aceptado comúnmente en las últimas décadas.
Entonces, para un RDBMS de un tamaño determinado, normalmente tiene su diseño lógico (sin redundancia) y su diseño físico (con redundancia) para el rendimiento.
Avancemos rápidamente hasta hoy, donde el almacenamiento es barato y los procesadores son más rápidos que nunca, algunas de esas presiones de diseño no son tan importantes. En última instancia, es una cuestión de juicio si se preocupa por la redundancia y los registros huérfanos. Para algunas industrias como la banca, la corrección de datos es vital, por lo que es difícil ver cómo alguna vez se alejarán de los RDBMS. Para otras industrias, los nuevos jugadores ingresan al mercado todo el tiempo, por lo que las opciones son innumerables.
En cuanto a si su equipo está incómodo con las restricciones que puede traer un RDBMS, ¿quién sabe? Ciertamente, los desarrolladores junior que veo no tienen el nombre RDBMS que tenían los desarrolladores de generaciones anteriores, pero esto probablemente tenga más que ver con la proliferación de tecnologías de desarrolladores y plataformas de bases de datos.
Un desarrollador puede aprender un sinfín de tecnologías y puede ser difícil hacer la patada correcta para su carrera. Ciertamente, los días en que los desarrolladores eran un factor decisivo para todos los oficios han quedado atrás: hay demasiado que uno puede aprender.
Pero, a la pregunta en mano. Por su propia admisión, no espera que los volúmenes de datos crezcan y el sistema esté funcionando bien. Sería bastante difícil para usted vender la idea de reingeniería de cosas sin ningún beneficio perceptible. Tal vez si se pudiera hacer una prueba de concepto que un enfoque RDBMS se cosechan beneficios, que sería una historia diferente.
fuente
Depende de qué base de datos estés usando.
En un RDBMS tradicional, tienes razón. La duplicación de datos es una abominación. Las columnas y su equivalencia json inevitablemente se desincronizarán porque no hay nada que lo obligue. El soporte de claves externas es bien conocido, hace un gran trabajo al describir y hacer cumplir las relaciones. Y la atomicidad es vital para hacer casi cualquier cosa con datos.
En un tipo de configuración nosql, es menos claro. Como no hay relaciones firmes, la aplicación de las relaciones se vuelve menos importante. Ese tipo de contenido json con índice de columna es mucho más común en estos sistemas porque ninguna relación significa que es menos probable que se desincronice. Y la atomicidad se limita a la tabla única porque así es como funciona nosql.
Lo que es mejor depende de lo que realmente está haciendo y de lo que realmente necesita.
Pero parece que tus compañeros de trabajo están en una secta de carga. Fueron mordidos por viejas cosas malas, por lo que ahora las cosas deben ser lo nuevo y brillante. En unos pocos años, una vez que hayan sido mordidos por la nueva cosa brillante, se darán cuenta de que SQL vs noSQL es un conjunto de compensaciones.
Pero no lo harán. Aunque espero que lo hagas.
fuente