mongodb - example - Entonces... esta cosa de NoSQL
order mongodb find (8)
He estado mirando a MongoDB y estoy fascinado. Parece (aunque tengo que ser sospechoso) que a cambio de organizar mi base de datos de una manera ligeramente diferente, obtengo tanto rendimiento como CPU y RAM de forma gratuita. Parece elegante y flexible, pero no lo estoy cambiando tan rápido como lo estoy con Rails. Entonces, ¿cuál es el truco? ¿Qué me proporciona una base de datos relacional que no puedo hacer tan bien o nada con Mongo? En otras palabras, ¿por qué (aparte de la inmadurez de los sistemas NoSQL existentes y la resistencia a cambiar) no toda la industria se lanza desde MySQL?
Tal como lo entendí, a medida que escala, obtiene MySQL para alimentar a Memcache. Ahora parece que puedo comenzar con algo igualmente productivo desde el principio.
Sé que no puedo hacer transacciones en las relaciones ... ¿cuándo sería esto un gran problema?
Leí http://teddziuba.com/2010/03/i-cant-wait-for-nosql-to-die.html pero, según tengo entendido, su argumento es básicamente que las empresas reales que usan herramientas reales no necesitan para evitar SQL, por lo que las personas que sienten la necesidad de deshacerse de él lo están haciendo mal. Pero ninguna "empresa" tiene que lidiar con casi tantos usuarios concurrentes como Facebook o Google, así que realmente no veo su punto. (Walmart tiene 1,8 millones de empleados, Facebook tiene 300 millones de usuarios).
Estoy genuinamente curioso sobre esto ... Prometo que no estoy trolling.
¿Con qué frecuencia cree que Facebook realiza consultas arbitrarias contra su (s) almacén (es) de datos? No todo es una aplicación web y, a la inversa, no todos los datos deben analizarse a fondo.
NoSQL, en mi opinión, es en gran parte una respuesta reaccionaria a lo que básicamente equivalía a que las personas usaran RDBMS para tareas que no eran adecuadas porque las personas no tomaron una decisión activa en función de sus necesidades y eligieron algunas por defecto. "Salir de MySQL" (o RDBMS en general) en toda la industria sería cometer el mismo error una y otra vez y el péndulo terminará girando hacia atrás para el otro lado.
Si MongoDB funciona para su caso de uso, de todos modos adelante. Simplemente no asumas que tu caso de uso son todos los casos de uso. No hay tecnología que se adapte a todos los escenarios. La invención de los aviones supersónicos no eliminó el uso de trenes de mercancías.
Déjame golpear las preguntas de a una por vez:
Sé que no puedo hacer transacciones en las relaciones ... ¿cuándo sería esto un gran problema?
La imagen en cascada elimina. O incluso solo integridad referencial básica. El concepto de "claves externas" no puede aplicarse en "colecciones" (el término de Mongo para tablas). Puede hacer escrituras atómicas en un solo "documento" (registro AKA). Entonces, si tiene un problema de DB, puede huérfano de datos en el DB.
¿Obtuve tanto rendimiento como CPU y RAM de forma gratuita?
No es gratis, pero definitivamente tiene un conjunto diferente de compensaciones. Por ejemplo, Mongo es excelente para ejecutar búsquedas de clave / valor de un solo registro. Sin embargo, Mongo es pobre en la ejecución de consultas relacionales. Tendrá que usar map-reduce para muchos de estos. Mongo es un "RAM-puta". Mongo básicamente exige 64 bits para cualquier conjunto de datos significativo. Mongo absorberá espacio en el disco, cargará una base de datos de 140 GB y podrá terminar utilizando 200+ GB a medida que el archivo de intercambio crezca durante el uso.
Y todavía vas a querer un disco rápido.
De hecho, creo que es seguro decir que el MongoDB es realmente un sistema DB que atiende al hardware de vanguardia (64 bits, mucha RAM, SSD). Quiero decir, toda la base de datos se centra en buscar datos de índice de datos en la RAM (hola de 64 bits) y luego realizar búsquedas aleatorias enfocadas en la unidad (SSD hola).
¿Por qué ... no toda la industria se lanza desde MySQL?
- No es compatible con ACID . Probablemente bastante malo para el sistema bancario (por supuesto, la mayoría de ellos aún procesan archivos planos, pero ese es un problema diferente). Sin embargo, tenga en cuenta que puede forzar escrituras "seguras" con Mongo y garantizar que los datos lleguen al disco, pero solo un "documento" a la vez.
- Todavía es muy joven . Muchos de los grandes negocios aún ejecutan versiones antiguas de Crystal Reports en su aplicación SQL Server 2000 escrita en VB6. O están construyendo autobuses de servicios empresariales para administrar los locos entornos heterogéneos que han acumulado a lo largo de los años.
- Es un paradigma muy diferente . Tal vez el 30% de las preguntas que veo regularmente en las listas de correo de Mongo (y aquí) están fundamentalmente relacionadas con "¿cómo consulto X?" o "¿cómo estructurar esta información?" . Usar MongoDB generalmente requiere que se desnormalice por adelantado. Esto no es solo un poco difícil, no está entrenado. La mayoría de la gente solo aprende la "normalización" en la escuela, nadie nos enseña cómo desnormalizar para el rendimiento.
- No es la herramienta adecuada para todo . Honestamente, creo que MongoDB es una gran herramienta para leer y escribir datos transaccionales. Ese simple CRUD "uno por vez" que comprende gran parte de las aplicaciones modernas. Sin embargo, MongoDB no es realmente bueno para informar. De hecho, honestamente imagino que el siguiente paso no es "Mongo para todo" sino "Mongo para transacciones" y "MySQL para informes" . Cuando sus datos son lo suficientemente grandes como para arrojar "informes en tiempo real", entonces usar Map-Reduce para llenar un DB de informes no parece tan malo.
Tal como lo entendí, a medida que escala, obtiene MySQL para alimentar a Memcache. Ahora parece que puedo comenzar con algo igualmente productivo desde el principio.
Honestamente, estoy trabajando para esto en algunos de mis proyectos. De nuevo, creo que MongoDB realmente hace una capa de caché válida. De hecho, crea una capa de almacenamiento en caché respaldada por archivos. Entonces, si eres capaz de impulsar el cambio de MySQL a Mongo, entonces obtienes Memcached sin fallas en el caché. También hace que sea fácil "calentar el caché" en el nuevo servidor, simplemente copie los archivos e inicie Mongo señalando la carpeta correcta, realmente es así de fácil.
Escribo esto pero como una disputa a la respuesta de Rex.
Discuto la idea de que nosql es sin relación y difusa.
Hace muchos años que trabajaba con CODASYL con C y Cobol, las relaciones entre entidades son muy estrictas en CODASYL.
Por el contrario, los sistemas de bases de datos relacionales tienen una política muy liberal hacia las relaciones. Siempre que pueda identificar una clave externa, podría formar una relación adhoc.
Con frecuencia se da por sentado que SQL es sinónimo de RDBMS, pero las personas han estado escribiendo controladores SQL para CODASYL, XML, conjuntos invertidos, etc.
RDBMS / SQL no son iguales a la precisión en datos o relaciones. De hecho, RDBMS ha sido una causa constante en la imprecisión y la percepción errónea de las relaciones. No veo cómo RDBMS ofrece mejores datos e integridad de relación que hadoop, por ejemplo. Ponte una capa de JDO, y podemos construir una red de buenas y limpias relaciones entre entidades en hadoop.
Sin embargo, me gusta trabajar con SQL porque me da la capacidad de crear secuencias de comandos de relaciones adhoc, aunque me doy cuenta de que las relaciones adhoc son una causa constante de adulteración y problemas de relación.
Al tener la oportunidad de trabajar con el análisis estadístico de los procesos comerciales e industriales, SQL me dio la capacidad de explorar relaciones en las que no se habían percibido relaciones previamente. La oportunidad de trabajar con el análisis estadístico me dio ideas que normalmente no vendrían de la mano de los programadores de SQL.
Por ejemplo, diseñaría y normalizaría su esquema para reflejar un conjunto de procesos. Lo que quizás no se dé cuenta es que las relaciones cambian con el tiempo. Las características estadísticas revelarían que un esquema ya no puede estar tan "debidamente normalizado" como lo había sido antes. Que los componentes principales de los procesos han mutado con el tiempo. Pero los programadores no estadísticos no entienden eso y siguen promocionando RDBMS como la solución perfecta para la integridad de los datos y la precisión de las relaciones.
Sin embargo, en una base de datos de vinculación de relaciones, podría vincular entidades en las relaciones tal como aparecen. Cuando las relaciones cambian, la vinculación muta naturalmente con los datos. Las relaciones y su mutación están documentadas dentro del sistema de base de datos sin la costosa necesidad de renormalizar el esquema. En ese punto, RDBMS es bueno solo como temperatura dbs.
Pero luego puede contar que RDBMS también le permite mutar de manera flexible sus relaciones, ya que es lo que SQL hace mejor. Es cierto, muy cierto, siempre que realice BCNF o incluso 4NF. De lo contrario, comenzaría a ver que sus consultas y cargadores de datos realizan operaciones replicadas. Pero sus muchos años en el negocio RDBMS hasta ahora ciertamente le han hecho darse cuenta de que BCNF es muy costoso e ineficiente desde el punto de vista operativo y que somos constantemente culpables de 2.5 NFing nuestros esquemas.
Decir que RDBMS y SQL promueven la integridad de los datos y las relaciones es una declaración errónea. O trabajas en una empresa que es muy pequeña o no permaneces en tus puestos durante más de dos años; no verías la cantidad de datos o la mutación de información y los problemas causados por RDBMS. El abuso de RDBMS es la causa de que los ejecutivos se vean restringidos por las aplicaciones informáticas y la causa de fallas financieras de las compañías que no ven los cambios en el comportamiento del mercado porque sus puntos de vista fueron restringidos por los programadores cuyas opiniones se limitaban a su veneración de sus seres queridos. Esquemas RDBMS.
Es por eso que los programadores de SQL no entienden por qué el estadístico de su empresa se niega a usar su aplicación que diseñó meticulosamente, pero emplearon a un interno universitario para escribir SQL para descargar datos en sus servidores personales y que los ejecutivos de su empresa aprenden a confiar en contadores y estadísticos ''hojas de cálculo en lugar de sus aplicaciones elegantes de múltiples niveles debido a la incapacidad de sus aplicaciones para mutar con los procesos.
Puede que no sea posible, pero aún así le insto a que adquiera cierta comprensión estadística para percibir cómo los procesos cambian con el tiempo para que pueda tomar la decisión tecnológica correcta.
La razón por la cual las personas no se están moviendo a SQL-less es la falta de un buen entorno de scripting como SQL para realizar un análisis de relación adhoc. No porque la tecnología sin SQL sea deficiente en precisión o integridad. El análisis de relaciones Adhoc es muy importante hoy en día debido a las actitudes y estrategias de desarrollo de aplicaciones rápidas y ágiles que tenemos hoy en día.
He usado MongoDB, Redis (más que la lista de conjuntos de pares clave-valor, set y conjunto ordenado), Tokyo Tyrant, Memcached y MySql & PostgreSQL.
Los argumentos entre NoSQL DB y DB basado en SQL son completamente infundados. Debe elegir el modelo adecuado en función de su caso de uso. Si necesita cumplimientos de ACID, continúe con SQL DB como PostgreSQL, Oracle, etc. Necesita alto rendimiento, pero le importan menos los datos, entonces puede considerar no DB de SQL. Son tecnologías fundamentalmente diferentes. Incluso puedes usar la combinación de modelos. Con NoSQL, perderá relaciones, restricciones y, a veces, transacciones ... De hecho, esa es una de las razones por las que NoSQL es más rápido ...
Una vez que he perdido dos meses de datos agregados con MongoDB ... No tengo idea de cómo los perdí ... Pero tuve una copia de seguridad y perdí unos minutos de datos. Devolví MongoDB con copia de seguridad. Si usa NoSQL, haga copias de seguridad ocasionales o programe tareas cron para copias de seguridad de bases de datos. Esto es aplicable para SQL DB también.
En comparación con SQL RDBMS, las bases de datos NoSQL son más recientes y actualmente se encuentran en pleno desarrollo, pero las bases de datos NoSQL se ven maduras en su alcance, es decir, su alto rendimiento y su fácil replicación.
En mi sitio web (stacked.in), he utilizado solo redis DB, funciona mucho más rápido que MySQL.
La gran reacción contra NoSQL está arraigada en la mentalidad de muchos de los defensores de NoSQL. Específicamente, la actitud mejor resumida como "SQL es muy difícil, no debería tener que hacerlo". No me gusta NoSQL porque parece que en muchos casos está elevando la ignorancia.
Sé que no puedo hacer transacciones en las relaciones ... ¿cuándo sería esto un gran problema?
Con más frecuencia de lo que podrías esperar Hay muchas cosas que pueden salir mal cuando no se puede asumir un conjunto de datos consistente.
Recuerde, NoSQL no es exactamente nuevo. Después de todo, tenían que usar algo antes de SQL y bases de datos relacionales, ¿verdad? De hecho, los sistemas como MUMPS y CODASYL funcionan de la misma manera y tienen décadas de antigüedad. Lo que las bases de datos relacionales le dan es la capacidad de consultar datos de forma arbitraria.
Supongamos que tiene una base de datos con los clientes, sus compras y los artículos que compraron. Un DB NoSQL puede tener clientes que contengan compras y compras que contengan artículos. Esto hace que sea más fácil averiguar qué artículos compró un cliente determinado, pero es difícil averiguar qué clientes compraron un artículo determinado. Una base de datos relacional tendría tablas para clientes, compras, artículos y una tabla que vincula los artículos con las compras. En SQL, ambas consultas son triviales de formular, y el motor de la base de datos hace todo el trabajo por usted.
Además, tenga en cuenta que parte de la tendencia de NoSQL es sacrificar la consistencia o la confiabilidad de velocidad, escalabilidad y costo. Los DB relacionales pueden escalar, pero no es barato. Si va a http://tpc.org , puede encontrar RDBMS que se ejecutan en cientos de núcleos simultáneamente para entregar millones de transacciones por minuto, pero cuestan millones de dólares.
Si sus datos no aprovechan el álgebra relacional, ni necesita garantías de ACID, entonces no obtendrá nada utilizando idiomas que se destinen exclusivamente a esos usos.
También soy un gran fan de MongoDB. Habiendo dicho eso, definitivamente no es un reemplazo al por mayor para RDBMS. Facebook tiene 300 millones de usuarios, pero si algunos de tus amigos no aparecen en la lista una vez, o uno de los álbumes de fotos falta en la solicitud ocasional, ¿lo notarías? Probablemente no. Si su actualización de estado no se filtra a todos sus amigos durante unos minutos, ¿es importante? Apenas. Si los balances de Wal-Mart no están sincronizados, ¿alguien perdería la cabeza? Seguro.
Las bases de datos NoSQL son excelentes en entornos "difusos" donde las relaciones no son estrictas y la integridad de los datos puede permitirse estar fuera de sincronización. Los RDBMS siguen siendo importantes cuando los conjuntos de datos son extremadamente complejos y relacionales (de ahí el nombre), y deben mantenerse puros.
El gran impulso para NoSQL proviene del hecho de que durante los últimos 30 años, hemos estado usando sistemas RDMBS para ambos escenarios. Ahora tenemos una herramienta más apropiada para muchas situaciones. Algunos discutirían más, de hecho. Pero nadie discutiría todo.