Quiero un ejemplo trivial de dónde MongoDB puede escalar pero una base de datos relacional tendrá problemas [cerrado]

8

Estoy aprendiendo a usar MongoDB, y cuando hablo con otros programadores me gustaría un ejemplo rápido de por qué NoSQL puede ser una buena opción en comparación con un RDBMS tradicional, sin embargo, los escenarios que encuentro y puedo encontrar en línea parecen bastante artificiales.

Por ejemplo, un blog con mucho tráfico podría representarse relacionalmente, pero requerirá algunos ajustes de rendimiento y se unirá en todas las tablas (suponiendo que se esté utilizando la desnormalización completa). Mientras que MongoDB permitiría la recuperación directa de una colección con el mismo efecto.

Pero la respuesta que recibo de otros programadores es "¿por qué no mantenerlo relacional y luego agregar un almacenamiento en caché trivial más tarde?"

¿Alguien tiene un ejemplo menos artificial en el que MongoDB realmente brille y una base de datos relacional se caiga mucho más rápido? Cuanto más pequeño sea el proyecto / sistema, mejor, porque deja menos espacio para el desacuerdo.

Algo similar a la complejidad del ejemplo del blog sería realmente útil.

Gracias.

Ryan Weir
fuente
¿Está esto limitado a MongoDB o NoSQL en general? Tendría un buen ejemplo para la búsqueda facetada de Apache Lucene que, aunque no tengo idea de si esto también se aplicaría a MongoDB.
thorsten müller
NoSQL en general, supongo. Si ya tienes algunos ejemplos, me encantaría verlos.
Ryan Weir
3
MongoDB es Web Scale !!!
Wim Ombelets
1
Vea mongodb-is-web-scale.com para obtener una explicación interesada (y ligeramente NSFW); Ahora puedes hacer cualquier cosa a escala si te acercas bien.
Wyatt Barnett

Respuestas:

6

Primero, escala bien.

Cuando una base de datos MongoDB es demasiado frecuentada o demasiado grande para un solo servidor, puede agregar fácilmente más servidores creando un clúster o conjunto de réplicas de múltiples fragmentos. Se escala casi linealmente. Esto no funciona tan bien con la mayoría de las bases de datos relacionales. Eche un vistazo a la lista de limitaciones de MySQL cuando trabaje como un clúster , por ejemplo. La mayoría de las entradas en la lista no son un problema para MongoDB (o no se aplican).

En segundo lugar, permite datos heterogéneos.

Imagine, por ejemplo, la base de datos de productos de una tienda de hardware. ¿Qué propiedades tienen los productos? Todos los productos tienen un precio y un proveedor. Pero las CPU tienen una frecuencia de reloj, los discos duros y los chips RAM tienen una capacidad (y estas capacidades no son comparables), los monitores tienen una resolución, etc. ¿Cómo diseñarías esto en una base de datos relacional? Crearía una tabla muy larga de productID-property-value o crearía una tabla de productos muy amplia y dispersa con todas las propiedades que pueda imaginar, pero la mayoría de ellas son NULLpara la mayoría de los productos. Ambas soluciones no son realmente elegantes. Pero MongoDB puede resolver esto mucho mejor porque permite que cada documento de una colección tenga un conjunto diferente de propiedades.

Philipp
fuente
55
'Segundo, permite datos heterogéneos'. Tu ejemplo es perfecto. ¿Quién no ha tenido el horrible patrón de convertir el db-en-un-almacén de valores clave en un sistema en el que las entidades tienen muchos atributos posibles? Todos los programadores deberían poder relacionarse de inmediato.
Ryan Weir
55
MongoDB también tiene algunos problemas de escala. Un clúster de más de 12 nodos no puede usar el mecanismo de replicación de conjunto de réplica predeterminado. Tienes que recurrir a la configuración maestro-esclavo. La replicación maestro-esclavo tiene problemas como la no conmutación por error automática en la pérdida del maestro. Mientras que Mysql puede manejar cientos de nodos en un clúster.
stonemetal
1
No sé si permitir datos heterogéneos es un factor en la capacidad de MongoDB para escalar. Aunque estoy de acuerdo en que esto simplifica muchos casos en los que está utilizando su base de datos como un almacén de clave / valor, esa propiedad por sí sola no ayuda mucho a decir por qué MongoDB escala mejor que un RDBMS
dsw88
2
Lo siento, no fue nada en tu respuesta. Es solo que el título de esta pregunta es "Quiero un ejemplo trivial de dónde MongoDB puede escalar pero una base de datos relacional tendrá problemas". No parece una pregunta general "Cuándo usar NoSQL sobre RDBMS"; en cambio, parecía dirigido exclusivamente a las capacidades de escalado de ambos tipos de bases de datos.
dsw88
2
@RyanWeir - de acuerdo. ¿Cuándo brilla una base de datos NoSQL? ¡Cuando te das cuenta de que acabas de construir una base de datos NoSQL usando un SQL RDB como motor de almacenamiento!
Carson63000
3

Algún ejemplo del mundo real de un problema que no tendría idea de cómo resolver de manera razonable con SQL y una base de datos relacional sola (quizás mi culpa).

Entonces tenemos una base de datos (relacional común) con aproximadamente 30,000 productos. Nada grande hasta ahora. Cada uno de estos productos tiene muchos atributos. Hay los más comunes como grupo (cables, antenas, fundas para iphone ... alrededor de 80), surtido (de alguna manera similar a grupos: automóvil, equipo de música, mp3, solo 15), marca (30).

Luego vienen los datos técnicos. Cada artículo tiene muchos de esos como color, longitud del cable, peso, volumen. alrededor de 200 tipos de valores y miles de valores.

