¿Qué base de datos debo usar para una aplicación web excelente en la que estoy trabajando: MongoDB, PostgreSQL o MySQL, con MongoDB / Redis como secundario?

Entre PostgreSQL y MySQL, generalmente no hay una buena razón para usar MySQL sobre PostgreSQL, así que eliminemos eso de la lista.

SQLite3 es fantástico si desea una base de datos incrustada en una situación en la que tiene recursos limitados o necesita una experiencia de instalación perfecta para el usuario. SQLite es la base de datos estándar en aplicaciones móviles en Android e iOS (desde el iPod original) e incluso está incrustado en algunos navegadores web como WebSQL (aunque está en desuso ya que la gente de Chrome quería que el estándar se basara en el Implementación de SQLite, mientras que la gente de Mozilla pensó que esta era una forma ridícula de definir estándares).

Como mencionó las aplicaciones web, no debería usar SQLite. Requiere bloquear el acceso al archivo de la base de datos para cada escritura, y dado que se ejecuta dentro del proceso de su aplicación, eso significa que solo puede tener un proceso ejecutándose con acceso de escritura a la base de datos (aunque varios subprocesos están bien). Python tiene un bloqueo de intérprete global, lo que significa que puede usar efectivamente solo un núcleo en una CPU de varios núcleos a menos que ejecute múltiples procesos, lo que no puede porque SQLite no lo admite. Entonces: no use SQLite si está creando aplicaciones web en Python.

Lo que nos deja PostgreSQL y MongoDB.

PostgreSQL, como todas las bases de datos SQL (incluido SQLite), es una base de datos relacional. Se especializa en el seguimiento de las relaciones entre datos y en ayudarlo a recuperar algo si sabe algo relacionado con él.

Por ejemplo, si tiene dos tablas de base de datos, diga “Usuarios” para todos los usuarios y “Publicaciones” para todas las publicaciones realizadas por un usuario determinado, siendo “Posts.user_id” una referencia de clave externa para “Usuario”. id “, tiene un esquema en el que una publicación tiene un solo usuario y, como corolario, un usuario puede tener muchas publicaciones (dado que los propios usuarios no definen ninguna relación con las publicaciones, la relación es de la otra dirección). SQL hace que sea realmente fácil trabajar con tales relaciones. Puede decir “dado un usuario, consígame todas las publicaciones que hagan referencia a este usuario” o “dada esta publicación, consígame el usuario referido”.

Todas las bases de datos SQL pueden hacer consultas relacionales como esta, pero PostgreSQL es realmente muy bueno en esto. Sin embargo, existe un caso de uso avanzado para el que PostgreSQL no es tan bueno para: gráficos. Llegaremos a eso en un minuto.

La relación de usuarios y publicaciones anterior es un ejemplo de una relación de “uno a muchos” (o “muchos a uno”, según el lado desde el que esté mirando). Hay algo más llamado una relación de “muchos a muchos” que es básicamente un combo de “muchos a uno + uno a muchos”. En nuestro ejemplo hipotético de usuarios y publicaciones, si quisiéramos hacer posible que una publicación tenga más de un usuario, lo haríamos así: “Usuarios <- Usuarios_Publicaciones -> Publicaciones” donde esta nueva tabla “Usuarios_Publicaciones” tiene exactamente dos columnas, una referencia de clave externa a una fila en Usuarios, otra referencia de clave externa a una fila en Publicaciones. Para cada combinación única de Usuario y Publicación, puede agregar otra fila en la tabla Users_Posts que vincula ese usuario y publicación.

Aquí hay una situación muy común en la que necesita un modelo de este tipo: mapeo de películas y sus actores. Tiene una tabla para películas y actores, y una tabla de unión de “muchos a muchos” que los une a ambos.

Digamos que quiere saber en qué películas aparecieron los actores A y B. Eso es fácil: “SELECCIONAR * DESDE Películas DONDE ENTRAR (SELECCIONAR películas_id DESDE Películas_Actores DONDE ENTRAR actores_id (A, B))”.

¿Ves lo que hicimos? Esta es una consulta anidada. Comenzando desde el interior, primero solicitamos todos los ID de película en la tabla de unión que presentan a los actores A o B, luego solicitamos todos los detalles de la tabla de Películas donde la identificación de la película está en los resultados de la consulta anterior.

Ahora, ¿qué pasa si tienes una situación en la que A y B nunca han aparecido juntos en una película, pero quieres saber si tienen co-actores comunes? Esto es como LinkedIn o Facebook, donde estás mirando el perfil de alguien con quien no eres amigo, pero LinkedIn o Facebook te dicen que tienes amigos comunes. Este es un patrón de búsqueda de gráficos y es el tema de un tipo de base de datos completamente diferente llamado, apropiadamente, una base de datos de gráficos . Busque Neo4j para ver un ejemplo. Aunque los datos de gráficos se pueden modelar usando una base de datos relacional como PostgreSQL, es mejor usar algo especializado como Neo4j.

Y finalmente, MongoDB. ¿Para qué es esto? MongoDB no es una base de datos gráfica, ni siquiera una base de datos relacional . Al igual que CouchDB, es una base de datos de documentos y representa el otro extremo de la escala. ¿Qué sucede si desea almacenar todos los detalles de una película en un solo lugar y no está interesado en poder hacer una referencia cruzada de los datos? Las bases de datos relacionales quieren que “normalice” sus datos almacenando cada pequeño detalle en una tabla separada, pero le resulta molesto. Solo desea almacenar sus datos en un solo lugar sin tener que pensar demasiado. Todavía está descubriendo qué datos desea almacenar, por lo que por ahora solo desea volcarlos en algún lugar y preocuparse por consultarlos más adelante. Para eso son exactamente las bases de datos de documentos y MongoDB es el rey de esa colina.

