Conceptos básicos. Seminario web 6: Despliegue de producción
•Als PPTX, PDF herunterladen•
2 gefällt mir•1,609 views
Este es el último seminario web de la serie Conceptos básicos, en la que se realiza una introducción a la base de datos MongoDB. En este seminario web le guiaremos por el despliegue en producción.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Conceptos básicos. Seminario web 6: Despliegue de producción
Ähnlich wie Conceptos básicos. Seminario web 6: Despliegue de producción (20)
Mehr von MongoDB
Mehr von MongoDB (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Conceptos básicos. Seminario web 6: Despliegue de producción
- 2. MongoDBEurope2016 Old Billingsgate, London 15th November Use my code rubenterceno20 for 20% off tickets mongodb.com/europe
- 3. Conceptos Básicos 2016 Despliegue en Producción Rubén Terceño Senior Solutions Architect, EMEA ruben@mongodb.com @rubenTerceno
- 4. Agenda del Curso Date Time Webinar 25-Mayo-2016 16:00 CEST Introducción a NoSQL 7-Junio-2016 16:00 CEST Su primera aplicación MongoDB 21-Junio-2016 16:00 CEST Diseño de esquema orientado a documentos 07-Julio-2016 16:00 CEST Indexación avanzada, índices de texto y geoespaciales 19-Julio-2016 16:00 CEST Introducción al Aggregation Framework 28-Julio-2016 16:00 CEST Despliegue en producción
- 5. Resumen de lo visto hasta ahora • ¿Porqué existe NoSQL? • Características clave de MongoDB • Instalación y creación de bases de datos y colecciones • Operaciones CRUD, Índices y explain() • Diseño de esquema dinámico • Jerarquía y documentos embebidos • Búsquedas de texto libre y geoespaciales • Pipeline de Agregación
- 6. Production Checklist •Alta Disponibilidad •Escalabilidad Horizontal •Monitorización y Performance Tuning •Backup y Recovery •Seguridad
- 7. Replica Sets • Replica set – 2 to 50 copies • Replica sets make up a self-healing ‘shard’ • Data center awareness • Replica sets address: • High availability • Data durability, consistency • Maintenance (e.g., HW swaps) • Disaster Recovery Application Driver Primary Secondary Secondary Replication
- 8. Replica Sets – Workload Isolation • Replica sets enable workload isolation • Example: Operational workloads on the primary node, analytical workloads on the secondary nodes eCommerce Application MongoDB Primary In-memory Storage Engine MongoDB Secondary WiredTiger Storage Engine User Data Sessions, Cart, Recommendations MongoDB Secondary WiredTiger Storage Engine Persisted User Data
- 9. Node 1 Node 2 Node 3 Replica Set Creation
- 10. Node 1 (Primary) Node 2 (Secondary) Node 3 (Secondary) Replication Replication Heartbeat Replica Set - Initialize
- 11. Node 2 (Secondary) Node 3 (Secondary) Heartbeat Primary Election Node 1 (Primary) Replica Set - Failure
- 12. Node 1 (Primary) Node 2 (Primary) Node 3 (Secondary) Heartbeat Replication Replica Set - Failover
- 13. Node 2 (Primary) Node 3 (Secondary) Heartbeat Replication Node 1 (Recovery) Replication Replica Set - Recovery
- 14. Node 2 (Primary) Node 3 (Secondary) Heartbeat Replication Node 1 (Secondary) Replication Replica Set - Recovered
- 15. writeConcern & readConcern • writeConcern • Configurable level of acknowledgement • { w: <value>, j: <boolean>, wtimeout: <number> } • w 1, n, majority, tag • readConcern • Configurable level of read isolation • readConcern: { level: <"majority"|"local"> }
- 16. Node 1 (Primary) Node 2 (Secondary) Node 3 (Secondary) Application Driver Read and write Strong Consistency
- 17. Node 1 (Primary) Node 2 (Secondary) Node 3 (Secondary) Application Driver Strong Consistency Read Read Read and write
- 18. readPreference • Read preference describes how MongoDB clients route read operations to the members of a replica set. • primary • primaryPreferred • secondary • secondaryPreferred • nearest • tags
- 19. Elastic Scalability: Automatic Sharding • Increase or decrease capacity as you go • Automatic load balancing • Three types of sharding • Hash-based • Range-based • Tag-aware Shard 1 Shard 2 Shard 3 Shard N Horizontally Scalable
- 20. Query Routing • Multiple query optimization models • Each of the sharding options are appropriate for different apps / use cases
- 21. Sharding key • Sharding key is the way MongoDB partition collections. • The range of the sharding key is split in several chunks. • The chunks are distributed evenly among the available shards
- 22. Selecting a sharding key • Probably the most influential decision on performance • A good sharding key has: • High cardinality • Evenly distributed frequency • A non-monotonic creation rate • And much more important: is used on queries. • Limitations • Sharding key is immutable • Sharding key values are immutable • Sharding key can’t be a multikey, geospatial or text index
- 23. Config servers and mongos • Config servers store metadata (chunk distribution and location) • The can be configured as a replica set from version 3.2 (CSRS) • Up to 50 config servers • Hardened failover • mongos acts as query routers • mongos keep a local copy of config server information • mongos can be deployed on the application server
- 24. Sharding, when? • Shard only when needed: • Vertical scalability is not possible anymore • RAM • CPU • IOPS • Concurrency • Depending on the server technology the range to start thinking in sharding is around a few Tb of data.
- 25. Monitoring • MongoDB offers tools for monitoring the cluster performance • mongostats • Shows operations per second, memory usage, page faults, queues and more • mongotop • Provides statistics on a per collection basis • Mongo Shell • db.serverStatus() • db.serverStatus({ workingSet : 1 })
- 26. Profiling • Database profiler • db.setProfilingLevel(<level>,slowOpThresholdMs) • level 0: Profiler off. Slow operations are always written to the log (default) • level 1: Collects data for operations slower than the threshold • level 2: Collect information for all operations • Profile info is on system.profile collection on admin database
- 27. Logs • Logs • db.setLogLevel(<level>, <component>) • level 0-5 : Different verbosity levels • level -1 : Inherits verbosity from parent • https://docs.mongodb.com/manual/reference/log-messages/#components • In order to analyze the log information you can use mtools • https://github.com/rueckstiess/mtools • Not supported by MongoDB, but built by MongoDB employees and used internally (a lot)
- 28. Backup – mongodump • Generates a BSON file and a JSON metadata file. • Better done from a secondary • Potentially generates inconsistent data • Lock the database during dump db.fsyncLock() & db.fsyncUnlock() • Disconnect a secondary node temporally • Use the -oplog and -oplogReplay options • mongodump -h myhost –oplog • mongorestore –h myhost –oplogReplay ./cms/dump • Simple but slow for both backup and restore
- 29. Backup – file system copy/snapshot • Copy files on your data directory • Lock the database first!! • Fastest way to restore • Challenging on a sharded environment • Disable the chunks balancer sh.setBalancerState(false) • Backup each shard • Backup the config servers
- 30. Security • MongoDB is unsecured by default • It’s up to you to use the provided security mechanism • Authentication Users, Certificates • Authorization Roles • Encrypt communications TLS/SSL • Limit network exposure bindIp • Use dedicated OS users. • … • Read the security checklist: https://docs.mongodb.com/manual/administration/security-checklist/
- 31. MongoDB – We’re here to help Security License SupportTooling Services
- 32. MongoDB Compass MongoDB Connector for BI MongoDB Enterprise Server MongoDB Enterprise Advanced CommercialLicense (NoAGPLCopyleftRestrictions) Platform Certifications MongoDB Ops Manager Monitoring & Alerting Query Optimization Backup & Recovery Automation & Configuration Schema Visualization Data Exploration Ad-Hoc Queries Visualization Analysis Reporting LDAP & Kerberos Auditing FIPS 140-2Encryption at Rest REST APIEmergency Patches Customer Success Program On-Demand Online Training Warranty Limitation of Liability Indemnification 24x7Support (1hourSLA)
- 33. MongoDB Atlas Database as a service for MongoDB MongoDB Atlas is… • Automated: The easiest way to build, launch, and scale apps on MongoDB • Flexible: The only database as a service with all you need for modern applications • Secured: Multiple levels of security available to give you peace of mind • Scalable: Deliver massive scalability with zero downtime as you grow • Highly available: Your deployments are fault-tolerant and self-healing by default • High performance: The performance you need for your most demanding workloads
- 34. Summary • Los Replica Sets permiten alta disponibilidad y facilitan las operaciones de mantenimiento. • writeConcern, readConcern y readPreference permiten controlar la persistencia y consistencia de los datos. • El sharding permite escalar horizontalmente • La selección de una buena clave de sharding es la clave. • MongoDB ofrece herramientas para monitorizar y controlar el rendimiento de la base de datos, así como para generar los backups • ¡La seguridad es lo primero! Usuarios, roles y encriptación • MongoDB proporciona todas la herramientas requeridas para operar su despliegue en producción con seguridad y de manera profesional.
- 35. ¿Ya no hay más webinars? • Sigue habiendo webinars en https://www.mongodb.com/webinars • Si quiere aprender más sobre mongodb: • University: https://university.mongodb.com/ • Si quiere demostrar el mundo lo que sabe: • Certificaciones: https://university.mongodb.com/exams • Si quiere conocer otras personas que usan mongodb: • MongoDB User Groups (MUGs): http://www.meetup.com/pro/mongodb/ • Denos su opinión, por favor: back-to-basics@mongodb.com
- 36. ¿Preguntas?
Hinweis der Redaktion
- Who I am, how long have I been at MongoDB.
- High Availability – Ensure application availability during many types of failures Meet stringent SLAs with fast-failover algorithm Under 2 seconds to detect and recover from replica set primary failure Disaster Recovery – Address the RTO and RPO goals for business continuity Maintenance – Perform upgrades and other maintenance operations with no application downtime Secondaries can be used for a variety of applications – failover, hot backup, rolling upgrades, data locality and privacy and workload isolation
- MongoDB provides horizontal scale-out for databases using a technique called sharding, which is trans- parent to applications. Sharding distributes data across multiple physical partitions called shards. Sharding allows MongoDB deployments to address the hardware limitations of a single server, such as bottlenecks in RAM or disk I/O, without adding complexity to the application. MongoDB automatically balances the data in the cluster as the data grows or the size of the cluster increases or decreases. MongoDB supports three types of sharding: • Range-based Sharding. Documents are partitioned across shards according to the shard key value. Documents with shard key values “close” to one another are likely to be co-located on the same shard. This approach is well suited for applications that need to optimize range- based queries. • Hash-based Sharding. Documents are uniformly distributed according to an MD5 hash of the shard key value. Documents with shard key values “close” to one another are unlikely to be co-located on the same shard. This approach guarantees a uniform distribution of writes across shards, but is less optimal for range-based queries. • Tag-aware Sharding. Documents are partitioned according to a user-specified configuration that associates shard key ranges with shards. Users can optimize the physical location of documents for application requirements such as locating data in specific data centers.
- Sharding is transparent to applications; whether there is one or one hundred shards, the application code for querying MongoDB is the same. Applications issue queries to a query router that dispatches the query to the appropriate shards. For key-value queries that are based on the shard key, the query router will dispatch the query to the shard that manages the document with the requested key. When using range-based sharding, queries that specify ranges on the shard key are only dispatched to shards that contain documents with values within the range. For queries that don’t use the shard key, the query router will dispatch the query to all shards and aggregate and sort the results as appropriate. Multiple query routers can be used with a MongoDB system, and the appropriate number is determined based on performance and availability requirements of the application.
- We offer a comprehensive suite of solutions and services to help you succeed with your MongoDB deployment. They include: Enterprise tooling enables your teams to operationalize MongoDB more efficiently. This includes monitoring, performance optimization, automation, & backup. Other products include a MongoDB GUI to make MongoDB accessible to your wider organization, a connector to your SQL-based BI platforms, and more. Enterprise security – we make it easier for you to protect your data and / or build compliant applications. Commercial License to help you protect your investments. Support – 24 x 7 enterprise-grade support from the same team that builds the database Services – specialized professional services packages for all teams throughout your development lifecycle, from design to production.
- Lists the specific security features in MongoDB Enterprise Server
- Built and managed by the same team that builds the database, MongoDB Atlas provides the features of MongoDB without the operational heavy lifting, enabling you to focus on what you do best.