Y lo más complicado: muchos de esos productos pertenecen a algún tipo de automóvil (o varios de ellos) o algún tipo de dispositivo móvil. Éstos vienen en jerarquías en la forma como: marca (apple) modelo (ipad) tipo (1,2,3,4) y en algunos casos generación. (para automóviles es similar, aunque en lugar de generación tenemos años de fabricación)

Problema primer paso:

Queremos la cantidad de productos para cada uno de esos atributos. Cuantos son rojos? ¿Cuántos hay en el grupo de cable? Y así.

Esto podría resolverse parcialmente con SQL. Sería un montón de consultas y bastante feo, pero creo que es posible. Tal vez lento, pero podríamos hacerlo aún más feo y mantener contadores en cada tabla y actualizar cada cambio. Especialmente difícil con aquellos atributos donde un producto puede tener múltiples (como funciona con iPhone y otros 12 teléfonos móviles)

Pero aquí viene el problema, paso dos:

Cuando un cliente selecciona un atributo (digamos que solo quiere ver productos que son rojos), queremos actualizar todos esos contadores en tiempo real. Esto significa que tendríamos consultas extremadamente complicadas (probablemente no lo suficientemente rápido de todos modos) o mantendríamos contadores para posibles combinaciones de atributos (miles de millones).

Cuando comencé este proyecto, probaron la opción de contador y lo hicieron para un subconjunto muy pequeño de atributos (grupo, surtido, marca). El código era feo, con errores y lento. Además, ahora tenían una mesa con mostradores que era mucho más grande que la mesa de productos.

Usar las facetas de Apache Solr fue en realidad la solución. Acoplar las tablas en una lista de documentos (uno por producto) autorizados para obtener todos estos datos en tiempo real con consultas mucho más simples.

Thorsten Müller
fuente
2

Puede pensar en cualquier momento que piense que una tabla EAV es la mejor manera de hacer las cosas (notoriamente lenta en bases de datos reales y difícil de consultar), es posible que necesite una base de datos nosql. Esto es especialmente cierto cuando no tiene forma de saber de antemano cuáles serían los campos. Un ejemplo sería almacenar los detalles de las pruebas médicas. Cada nueva prueba puede tener datos completamente diferentes que necesitaría almacenar. Y aunque podría (en teoría) modelar las pruebas existentes (con mucho tiempo y esfuerzo, ya que hay miles de ellas), ¿cómo podría saber de qué nuevas pruebas podría obtener resultados para las pruebas (y tal vez el equipo médico) que no tenemos? t inventado aún.

HLGEM
fuente
1
Esta es una buena razón incluso para algo tan simple como un administrador de contactos. Todos quieren rastrear algo diferente. No es gran cosa, siempre y cuando sepas para qué columna: se utiliza Text14.
JeffO
0

Cuanto más pequeño sea el proyecto / sistema, mejor, porque deja menos espacio para el desacuerdo.

Esto es difícil porque NoSQL solo es mejor en entornos grandes. Supongo que te refieres a un ejemplo simple , y tengo uno perfecto para ti.

Suponga que está haciendo un sitio web de viajes y necesita que sus usuarios viajen desde y desde los 5.170 aeropuertos de EE. UU. Destinados a cualquiera de los otros 5.170 aeropuertos de EE. UU. ...

Pero aquí está el Kicker, no todos los vuelos son directos, también debe decirle al usuario todas las opciones de escala, a veces 2 o 3 escalas. ¡También debe decirle al usuario todas las opciones en un período de 5 horas! Y necesita calcular esto en menos de 10 segundos mientras el usuario está esperando.

Esta es la pesadilla relacional de DB ... En NoSql viene, las rutas de vuelo generalmente se establecen en piedra con unas pocas semanas de anticipación, por lo que puede calcular todos los miles de millones de rutas posibles en la tienda anticipada que en un clúster simple NoSql DB ...

NoSql es el claro ganador en tal escenario.

Imbéciles
fuente
Gracias, me encanta ese ejemplo y lo utilizaré. Pero si lo que está diciendo es cierto que 'NoSQL solo es mejor en entornos grandes', entonces tendré que presentar un caso más sólido en el lado del tiempo de desarrollo más rápido, una mejor prueba de escala del futuro, etc. Cualquier otra idea ?
Ryan Weir
44
@RyanWeir Las respuestas a esas preguntas tendrán que ser específicas de la aplicación. Para ser honesto, parece que quieres vender NoSql al equipo porque quieres aprender NoSql. Pero esa es una razón no válida, por lo que está tratando de llegar a otra cosa. Simplemente les diría que "usemos NoSQL para que podamos aprenderlo, es una buena habilidad tener".
Morons
1
¿Por qué es este un problema de base de datos en primer lugar? Si tuviera que ejecutar cálculos como este, lo configuraría como una variante en A * que no se detiene después del primer resultado. Extraiga todos los datos de vuelo relevantes de la base de datos (o hágalos en la memoria caché), construya un gráfico ponderado de acuerdo con las prioridades que el usuario haya establecido e informe el primer número X de resultados.
Mason Wheeler
@MasonWheeler no está seguro de lo que quiere decir con "variante en A *"
Morons
1
@RyanWeir: Morons tiene razón, de verdad. NoSQL solo es mejor en entornos grandes. A menos que esté tratando de construir algo a gran escala (es decir, Facebook, Flickr, EBay, Amazon, etc.) es casi seguro que no lo necesita, y las compensaciones en el tiempo de desarrollo valen la pena una vez que llegue a moderado a- a gran escala, que el modelo relacional maneja bastante bien en hardware moderno. Es entonces cuando realmente comienza a apreciar los beneficios y las garantías que aportan ACID y el modelo relacional.
Mason Wheeler