PostgreSQL introdujo un tipo de datos JSON en la versión 9.2 y un tipo JSONB más eficiente en 9.4 (la versión actual), por lo que si tiene una combinación de datos relacionales y de documentos (que es muy probable), es posible que desee seguir con PostgreSQL en sí (consulte ¿Qué hay de nuevo en PostgreSQL 9.4).

Espero que ayude.

La reciente incorporación del soporte de tipo de datos JSON (así como los índices en columnas JSON) en PostgreSQL convierte a MongoDB en la opción menos atractiva entre estos 3.

En general, PostgreSQL es el más equipado con características y consiste en términos de cómo admite diferentes características entre los DBMS listados. Tiene el optimizador de consultas más avanzado; por el contrario, MySQL no tiene un caché de plan de consulta en absoluto, esto significa que su optimizador se basa en heurísticas relativamente simples para ser rápido.

Por otro lado, MySQL tiene una comunidad mucho más grande.

Asi que:

• Personalmente, elegiría PostgreSQL, principalmente debido a la compatibilidad con JSON (por lo que ahora está en los mundos relacionales y NoSQL ahora), mejores características de replicación y soporte completo de las transacciones distribuidas / de compromiso grupales.
• MySQL también es una muy buena opción: alimenta Facebook y muchos otros sitios grandes en la web (incluido este), por lo que definitivamente es una opción segura. No lo puse en primer lugar principalmente porque la popularidad, la estabilidad comprobada y la escalabilidad son comparables para estas bases de datos, pero PostgreSQL parece una mejor opción para mí debido a las pocas características que enumeré anteriormente.
• En mi opinión, MongoDB es la opción menos atractiva: la falta de transacciones significa un gran dolor de cabeza en caso de que realmente lo necesite. Además, hay muchos informes (ver, por ejemplo, Un año de MongoDB) que muestran que tiene un conjunto de otros problemas serios. Así que definitivamente es la opción más arriesgada.

Preguntas relacionadas:

• ¿Cuáles son los pros y los contras de PostgreSQL y MySQL? Con respecto a la confiabilidad, velocidad, escalabilidad y características.
• ¿Por qué Quora utiliza MySQL como el almacén de datos en lugar de NoSQL como Cassandra, MongoDB o CouchDB? ¿Están haciendo alguna UNIÓN sobre MySQL? ¿Hay planes para cambiar a otra base de datos?

PD: No usé MongoDB (aunque jugué con él), sino que usé MySQL, PostgreSQL y un conjunto de otros DBMS durante aproximadamente 10 años.

Honestamente, puedo ver un caso para un poco de ambos.

Las transacciones y la información del usuario se guardan mejor en SQL. Va a ejecutar pagos y descargar muchos datos muy “rectangulares” a la contabilidad. SQL es fácilmente la herramienta más limpia para esto exactamente. Admite los niveles de seguridad adicionales que necesita para cosas como “los usuarios normales no pueden eliminar de esta tabla” . También tiene excelentes herramientas para extraer datos, muchos contadores conocen SQL básico.

La información del artículo puede ser una buena combinación para MongoDB. Especialmente cuando se trata de tener “campos flexibles” como dos rangos de tamaño, rangos de color, etc. Los datos en este formato son mucho más fáciles de leer que usar SQL y EAV y es relativamente más eficiente.

Tenga en cuenta que querrá aprovechar los índices dispersos y realmente querrá comprender las características de indexación si planea implementar cualquier forma de búsqueda en los elementos.

Entonces la respuesta aquí simplemente es que realmente no hay “mejor”. De hecho, esto es realmente común con NoSQL. En general, no reemplaza “todo” solo algunas cosas. Los diferentes tipos de datos se prestan a un almacenamiento diferente, incluso dentro del mismo sistema.

Editar: esta respuesta es muy antigua; Las cosas han cambiado. Es posible que desee buscar en otro lado.

Yo diría que la principal desventaja de MongoDB es que no es tan probado o maduro como MySQL.

Si está usando MongoDB, es mucho más probable que termine en un escenario jodido, tenga corrupción de datos, tenga problemas para intentar actualizar, encuentre algún error de rendimiento, …

MySQL definitivamente no es perfecto, pero sus problemas son más conocidos y se han ejecutado a través del guante miles de veces.

• MongoDB no admite combinaciones. Pero puede hacer algo llamado incrustación. Por ejemplo, si creara un blog usando MySQL, tendría una tabla para publicaciones y una tabla para comentarios. En MongoDB, es posible que tenga una única colección de publicaciones y una serie de comentarios dentro de cada publicación.
• MongoDB no admite transacciones ( la capacidad de contener múltiples operaciones dentro de una transacción y revertir todo como si fuera una sola operación ) . Las operaciones individuales son atómicas en MongoDB.

  ¿Cuándo deberías usar MySQL?

