MongoMK - A Scalable Storage Solution for AEM Using MongoDB
•Als PPTX, PDF herunterladen•
2 gefällt mir•1,863 views
Adobe Experience Manager helps you organize and manage the delivery of creative assets and other content across all of your digital marketing channels. MongoDB enables applications and system to scale beyond the ordinary assumptions in flexible and and agile way. Operating large scalable digital asset management system requires a certain understanding of how data is handled and how data is consumed. This talk his about how to make the most out of these 2 technologies: how to operate, maintain and optimize these system using the best practices and lessons learn from existing installation of AEM and MongoDB.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (9)
Ähnlich wie MongoMK - A Scalable Storage Solution for AEM Using MongoDB
Ähnlich wie MongoMK - A Scalable Storage Solution for AEM Using MongoDB (20)
Mehr von MongoDB
Mehr von MongoDB (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
MongoMK - A Scalable Storage Solution for AEM Using MongoDB
- 1. MongoMK
- 2. MongoDB MicroKernel • AEM 6 Scalable Storage Solution • Flexible • Multi-Datacenter Deployments • Geo Distributed Content • Auto-Failover
- 3. MongoMK Nodes Blobs Settings Changes ClusterNodes Metadata collection Content node structure Internal AEM indexes Multi version structures Blobs collection Binary file chunks Enforces data de-duplicationSettings, Changes, ClusterNodes Internal AEM collections Configuration and settings data
- 4. MongoMK - Content Metadata Binary / Blobs
- 5. Binary / Blobs MongoMK – Metadata Metadata
- 6. MongoMK – Data Model
- 7. MongoMK – Version Control Revisions of content are maintained as separate trees
- 8. MongoMK – Data Model
- 9. MongoMK – Versioning & Concurrency System provides version and concurrency control of content revisions.
- 10. MongoMK – Versioning & Concurrency
- 11. Binary / Blobs MongoMK – Binary Data Metadata
- 12. AEM Blob Storage TAR MONGODB S3
- 13. MongoMK - Blobs
- 14. MongoMK - Blobs
- 15. Scale
- 16. Why is MongoDB ideal for AEM? General Purpose Database Scalable Flexible Data Model High Availability out-of-the-box
- 17. Sizing
- 18. MONGODB SIZING Availability Volume Expected Latency Working Data Set
- 21. Sizing - Availability Author Publisher - Multiple Teams working on same content - 24/7 our 9/5 on single time zone - Backups and Maintenance Operations - User Generated Content - Geographical deployment - Application Latency SLA
- 22. Sizing - Availability AEM - author AEM - author AEM - author Primary Secondary Secondary Datacenter West Datacenter EastDatacenter Center AEM - authorAEM - author
- 23. Sizing - Availability AEM - author AEM - author AEM - author Primary Secondary Secondary Backups (hidden) Hot Backups (delayed)
- 24. Sizing - Volume Indexes Properties Multi Version Nodes
- 25. Sizing - Volume Full Text Search Indexes Blobs Binary Chunks
- 26. Sizing - Volume • Space required by – Data – Indexes • Read / Write Ratio • Computational Unit Capacity – RAM – Disk • Types of Disks! – CPU
- 27. Automatic Sharding Three types: hash-based, range-based, location-aware Increase or decrease capacity as you go Automatic balancing
- 28. Sizing – Working Set Working Set Rest of your Database
- 29. Sizing – Working Set • Percentage of data that is constantly request by the application – Indexes – Recent Used Data • Read / Write – Impacts the calculation of the RAM requirement • Working Set Should Fit In RAM
- 30. Working Set Not in RAM
- 31. Sizing – Working Set • AEM Calculation of Working Set –Internal MongoDB Indexes –Constantly accessed Assets • % of data access –AEM Indexes • Multi-version Indexes • Lucene Indexes
- 32. Working Set Can Be Distributed Across Shards
- 34. Deploy
- 35. Rules for a Good Deployment Prototype Test MonitorScale Automate
- 36. AEM + Ops Manager Scale EasilyMeet SLAs Best Practices, Automated Cut Management Overhead
Hinweis der Redaktion
- Collections Nodes: Nodes and properties Metadata information Blobs: Stores binary data Binary file chunks ClusterNodes: Cluster configuration data Settings: general application configuration data Changes: revision tracking
- Chops file into 258 block sizes Generates a SHA-256 of all individual , it's id Generates a diggest and stores it in nodes collection
- General purpose are ideal for Content Management Systems Rich Queries Secondary indexes … Flexible data model is also good for the concurrency management and version control Allows to scale the infrastructure and has HA out of the box
- Author Environment Multiple teams working on same assets ? Collaboration Validation Curation 24/7 or just working hours on specific timezone? Backups Maintenance operations Data Freshness Make sure you design your infrastructure for availability compliance RTO RPO Data Distribution Multi datacenter Disaster Recovery High Availability Functional Segregation Analytics workload Backups Secondary Reads
- Author Environment Multiple teams working on same assets ? Collaboration Validation Curation 24/7 or just working hours on specific timezone? Backups Maintenance operations Data Freshness
- High Availability – Ensure application availability during many types of failures 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
- Get some slides on MongoDB sizing
- Get some slides on MongoDB sizing
- Get some slides on MongoDB sizing
- Get some slides on MongoDB sizing
- Data Deduplication Lucene FTS indexes structure
- Get some slides on MongoDB sizing
- Get some slides on MongoDB sizing
- AEM can benefit from sharding but we still need to fine tune this it's implementation on multidatacenter setups. If you are restricted by the volume on a primary node and want to shard within a single datacenter we strongly advise you to do so. On Publishing nodes this is an effective way to scale your UGC data too.
- Get some slides on MongoDB sizing
- Get some slides on MongoDB sizing
- Get some slides on MongoDB sizing
- Get some slides on MongoDB sizing
- Reduce Latency Coolocation Secondary reads Indexation Selectivety Concurrency Model Compression
- AEM Nodes and MongoDB Can Be Decoupled Scaling Operational Test for Load How Many Assets Are We Dealing With Today How Many We Want In 6, 12, 24 months? Monitor Your AEM Nodes Load Number of concurrent users Number of operated assets Monitor Your MongoDB Nodes Active Data Set Disk Usage IO Scale!
- MMS can do a lot for [ops teams]. Best Practices, Automated. MMS takes best practices for running MongoDB and automates them. So you run ops the way MongoDB engineers would do it. This not only makes it more fool-proof, but it also helps you… Cut Management Overhead. No custom scripting or special setup needed. You can spend less time running and managing manual tasks because MMS takes care of a lot of the work for you, letting you focus on other tasks. Meet SLAs. Automating critical management tasks makes it easier to meet uptime SLAs. This includes managing failover as well as doing rolling upgrades with no downtime. Scale Easily. Provision new nodes and systems with a single click.