MongoDB World 2018: Breaking the Mold - Redesigning Dell's E-Commerce Platform
•Download as PPTX, PDF•
1 like•491 views
Speaker: Lee Chuen Ooi, Senior Principle Engineer, Dell | Scott Hilleque, Architect, Dell
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to MongoDB World 2018: Breaking the Mold - Redesigning Dell's E-Commerce Platform
Similar to MongoDB World 2018: Breaking the Mold - Redesigning Dell's E-Commerce Platform (20)
More from MongoDB
More from MongoDB (20)
Recently uploaded
Recently uploaded (20)
MongoDB World 2018: Breaking the Mold - Redesigning Dell's E-Commerce Platform
- 1. Breaking the mold - Redesigning Dell’s E- Commerce Platform Prepared by: Hilleque, Scott Ooi, Lee Chuen
- 2. 2 Agenda • Dell Digital IT Introduction • Advancing from Service-Oriented to Resource Oriented Architecture • Taking Advantage of Pre-Computation • Command Query Responsibility Separation (CQRS) • Why Document Stores? • Success story - DCQO application – Legacy System using RDBMS and gap – “Proof of concept” testing result summary – MongoDB Architecture using cluster(sharding) – Key notes during design & development – Data migration strategy from RDBMS to MongoDB – Ops Manager - operation, administration, backup/restore tool
- 3. 3 Dell Digital IT “We moved Dell’s U.S. business off of Dell Order Management (DOMS), a mainframe more than 30 years old, to processes and tools that better serve our customers. Using the new processes and tools: • 90 percent of Dell’s business now on a single global order management system • 30 percent fewer consumer orders result in cancellation • Commercial orders need 40 percent less intervention • Once placed, orders reach factories 35 percent faster” Product Price Payment Cart Quote Order
- 4. 4 Typical Service-Oriented Architecture Dependency Service Database Commerce Service Dependency Service Database Database Client Commerce Service Data Dependency Service Dependency Service Run Time
- 5. 5 Enhanced SOA Cache Denormalized Database Commerce Service Dependency Service Read Only Replica Database Dependency Database Data Replication CacheCache Dependency ServiceService Bus Change Notification Source Database Replication Job Run Time
- 6. 6 Resource Oriented Architecture Resources GET http://quotes/quote1 GET http://quotes/quote2 POST http://quotes PATCH http://quotes/quote3 GET http://quotes/quote3
- 7. 7 Resource Oriented Architecture Authoring Time Dependency Service Database Commerce Service Dependency Service Database Database Resources Notification Service Notification Service Run Time Commerce Service GET
- 8. 8 Resource Oriented Architecture Item Product Price Inventory Fulfillment Discount Accessories Tax
- 9. 9 Taking Advantage of Permutations
- 15. 15 CAP Theorem
- 16. 16
- 17. 17 Validation
- 19. 19 CQRS- Command Query Responsibility Separation ServerClient Command Query Write API Read API Domain Model Read Queries Commands Queries Transactional Database Non-Transactional Database Replication
- 20. 20 Strategies for Managing Schema Versions
- 21. 21 What is DCQO application? • Dell online Cart Quote Order • Part of Dell’s digital transformation strategy • Read write intensive • 24*7 mission critical application • Key revenue system for Dell Sales • Current MongoDB size is 5.4TB (growing 40% YoY). There are 243 millions of records in one of the large collections.
- 22. 22 Legacy System using RDBMS and gap • Use RDBMS to store XML as LOB (large object) • Create a quote: Serialize to XML -> Compress -> save as LOB (large object) • Retrieve a quote: Decompress LOB -> De-serialize the XML • Concern – how far can it scale vertically with the current design?
- 23. 23 Proof of Concept testing result summary • MongoDB version : 3.2.10 (back in Dec 2016) Test cases RDBMS Lob vs MongoDB standalone on same hardware spec RDBMS Lob vs MongoDB cluster (Stress test until breakpoint) MongoDB replica set vs MongoDB cluster Performance testing result +- 5% (no significant difference) RDBMS errored out, while MongoDB was still consistently performing. +10% overhead using MongoDB Cluster
- 24. MongoDB Journey continues ….. Design and Development
- 25. 25 DCQO Application Architecture Quote Item Price Contact Mongo DB Elasticsearch Asynchronous Synchronous Data Warehouse Quote Microservices Eventual Consistency Replication
- 26. 26 • Cluster/sharding is used because we need to support high IOPS and it is easy to scale horizontally • Total size of data bearing nodes (primary) = 5.4 Terabytes (still growing) Plan to change Arbiter to Secondary when DC 4 is ready
- 27. 27 Shard Key • Choose the right shard key to ensure equal distribution • Shard key cannot be changed (be cautious) • Use GUID to generate shard key in the application layer if the shard key is needed in the application logic before saving in MongoDB to save round trip. • Sample GUID: wqw5cQRGD0yxyEnIs4i4nQ
- 28. 28 Sizing • 1) Snappy compression is enabled by default in WT. • 2) Include WT compression when calculating storage required. • 3) Data is uncompressed in memory DB Storage size (GB)Actual Size (GB) Count WT compression Db1 499 1,912 26,684,160 74% Db2 17 38 6,216,016 55%
- 29. 29 Schema design • $lookup function doesn’t support sharded collection • Not 1:1 table to collection mapping • Limit to 16MB size per doc. – Performance result: The get/save elapsed time increased 200% when Json doc size increased from 67kb to 148kb. • Schema less, not “schemaless” • De-normalized schema - good for high read to write ratio, but MongoDB version 3.6 can’t achieve an atomic update on different documents 30 tables quote_info Export_info Contact Enduser Fulfillment Promotion Phone Salesrep …….. 1 collection quote
- 30. 30 Query/Update/Delete • Check the MongoDB log to identify problematic query/transaction • Use explain() to review the execution path • Create index • Use $indexStats to clean up unused index. > 5% performance improvement • Partial document update. ~20% performance improvement • Simplify the query, avoid complex and repeated conditions db.collection.find ({ $and: [ { “field1": { $ne: null } }, -- this line can be removed as it is covered by the next line “field1” =19. { "field1": "19" } ] }) db.collection.find({ $or: [ { "field1":{$in: [ "vf1", "vf2", "vf3",…,"vf100" ] }, "field2": { $in: [ "v1", "v2", "v3", "v100"] } } ,{ "field1":{$in: [ "vf1", "vf2", "vf3“ ,…,"vf100"] }} ]}) -- the 1st OR clause can be removed • Pre-load data in performance database before performance testing
- 31. 31 Security/User Management • Remember to enable authentication • Use LDAP to ease the user management • Use Kerberos to avoid specifying encrypted password in the application connection string • Each application uses unique account to login to MongoDB
- 32. MongoDB Journey continues ….. Data Migration from legacy system
- 33. 33 Migration strategy to make MongoDB live Legacy RDBMS MongoDb 1) populate last_modify_date column, if not exists 3) Complete initial loading. Application sends data to both RDBMS and MongoDB based on last_modify_date. 4) 1 month stabilization period 5) Stop application Make sure the last data sync up completes 6) Switch application to connect to MongoDb 8) Application continues to send data to both MongoDB and legacy RDBMS 7) Start application. MongoDB is LIVE! 2) Setup MongoDB and collections Application
- 34. 34 Ops Manager • Monitor and send alerts - integrate with IT operation tool, ServiceNow via SNMP (Simple Network Management Protocol) to create Incident ticket automatically to operation team.
- 35. 35 Ops Manager (continue…) • Administration tasks (version upgrade, startup, shutdown, configure cluster/replicateSet…..). • Backup • Take snapshot every 12 hours. • Restore • Testing result: • The network transfer was 25MBps. • < 4 hours to complete full auto restore of 3 shards clusters with 2 TB size.
Editor's Notes
- [Scott] Good morning, my name is Scott Hilleque and I'm a senior architect in the Digital Commerce Services Platform at Dell Technologies and today happens to be my 7-year anniversary with Dell. For pretty much as long as I’ve been in this industry I’ve been a product engineer. That’s taking things that are purpose built for one client or scenario, and making them scale and adapt to work for many. [LC] My name is Lee Chuen. I am a senior principle database engineer in Dell. I work on RDBMS and NOSQL databases. [Scott] So, we have recently gone though a journey of making MongoDB our system-of-record document store; and we are here today to share with you some of what we learned, some of the choices we made, and maybe a couple of stumbles along the way that we hope we can help you avoid.
- [Scott] We’ll kick off with an introduction to our domain, then I’ll discuss some common architectural problems Mongo is helping us solve, and then LC is going to go into specifics of how we implemented our repositories and completed our migration.
- [Scott] I’d like to start by giving you a bit of insight into our "problem space”. So, Dell Digital IT Services is the suite of tools that we use to manage products, prices, carts, quotes, payments, and orders across our customer experiences. This is pretty much everything that we use to transact business-to-consumer and business-to-business e-commerce. You may also have heard Dell is in the process of merging with EMC, so we were dually tasked with keeping all this working AND converging two large enterprises on “one unified global commerce platform”. We knew we’d have to be MUCH more aggressive in regards to performance and availability; and we especially wanted to take advantage of cloud-type horizontal scalability. Ultimately, the overall approach we landed on was mixed; a bit of tried and tested combined with bleeding edge. We were certain from the outset though that our basic application architecture needed a completely new vision though. So, to start that, we made our list of architectural imperatives; things like micro-services, strong versioning, and continuous integration. But there were two key patterns that made the whole thing click into place; and those are resource-orientation and pre-computation.
- [Scott] To explain resource orientation, we need to take a step back and understand how the existing application designs were hurting us. Here you see a typical (legacy) service-oriented-architecture flow diagram. Incoming requests are validated, data is retrieved from databases and other services, business rules get run, and a response is assembled and sent back to the client. So what’s wrong with this? First, each dependency service call costs some number of milliseconds and, in our case, those fractions of a second added up to the majority of overall transaction time. Modern network infrastructures provides super low latency and high bandwidth, but serialization and raw time on the wire were making outward performance much slower than the individual parts. The second problem with this is reliability. I expect most of you have heard of the concept of 5-nines availability; sometimes referred to as six-sigma. That’s the goal of having only about 5 1/2 minutes of unscheduled down time per year. When you serially connect services like this, your outward availability can never be better than your weakest link. That’s the primary reason the average SOA system doesn’t get close to 5-nines; one intermittent crash or a race condition downstream can ruin it for everyone up the line.
- [Scott] The shortcomings of real-time service dependencies are pretty well understood now. Typically, the next step that architects and developers take is to employ caches, read-only replicas, and sometimes service-buses to improve responsiveness, Unfortunately, our experience has been that the benefits of those additions never really materialized in performance metrics. Also with more moving parts, we frequently found an actual reduction in availability. One more thing; caches introduce the problem of cache expiration, which makes it possible to get two different results between load-balanced servers at runtime. A favorite quote of Martin Fowler, who is the godfather of the Agile Methodology, is that the 2 toughest problems remaining in computer science are naming things and cache expiration. I can certainly vouch for the latter.
- [Scott] So the next-generation answer to these problems is resource-orientation, which you may have heard referred to as REST or maybe WebAPIs. Personally, I like the term Resource-Oriented-Architecture better because we’re talking about more than just a new protocol or an access method. It’s a new way of solving business problems which de-emphasizes behavior and focuses instead on state. So why is that important? Well, if you look at Internet-scale applications, like the web (www) or email, you’ll notice it’s very rare to see behavior changes out at the edge. For example, HTTP has been stable on version 1.1 since 1996. It’s not likely that a line-of-business application is ever going to be so future-proof that new features aren’t needed for 22 years; or at least I hope not. But that frequency of change, or surface area to changing business requirements, is what makes them hard to make reliable.
- [Scott] Then another feature of ROA is that it naturally guides you to separate “authoring-time” concerns from “user-time” concerns. This has a huge impact on scalability and performance. We’re going to go into that more in a bit.
- [Scott] Resources also help with your domain separation of concerns. Instead of services carrying copies of all the data from their dependency systems, they can just link to those resources with URLs. This is nice because it allows clients to selectively hydrate the details they are interested in and only pay that portion of transport cost when they need it. This is basically how modern responsive web pages work; HTML contains links to style sheets, JavaScript, and image resources, which are then opportunistically downloaded only when needed.
- [Scott] Our second big architecture change is pre-computation. That means pushing your data forward, all the way to the client-ready state so you don’t need to make real-time service calls at runtime. In resource-oriented-architectureds you still need to have validation of source data and running of business rules, but your focus is shifted to preparing the end state for fast retrieval. In web experiences, customers expect page loads and navigation to respond instantly, so that is not the time to be running your complex business logic. In effect, the idea here is to have answers to customers’ questions before the question is asked. Changes that originate with source data are expected to take a bit longer, but their retrieval always has to be as fast as possible.
- [Scott] An example I like to use to demonstrate how to think of this is an item placed in a shopping cart; we’ll use this Precision 5520 laptop. The item resource for it consists of product data, some configuration options, prices, and other details like how long it takes to go from ordered to shipped and shipped to delivered. In the classic SOA model we would have all that information spread across several systems-of-record and go retrieve them at runtime. Now, we’ve figured out all the valid choices a user can make and save them in a precomputed store as separate resources.
- [Scott] You do have to keep an eye on how far you go with your precomputations. Too much and it'll feel like you're boiling an ocean. For example, if we were to precompute every possible permutation of Dell enterprise server products that could easily result in tens of millions of product documents; most of which would never be of interest to an actual user.
- [Scott] On the other hand, if you achieve too little precomputation; you're back where you started; having to do too much work while the user is waiting. Our advise is to aim for "no real-time calls to dependency services at runtime". If you still need to run some real-time business logic that's OK. Just make sure you have all the state you need to run that logic in your resource.
- [Scott] Ok, so why use a document store to solve these problems? We have lots of other options; relational, graph, key-value pair. Relational is great where structure, type, and referential integrity are top priority, which typically occurs with source data. Graphs are good for asking dynamic and nested questions. Key-value pair, well, I haven’t actually figured out a really good use for them yet.
- [Scott] The answer is that documents are simply the best form for holding complex and hierarchical precomputed state. That can include a mix of strongly-typed data fields, one-to-many relationships, internal references, links to external resources, and anything else that we’ve needed to model inside an atomic resource.
- [Scott] When making a decision on which document store, we first need to understand a bit about the "CAP Theorem". CAP is a formally proven conjecture that says any distributed database has to make a sacrifice between consistency, availability, and partition tolerance. Since partition tolerance isn't really a thing, all distributed databases favor either consistency or availability. High-availability is great for read-only data, but things get complicated when you look close at what happens during a failure event. Regardless of marketing claims, all AP document stores (AP means they compromise on C-consistency) will lose data under at least some failure modes. Sometimes you can manually recover that data and sometimes you can't, but they all share the very-real possibility of data loss. CP, or high-consistency stores, on the other hand have the possibility of being off-line when a quorum of nodes can't be reached, but they can be proven to never lose data under any circumstances.
- [Scott] Note: The question of data loss due to a node failure, lost drive, or hung VM is really not what were talking about here; that's actually become a non-interesting event. The kind of failure we have to consider is a data center power outage, core switch failure, or misconfigured firewall/router. We have to plan for these type of events as well, and when they happen we have a choice; favor availability or consistency. There are no magic solutions that provide both at the same time.
- [Scott] Some of the more complicated failure modes, like unidirectional routing, can be difficult to simulate and test for. There is a tool called Jepsen though, that can thoroughly evaluate CP consistency claims. This wasn’t available yet when we made our decision to adopt Mongo, but the fact that Mongo received a clean bill of health from Jepsen gave us confidence we made the right choice.
- [Scott] When describing all this to your business partners, and you advise them of a risk of potential data loss, of course they're going to say it's never acceptable to lose data. Sometimes that's true and sometimes not so much. The better question to ask is what are the consequences of accepting a transaction, confirming it back to the user, and then subsequently losing the transaction forever. If were talking about a wish list or shopping cart and the occurrence is rare, nobody's likely to get bent out of shape. On the other hand if you accept a $1M order for hardware and service and then, poof, it disappears. That could be a career limiting situation. If you think you're dealing with the latter, you're probably best sticking to high consistency stores.
- [Scott] There’s another related architectural pattern I’d like to mention quickly and that’s Command Query Responsibility Separation (CQRS). Document stores are ideal for the command side of CQRS, the part were your updating and retrieving a resource at a time. The reason CQRS works well here is because it separates record level access (i.e. row locks) from much broader page and table level locks.
- [Scott] Before I hand off, some advise on handling schema versioning. First, put schema version numbers in your documents from the beginning. This gives you options later on how to handle simultaneous versions and data migration. Next, plan out how you are going to handle backwards incompatible changes to your document’s structure. Option #1 is mass migration. This is how most shrink-wrapped commercial products work. When deploying a new version all historical data is translated to the new format. This keeps things simple but it get impractical at large volumes and doesn’t allow running both versions for a while. Option #2 is to migrate on demand. Just save the documents in the last-used schema. I like this option a lot because its simple and scales well, but it does have an affect performance. You also have to write both forward AND backward converters. Option #3 is explicit migration, which is like moving between two similar systems made by different vendors. The downside with #3 is you will have some of the same data stored in both version until you completely shut down the old one.
- [Scott] OK, now LC is going to take over and provide some more specific examples. [LC] Thanks Scott. Let me go through with you how we started MongoDB. We will also share our key notes during the design and development phases, how we migrated RDBMS data to MongoDB by using DCQO application as an example. DCQO stands for Dell Online Cart Quote and Order. It is part of Dell’s digital transformation. It is a read write intensive mission critical application, one of the key applications which generates revenue to Dell. Our current Production MongoDB size is 5.4 TB with the yearly growth rate of 40%. One of our large collections is having 243 millions of records.
- [LC] Here was our problem statement in the legacy system. When a quote information is saved, application serialize into XML format -> compress it and store it in RDBMS database as LOB (Large Object). When a quote is retrieved, application will decompress the LOB (large object) from RDBMS -> de-serialize it to get the quote information. With the increase of transaction volume every year, we started to look for alternative to support higher concurrency, without compromising performance.
- [LC] We started “Proof of Concept” by using MongoDB Enterprise Version 3.2.10 back in Dec 2016. We spent around 1 month to complete our “Proof of Concept” after running > 50 rounds. Each test case was repeated a few rounds to ensure consistency. Here is our key testing result summary back in Dec 2016: The 1st test case is to compare RDBMS (LOB) vs MongoDB standalone hosted on the same hardware spec. The performance test result in term of TPT(transaction per second) is +-5%. There was no obvious performance difference between RDBMS vs MongoDB. The 2nd test case is to compare RDBMS (LOB) vs MongoDB cluster. We stress test the database until it hit to the breakpoint. With the same workload, RDBMS errored out, while MongoDB was still consistently performing. It scales horizontally. The 3rd test case is to compare MongoDB replicateSet vs MongoDB cluster. There is +10% overhead in term of response time when using MongoDB cluster. We presented the above performance result to the stakeholders and concluded that since it was only 10% overhead, which was mill-second difference, the decision was to go with MongoDB cluster.
- [LC] Our MongoDB journey continues with Design and Development.
- [Scott] This is the microservice architecture of our quotation system. MongoDB is the transactional data store, what we call a Class 1 system-of-record, which means it holds real-time business critical data with verified fault tolerance. Asynchronously, data changes are then replicated and indexed to Elasticsearch (following CQRS). Elastic is where users run queries to find individual quotes and lists of quotes. Finally, there is an eventually consistent feed to our data warehouse where complex analysis and reporting jobs are run. Separating these workloads helps us prevent any adverse impacts on transactional users from complex and batch processes.
- [LC] Here is our MongoDB architecture. We use cluster/sharding because we need to support high IOPS and it is easy to scale horizontally. There are 3 data centers. Each box is representing 1 server. We use MongoDB cluster with 3 replica Set. Each Replicate Set has 3 members. Data bearing nodes , which are brown boxes are hosted in DC1 and DC2. Arbiter is hosted in DC3. We use arbiter because DC3 is physically far from DC1 and DC2. There is network latency and this is read write intensive db. We do have a plan to upgrade Arbiter to Secondary when DC4 is ready.
- [LC] If you are using Mongodb cluster, it is very important to choose the right shard key to ensure equal distribution. Once collection is sharded, we cannot select a different shard key and we cannot update the value of the shard key field. For our application, as the shard key is needed at the biz level before saving the doc into MongoDB, we use GUID as the shard key. This is to save the round trip between MongoDB and application server. GUID is the global unique identifier, 128 bit. We use the 22 alphanumeric, which is save to be used as part of URL.
- [LC] While estimating the MongoDB sizing, Snappy WiredTiger compression is enabled by default. It means the actual storage size is smaller than the actual data size. As shown in the table, our MongoDB has a good compression rate, which 55%-74%. This saves the storage cost. Do take note that data is uncompressed when it is loaded into the memory.
- [LC] Most of us comes from RDBMS background. We get use to JOIN tables in relational model. MongoDB $lookup function doesn’t support sharded collection. We store all these quote information into 1 collection. When de-normalize and consolidating all information into 1 Json doc, make sure that the size of the doc is <16MB. MongoDB is “schema less”, not “schemaless”. Json document is flexible for e.g. data length and type, but we still need to spend time to come out with a good schema design. De-normalized schema good for high read to write ratio, but Mongodb 3.6 can’t achieve an atomic update on different documents. The good news is Mongodb 4.0 will be supporting updating multiple doc in 1 txn. If you are the beta version Mongodb 4.0, pls let me know what you think on this new feature. I will be glad to hear from you.
- [LC] Most of the time, DBA doesn’t have visibility on what query is used in the application. One of the direct way to identify problematic query is checking the MongoDB logfile during performance testing. By default, mongodb logs any txn/query which takes more than 100 ms. Use explain() function to see the winningPlan. Avoid COLLSCAN in large collection, which is the full table scan in RDBMS. If you think that this is too much of work, alternatively, you can use Ops Manager 3.6, refer to the Performance Advisor section, which will recommend the index required. This saves a lot of time to look at the mongodb logfile. It is also a good practice to drop any unused index to optimize the insert/update txn. Use indexStats -> accesses.op to find out how many operations have used the index. There was 5% performance improvement gain after we clean up the indexes. We found out that using partial update rather than updating the whole doc improve the performance. We have seen 20% performance improvement once using partial update. We should also simplify the query to avoid complex and repeated conditions. I have given 2 examples on the slides: The 1st example is the AND condition. The query wants to retrieve documents which has field1 = 19. It is not needed to check if field1 is NOT NULL. The 2nd example is the OR condition. The 1st OR and 2nd OR condition have the same value. The 1st OR condition can be removed because it is a subset of the 2nd OR condition. Last few weeks, my colleges came to me and said, “Hi LC, we faced performance issue in PROD. We tested in PERF and everything was fine. We even have higher hardware spec in PROD than in PERF”. After I looked at the statistic, the PROD volume is 150 times higher than the volume in PERF env. This silence the potential issue during performance testing. Hence, pls load the expected volume in PERF env to simulate PROD load in PERF env.
- [LC] Every database needs to be protected. Remember to enable “Authentication” in MongoDB. We find that LDAP Authentication simplify the user management. For e.g. we can grant all DBAs with a set of role/privileges without granting each induvial privilege. We use Kerberos to avoid specifying encrypted password in the application connection string. Our application run on service account, which is managed by security team. Each application should have unique account to login to MongoDB. This is not only a good guideline to segregate out the access, it also helps in troubleshooting because the login information is logged in the logfile.
- [LC] – Next, we will share with you how we migrated data from legacy RDBMS to MongoDB.
- [LC] Here is our data migration strategy making MongoDB live: Populate last_modify_date in the legacy RDBMS if this col doesn’t exist. Setup database and collection in MongoDB. Make sure that there is a “last_modify_date” field in all documents during the schema design. Then, we will start with the Initiate data loading. For our case, we have to backload data since year 2014 onwards. It took us a week to complete initial loading. Once data is caught up between the legacy RDBMS and MongoDB, application sends data to both RDBMS and MongoDB, Let MongoDB stabilize for 1 month. Testing team can also run any testing hitting MongoDB during this stabilization period. After pass the stabilization period, stop application. No data should go into the legacy RDBMS. Complete the last data sync up. Switch the application connection to the new MongoDB. For our case, this cut over happened within a few minutes. Start application. MongoDB takes live traffic. Continue to send data to both MongoDB and legacy RDBMS. This strategy buys us insurance. If there is any issue, we still have a choice to switch back to Legacy RDBMS since data is in sync. This minimize the risk. We originally target to bring down the data migration tool after 3 months. In fact, it ran more than ½ year. Anyone wants to do a guess why? Reason is “no news is good”. It was stabile until nobody could remember that we still had the migration tools running. We only realized and stopped the data migration tool after server team sent us notification that we need to decommission the legacy RDBMS.
- [LC] We use Ops Manager to monitor and send alerts. We have integrated the alert with our IT operation tool, ServiceNow, via SNMP (Simple Network Management Protocol) to automatically create incident ticket for the operation team.
- [LC] We also use ops manager to perform administration tasks. For e.g., version upgrade, startup, shutdown, configure cluster/replicateSet…. It increases the productivity of DBA. It is used to backup/restore our MongoDB. We are using Blockstore db as storage to perform backup. We schedule to take snapshot every 12 hours. The full DB recovery is pretty fast. The network transfer was 25MBps. It took less than 4 hours to complete full auto restore of 3 shards clusters with 2 TB size via Ops Manager.
- That’s all for our presentation today. We have shared how MongoDB helps us to solve the common architectural problems, the list of key notes during design and development phase and how we completed the data migration from RDBMS to MongoDB. I hope you enjoy our sharing and get benefits from it. We are now opened for question and answer.