1. Si su estructura de datos encaja perfectamente en tablas y filas, MySQL le ofrecerá una interacción sólida y fácil con sus datos.
2. Si lo que le preocupa es el rendimiento, existe una buena posibilidad de que realmente no necesite MongoDB. Lo más probable es que solo necesite indexar sus datos correctamente.
3. Si requiere SQL o transacciones, deberá seguir con MySQL.
• ¿Cuándo deberías usar MongoDB?
1. Si sus datos parecen complejos de modelar en un sistema de base de datos relacional, o si se encuentra desnormalizando el esquema de su base de datos o codificando problemas de rendimiento, debería considerar usar MongoDB.
2. Si te encuentras tratando de almacenar matrices serializadas u objetos JSON, es una buena señal de que estás mejor con MongoDB.
3. Si no puede predefinir su esquema o si desea almacenar registros en la misma colección que tienen campos diferentes, esa es otra buena razón.
• MySQL y MongoDB son tremendamente útiles, y existen diferencias mucho más importantes en sus operaciones básicas que simplemente el rendimiento.

  Realmente se reduce a las necesidades de su aplicación específica.

La “aplicación web asesina” realmente no describe con precisión qué tipo de datos planea almacenar o qué planea hacer con ellos. Es un poco vago, por lo que esta respuesta no le dará una respuesta directa, pero podría ayudarlo a cambiar un poco su proceso de pensamiento.

Una base de datos es muy importante, sin duda, pero debes saber que no te dará ninguna ventaja inicial al elegir una sobre la otra. Solo cuando comience a escalar tendrá que tomar algunas decisiones, pero esta es una situación en la que no se encontrará durante mucho tiempo.

• ¿Su aplicación web escribe mucho o está muy pesado o cae en el medio? Esto determinará no solo qué índices configurar, sino también si normaliza, desnormaliza o elige una solución NoSQL.
• ¿Qué tipo de datos está almacenando? ¿Se trata de elementos únicos relacionales o altamente dinámicos que no se pueden encasillar en un esquema particular? Un buen ejemplo de datos relacionales es una red social como Facebook. Un usuario tiene muchos comentarios, fotos, amigos, grupos e intereses. Un ejemplo de datos no relacionales es el almacenamiento de documentos o información analítica.
• ¿Trabajará con datos de ubicación / coordenadas? PostgreSQL y MongoDB son excelentes para trabajar con coordenadas y distancias GPS. MySQL, por otro lado, puede, pero tiene algunas limitaciones severas y podría decirse que actualmente no es ideal para trabajar con distancias.
• ¿Qué tipo de entorno de alojamiento utilizará? Si está utilizando un servidor de Windows, por ejemplo, probablemente se inclinará hacia Microsoft SQL Server (MSSQL).

Mi consejo sería dejar de enfocarse en la base de datos, solo elija lo que sepa que se sentirá cómodo usando. Mi recomendación personal sin conocer el contexto o los requisitos sería MySQL o PostgreSQL.

Ambas bases de datos pueden escalar MUY fácilmente y pueden ser martilladas incluso antes de tener que escalarlas. Si bien MongoDB es excelente, tiene sus limitaciones, especialmente si necesita el cumplimiento de ACID o transacciones verdaderas adecuadas o tiene un esquema predominantemente relacional.

Estas son lecciones que aprendí de la experiencia real del producto.

MongoDB no es relacional. Por lo tanto, es muy adecuado para escenarios de productos, como el registro. En cuanto al registro, me refiero a los datos que se generan y no cambian en absoluto. El microblogging es un modelo de registro. No puede cambiar el contenido de un tweet publicado. Si cambia de opinión, debe eliminar el tweet anterior y publicar uno nuevo, lo que genera otro registro.

MongoDB también es bueno para el cambio frecuente de esquemas de datos. Para productos de inicio cuyos requisitos pueden cambiar de vez en cuando. MongoDB puede reducir muchos costos de operación. Sin embargo, otros RDBMS pueden adaptarse a cambios frecuentes con un diseño adecuado, pero requieren más esfuerzos de operación.

Más allá de la ventaja anterior, MongoDB no puede competir con RDBMS.

Si los datos no son como el registro y pueden actualizarse al azar, MongoDB es un diaster. Es difícil mantener datos consistentes programáticamente para datos desnormalizados.

Para la mayoría de los productos, tarde o temprano, la transacción debe estar involucrada. El truco que simula la transacción en MongoDB no proporciona una verdadera función ACID. Entonces, para el sistema de facturación, todavía tiene que usar RDBMS como MySQL. Ahora, tiene dos almacenamiento principal en manos: MongoDB y MySQL. La unión de datos en los dos almacenes diferentes solo se puede hacer a nivel de aplicación. Nuevamente, pierde la ventaja de la transacción RDBMS. Luego, debe sincronizar los datos de MongoDB a MySQL. La sincronización debe realizarse con cuidado para ser coherente.

OMI, si el requisito del producto es básicamente estable, siempre es preferible almacenar datos en RDBMS, como MySQL, de forma normalizada. Si hay un cuello de botella en el rendimiento, los datos se pueden eliminar de la memoria caché, como redis. Si se actualizan los datos normalizados, siempre puede elegir el momento adecuado para invalidar el almacenamiento en caché.

TLDR:

PostgreSQL es la opción óptima. Es muy similar a MySQL y SQLite, pero juega mejor con la implementación y los rieles, y es escala de producción. La razón más importante es que casi todos los tutoriales de rails usan bases de datos relacionales como esas tres, en lugar de bases de datos no relacionales como MongoDB o NoSQL. Por lo tanto, es más natural y más adecuado usar bases de datos relacionales al aprender Rails. Quizás alguien pueda confirmar esto, pero muchas compañías también usan bases de datos relacionales con Rails.

