Las organizaciones que desean aprovechar las numerosas ventajas de las bases de datos documentales NoSQL, a menudo se encuentran con dos retos:
- Cómo convertir sus esquemas RDBMS para aprovechar el modelo de documento sin esquema.
- Aprender una nueva API/Query para acceder a los datos.
Algunos también encuentran la confusión con el nombre NoSQL. La abreviatura significa 'No sólo SQL', pero también puede malinterpretarse como 'No al SQL', aceptando así que para utilizar un Base de datos NoSQLPor lo tanto, las organizaciones no sólo tendrán que convertir su modelo de datos relacional en el modelo documental, sino también formarse en las API de la base de datos NoSQL que elijan.
En realidad, la industria de las bases de datos NoSQL nunca ha abandonado el acceso a datos más popular para las bases de datos. Muchos proveedores de NoSQL siguen utilizando una variación de SQL. Cosmos DB, Cassandra CQL, Elasticsearch SQL, Laboratorios Cucaracha. Incluso con Consulta en Mongodb encontrará que se basa en la construcción select-join-project, que es la base del álgebra relacional que se utiliza en SQL.
Una empresa de bases de datos del espacio NoSQL que ha abordado de lleno esta cuestión del lenguaje de consulta es Couchbase. Mientras que Couchbase almacena los datos en el formato nativo JSON, el modelo de datos que soporta puede ser relacional o de estructura jerárquica, que a menudo se utiliza en el modelo basado en documentos por su flexibilidad de esquema y extensibilidad. Esto es posible porque Couchbase proporciona un SQL-N1QL, que amplía el lenguaje SQL para permitir a los usuarios manipular la naturaleza jerárquica del modelo documental. Todo ello se basa en el servicio de datos de alto rendimiento Couchbase con sus API de clave-valor.
Las organizaciones que desean asegurarse de que sus inversiones en bases de datos aprovechan las ventajas que ofrecen actualmente las Tecnología NoSQL debe tener en cuenta:
- Soporte de datos estructurados y no estructurados
- Escalabilidad horizontal
- Evolución de esquemas fácil de gestionar
- Quizá la más importante de todas sea la posibilidad de elegir proveedor, más allá de los actuales proveedores de RDBMS que han dominado el mercado de bases de datos durante las tres últimas décadas.
Para ayudar a los clientes en su decisión, Altoros -una empresa que se centra en ayudar a las empresas a pasar de su sistema informático heredado al futuro- ha publicado un informe para comparar el lenguaje de consulta en las bases de datos más populares de la actualidad. Se ha optado por centrarse en MySQL/SQL, Couchbase N1QLy Consulta MongoDB lenguajes. Se evaluaron las implementaciones de cada lenguaje de consulta para responder a los distintos escenarios de consulta utilizando las siguientes métricas.
- Simplicidad
- Legibilidad
- Expresividad
- Flexibilidad
- Disponibilidad de competencias
- Línea de códigos
- Número de viajes de la aplicación al servidor
Puede obtener más detalles de este informe en el Página web de Altorosy también está disponible aquí lo que hay en la columna "Nuevo".
Todos los ejemplos de lenguaje NoSQL de consultas y volcados de bases de datos que pueden ayudar a desplegar y ejecutar todos los escenarios de este informe se pueden encontrar en este repositorio de GitHub.
Metodología del informe Altoros
El objetivo del informe es comparar los lenguajes de consulta desde la perspectiva de las aplicaciones RDBMS tradicionales. Para ello se han seleccionado:
Un modo de aplicación de Gestión de Actividades, que se encuentra a menudo en muchos de los sistemas CRM que gestionan las actividades de Ventas, Servicios y Marketing. La configuración del informe incluye tanto el modelo relacional como el modelo documental que utilizan Couchbase y MongoDB
También utiliza un conjunto de escenarios de consulta que la mayoría de los usuarios de estos sistemas reconocerían.
| Escenario | Descripción |
| 1. Informe de la reunión de clientes | Para preparar las reuniones con clientes a las que asistiré la semana que viene, quiero obtener una lista de todos los clientes que asistirán a las reuniones y sus contactos. |
| 2. Informe sobre el territorio de ventas regional | Soy Director Regional de Ventas para el territorio de Vendedores de la C-Suite. Quiero obtener todas las cuentas asignadas a este territorio y los miembros del equipo de cuentas. |
| 3. Las 10 principales industrias de los clientes | Determinar las 10 principales industrias de nuestros clientes en función de las actividades de ventas de 2018. |
| 4. Organizaciones de ventas | Quiero saber cuánto tiempo dedicamos a hablar con las cuentas asignadas a mi territorio en el tercer trimestre del año fiscal 19. |
| 5. Un informe de actividad de ventas | Cómo ha cambiado el número de tareas relacionadas con las ventas mes a mes durante el año 2018. |
| 6. Un equipo de ventas Competencias | Un análisis de las competencias y funciones del equipo de ventas en la organización de ventas actual. |
| 7. Informe de interacciones con los clientes | Una consulta para revisar todas las presentaciones que hemos realizado con los clientes en CY19Q4 con métricas detalladas sobre el tiempo dedicado a cada cliente y la eficacia de la reunión. |
| 8. Analizar el sentimiento de las reseñas de hoteles | Llamada a la API de lenguaje natural de Google para ordenar todas las opiniones en función de la puntuación de sentimiento |
| 9. Un informe de búsqueda de texto para identificar reuniones de clientes | Identificar las cuentas de clientes y sus contactos relacionados, en las que se ha tratado un tema concreto. Los criterios de búsqueda pueden incluir la siguiente información de forma parcial o completa: un título de reunión, un intervalo de fechas de reunión, datos de contacto del cliente, datos de los miembros del equipo de ventas (participantes) y un nombre de cliente. |
Para cada escenario, el informe proporciona las soluciones correspondientes escritas en lenguaje de consulta SQL, N1QL y MongoDB.
- El informe proporciona una clasificación para cada lenguaje de consulta basada en los siguientes criterios.
- Simplicidad
- Legibilidad
- Expresividad
- Flexibilidad
- Disponibilidad de competencias
- El informe también tabula dos métricas adicionales para el número de líneas de código, y el número de viajes cliente-servidor requeridos por cada lenguaje de consulta en cada solución de los nueve escenarios.
Resultados de los criterios de evaluación
La tabla siguiente es un resumen de todas las valoraciones para todos los escenarios de consulta. Consulte en el informe la valoración individual de cada uno de los escenarios de consulta.
Utilizando MySQL-SQL como punto de referencia, el informe evalúa Couchbase N1QL y MongoDB Query Language en función de una serie de criterios.
Notas:
- Altoros que ha trabajado con MongoDB, Cassandra, RedisLab ha encontrado que N1QL es muy similar a SQL, y le ha dado consistentemente una calificación más favorable que la del lenguaje de consulta MongoDB.
- El código de ejemplo del escenario #3 muestra que los tres lenguajes de consulta son relativamente similares para los escenarios de consulta simple, y tienen puntuaciones similares en los criterios de evaluación.
El número de líneas de código
El gráfico muestra el número de líneas de código de cada consulta. Aunque esta métrica puede estar sujeta a tergiversaciones, ya que todos los lenguajes de consulta tienen su propio formato recomendado, puede proporcionar una guía sencilla sobre la complejidad que entraña.
Notas:
- El lenguaje de consulta NoSQL N1QL tiene aproximadamente el mismo número de líneas de código que SQL.
- El lenguaje de consulta de MongoDB tiene sistemáticamente más líneas de código.
- Para el escenario #7, el equipo de Altoros tuvo que escribir 347 líneas para el lenguaje de consulta MongoDB, en comparación con las 21 líneas de N1QL. Este valor atípico refleja las limitaciones del lenguaje de consulta de MongoDB para calcular agregaciones complejas y expresiones de tabla comunes (CTE) que SQL, y ahora N1QL, han sido siempre los puntos fuertes de la tecnología de bases de datos relacionales en las últimas décadas.
Número de viajes cliente-servidor
El gráfico muestra el número de viajes que la aplicación tiene que enviar al servidor de la base de datos.
Notas:
- Para la mayoría de los escenarios, SQL/N1QL sólo requiere un único envío de consulta al servidor, mientras que la consulta MongoDB requiere múltiples viajes. Esto se debe a la expresividad de SQL/N1QL, donde los desarrolladores de aplicaciones simplemente tienen que declarar la salida deseada, y depende del servidor procesar y devolver los resultados.
- La falta de soporte de agregación compleja requiere que MongoDB realice su cálculo en múltiples fases. Esto es similar al enfoque estándar de subconsultas SQL. La diferencia aquí es que los conjuntos de resultados de la subconsulta deben mantenerse en las aplicaciones cliente, que posteriormente se pasan a otra consulta.
Principales conclusiones del informe
