Las ventajas de una base de datos no relacional (como el almacenamiento de pares clave-valor) son evidentes cuando se usan en conjuntos de datos a gran escala (google, facebook, linkedin). ¿Cómo cree que las aplicaciones pequeñas y medianas pueden beneficiarse del uso de bases de datos no relacionales?Bases de datos no relacionales (NoSQL) para aplicaciones pequeñas o medianas
IBM Mainframes tiene bases de datos "no relacionales" desde los años 60 (bases de datos jerárquicas como IMS +). Estas bases de datos todavía están en uso porque son extremadamente rápidas y manejan bien a gran escala.
El objetivo de las bases de datos relacionales era proporcionar un método regular y relativamente abstracto para almacenar y recuperar datos en los que la sintonización se puede realizar con relativa independencia del modelo de datos (no válido para IMS). Fueron diseñados más bien en reacción a la incapacidad de reorganizar bases de datos jerárquicas fácilmente. Lo bueno es una buena organización; el inconveniente es mediano, no de alto rendimiento.
Google proporciona almacenamiento escalable y MapReduce para manejar la escala. No es relacional.
Hubo un gran impulso a principios de la última década para almacenar datos en XML, en forma esencialmente hierárquica porque XML es implícitamente jerárquica. Eso fue un gran error en mi humilde opinión, porque repetía la inconveniencia de las bases de datos jerárquicos, pero no tenía ninguno de los resultados. No estoy muy sorprendido de que este movimiento haya muerto.
La mayor parte del empuje práctico a no relacional me parece ser hacia el rendimiento y la escala. No veo cómo esto ayuda mucho a las aplicaciones "pequeñas".
Las personas han propuesto, pero no han hecho una gran cantidad de gestión de datos práctica utilizando esquemas basados en el conocimiento. Me viene a la mente el CYC de Doug Lenat aquí. La capacidad de la base de datos para ayudar a una aplicación a sacar conclusiones no obvias me parece muy interesante para aplicaciones "pequeñas" que intentan ser "inteligentes". Pero aún no hay muchos de estos.
El punto clave de utilizar una base de datos NoSQL a esa escala es cuando el modelo de base de datos (clave-valor, documento, etc.) coincide con las necesidades de la aplicación y no se necesita la funcionalidad relacional avanzada.
En el extremo pequeño del espectro, el rendimiento no es un problema porque casi todo es rápido. Los motores de almacenamiento no son un problema, si no necesita un motor de consulta sofisticado, la falta de soporte SQL no es un problema.
Te queda lo bien que encaja y lo fácil que es de usar. Honestamente, sin embargo, las herramientas se convierten en un problema. La herramienta de base de datos relacional está madura, las herramientas NoSQL tienen menos funciones y menos batalla endurecida. Con demasiada frecuencia son herramientas para enrollar. Definitivamente, considere a qué herramientas renunciaría y cuánto las necesita.
Existe una lista adicional de ventajas para proyectos más pequeños al considerar un servicio NoSQL (como Amazon SimpleDB y Microsoft Azure) en comparación con un producto. Si solo tiene que pagar por lo que usa y no usa mucho, puede ser más barato que ejecutar un servidor dedicado, bajar hasta algo gratis como el nivel de uso gratuito SimpleDB.
También evita algunos de los costos de mantenimiento del servidor y la base de datos. Esto puede ser una gran ganancia si no tienes un DBA, o si tus DBA ya han trabajado demasiado. Por supuesto, todavía tendrá trabajo de administrador que hacer, pero se reduce significativamente, y por lo general es más simple.
Cuando se trata de bases de datos de gráficos (como Neo4j - un proyecto en el que estoy involucrado) se destacan en scaling to complexity.Esto significa que proporcionan "better substrates for modeling business domains" (vea The State of NoSQL, también por Ben Scofield, también). Tal como lo veo, esto es muy importante en aplicaciones pequeñas y medianas.
Esto puede ser mejor explicada a través de ejemplos, así que aquí tiene algunos enlaces a ejemplos de aplicaciones/modelado de dominio:
La cuestión tal vez requiere un poco más contexto ... asumiendo un entorno de Python, considere el tutorial en el proyecto y_serial: http://yserial.sourceforge.net/
NoSQL no se adopta simplemente por razones de escalabilidad. La serialización (de cualquier objeto arbitrario de Python) y la persistencia son muy convenientes a cualquier escala, así que considere el sistema de clave-valor como un enfoque.
Bueno, uno de los problemas con un RDBMS es que debe dedicar un esfuerzo al mapeo de sus modelos de dominio de lenguajes de programación al esquema relacional de su RDBMS. Este esfuerzo generalmente se usa para configurar su capa de ORM.
Con las bases de datos NoSQL no está obligado a asignar sus objetos a un modelo relacional y en la mayoría de los casos sus objetos se serializan como están. Debido a la falta de un esquema intermedio, data migrations and versioning become easier.
Otro beneficio es la escalabilidad y el rendimiento. Dado que la mayoría de las veces sus datos se reciben mediante 'claves', todo lo que usa e indexa. La fragmentación trivial es posible al hacer un% (MOD) en la clave frente al número de instancias NoSQL disponibles, lo que proporciona partición de datos naturales que es crucial para la fragmentación.
Si le interesa ver cómo el desarrollo con un NoSQL difiere de un RDBMS, tengo un tutorial en el que muestro cómo proceder con designing a simple blog application using Redis.
Si combina algunos servicios comunes de nube PaaS como una tienda Key-Value, una tienda BLOB y una tienda Message Queue tiene algunas herramientas útiles que pueden liberar a los desarrolladores de pequeñas aplicaciones de la tiranía del DBA y la infraestructura amigos.
Hoy en día, los pequeños desarrolladores suelen recurrir a Jet MDB. ¿Por qué? El acceso fácil y compartido es tan fácil como almacenar el archivo MDB en un archivo compartido visible para toda la comunidad de aplicaciones. Cuando puedan salirse con la suya (es decir, obtener el apoyo necesario de los guardianes) pueden usar SQL Server Express, MySQL, etc.
Lamentablemente, esos guardianes pueden ser bastante hostiles para tratar en una organización grande. Mencione una "base de datos" y de repente se enfrenta a la pandilla de DBA y las demoras asociadas, las revisiones de las solicitudes, la priorización, etc. Mencione la necesidad de un servidor y se enfrente a ese otro pelotón de fusilamiento.
El uso de una solución NoSQL y servicios en la nube relacionados puede eliminar una tonelada de esto si no necesita un RDBMS.
Por un lado, todo lo que realmente se requiere es una cuenta con un proveedor de nube pública. Esto es algo que se vuelve bastante fácil una vez que el concepto ha sido aprobado. Y es más fácil para usted como desarrollador una vez que ha sido aprobado y se le ha asignado una cuenta, aunque, por supuesto, existen los problemas habituales de contabilidad.
Pero dejemos eso a un lado. ¿Qué pasa si su organización implementó una nube privada para tales usos?Muchos de los problemas de facturación externa desaparecen, las preocupaciones sobre la inseguridad de datos desaparecen, etc.
Tal cosa podría implementarse y aprovisionarse de manera semi anónima, casi tan fácilmente como la administración de archivos compartidos. El anonimato aparece porque una vez que se le aprueba para desarrollarse en la nube interna, nadie necesita identificar los detalles de sus actividades, usarlo más de lo necesario para examinar una solicitud antes de poder crear un archivo en un archivo compartido existente. .
Obviamente, habría cuotas de almacenamiento y CPU para administrar. Nadie puede permitirse seguir escalando indefinidamente. Las aplicaciones deshonestas pueden consumir grandes cantidades de recursos. Entonces, lo que necesitas es algún tipo de sistema de cuotas para limitar el uso. Si la gente de la infraestructura lo monitorea es una decisión de implementación, o podría tratarse igual que el uso compartido de archivos: agotarse y alguien le grita al programador que a su vez lo investiga y solicita más si es necesario (o corrige sus fallas).
Pero termina con "informática de utilidad" y al "no usar SQL" no incurre en el costo (y problemas) de tratar con los DBA. Todavía pueden sentarse tranquilamente navegando por la Web en sus grandes oficinas mientras trabajan.
Amazon SimpleDB puede ser útil para aquellos que necesitan una base de datos no relacional para el almacenamiento de datos más pequeños y no estructurales. Amazon SimpleDB tiene un tamaño de almacenamiento restringido a 10 GB por dominio. Amazon SimpleDB ofrece simplicidad y flexibilidad. SimpleDB indexa automáticamente todos los datos. Los precios de Amazon SimpleDB se basan en el uso real de tu caja. Puede almacenar cualquier cadena de datos UTF-8 en Amazon SimpleDB.
wiki de la comunidad .... – jldupont
Admito que no tengo una experiencia real con esto, pero me gustaría ver algunos enlaces para respaldar esa afirmación o al menos explicar cuáles son las alternativas. También estoy de acuerdo en que probablemente debería ser wiki de la comunidad. –
¿Podría definir "no relacional" como algo que no sea "no relacional"? De lo contrario, cualquier esquema ad hoc para almacenar datos califica. –