Si desea aprender Rails de vainilla, elija mySQL, SQLite o, preferiblemente, PostgreSQL, que es más adecuado para la escala de producción y es fácil de integrar.

Si ya sabe que su aplicación será más adecuada para una base de datos no relacional como MongoDB o NoSQL, vaya con ellas. Sin embargo, lo más probable es que si estás aprendiendo Rails, probablemente no necesites bases de datos no relacionales, ni tu tráfico haría necesaria esa elección. Con una base de datos no relacional, también necesita un ORM (mapeador relacional de objetos) diferente para realizar consultas desde rieles en forma de llamada a método. Mira algo como mongoid / mongoid

Es realmente una cuestión de sabor. Pero las bases de datos relacionales es con lo que Rails se entrega, y para qué es adecuado el registro activo predeterminado de Rails. La mayoría de los tutoriales utilizarán bases de datos relacionales y registros activos. Entonces, SQL, especialmente PostgreSQL es lo que recomendaría. para aprender y comenzar con.

Cabe señalar que lo más importante es comenzar a trabajar con algo y no tropezarse con la tecnología que utiliza. A medida que progreses y aprendas más, aprenderás los beneficios de las diferentes tecnologías, pero muchas de ellas no entran en juego para las aplicaciones a pequeña escala y para aquellos que aprenden. Independientemente de lo que use, obtendrá conocimiento de las bases de datos, las consultas y su uso con sus aplicaciones. Ese conocimiento, diría, es más importante que los detalles del uso de uno u otro.

También es bueno tener una buena base de bases de datos relacionales, ya que te enseña mucho sobre cómo funciona el diseño de bases de datos. Las bases de datos no relacionales es algo que se puede aprender más tarde, y no está tan bien cubierto por los tutoriales de rieles que existen. De hecho, no creo haber visto nunca un tutorial sobre rieles que usara una base de datos no relacional.

Si desea crear una aplicación mientras aprende rápidamente con un experto y obtener la experiencia de trabajar con un equipo, consulte Hackerupt. Usan Rails y PostgreSQL para crear la aplicación que desee. Revisa todas las características comunes y de uso más frecuente de Rails y cuenta con un experto que lo ayuda a adaptar las lecciones para que se adapten a su aplicación, resolver problemas difíciles y brindarle una comprensión más profunda de las cosas si lo desea. No siempre necesita al experto, pero necesita a alguien que se ocupe de su problema. Se organizan equipos de colaboración, incluso si cada miembro tiene diferentes aplicaciones que están creando, por lo que obtendrá el beneficio de la colaboración entre pares. Y la experiencia del equipo es una gran ventaja para las entrevistas y el currículum, por lo que realmente estaría matando a muchas aves con una piedra rentable.

Solo usa MySQL o Postgres. ¿Por qué? Si todo su conjunto activo se ajusta en la memoria principal de una sola máquina (que puede ser de hasta 128 GB + con máquinas modernas), no tiene un problema de escalabilidad horizontal: es decir, no hay absolutamente ninguna razón para que particione (“fragmento” ) su base de datos y renunciar a las relaciones. Si su conjunto de datos activo cabe en la memoria, la mayoría de las bases de datos sintonizadas correctamente con un índice funcionarán lo suficientemente bien como para saturar su tarjeta Ethernet antes de que la base de datos se convierta en una limitación.

Si decide que el modelo relacional en sí mismo no encaja bien, puede crear fácilmente una “tienda orientada a documentos” sobre MySQL: esto es lo que terminó haciendo Friendfeed, seguiría su modelo (excepto que usaría Avro (software), Apache Thrift o Google Protocol Buffers en lugar de la serialización específica del idioma) – http://bret.appspot.com/entry/ho …

Si su sitio se vuelve inmensamente exitoso, tendrá un conjunto activo que ya no cabe en la memoria principal de su máquina. En este caso, el rendimiento de un motor de almacenamiento mal diseñado disminuirá rápidamente. Sin embargo, InnoDB de MySQL (o el motor de almacenamiento de Postgres) todavía le permitirá mantener (dependiendo de la distribución de su solicitud) una relación de datos a memoria de ~ 2: 1-5: 1 con un disco giratorio. Una vez que haya ido más allá de eso, el rendimiento comienza a disminuir rápidamente (a medida que realiza múltiples búsquedas de discos para cada solicitud). Ahora, su mejor curso de acción es simplemente actualizar a SSD (unidades de estado sólido), lo que, nuevamente, le permite saturar su tarjeta Ethernet * antes * de que la base de datos se convierta en una limitación.

Finalmente, cuando llegue al tamaño del conjunto de datos que no se ajusta, por ejemplo, varios SSD en una configuración de incursión de software 1 + 0 (mientras le da espacio para copias de seguridad, múltiples versiones de datos, etc.), entonces debe escalar horizontalmente . Es decir, tendrá que usar una base de datos que soporte intrínsecamente el particionamiento (por ejemplo, Riak, Voldemort, Cassandra, HBase) o construir una capa de particionamiento a nivel de aplicación sobre su almacén de datos basado en MySQL / Postgres. No puedo decirte qué solución es correcta, ya que ni yo (ni tú) tenemos idea de cómo serán tus datos y sus patrones de acceso en ese momento. Dicho esto, escribir su propia capa de fragmentación es otro lugar donde puede introducir errores adicionales en el código: no tener que construir su propia base de datos distribuida (lo que efectivamente está haciendo al construir una capa de fragmentación) es el mayor atractivo de usar una existente , base de datos escalable NoSQL.

