MongoDB 2.2 Released

MongoDB
August 29, 2012
#Releases

We are pleased to announce the release of MongoDB version 2.2.  This release includes over 1,000 new features, bug fixes, and performance enhancements, with a focus on improved flexibility and performance. For additional details on the release:

New Features

Aggregation Framework

The Aggregation Framework is available in its first production-ready release as of 2.2. The aggregation framework makes it easier to manipulate and process documents inside of MongoDB, without needing to useMap Reducez,/span>, or separate application processes for data manipulation.

See the aggregation documentation for more information.

Additional “Data Center Awareness” Functionality

2.2 also brings a cluster of features that make it easier to use MongoDB for larger more geographically distributed contexts. The first change is a standardization of read preferences across all drivers and sharded (i.e. mongos) interfaces. The second is the addition of “tag aware sharding,” which makes it possible to ensure that data in a geographically distributed sharded cluster is always closest to the application that will use that data the most.

Improvements to Concurrency

v2.2 eliminates the global lock in the mongod process.  Locking is now per database.  In addition a new subsystem avoids locks under most page-fault events; thus concurrency improves even on systems with a single database.   Parallelism in application of writes on secondaries is enhanced also.  See this video for more details.

We’re looking forward to your feedback on 2.2. Keep the Jira Issues, blog posts, user group posts, and tweets coming.

- Eliot and the 10gen/MongoDBteam

Like what you see? Get MongoDB updates straight to your inbox

← Previous

Forward Intel uses Mongo for ...causalâ?? analytics

This was originally posted to the Forward Intel blog Forward Intelligence Systems has chosen MongoDB to serve as the backend datastore to support DataPoint , a new analytics system designed to reveal deeper meaning behind typical business intelligence data. Endless tables, graphs and charts are replaced with simple decision-aiding ...plain English analytics“ to help make the job of the business analyst and company owner quicker and easier. DataPoint is designed to run on top of existing analytics systems like Google Analytics, Piwik, Open Web Analytics and HubSpot. Using the hosted solution, users simply connect their analytics account to their DataPoint profile and the application does the rest. DataPoint will import the data from multiple sources and will identify trends and patterns, removing the guesswork out of why a web site may have seen a decrease in traffic in the month of July. Using Bayesian math, DataPoint determines the causal relationship between an event and its most likely cause. MongoDB is a powerful semi-structured database engine built to withstand the increased traffic that today's web applications endure. It is fast, light-weight and extremely scalable, making it a clear and convincing choice for large scale business intelligence and analytics systems. Mongo stores data using a key/value paradigm within entities known as ...documents“, and queried using simple and straight-forward syntax similar to that of Structured Query Language (SQL). Mongo is schema-less, which means database developers are not confined to the typical column and row structure of relational databases. Dynamic data structures are essential for managing big data applications. Further - and critical to its power and flexibility - Mongo contains support for MapReduce, which is an engine that allows for rapid processing of large amounts of data. Implementing algorithms designed to chug through incredibly large volumes of data simply would not be feasible without Mongo's batch processing support. ...At Forward Intel, we're incredibly excited to start using MongoDB,“ said the company's CEO, Steve Adcock. “Mongo's recent award of over $40 million to further its development ensures that it is here to stay, and we are confident that Mongo will serve us quite well.“ Tagged with: analytics, production uses, mongodb good, MongoDB, Mongo, NoSQL, Polyglot persistence, 10gen

August 28, 2012
Next →

Construyendo con patrones: un resumen

