Diría que depende mucho del tipo de datos que la aplicación web almacenará en la base de datos, y del tipo de procesamiento realizado por la aplicación .
La elección también debe considerar los requisitos de rendimiento (rendimiento y escalabilidad) del sistema , pero al hacer una elección impulsada únicamente por algo como “X ofrece un rendimiento superior”, puede perderse una imagen de nivel superior y, de hecho, requisitos que son críticos para El éxito de los negocios.
- Por ejemplo, si está escribiendo una aplicación bancaria (digamos que el banco ‘XXX’ ha subcontratado el desarrollo de su portal en línea que proporcionará funciones de banca en línea a sus clientes habituales).
- Dicha aplicación será una típica aplicación OLTP (procesamiento de transacciones en línea) donde el sistema web ejecutará internamente transacciones para proporcionar transferencias de dinero y otros tipos de cosas.
- Es extremadamente importante que la base de datos garantice las propiedades transaccionales (ACID) en las operaciones ejecutadas por el sistema en los datos del usuario. Propiedades como la recuperación de datos también son igualmente importantes.
- Los datos serán principalmente información de la cuenta del cliente, información personal del cliente, información de la transacción, etc. Estos son ejemplos bien conocidos de datos de datos relacionales (datos estructurados) que se pueden organizar en varias filas con diferentes atributos como columnas.
- Del mismo modo, cada tipo de entidad (como transacción, cliente, cuenta) se puede almacenar como una tabla separada, y se puede crear una relación padre-hijo entre las tablas , las restricciones (como FOREIGN KEY, UNIQUE KEY) se pueden aplicar fácilmente. El usuario puede ejecutar consultas basadas en claves y no basadas en claves.
- Dichas aplicaciones OLTP se escribirán utilizando el conocido lenguaje SQL estándar de la industria para acceder y manipular datos.
- Las bases de datos adecuadas en tal caso serán las bases de datos relacionales. Más específicamente, las principales bases de datos de filas (como Oracle, SQLServer, MySQL) serán los almacenes de datos ideales para dicha aplicación. La razón para decir “fila principal” es la naturaleza OLTP de la aplicación, es decir, habrá menos cargas de trabajo analítico que se beneficien de la organización principal de datos de la columna, ya que el interés está en los datos de una columna en todas las filas.
- Obviamente, estos requisitos deben cumplirse con un rendimiento óptimo, pero es probable que estas bases de datos relacionales no ofrezcan el mejor rendimiento cuando se comparan con otras soluciones no relacionales que existen, ya que las bases de datos relacionales ofrecen garantías y semánticas bastante sólidas : (1) Una vez los datos están comprometidos, la base de datos se asegura de que sea duradera. (2) Una vez que transfiera dinero de su cuenta a otra cuenta, una consulta posterior reflejará el débito, y el destinatario definitivamente debería ver el crédito. Y muchos más como estos.
- Tales garantías sólidas generalmente tendrán el costo de una alta latencia de operación, una capacidad de escalado limitada, etc. Esta es la razón por la cual, al comienzo de la respuesta, mencioné que no debe estar completamente impulsado por el rendimiento y la escalabilidad al seleccionar la base de datos ya que no es relacional Es muy probable que las bases de datos (también conocidas como NoSQL) superen a las bases de datos relacionales tradicionales en estas áreas.
- Es la estructura de sus datos (relacionales, bien estructurados y orientados a esquemas) y los requisitos de aplicación (garantías transaccionales, recuperación, etc.) lo que debe impulsar la decisión a favor de las bases de datos relacionales.
- No quiere decir que las bases de datos relacionales no sean eficientes. Pero el rendimiento no puede simplemente salir de la caja. DBA tiene que hacer esfuerzos conscientes al usar la configuración correcta (almacenamiento, almacenamiento en caché, etc.) para optimizar el rendimiento de RDBMS.
- Por otro lado, las bases de datos no relacionales (también conocidas como bases de datos NoSQL, según tengo entendido) son diferentes de las bases de datos relacionales en el tipo de modelo de datos que admiten y las garantías que brindan.
- Si sus datos son desestructurados o semiestructurados (documentos XML, tweets de usuario, mensajes de usuario, elementos de valor clave, etc.), entonces la base de datos relacional puede no ser la opción correcta. Las bases de datos NoSQL ofrecen una variedad de soluciones en este caso, y la mayor propiedad común entre estas bases de datos es la semántica relajada en lo que respecta a las propiedades transaccionales.
- La atención se centra más en la baja latencia de operación, la escala masiva a cientos (incluso miles) de nodos, la replicación de datos en múltiples nodos para una mayor tolerancia a fallas y disponibilidad. Dichas propiedades se proporcionan haciendo algunas grandes compensaciones arquitectónicas a favor del rendimiento.
- El mayor requisito de una buena aplicación candidata para una solución NoSQL / no relacional es un almacén de datos de alta velocidad que no necesariamente admite transacciones, y es capaz de manejar petabytes de datos (y aún escalar si es necesario), ingesta de datos de alta velocidad etc.
- Por lo tanto, el rendimiento (específicamente la escalabilidad y el rendimiento) y la disponibilidad con la replicación de datos en múltiples zonas de disponibilidad , los centros de datos son las principales áreas de enfoque de dichas bases de datos.
- Las bases de datos como DynamoDB, Cassandra son buenos ejemplos de bases de datos no relacionales . No es que no implementen conceptos de bases de datos como tablas, clave primaria, índices, particiones, etc. Algunos / Todos estos conceptos se implementan más o menos de una manera diferente, pero en realidad no brindan soporte completo para las transacciones ( que es el núcleo de las bases de datos relacionales heredadas).
- Del mismo modo, pueden no ser adecuados para el procesamiento de consultas complejas que implica uniones en varias tablas diferentes. Hasta donde sé, Cassandra solo admite consultas basadas en la clave primaria y tiene su propio lenguaje de consulta CQL.
- Por ejemplo, uno de los buenos casos de uso para Cassandra serían las aplicaciones de estilo IoT que necesitan ingerir una gran cantidad de puntos de datos de sensores, dispositivos (esto se usa mucho en las carreras de F1) a muy baja latencia. No importa incluso si se pierden algunos puntos de datos. Pero sí, la ingestión y el análisis tienen que suceder rápidamente. Cassandra es una base de datos orientada a columnas y también admite operaciones analíticas rápidas.
Al final, llega a su comprensión de los requisitos y el modelo de datos para la aplicación. En consecuencia, se puede elegir una base de datos adecuada.
- ¿Cuáles son los mejores marcos que debo consultar para mi aplicación web?
- ¿Me aconsejaría utilizar material angular como marco de diseño y es similar a Bootstrap?
- ¿Cómo agrego imágenes aleatorias en una página web sin o con la ayuda de Backstretch en jQuery?
- Si le gusta alguna aplicación web o móvil y desea crear un producto muy similar, ¿habrá algún problema legal?
- ¿Cuál es la diferencia entre ingeniería web y tecnología web?
También puede consultar mi respuesta a una pregunta similar: ¿cuándo debe usar una base de datos no relacional frente a una base de datos relacional?
