database - tutorial - mongodb ventajas y desventajas
¿Qué es NoSQL, cómo funciona y qué beneficios proporciona? (9)
He estado escuchando cosas sobre NoSQL y que eventualmente podría convertirse en el reemplazo de los métodos de almacenamiento SQL DB debido al hecho de que la interacción DB es a menudo un cuello de botella para la velocidad en la web.
Así que solo tengo algunas preguntas:
¿Qué es exactamente?
¿Como funciona?
¿Por qué sería mejor que usar una base de datos SQL? ¿Y cuánto mejor es?
¿La tecnología es demasiado nueva para comenzar a implementarla o merece la pena echarle un vistazo?
¿NoSQL significa una base de datos no relacional?
Sí, NoSQL es diferente de RDBMS y OLAP. Utiliza modelos de coherencia más flexibles que las bases de datos relacionales tradicionales.
Los modelos de consistencia se usan en sistemas distribuidos como sistemas de memoria compartida distribuida o almacén de datos distribuidos.
¿Cómo funciona internamente?
Los sistemas de bases de datos NoSQL a menudo están altamente optimizados para operaciones de recuperación y adición y a menudo ofrecen poca funcionalidad más allá del almacenamiento de registros (por ejemplo, tiendas de valores clave). La flexibilidad reducida en tiempo de ejecución en comparación con los sistemas completos de SQL se compensa con ganancias marcadas en escalabilidad y rendimiento para ciertos modelos de datos.
Puede trabajar en datos estructurados y no estructurados. Utiliza colecciones en lugar de tablas
¿Cómo consulta esa "base de datos"?
Mire SQL vs NoSQL: Battle of the Backends ; lo explica todo.
¡No existe tal cosa como NoSQL!
NoSQL es una palabra de moda.
Durante décadas, cuando las personas hablaban de bases de datos, se referían a bases de datos relacionales. Y cuando las personas hablaban sobre bases de datos relacionales, se referían a las que controlas con Structured Query Language de Edgar F. Codd. ¿Almacenar datos de alguna otra manera? ¡Locura! Cualquier otra cosa es solo un archivo plano.
Pero en los últimos años, la gente comenzó a cuestionar este dogma. La gente se preguntaba si las tablas con filas y columnas son realmente la única forma de representar datos. La gente comenzó a pensar y codificar, y se le ocurrieron muchos conceptos nuevos sobre cómo organizar los datos. Y comenzaron a crear nuevos sistemas de bases de datos diseñados para estas nuevas formas de trabajar con datos.
Las filosofías de todas estas bases de datos eran diferentes. Pero una cosa que todas estas bases de datos tenían en común, era que el Lenguaje de Consulta Estructurado ya no era una buena opción para usarlas. Entonces cada base de datos reemplazó SQL con sus propios lenguajes de consulta. Y así nació el término NoSQL, como una etiqueta para todas las tecnologías de bases de datos que desafían el modelo clásico de base de datos relacional.
Entonces, ¿qué tienen las bases de datos NoSQL en común?
En realidad, no mucho.
A menudo oyes frases como:
- ¡NoSQL es escalable!
- ¡NoSQL es para BigData!
- ¡NoSQL viola ACID!
- ¡NoSQL es una tienda de valores / llaves glorificada!
¿Es eso cierto? Bueno, algunas de estas afirmaciones pueden ser ciertas para algunas bases de datos comúnmente llamadas NoSQL, pero cada una de ellas también es falsa para al menos otra. En realidad, lo único que las bases de datos NoSQL tienen en común es que son bases de datos que no usan SQL. Eso es. Lo único que los define es lo que los distingue unos de otros.
Entonces, ¿qué diferencia a las bases de datos NoSQL?
Así que dejamos en claro que todas las bases de datos a las que comúnmente se hace referencia como NoSQL son demasiado diferentes para evaluarlas juntas. Cada uno de ellos debe evaluarse por separado para decidir si son adecuados para resolver un problema específico. Pero, ¿por dónde empezamos? Afortunadamente, las bases de datos NoSQL se pueden agrupar en ciertas categorías, que son adecuadas para diferentes casos de uso:
Orientada a documentos
Ejemplos: MongoDB, CouchDB
Fortalezas: datos heterogéneos, orientados a objetos de trabajo, desarrollo ágil
Su ventaja es que no requieren una estructura de datos coherente. Son útiles cuando sus requisitos y, por lo tanto, su diseño de base de datos cambian constantemente, o cuando se trata de conjuntos de datos que pertenecen juntos pero que aún se ven de manera muy diferente. Cuando tienes muchas tablas con dos columnas llamadas "clave" y "valor", vale la pena investigarlas.
Bases de datos
Ejemplos: Neo4j, GiraffeDB.
Fortalezas: Minería de datos
Si bien la mayoría de las bases de datos NoSQL abandonan el concepto de gestión de las relaciones de datos, estas bases de datos lo aceptan incluso más que las denominadas bases de datos relacionales.
Su objetivo es definir los datos por su relación con otros datos. Cuando tiene muchas tablas con claves primarias que son las claves primarias de otras dos tablas (y tal vez algunos datos que describen la relación entre ellas), estas pueden ser algo para usted.
Tiendas de valor clave
Ejemplos: Redis, Cassandra, MemcacheDB
Fortalezas: búsqueda rápida de valores por claves conocidas
Son muy simplistas, pero eso los hace rápidos y fáciles de usar. Cuando no necesita procedimientos almacenados, restricciones, desencadenadores y todas las características avanzadas de la base de datos y solo desea un almacenamiento y recuperación rápidos de sus datos, entonces esos son para usted.
Lamentablemente, suponen que sabes exactamente lo que estás buscando. ¿Necesitas el perfil de User157641? No hay problema, solo tomará microsegundos. Pero, ¿qué pasa cuando desea los nombres de todos los usuarios que tienen entre 16 y 24 años, tienen "waffles" como su comida favorita y han iniciado sesión en las últimas 24 horas? Mala suerte. Cuando no tiene una clave definida y única para un resultado específico, no puede sacarla fácilmente de su tienda de KV.
¿SQL está obsoleto?
Algunos proponentes de NoSQL afirman que su base de datos NoSQL favorita es la nueva forma de hacer las cosas, y SQL es una cosa del pasado.
¿Están en lo cierto?
No, por supuesto que no. Si bien hay problemas para los que SQL no es adecuado, aún tiene sus puntos fuertes. Muchos de los modelos de datos simplemente se representan mejor como una colección de tablas que se referencian entre sí. Especialmente porque la mayoría de los programadores de bases de datos fueron entrenados durante décadas para pensar en los datos de una manera relacional, y tratar de presionar esta mentalidad sobre una nueva tecnología que no fue creada ya que rara vez termina bien.
Las bases de datos NoSQL no son un reemplazo para SQL, son una alternativa.
La mayoría de los ecosistemas de software alrededor de las diferentes bases de datos NoSQL aún no son tan maduros. Si bien hay avances, todavía no tienes herramientas complementarias que sean tan maduras y potentes como las disponibles para las populares bases de datos SQL.
Además, hay mucho más know-how para SQL alrededor. Generaciones de científicos informáticos han dedicado décadas de sus carreras a la investigación centrada en bases de datos relacionales, y muestra: la literatura escrita sobre bases de datos SQL y modelos de datos relacionales, tanto prácticos como teóricos, podría llenar múltiples bibliotecas llenas de libros. Cómo construir una base de datos relacional para sus datos es un tema tan bien documentado que es difícil encontrar un caso de esquina donde no exista una mejor práctica general aceptada por el libro.
La mayoría de las bases de datos NoSQL, por otro lado, todavía están en su infancia. Todavía estamos averiguando la mejor manera de usarlos.
¿Qué es exactamente?
Por un lado, un NoSQL , pero también se ha convertido en una palabra genérica para una variedad de nuevos backends de almacenamiento de datos que no siguen el modelo de DB relacional.
¿Como funciona?
Cada uno de los sistemas etiquetados con el nombre genérico funciona de manera diferente, pero la idea básica es ofrecer una mejor escalabilidad y rendimiento mediante el uso de modelos de bases de datos que no admitan toda la funcionalidad de un RDBMS genérico, pero con suficiente funcionalidad para ser útil. De alguna manera es como MySQL, que en un momento careció de soporte para las transacciones, pero, precisamente por eso, logró superar el rendimiento de otros sistemas de bases de datos. Si pudieras escribir tu aplicación de una manera que no requiriera transacciones, sería genial.
¿Por qué sería mejor que usar una base de datos SQL? ¿Y cuánto mejor es?
Sería mejor cuando su sitio necesita escalar de manera tan masiva que el mejor RDBMS que se ejecute en el mejor hardware que pueda permitirse y optimizado tanto como sea posible simplemente no puede mantener el ritmo de la carga. Cuánto mejor es depende del caso de uso específico (mucha actividad de actualización combinada con muchas combinaciones es muy difícil en los RDBMS "tradicionales") - podría ser un factor de 1000 en casos extremos.
¿La tecnología es demasiado nueva para comenzar a implementarla o merece la pena echarle un vistazo?
Depende principalmente de lo que estás tratando de lograr. Ciertamente es lo suficientemente maduro como para usar. Pero pocas aplicaciones realmente necesitan escalar de forma masiva. Para la mayoría, un RDBMS tradicional es suficiente. Sin embargo, con el uso de Internet cada vez más omnipresente, es bastante probable que las aplicaciones que lo hagan se vuelvan más comunes (aunque probablemente no dominantes).
Como alguien dijo que mi publicación anterior no estaba relacionada con el tema, intentaré compensarlo :-) NoSQL no está, y nunca fue, destinado a ser un reemplazo para más bases de datos SQL, pero hay un par de palabras para obtener cosas en la perspectiva correcta.
En el corazón de la filosofía NoSQL radica la consideración de que, posiblemente por razones comerciales y de portabilidad, los motores SQL tienden a ignorar la tremenda potencia del sistema operativo UNIX y sus derivados.
Con una base de datos basada en el sistema de archivos, puede aprovechar de inmediato las capacidades y el poder cada vez mayores del sistema operativo subyacente, que han ido aumentando constantemente durante muchos años, de acuerdo con la ley de Moore. Con este enfoque, muchos comandos del sistema operativo se convierten automáticamente también en "operadores de bases de datos" (piénsese en "ls", "ordenar", "buscar" y en las otras innumerables utilidades de shell de UNIX).
Con esto en mente, y un poco de creatividad, puede diseñar una base de datos basada en un sistema de archivos capaz de superar las limitaciones de muchos motores SQL comunes, al menos para patrones de uso específicos, que es el punto central de la filosofía de NoSQL, la como yo lo veo
Ejecuto cientos de sitios web y todos usan NoSQL en mayor o menor medida. De hecho, no alojan grandes cantidades de datos, pero incluso si algunos de ellos lo hicieran, probablemente podría pensar en un uso creativo de NoSQL y el sistema de archivos para superar los cuellos de botella. Algo que probablemente sería más difícil con las "cárceles" SQL tradicionales. Le pido que busque en google "unix", "manis" y "shaffer" para entender a qué me refiero.
En la práctica, NoSQL es un sistema de base de datos que admite un acceso rápido a objetos binarios grandes (documentos, jpgs, etc.) utilizando una estrategia de acceso basada en claves. Esto es una desviación del acceso SQL tradicional que solo es lo suficientemente bueno para valores alfanuméricos. No solo el almacenamiento interno y la estrategia de acceso, sino también la sintaxis y las limitaciones del formato de visualización restringen el SQL tradicional. Las implementaciones de BLOB de las bases de datos relacionales tradicionales también sufren de estas restricciones.
Detrás de la escena hay una admisión indirecta de la falla del modelo SQL para soportar cualquier forma de OLTP o soporte para nuevos formatos de datos. "Soporte" significa no solo almacenamiento, sino capacidades de acceso completo, programáticas y de consulta utilizando el modelo estándar.
¡Los entusiastas relacionales modificaron rápidamente la definición de NoSQL de Not-SQL a Not-Only-SQL para mantener SQL en la imagen! Esto no es bueno, especialmente cuando vemos que la mayoría de los programas de Java actuales recurren al mapeo ORM del modelo relacional subyacente. Un nuevo concepto debe tener una definición clara. De lo contrario, terminará como SOA.
La base de los sistemas NoSQL radica en el par aleatorio clave-valor. pero esto no es nuevo. Los sistemas de bases de datos tradicionales como IMS e IDMS admitieron claves hash de hash (sin utilizar ningún índice) y todavía lo hacen. De hecho, IDMS ya tiene una palabra clave NONSQL donde admiten el acceso SQL a su base de datos de red anterior, a la que denominaron NONSQL.
Es como Jacuzzi: una marca y un nombre genérico. No es solo una tecnología específica, sino más bien un tipo específico de tecnología, en este caso se refiere a las "bases de datos" a gran escala (a menudo dispersas) como BigTable o CouchDB de Google.
NoSQL es un sistema de base de datos que no utiliza consultas SQL basadas en cadenas para obtener datos.
En su lugar, genera consultas utilizando una API que proporcionará, por ejemplo, Amazon DynamoDB es un buen ejemplo de una base de datos NoSQL.
Las bases de datos NoSQL son mejores para aplicaciones grandes donde la escalabilidad es importante.
Si recuerdo correctamente, se refiere a los tipos de bases de datos que no necesariamente siguen la forma relacional. Me vienen a la mente las bases de datos de documentos, las bases de datos sin una estructura específica y las que no usan SQL como lenguaje de consulta específico.
Por lo general, es más adecuado para aplicaciones web que dependen del rendimiento de la base de datos, y no necesita funciones más avanzadas de los motores de base de datos relacionales. Por ejemplo, una tienda Key-> Value que proporciona una consulta simple por interfaz id puede ser 10-100 veces más rápida que la implementación del servidor SQL correspondiente, con un menor costo de mantenimiento del desarrollador.
Un ejemplo es este paper para un OLTP Tuple Store, que sacrificó las transacciones para el procesamiento de un único subproceso (no hubo problemas de concurrencia porque no se permitió la concurrencia), y mantuvo todos los datos en la memoria; logrando un rendimiento 10-100x mejor en comparación con un sistema similar impulsado por RDBMS . Básicamente, se está alejando de la vista ''One Size Se adapta a todos'' de SQL y sistemas de bases de datos.
NoSQL el programa real parece ser una base de datos relacional implementada en awk usando archivos planos en el back-end. A pesar de que profesan, "NoSQL esencialmente no tiene límites arbitrarios, y puede funcionar donde otros productos no pueden. Por ejemplo, no hay límite en el tamaño del campo de datos, el número de columnas o el tamaño del archivo", no creo que sea la base de datos a gran escala del futuro.
Como dice Joel, las bases de datos masivamente escalables como BigTable o HBase son mucho más interesantes. GQL es el lenguaje de consulta asociado a BigTable y App Engine. Se trata en gran medida de SQL ajustado para evitar las características que Google considera cuellos de botella (como las uniones). Sin embargo, no he escuchado esto antes referido como "NoSQL".