Al concluir la serie Construyendo con patrones, es una buena oportunidad para recapitular los problemas que resuelven los patrones que se han cubierto y resaltar algunos de los beneficios y compensaciones que tiene cada patrón. La pregunta más frecuente que se hace sobre los patrones de diseño de esquemas es "Estoy diseñando una aplicación para hacer X, ¿cómo modelo los datos?" Como esperamos que haya descubierto a lo largo de esta serie de blogs, hay muchas cosas a tener en cuenta para responder a esa pregunta. Sin embargo, hemos incluido un gráfico de casos de uso de muestra que nos ha parecido útil para al menos proporcionar una guía inicial sobre patrones de modelado de datos para casos de uso genéricos. Casos de uso de muestra El siguiente cuadro es una guía de lo que hemos encontrado después de años de experiencia trabajando con nuestros clientes sobre qué patrones de diseño de esquemas se utilizan en una variedad de aplicaciones. Este no es un conjunto de reglas “escritas en piedra” sobre qué patrón de diseño se puede utilizar para un tipo particular de aplicación. Asegúrese de mirar los que se usan con frecuencia en su caso de uso. Sin embargo, no descartes los demás, es posible que aún se apliquen. La forma en que diseña el esquema de datos de su aplicación depende en gran medida de sus patrones de acceso a los datos. Resúmenes de patrones de diseño Aproximación El patrón de aproximación es útil cuando con frecuencia se realizan cálculos costosos y cuando la precisión de esos cálculos no es la máxima prioridad. Ventajas Menos escrituras en la base de datos. Mantener números estadísticamente válidos. Contras No se representan números exactos. La implementación debe realizarse en la aplicación. Atributo El patrón de atributos es útil para problemas que se basan en tener documentos grandes con muchos campos similares, pero hay un subconjunto de campos que comparten características comunes y queremos ordenar o consultar ese subconjunto de campos. Cuando los campos que necesitamos ordenar solo se encuentran en un pequeño subconjunto de documentos. O cuando ambas condiciones se cumplen en los documentos. Ventajas Se necesitan menos índices. Las consultas se vuelven más sencillas de escribir y, en general, más rápidas. Balde Patron de cubo es una excelente solución cuando se necesita gestionar la transmisión de datos, como series temporales, análisis en tiempo real o aplicaciones de Internet de las cosas (IoT). Ventajas Reduce el número total de documentos de una colección. Mejora el rendimiento del índice. Puede simplificar el acceso a los datos aprovechando la agregación previa. Calculado Cuando hay patrones de acceso a datos intensivos en lectura y la aplicación debe calcular los datos repetidamente, el patrón calculado es una excelente opción para explorar. Ventajas Reducción de la carga de trabajo de la CPU para cálculos frecuentes. Las consultas se vuelven más sencillas de escribir y, en general, más rápidas. Contras Puede resultar difícil identificar la necesidad de este patrón. Se debe evitar aplicar o abusar del patrón a menos que sea necesario. Versiones de documentos Cuando se enfrenta a la necesidad de mantener versiones anteriores de documentos en MongoDB, el patrón de control de versiones de documentos es una posible solución. Ventajas Fácil de implementar, incluso en sistemas existentes. No hay impacto en el rendimiento de las consultas sobre la última revisión. Contras Duplica el número de escrituras. Las consultas deben dirigirse a la colección correcta. Referencia extendida Encontrará que el patrón de referencia extendida es más útil cuando su aplicación experimente muchas operaciones JOIN para reunir datos a los que se accede con frecuencia. Ventajas Mejora el rendimiento cuando hay muchas operaciones JOIN. Lecturas más rápidas y reducción del número total de JOIN. Contras Duplicación de datos. Parte aislada ¿Le parece que hay algunas consultas o documentos que no encajan en el resto de sus patrones de datos típicos? ¿Estas excepciones impulsan la solución de su aplicación? Si es así, el patrón de valores atípicos es una solución maravillosa para esta situación. Ventajas Evita que algunos documentos o consultas determinen la solución de una aplicación. Las consultas se adaptan a casos de uso "típicos", pero aún se abordan los valores atípicos. Contras A menudo se adaptan a consultas específicas, por lo que es posible que las consultas ad hoc no funcionen bien. Gran parte de este patrón se realiza con código de aplicación. Preasignación Cuando conoce la estructura de su documento y su aplicación simplemente necesita llenarla con datos, el patrón de asignación previa es la opción correcta. Ventajas Simplificación del diseño cuando se conoce de antemano la estructura del documento. Contras Simplicidad versus rendimiento. Polimórfico El Patrón Polimórfico es la solución cuando hay una variedad de documentos que tienen más similitudes que diferencias y los documentos necesitan mantenerse en una sola colección. Ventajas Fácil de implementar. Las consultas pueden ejecutarse en una única colección. Control de versiones de esquemas Prácticamente todas las aplicaciones pueden beneficiarse del patrón de control de versiones del esquema , ya que con frecuencia se producen cambios en el esquema de datos durante la vida útil de una aplicación. Este patrón permite que las versiones anterior y actual de documentos existan una al lado de la otra en una colección. Ventajas No se necesita tiempo de inactividad. Control de migración de esquemas. Reducción de la deuda técnica futura. Contras Es posible que necesite dos índices para el mismo campo durante la migración. Subconjunto El patrón de subconjunto resuelve el problema de que el conjunto de trabajo exceda la capacidad de la RAM debido a documentos grandes en los que gran parte de los datos del documento no están siendo utilizados por la aplicación. Ventajas Reducción del tamaño total del conjunto de trabajo. Tiempo de acceso al disco más corto para los datos utilizados con más frecuencia. Contras Debemos gestionar el subconjunto. Obtener datos adicionales requiere viajes adicionales a la base de datos. Árbol Cuando los datos tienen una estructura jerárquica y se consultan con frecuencia, el patrón de árbol es el patrón de diseño a implementar. Ventajas Mayor rendimiento al evitar múltiples operaciones JOIN. Contras Las actualizaciones del gráfico deben gestionarse en la aplicación. Conclusión Como esperamos que haya visto en esta serie, el modelo de documento de MongoDB proporciona mucha flexibilidad en la forma de modelar datos. Esa flexibilidad es increíblemente poderosa, pero ese poder debe aprovecharse en términos de los patrones de acceso a datos de su aplicación. Recuerde que el diseño de esquemas en MongoDB tiene un impacto tremendo en el rendimiento de su aplicación. Hemos descubierto que los problemas de rendimiento con frecuencia se deben a un diseño deficiente del esquema. Tenga en cuenta que para mejorar aún más el poder del modelo de documento, estos patrones de diseño de esquema se pueden usar juntos, cuando y si tiene sentido. Por ejemplo, el control de versiones de esquemas se puede utilizar junto con cualquiera de los otros patrones a medida que evoluciona la aplicación. Con los doce patrones de diseño de esquemas que se han cubierto, usted tiene las herramientas y el conocimiento necesarios para aprovechar el poder de la flexibilidad del modelo de documento.

October 2, 2023