Tenga en cuenta que todavía no estoy poniendo en juego el teorema CAP. La razón es que el CAP en sí mismo no tiene nada que ver con la escalabilidad, sino con la disponibilidad y el manejo de fallas. Lo que significa es que, bajo ciertos escenarios de falla (llamados Particiones, que no deben confundirse con la partición de bases de datos), no puede retener la disponibilidad de A y proporcionar una coherencia de C linealizable al mismo tiempo. La consistencia linealizable corresponde aproximadamente a A e I en ACID. Esto tiene más que ver con la replicación de una sola entidad (por ejemplo, una fila en una base de datos) en varias máquinas, con la partición horizontal ya es difícil (por otras razones) realizar transacciones entre varias entidades en una base de datos.

Es un error común pensar que las bases de datos SQL “eligen C” y las bases de datos “NoSQL” “eligen A”. En realidad, creo que varias bases de datos SQL * no * usan de manera predeterminada el nivel de aislamiento de transacciones “serializables” (eligiendo en su lugar el aislamiento de instantáneas) incluso en una sola máquina. Cuando se usa la replicación asincrónica de MySQL, es posible estar en un escenario en el que una máquina maestra recibe una escritura, permite a los lectores ver la escritura y luego baja * antes * de enviar este valor a otra réplica, es decir, perder la consistencia serializable cuando la otra se lee la réplica (en caso de falla del maestro).

Mientras tanto, muchas bases de datos NoSQL (p. Ej., HBase) en realidad no proporcionan disponibilidad “cap-A” (a cambio de operaciones de mutación atómica / comparar y establecer, p. Ej., Incrementar atómicamente una columna dentro de una fila en HBase) o permiten configurarse (por ejemplo, Voldemort o Riak configurados para requerir quórums de lectura y escritura estrictos) por coherencia en lugar de disponibilidad (por ejemplo, para aplicaciones como contadores).

También hay una variable oculta en CAP: latencia. Si simplemente puede volver a intentar su operación hasta que se elija un nuevo nodo maestro o vuelva a estar en línea (que generalmente es rápido ya que la mayoría de las fallas son transitorias), tendrá una alta disponibilidad de A y una consistencia de C, como puede. simplemente espere a que termine la partición P (esta vez se llama “MTTR”). Eso, obviamente, no es una opción para sitios grandes: los usuarios harán clic si esperan demasiado tiempo para que se carguen las páginas, se perderá dinero si no se pueden agregar artículos a los carritos de compras o no se pueden mostrar anuncios. Sin embargo, eso no es necesariamente una preocupación cuando sus volúmenes de tráfico no son significativos: nuevamente, esta es una decisión comercial.

¿Qué compensaciones de CAP eliges? Eso, nuevamente, depende de su aplicación y sus datos. Puede observar que muchas aplicaciones grandes (p. Ej., Sitios web complejos) usan una combinación de ambas (consistencia sólida para algunas operaciones, alta disponibilidad para otras), según los requisitos del negocio.

( Nota: estoy simplificando excesivamente y hablando en el contexto de un solo centro de datos. Cuando tiene una replicación en una WAN, la coherencia fuerte se vuelve poco práctica (los costos de latencia son prohibitivos), es por eso que HBase admite el envío de registros para permitir la replicación asincrónica a un sitio remoto).

Resumen: comprenda sus datos y aplicaciones, y * luego * planifique para proporcionar escalabilidad y alta disponibilidad para sus datos y aplicaciones. Si tiene curiosidad intelectual sobre sistemas distribuidos y problemas como CAP et al, consulte las respuestas en ¿Cuáles son los mejores recursos para aprender sobre sistemas de archivos distribuidos?

[Descargo de responsabilidad: trabajo en una base de datos “NoSQL”]

MongoDB resuelve algunos problemas y dificultades específicos sobre MySql o PgSql. Es bueno tener una idea del desafío que está viendo como desarrollador o creador de una solución.

MongoDB puede ayudar con algunos de los siguientes escenarios:

• Esperando una gran carga de escritura en la base de datos:
  Existen medidas de seguridad en las transacciones de datos, sin embargo, Mongodb puede funcionar muy bien con valores de inserción altos de datos.
• Alta demanda por fuentes menos confiables:
  La idea de tener conjuntos de datos de réplica ofrece opciones muy interesantes para que el desarrollador trabaje. Mongodb puede hacerlo bien con Master-Slaves escenarios Master-Slaves . Especialmente teniendo recuperaciones instantáneas de conexiones caídas o casos similares.
• Las bases de datos de fragmentación pueden volverse engorrosas después de un tiempo cuando se usa MySql. Bueno, inicialmente la idea de tener límites de rendimiento es un problema con una sola tabla de base de datos en MySql que alcanza 5-10 GB por tabla. MongoDB tiene soluciones integradas para este escenario.
• En el punto anterior mencioné las opciones que MongoDB abre para escenarios Master-Slave. Bueno, la base de datos puede estar basada en la ubicación, por ejemplo, en situaciones de tener diferentes versiones del producto ejecutándose por ubicaciones, Mongo también ha incorporado cosas para esto.
• Gran conjunto de datos donde el esquema es inestable. A veces, los desarrolladores comienzan con 1 Gb de datos, aunque todavía no están seguros del conjunto de datos inicial. Quizás este sea un buen momento para elegir MongoDb, un almacén de datos sin esquema sobre cualquier otro RDBMS.

Tenga en cuenta que lidiar con Big data sigue siendo un problema, eso no significa que solo usar MongoDb resolverá todos los problemas.

Personalmente, he decidido usar PostgreSQL y MongoDB en la misma solución a veces, cada uno para su propia carga de trabajo.

Por lo general, no comparo soluciones como estas, porque, como dije, cada una es propia, pero es bueno tener una idea de cómo funciona:

Hay otras cosas que pueden hacer mejor que MongoDB también, pero cada una tiene su propio costo:

Fuente: NoSQL Benchmarks de rendimiento: Cassandra vs HBase vs MongoDB vs Redis vs MySQL | Planeta cassandra

Aquí hay algunas charlas que podrían ayudarlo a comprender mejor su elección:

• Introducción a MongoDB – O’Reilly Webcast

Además, hay un AMA en curso con el CTO de MongoDB, Eliot Horowitz, en este momento [5 / feb / 15]. Quizás puedas hacerle personalmente tus preguntas 🙂

Advertencia: en lo que respecta a las “ventajas”, vale la pena mencionar que el viejo adagio sobre la “herramienta adecuada para el trabajo correcto” se aplica tanto si se habla de tecnología más antigua como de lo más nuevo y actual (una posición que actualmente ocupa NoSQL en general) .

Con el descargo de responsabilidad fuera del camino, el modelo no relacional tiene ventajas palpables para la aplicación web típica y abre nuevas oportunidades al ocupar la posición en la pila donde mysql solía sentarse. La razón de esto es la naturaleza dinámica del desarrollo de aplicaciones web. Las características a menudo cambian con iteraciones en los comentarios de los usuarios. Estas características nuevas y diferentes a menudo tienen requisitos de persistencia diferentes que deben ajustarse al esquema de base de datos existente.

MongoDB es perfectamente adecuado para eso. De alguna manera, es la mejor caída en el reemplazo no relacional para una base de datos relacional como MySQL, ya que pone el mayor esfuerzo para facilitar la transición. Lo que obtienes es libertad para cambiar tu esquema de datos sobre la marcha: no hay columnas con nombre con tipos de datos fijos. Esencialmente, puede poner cualquier “material” en un documento, y los documentos dentro de una colección (el equivalente mongo de una tabla) no necesitan tener representaciones consistentes. Un documento puede tener muchas claves, mientras que otro solo tiene algunas.

Otra gran funcionalidad lista para usar de Mongo para aplicaciones web es su replicación y fragmentación incorporadas. El sistema está diseñado para escalar a medida que crecen las necesidades y también tiene soporte nativo para la replicación con una configuración mínima. Esto es crítico en el entorno típico de aplicaciones donde la redundancia y la capacidad de responder a los picos de tráfico a menudo pueden salvar el día.

No se puede enfatizar lo suficiente como para que elija la herramienta adecuada: si está escribiendo una pasarela de finanzas que requiere atomicidad transaccional y un tipo de datos sólido con un esquema fijo, obviamente no fuerce esta clavija cuadrada a través de ese agujero redondo y use un Base de datos SQL Sin embargo, para el dominio del problema típico representado por una aplicación web / móvil de uso general orientada al consumidor, NoSQL ahorra tiempo y dolores de cabeza, especialmente MongoDB.

Depende de lo que estés tratando de lograr.
Sospecho que realmente estás haciendo la pregunta NoSQL vs Relacional.
En pocas palabras, MongoDB es más adecuado para sistemas altamente transaccionales en los que desea poder actualizar o leer datos especificando una clave y recuperando una carga de datos, todo en un gran bulto, por ejemplo. Detalles de la cuenta en un sitio web. También encaja bien con sistemas en los que la estructura de datos puede evolucionar rápidamente, y no desea estar demasiado atado con tener que evolucionar cuidadosamente las estructuras de datos. Es un poco más complicado hacer que sea compatible con ACID si desea registrar las acciones de los equipos financieros, pero no imposible.
MySQL se adapta mejor a los modelos de datos estructuralmente complejos donde la usabilidad de los datos es clave, y particularmente donde le gustaría poder consultar los datos de manera fácil y flexible, por lo que si la presentación de informes de muchas maneras es una consideración importante, esta puede ser la más fácil opción inicialmente. También es excelente cuando desea utilizar el gran banco de desarrolladores que conocen las herramientas ORM. Finalmente, por el momento, si desea probar una idea a bajo precio, es más barato (con más proveedores) obtener un proveedor de alojamiento que ofrezca MySQL que ofertas basadas en NoSQL como MongoDB.
Si sospecha que puede tener que escalar rápidamente a grandes cantidades de tipos de datos muy similares y la estructura de datos es razonablemente simple, entonces podría tener sentido seguir el enfoque de MongoDB y ahorrarse un poco de reingeniería posterior.

Estas son algunas de las preguntas que debe hacerse al tomar esta decisión:

1) ¿Será más conveniente almacenar sus datos en un formato RDMBS tradicional o en el formato de almacén de documentos más flexible de MongoDB?
2) ¿Le importa el aislamiento estricto de las transacciones de la base de datos?
3) ¿Cuán grandes serán sus datos? Si la respuesta es “muy grande”, ¿podría serle útil el fácil soporte de MongoDB para la replicación / fragmentación?
4) ¿En qué lenguaje / marco está desarrollando su aplicación? ¿Tiene buen soporte para MongoDB (casi todo debería tener buen soporte para MySQL)
5) ¿Va a querer hacer uniones en el nivel del almacén de datos (o hacer que el almacén de datos imponga restricciones de clave externa)? MongoDB no admite esto (porque las uniones son generalmente una mala idea de todos modos si tiene grandes necesidades de escala)
6) ¿Cuál es su nivel de tolerancia al riesgo? Es más probable que encuentre errores u otros problemas inesperados con MongoDB, ya que es mucho más nuevo (dicho esto, el equipo de 10gen es increíble para solucionar las cosas rápidamente cuando las personas se encuentran con problemas)

Creo que debería dejar de optimizar su sitio web para usar una base de datos nosql hasta que descubra un problema de rendimiento. Su base de datos tendrá que recibir una gran cantidad de escrituras antes de que una base de datos relacional sea un problema. Se puede manejar cualquier cantidad de lecturas mediante la replicación.

El rendimiento entre postgres y mysql dependerá en gran medida de la configuración. Le sugiero encarecidamente que instale ambos, ejecute algunas pruebas e intente optimizarlos. Si está utilizando un marco como Django que generará sus tablas por usted, puede ejecutar fácilmente su código en MySQL o PostgreSQL con solo un cambio de configuración.

Como no estoy al día con el estado exacto de todas las funciones en MySQL, mi razón principal por la que le recomendaría que use PostgreSQL en lugar de MySQL es porque Postgres tiene DDL transaccional. En otras palabras, si está implementando un gran cambio e intenta ejecutar el SQL en producción que crea un montón de tablas, agrega / elimina columnas y falla a la mitad. Postgres simplemente regresará al estado anterior de su base de datos. Por otro lado, MySQL lo dejará en algún lugar en medio de sus cambios. Si no puede solucionarlo rápidamente, tendrá que restaurar desde una copia de seguridad.
DDL transaccional en PostgreSQL: un análisis competitivo
MySQL 5.6 manual: 13.3.2 declaraciones que no se pueden revertir

La segunda ventaja que veo sobre MySQL es que Postgres tiene soporte para GIS, es decir, coordenadas GPS, por lo que puede escribir consultas que comparen la distancia entre dos puntos almacenados en la base de datos.
Objetos espaciales y geográficos para PostgreSQL
GeoDjango usa Postgis

Las bases de datos relacionales mantuvieron el liderazgo durante décadas y en ese momento la elección era bastante obvia, ya sea MySQL, Oracle o MS SQL, por nombrar algunas. Han servido como base para toneladas de aplicaciones empresariales, mientras que las aplicaciones modernas requieren más diversidad y escalabilidad. Las bases de datos no relacionales, como MongoDB, parecen cumplir con los requisitos existentes y reemplazar el entorno relacional actual.

MongoDB atrae a los usuarios con su filosofía abierta y simple, así como a la comunidad colaborativa y útil, mientras que los usuarios informan exactamente lo contrario con respecto a MySQL, después de la adquisición de Oracle. Otro problema con este último es el enfoque del propietario en el desarrollo de MariaDB junto con la negativa a aceptar parches de la comunidad y proporcionar un plan de sostenibilidad. Estos factores han provocado un punto muerto, aunque MySQL sigue siendo la solución para múltiples empresas en todo el mundo.

Al comparar la velocidad de MongoDB con MySQL, los desarrolladores observan que este último carece de velocidad y experimenta dificultades con grandes volúmenes de datos, por lo que será una mejor opción para las empresas con bases de datos más pequeñas y que buscan una solución más general. Si bien esta es una de las ventajas de MongoDB sobre MySQL: la capacidad de hacer frente a grandes cantidades de datos no estructurados.

Para responder a la pregunta principal: “¿cuándo usar MongoDB en lugar de MySQL?”, Debe tener en cuenta los requisitos de su proyecto y otros objetivos. MySQL es bien reconocido por su alto rendimiento, flexibilidad, protección de datos confiable, alta disponibilidad y facilidad de administración. La indexación de datos adecuada puede resolver el problema con el rendimiento, facilitar la interacción y garantizar la solidez. Pero si sus datos son desestructurados y complejos, o si no puede predefinir su esquema, será mejor que opte por MongoDB. Y lo que es más, si necesita manejar un gran volumen de datos y almacenarlos como documentos, MongoDB lo ayudará a enfrentar los desafíos.

Esta publicación apareció originalmente en el sitio web DA-14. Lee la publicación original aquí .

Para más publicaciones, consulte el blog de la compañía Solar Digital.

Si te gusta el comentario, ¡vota!

Hemos creado un sistema para la segunda comunidad de moda en línea más grande. Después de leer muchos artículos, parece que Redis y Cassandra son las capas de almacenamiento más utilizadas.

Es más fácil comenzar con Redis. Sin embargo, Cassandra es:

• Rentable debido al almacenamiento en disco
• Más fácil de fragmentar

Personalmente, creo que Cassandra es ideal para los sistemas de alimentación basados ​​en empuje.

Sin embargo, hacer la implementación correcta es un poco complicado, nuestros consejos:

• Cassandra> 2.0
• Usar datastax / python-driver
• Recorte inteligente tschellenbach / Feedly
• insertos por lotes no registrados Documentación DataStax CQL 3.0

Hemos abierto nuestro enfoque. Se llama Feedly y está disponible en Github (Feedly)
Creo que actualmente es la solución de código abierto más grande dirigida a este problema.
Del mismo equipo también hay una API alojada disponible en https://getstream.io

Los siguientes artículos me resultaron muy útiles al configurar nuestra arquitectura:

Twitter 2013 Redis, base de datos alternativa, muy similar al antiguo enfoque de Fashiolista.
Decisiones de diseño para escalar sus fuentes de alto tráfico – Alta escalabilidad –
Escala de alimentación de Etsy (Gearman, pasos de puntuación y agregación separados, acumulaciones: agregación, segunda parte)
Historia de Facebook
Proyecto Django, con buenas convenciones de nomenclatura.
Atom Activity Streams 1.0 (actor, verbo, objeto, objetivo)
Publicación de Quora sobre mejores prácticas
Quora escalando un feed de red social
Redis ruby ​​ejemplo
Enfoque de FriendFeed
Configuración Thoonk
Documento de investigación de Yahoo
Enfoque de Twitter
Cassandra en Instagram

PD.
El usuario 12631156322967250682 está seguro de que Facebook utiliza un enfoque basado en extracción para su feed. Supongo que hacen un despliegue a una alimentación temporal. Y calcule la alimentación agregada y de relevancia después. ¿Pero tal vez tienes algún conocimiento interno? 🙂

“Mejor” no es un gran término para usar cuando se comparan dos cosas que no son similares. MySQL es una base de datos relacional y MondoDB es una base de datos orientada a documentos.

Cada tipo de base de datos tiene un propósito diferente y satisface una necesidad diferente. Por ejemplo, uso bases de datos relacionales cuando la integridad referencial es MUY importante entre los tipos de elementos que se almacenan en una base de datos. Las bases de datos relacionales también son muy agradables cuando desea transferir parte de su procesamiento lógico a la base de datos, a través de disparadores, por ejemplo, aunque esta necesidad parece estar disminuyendo en estos días.

Sin embargo, las bases de datos orientadas a documentos son mucho mejores con conjuntos de datos muy grandes en los que los elementos en la base de datos están bien con las relaciones administradas por el código que interactúa con la base de datos. También encuentro que las bases de datos orientadas a documentos no son las mejores para informar / resumir las necesidades de datos. Esto se debe al hecho de que no implementan una interfaz SQL de la que dependen la mayoría de los sistemas de informes externos.

La decisión de utilizar una base de datos relacional frente a una base de datos de objeto es algo que debe dictar los requisitos de sus aplicaciones. Hay ventajas y desventajas para ambos y la necesidad debe determinar la herramienta. En mi aplicación actual, en realidad estoy usando una combinación de ambos, ya que cada uno cumple una función en mi aplicación.

Una gran desventaja en mi opinión es el uso liberal de MongoDB de bloqueos de escritura globales. En una tabla MySQL configurada por la propiedad, es posible lograr el bloqueo a nivel de fila y, en el peor de los casos, el bloqueo a nivel de tabla. Para la mayoría de las operaciones en MongoDB, requiere el uso de un bloqueo de escritura global, por ejemplo, no hay bloqueo de nivel de colección. Aunque en versiones recientes, más notablemente 1.8 y 2.0, han agregado más rendimiento (capacidad de renunciar temporalmente al bloqueo de escritura global), todavía es insuficiente y algunas consultas pueden bloquear toda su base de datos hasta su finalización, especialmente a largo plazo, grande El mapa de la huella reduce los empleos.

Otra característica que muchos usuarios nuevos de MongoDB pasan por alto es que el sistema operativo gestiona completamente el almacenamiento en caché. Esto es genial porque significa que puede usar toda la RAM disponible en su caja para almacenar en caché los datos sin establecer y ajustar explícitamente los tamaños de caché, como es típico de los entornos MySQL. La desventaja es que es mucho más fácil hacer que el sistema operativo libere páginas almacenadas en caché, lo que hace que MongoDB pueda potencialmente paginar en el disco. Por ejemplo, agrupar un archivo de registro grande podría hacer que desaparezca una gran parte de los datos de MongoDB en el caché del sistema de archivos.

En mi opinión, no hay muchas ventajas al usar MongoDB, excepto por sus características de auto-fragmentación y la falta de esquema (no necesita instrucciones ALTER). Sin embargo…

En mi experiencia decepcionante (alrededor de 2013) con MongoDB, las funciones de intercambio de múltiples nodos de MongoDB son propensas a fallas y los diversos controladores de idioma (Php, Node, Runy) son increíblemente complejos y presentan errores, especialmente cuando se conectan a un nuevo primario. Por esas razones, MongoDB no es la bala de plata para escalar rápidamente como dice ser.

Además, la falta de esquema puede ser un gran problema si no se tiene cuidado porque los tipos se pueden ordenar incorrectamente después de la inserción y luego se espera que sean algo que no son. Por ejemplo, podría insertar “0” en lugar de 0 o nulo en lugar de un no nulo, etc. Si tiene varios idiomas trabajando con un solo clúster mongo, tendrá que duplicar todo su código de clasificación para tener consistencia . Con SQL, la base de datos aplica el esquema por usted.

En general, yo diría que quédese con ActiveRecord y Postgres porque es muy fácil y es poco probable que a escala necesite funciones de auto-fragmentación.