└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # 100 Core MongoDB Interview Questions in 2025 2 | 3 |
4 |

5 | 6 | web-and-mobile-development 7 | 8 |

9 | 10 | #### You can also find all 100 answers here 👉 [Devinterview.io - MongoDB](https://devinterview.io/questions/web-and-mobile-development/mongodb-interview-questions) 11 | 12 |
13 | 14 | ## 1. What is _MongoDB_ and what are its main features? 15 | 16 | **MongoDB** is a robust, document-oriented NoSQL database designed for high performance, scalability, and developer agility. 17 | 18 | ### Key Features 19 | 20 | #### Flexible Data Model 21 | 22 | - Employs **JSON-like documents** (BSON format), facilitating complex data representation, deep nesting, and array structures. 23 | - Provides dynamic schema support, allowing **on-the-fly data definition and data types**. 24 | - Permits multi-document transactions within a replica set (group of nodes). **Sharding** extends this to support large distributed systems. 25 | 26 | #### Indexed Queries 27 | 28 | - Offers extensive indexing capabilities, such as single and multi-field support, **text**, **geospatial**, and **TTL** (Time to Live) Indexes for data expiration. 29 | - Gives developers the tools needed to design and optimize query performance. 30 | 31 | #### High Availability & Horizontal Scalability 32 | 33 | - Uses replica sets for data redundancy, ensuring **auto-failover** in the event of a primary node failure. 34 | - Adopts sharding to **distribute data across clusters**, facilitating horizontal scaling for large datasets or high-throughput requirements. 35 | 36 | #### Advanced Querying 37 | 38 | - Engages in **ad-hoc querying**, making it easy to explore and analyze data. 39 | - Provides **aggregation pipeline**, empowering users to modify and combine data, akin to SQL GROUP BY. 40 | - Specialized query tools like **Map-Reduce** and **Text Search** cater to distinctive data processing needs. 41 | 42 | #### Embedded Data Management 43 | 44 | - Encourages a rich, document-based data model where you can **embed related data** within a single structure. 45 | - This denormalization can enhance read performance and data retrieval simplicity. 46 | 47 | #### Rich Tool Suite 48 | 49 | - Further augmented by several desktop and web-supported clients, MongoDB Atlas offers a seamless and unified experience for database management. 50 | - Web-based MongoDB Compass handles query optimization and schema design. 51 | 52 | #### Code Sample: Data Interaction with MongoDB 53 | 54 | Here is the Python code: 55 | 56 | ```python 57 | from pymongo import MongoClient 58 | 59 | client = MongoClient() # Connects to default address and port 60 | db = client.get_database('mydatabase') 61 | 62 | # Insert a record 63 | collection = db.get_collection('mycollection') 64 | inserted_id = collection.insert_one({'key1': 'value1', 'key2': 'value2'}).inserted_id 65 | 66 | # Query records 67 | for record in collection.find({'key1': 'value1'}): 68 | print(record) 69 | 70 | # Update record 71 | update_result = collection.update_one({'_id': inserted_id}, {'$set': {'key2': 'new_value'}}) 72 | print(f"Modified {update_result.modified_count} records") 73 | 74 | # Delete record 75 | delete_result = collection.delete_one({'key1': 'value1'}) 76 | print(f"Deleted {delete_result.deleted_count} records") 77 | ``` 78 |
79 | 80 | ## 2. How does _MongoDB_ differ from relational databases? 81 | 82 | While both **MongoDB** and relational databases handle data, they do so in fundamentally different ways. Let's explore the key distinctions. 83 | 84 | ### Data Model 85 | 86 | #### Relational Databases 87 | - Use tables with predefined schemas that **enforce relationships and data types**. 88 | - Often use normalization techniques to minimize data redundancy. 89 | 90 | #### MongoDB 91 | - Stores data as **flexible, schema-less** sets of key-value pairs inside documents. 92 | - Relationships can be represented through embedded documents or referencing via keys, providing more granular control and allowing for a more natural representation of real-world data. 93 | 94 | ### Data Integrity 95 | 96 | #### Relational Databases 97 | - Rely on **ACID transactions** to ensure data consistency. 98 | 99 | #### MongoDB 100 | - Offers **ACID guarantees** at the document level, though transactions across multiple documents happen within the same cluster to ensure consistency. 101 | - Provides **multi-document transactions** for more complex operations. 102 | 103 | ### Query Language 104 | 105 | #### Relational Databases 106 | - Use SQL, a **declarative** query language. 107 | 108 | #### MongoDB 109 | - Employs **JSON-like** queries, which are **imperative** and resemble the structure of the data it operates on. 110 | 111 | ### Scalability 112 | 113 | #### Relational Databases 114 | - Traditionally use a **vertical scaling** approach, featuring limits on a single server's resources such as CPU, storage, and memory. 115 | 116 | #### MongoDB 117 | - Designed for **horizontal scaling**, making it easier to handle larger datasets and heavier loads by distributing data across multiple servers. This scalability also supports cloud-based setups. 118 | 119 | ### Performance 120 | 121 | #### Relational Databases 122 | - Can handle complex queries efficiently but might require multiple joins, potentially degrading performance. 123 | 124 | #### MongoDB 125 | - Optimized for quick CRUD operations and can efficiently handle large volumes of read and write requests. 126 | 127 | ### Indexing 128 | 129 | #### Relational Databases 130 | - Tables can have a multitude of indexes, which can be a mix of clustered, non-clustered, unique, or composite. 131 | 132 | #### MongoDB 133 | - Collections can have several indexes, including single field, compound, and multi-key indexes. 134 | 135 | ### Data Joins 136 | 137 | #### Relational Databases 138 | - Use joins to merge related data from different tables during a query, ensuring data integrity. 139 | 140 | #### MongoDB 141 | - Offers **embedded documents** and **manual reference** to achieve similar results, but multi-collection joins have performance and scalability considerations. 142 |
143 | 144 | ## 3. Can you describe the structure of data in _MongoDB_? 145 | 146 | In **MongoDB**, data units are organized into **collections**, which group related documents. Each **document** corresponds to a single **record** and maps to fields or **key-value pairs**. 147 | 148 | ### JSON-Like Format 149 | 150 | Data in MongoDB is stored using a **BSON** (Binary JSON) format that can handle a maximum depth of 100 levels. This means a BSON object or element can be a document consisting of up to 100 sub-elements, such as fields or values. 151 | 152 | #### Example: Nested Document 153 | 154 | Here is a nested document: 155 | 156 | ```json 157 | { 158 | "_id": "123", 159 | "title": "My Blog Post", 160 | "author": { 161 | "name": "John Doe", 162 | "bio": "Tech enthusiast" 163 | }, 164 | "comments": [ 165 | { 166 | "user": "Alice", 167 | "text": "Great post" 168 | }, 169 | { 170 | "user": "Bob", 171 | "text": "A bit lengthy!" 172 | } 173 | ] 174 | } 175 | ``` 176 | 177 | In the example above, the "author" field is an embedded document (or sub-document), and the "comments" field is an array of documents. 178 | 179 | ### Key Features 180 | 181 | - **Ad-Hoc Schema**: Documents in a collection don't need to have the same fields, providing schema flexibility. 182 | 183 | - **Atomicity at the Document Level**: The `ACID` properties (Atomicity, Consistency, Isolation, Durability) of a transaction, which guarantee that the modifications are successful or unsuccessful as a unit of work. 184 | 185 | - **Index Support**: Increases query performance. 186 | 187 | - **Support for Embedded Data**: You can nest documents and arrays. 188 | 189 | - **Reference Resolution**: It allows for processing references across documents. If a referenced document is modified or deleted, any reference to it from another document also needs to be updated or deleted in a multi-step atomic operation. 190 | 191 | - **Sharding and Replication**: For horizontal scaling and high availability. 192 | 193 | ### Data Model Considerations 194 | 195 | 1. **One-to-One**: Typically achieved with embedded documents. 196 | 197 | 2. **One-to-Many (Parent-Child)**: This can be modelled using embedded documents in the parent. 198 | 199 | 3. **One-to-Many (Referenced)**: Achieved through referencing, where several documents contain a field referencing a single document. For better efficiency with frequent updates, consider referencing. 200 | 201 | 4. **Many-to-Many**: Modeled similarly to "One-to-Many" relationships. 202 | 203 | 5. **You should avoid** using “repeatable patterns”, such as storing data in separate arrays or collections, to ensure smooth data manipulation and effective query operations. 204 | 205 | For example, using separate collections for similar types of data based on a category like "users" and "admins" instead of a single "roles" array with multiple documents. 206 | 207 | The above best practice example prevents **data redundancy** and ensures **consistency** between similar documents. Redundant storage or separating non-redundant data can lead to inconsistencies and increase the effort required for maintenance. 208 |
209 | 210 | ## 4. What is a _Document_ in _MongoDB_? 211 | 212 | In MongoDB, a **document** is the basic data storage unit. It's a JSON-like structure that stores data in key-value pairs known as fields. 213 | 214 | ### Document Structure 215 | 216 | Each **document**: 217 | 218 | - Is a top-level entity, analogous to a row in a relational database. 219 | - Is composed of **field-and-value** pairs, where the value can be a variety of data types, including arrays or sub-documents. 220 | - Has a unique `_id` or primary key that is indexed for fast lookups. 221 | 222 | Here is the document structure: 223 | 224 | ```json 225 | { 226 | "_id": 1, 227 | "name": "John Doe", 228 | "age": 30, 229 | "email": "john.doe@email.com", 230 | "address": { 231 | "city": "Example", 232 | "zip": "12345" 233 | }, 234 | "hobbies": ["golf", "reading"] 235 | } 236 | ``` 237 | 238 | ### Collections 239 | 240 | Documents are grouped into **collections**. Each collection acts as a container with a unique namespace within a database. Collections don't enforce a predefined schema, which allows for flexibility in data modeling. 241 | 242 | ### Key Advantages 243 | 244 | 1. **Flexibility**: Documents can be tailored to the specific data needs of the application without adherence to a rigid schema. 245 | 246 | 2. **Data Locality**: Related data, like a user's profile and their posts, can be stored in one document, enhancing performance by minimizing lookups. 247 | 248 | 3. **JSON Familiarity**: Documents, being JSON-like, enable easier transitions between application objects and database entities. 249 | 250 | 4. **Indexing**: Fields within documents can be indexed, streamlining search operations. 251 | 252 | 5. **Transaction Support**: Modern versions of MongoDB offer ACID-compliant, multi-document transactions that ensure data consistency. 253 | 254 | ### Example Use Case 255 | 256 | Consider an online library. Instead of having separate tables for users, books, and checkouts as in a relational database, you could store all the pertinent data about a user, including their checked-out books, in a **single document** within a `users` collection: 257 | 258 | ```json 259 | { 260 | "_id": 1, 261 | "name": "John Doe", 262 | "email": "john.doe@email.com", 263 | "address": { "city": "Example", "zip": "12345" }, 264 | "checkedOutBooks": [ 265 | { "bookId": 101, "dueDate": "2022-02-28" }, 266 | { "bookId": 204, "dueDate": "2022-03-15" } 267 | ] 268 | } 269 | ``` 270 | 271 | This approach enables swift retrieval of all pertinent user information in one go. 272 | 273 | ### Considerations 274 | 275 | - **Atomicity**: While single-document operations are atomic by default in MongoDB, transactions and atomicity guarantee apply to multi-document operations primarily. 276 | - **Size Limitations**: Documents can't exceed 16MB in size. In most cases, this limit should not be a practical concern. 277 |
278 | 279 | ## 5. How is data stored in _collections_ in _MongoDB_? 280 | 281 | In **MongoDB**, data is stored in **types of collections**, ensuring flexibility and efficiency in data modeling. 282 | 283 | ### Collection Basics 284 | 285 | - Collections are the **primary data storage structures** in MongoDB, akin to tables in relational databases. 286 | - They are schema-less, meaning that documents within a collection can have varying structures. This offers superior flexibility, while still allowing for structure validation through the use of JSON schema. 287 | 288 | ### Documents 289 | 290 | - **Documents** serve as the unit of data storage in MongoDB. These are akin to rows in relational databases or objects in languages such as JavaScript. 291 | - Documents are represented in **BSON** (Binary JSON) format, a binary representation closely mirroring JSON's attribute-value data model. 292 | 293 | ### Data Organization Hierarchy 294 | 295 | - Data in MongoDB is organized in a **hierarchical structure**, with each database having one or more **collections**, each of which stores multiple **documents**, all of which can possess distinct structures. 296 | 297 | ### Key Data Principles 298 | 299 | - MongoDB collections are designed to **optimize** data access rather than just serving as containers. 300 | - To maximize efficiency, it's crucial to design collections that cater to common query patterns. 301 | 302 | ### Types of Database Collections 303 | 304 | - By understanding the nuances of each collection type, you can better customize your MongoDB system to **cater to specific use-cases and performance requirements**. 305 | 306 | #### AJAX Comments 307 | 308 | - To effectively and iteratively store and manage comments, the AJAX Comments feature is engineered to provide a blend of flexibility and ease of access. 309 | - It leverages **JSON-like documents** and the native power of MongoDB, such as **rich indexing** for efficient interactions. 310 | 311 | #### Newsfeed Posts 312 | 313 | - Tailored for sequential, feed-like content, such as posts from a social media platform or a messaging app. 314 | - It benefits greatly from the ordered nature of **BSON documents**, making sure newer posts are easy to fetch. 315 | 316 | #### User Profiles 317 | 318 | - Focusing on user-defined, diverse, and possibly unstructured details, the User Profile collection is an ideal repository for self-descriptive user profiles. 319 | - The **flexibility** of schema allows for comprehensive storage with minimal overhead. 320 | 321 | #### Metadata 322 | 323 | - For persistent and global configurations, the Metadata collection provides a secure space to cache system information. 324 | 325 | #### Product Catalog 326 | 327 | - Bolsters browsing and shopping activities by housing consistent, structured details related to products or services on offer. 328 | - This attention to **consistency** helps in easy data retrieval and optimized user experiences. 329 | 330 | #### Logging 331 | 332 | - Ideally suited to record system interactions and debugging info, the Logging collection maintains an organized trail of system activity, nurturing a culture of informed decision-making. 333 |
334 | 335 | ## 6. Describe what a _MongoDB database_ is. 336 | 337 | A **MongoDB database** is a document-oriented, NoSQL database consisting of collections, each of which in turn comprise documents. 338 | 339 | ### Core Concepts 340 | 341 | #### 1. Collection 342 | 343 | - A collection is a grouping of MongoDB documents. A collection is the **equivalent of a table** in a relational database. 344 | 345 | Advantages of Using Collections: 346 | 347 | - **Flexibility**: Each document in a collection can have its own set of fields. Structural changes are easier to manage than in traditional, rigid SQL tables. 348 | - **Scalability**: Collections can be distributed across multiple servers or clusters to handle large data volumes. 349 | 350 | #### 2. Document 351 | 352 | - Synonymous with a record, a **document** is the main data storage unit in MongoDB. It is a set of key-value pairs. 353 | 354 | - Key: The field name 355 | - Value: The data 356 | 357 | **Document-Key Pairs**: 358 | 359 | - Each document maintains a unique ID, known as the **object ID** which is autogenerated. This ensures every document is distinct. 360 | 361 | - Unlike SQL databases where each row of a table follows the same schema, a document can be more fluid, accommodating fields as required. 362 | 363 | Considerations When Choosing the Level of Normalization: 364 | 365 | - **Optimized Reads**: Normalization into separate collections may be beneficial if there are large amounts of data that might not always have to be fetched. 366 | 367 | - **Batch Inserts and Updates**: Denormalization often leads to simpler write operations. If there will be a lot of changes or inserts, denormalization can be more efficient. 368 | 369 | - **Atomicity**: When data that belongs together is split into different collections, ensuring atomicity can become difficult. 370 | 371 | #### 3. Field 372 | 373 | - A **field** is a single piece of data within a document. It's synonymous with a database column. 374 | 375 | - **Field Type**: MongoDB supports multiple field types, including arrays. 376 | 377 | - **Limit on Nested Fields**: Documents can be nested, which is like being able to have sub-documents within a main document. However, there is a depth limitation: you can't embed documents endlessly. 378 | 379 | #### Schema 380 | 381 | MongoDB is often regarded as **schema-less**, but a more accurate description is that it's **flexible**. While documents within a single collection can have different fields, a robust schema design process is still essential. 382 | 383 | Adapting to Evolving Schemas: 384 | 385 | - **Versioning**: Managed schema changes and versioning in the application layer. 386 | 387 | - **Schema Validation**: Introduced in MongoDB 3.2, this feature allows for the application of structural rules to documents. 388 | 389 | - **Education and Training**: Properly educating developers on the use of a database can minimize potential misuse of its flexibility. 390 | 391 | - **Use of Techniques to Ensure Data Integrity**: Techniques such as double-entry bookkeeping can assure data accuracy, especially when dealing with multiple, occasionally outdated records. 392 | 393 | 394 | ### Modeling vs. Tuning Approaches 395 | 396 | - **Normalization**: Seeks to reduce redundancy and improve data consistency. 397 | 398 | - **Denormalization**: Emphasizes performance gains. Redundancies are knowingly introduced for optimized and rapid reads. 399 | 400 | - **Use Cases Dictate**: Neither is definitively superior; their suitability depends on the specific use case. 401 |
402 | 403 | ## 7. What is the default _port_ on which _MongoDB_ listens? 404 | 405 | The default **port number** for MongoDB is 27017. While it is possible to run multiple instances of MongoDB on the same machine, each instance must have its unique port number to ensure they don't conflict. 406 |
407 | 408 | ## 8. How does _MongoDB_ provide high availability and disaster recovery? 409 | 410 | **MongoDB** ensures high availability and disaster recovery through a robust data architecture and a distributed system model. It integrates various mechanisms to maintain data integrity, uptime assurances, and data redundancy. 411 | 412 | ### Key Components 413 | 414 | 1. **Replica Sets**: These are clusters of MongoDB nodes that use automatic failover to maintain data consistency. 415 | 416 | 2. **WiredTiger Storage Engine**: It powers numerous features including data durability, in-memory storage, and compression. 417 | 418 | 3. **Oplog**: Short for "operations log", it records all write operations in an append-only manner. 419 | 420 | 4. **Write Concerns**: These are rules that determine the level of acknowledgment required for write operations. 421 | 422 | 5. **Read Preferences**: They define which nodes in a cluster can satisfy read operations. 423 | 424 | 6. **Data Centers**: Hardware resilience can be achieved by distributing nodes across multiple data centers. 425 | 426 | 7. **Backups and Restores**: MongoDB offers built-in mechanisms to backup and restore data, further aiding in disaster recovery. 427 | 428 | 8. **Monitoring Tools**: For performance tracking and potential issue detection. 429 | 430 | 9. **Technology Agnostic**: Can deploy on multi-cloud, hybrid and on-premises architectures. 431 | 432 | ### Data Recovery Modes 433 | 434 | 1. **Restore**: Achieved through the backup of data when the config server is the only component that is active and accurate. This method doesn't consider data changes made after the backup was captured. 435 | 436 | 2. **Oplog Replays**: This involves using oplogs that track changes, ensuring that even after a cluster restart, any missed transactions are reinstated. 437 | 438 | 3. **Snapshotting**: It is a consistent snapshot of data across the nodes in the replica set. 439 | 440 | ### Code Example: Write Concerns and Oplog 441 | 442 | Here is the Python code: 443 | 444 | ```python 445 | # Import the MongoClient class from pymongo. 446 | from pymongo import MongoClient 447 | 448 | # Establish connection to the MongoDB server using MongoClient. 449 | client = MongoClient('mongodb://localhost:27017/') 450 | 451 | # Assign the test database to a variable 452 | db = client.test 453 | 454 | # Assign the collection within the test database to a variable 455 | collection = db.test_collection 456 | 457 | # Insert a document into the collection and set the write concern to 'majority' 458 | result = collection.insert_one({'test_key': 'test_value'}, write_concern={'w': 'majority'}) 459 | 460 | # Fetch the oplog entry associated with the insert operation. 461 | oplog_cursor = db.local.oplog.rs.find({'ns': 'test.test_collection', 'op': 'i'}) 462 | 463 | # Access the result and compare the count to ensure the operation was recorded in the oplog. 464 | operation_count = oplog_cursor.count() 465 | ``` 466 | 467 | ### Recommendations 468 | 469 | - Employ consistent and comprehensive **backup** strategies in conjunction with multi-faceted recovery plans. 470 |
471 | 472 | ## 9. What are _indexes_ in _MongoDB_, and why are they used? 473 | 474 | **Indexes** are employed in **MongoDB** to optimize database queries by providing faster access to data. Without indexes, MongoDB performs full collection scans. 475 | 476 | ### Common Types of Indexes in MongoDB 477 | 478 | - **Single Field Index**: The most basic form of index. 479 | - **Compound Index**: Generated across multiple fields; used for queries involving these fields. 480 | - **Multikey Index**: Specially designed for arrays or embedded documents. 481 | 482 | Batch Insert Operations on an Indexed Collection 483 | Describe any performance bottlenecks you anticipate. 484 | 485 | - **Text Index**: Suited for text searches, often leveraging stemming and stop words. 486 | 487 | Unique 488 | Explain in which situations it's beneficial to manage a unique index. 489 | Discard icon 490 | GEO Index 491 | Describe the purpose of this index type and the type of queries it can optimize. 492 | 493 | - **TTL (Time-to-Live) Index**: Deletes documents after a specified duration, suitable for logs and cached data. 494 | 495 | ### Common Performance Bottlenecks with Indexes 496 | 497 | - **Index Overuse**: Too many indexes can degrade write performance. 498 | 499 | - **Index Size**: Larger indexes consume more RAM and might slow down read and write operations. 500 | 501 | - **Index Inefficiency**: Inaccurate or non-selective index usage can render them ineffective. 502 | 503 | - **Write Penalties**: Indexes incur an overhead during writes, impacting their efficiency in write-heavy systems. 504 | 505 | - **Index Maintenance**: Regular maintenance, like rebuilding or reorganizing indexes, is often necessary. 506 | 507 | - **Workload Misalignment**: An index might not be beneficial if it's not aligned with the actual query workload. 508 | 509 | Make sure to keep the indexes required and remove any unnecessary ones. 510 |
511 | 512 | ## 10. What is the role of the _id field_ in _MongoDB documents_? 513 | 514 | The `_id` Field in MongoDB serves as a **primary key** and provides several key functionalities: 515 | 516 | - **Uniqueness Guarantee**: Each document must have a unique `_id`, which ensures data integrity. 517 | 518 | - **Automatic Indexing**: Automated indexing based on `_id` enhances query efficiency. 519 | 520 | - **Inherent Timestamp**: The `_id` can have an embedded timestamp, useful for time-based operations. 521 | 522 | For instance, with an **ObjectId**, the first 8 characters represent a 4 byte timestamp: 523 | 524 | $\text{timestamp} = \text{substr}(\text{ObjectId}, 0, 8)$ 525 | 526 | - **Concurrency Control**: If multiple write operations with the same `_id` occur simultaneously, MongoDB uses a technique called **last-write wins** to manage the conflict: 527 | 528 | The document with the most recent `_id` value, or timestamp if using an ObjectId, supersedes the others. 529 | 530 | - **_Modify and Return_**: When executing an operation to insert a new document or find & modify an existing one, you can request to return the modified document and its `_id`. 531 | 532 | ### ObjectId vs. Custom `_id` 533 | 534 | While MongoDB provides **automatic ObjectId** generation, documents can also use custom values. 535 | 536 | - **Custom Representations**: Unleash flexibility by using custom strings, numbers, or other valid BSON types for the `_id` field. 537 | 538 | - **Controlled Uniformity**: Design your own `_id` strategy to align with data, such as employing natural keys for documents originating from specific, external sources. 539 | 540 | - **Migrate with Care**: Once an application is live, altering the structure can be intricate. Transition plans are vital for a seamless shift. 541 | 542 | - **Custom Indexing**: Managing an index on a uniquely generated custom `_id` turns the data into a compact, high-throughput structure. 543 | 544 | ### Schema Design and the `_id` Field 545 | 546 | The choice between automatic ObjectId and custom `_id` values links back to the **intended data model, data access patterns**, and specific **domain requirements**. 547 | 548 | While using the automatic ObjectId brings about benefits like **ease of use** and **embedded timestamp**, custom `_id` generation provides finer control and helps in scenarios where a specific data structure is favored or where external data sources need to be integrated. 549 |
550 | 551 | ## 11. How do you create a new _MongoDB collection_? 552 | 553 | The process for creating a new collection in MongoDB is simple and instantaneous. 554 | 555 | ### Benefits of Instantaneous Creation 556 | 557 | - MongoDB collections are schemaless, leading to immediate collection creation. 558 | - Document structure and content drive schema design. 559 | - No predefined schema requirements allow for dynamic, evolving data models. 560 | 561 | ### Steps to Create a Collection 562 | 563 | 1. **Select the Database:** Ensure you are connected to the intended database for the collection's creation. Switch to the desired database using `use` in the `mongo` shell or select the database programmatically in your driver's API. 564 | 565 | 2. **Perform a Write Operation:** The new collection is created the moment you execute a write operation such as `insert`, `update`, or `save`. 566 | 567 | 3. **Check Collection Existence (Optional):** While not necessary for the creation process, you can verify the collection is created using the listCollections method. 568 |
569 | 570 | ## 12. What is the syntax to insert a _document_ into a _MongoDB collection_? 571 | 572 | To **insert a document** into a **MongoDB collection**, you can use the **`insertOne()`** method, which accepts the document as an argument: 573 | 574 | ```javascript 575 | db.collectionName.insertOne({ 576 | key1: "value1", 577 | key2: 2, 578 | key3: [1, 2, 3], 579 | key4: { nestedKey: "nestedValue" } 580 | }); 581 | ``` 582 | 583 | Alternatively, you can use the **`insertOne()`** method, supply an array of documents with **`insertMany()`**: 584 | 585 | ```javascript 586 | db.collectionName.insertMany([ 587 | { key: "value1" }, 588 | { key: "value2" } 589 | ]); 590 | ``` 591 |
592 | 593 | ## 13. Describe how to read data from a _MongoDB collection_. 594 | 595 | To **read** data from a **MongoDB collection**, you use the `find` method with various options for querying and data manipulation. 596 | 597 | ### Key Methods 598 | 599 | - **find**(filter, projection): Retrieves documents based on filter conditions. You can specify which fields to include or exclude in the result (**projection**). 600 | - **findOne**(filter, projection): Similar to `find` but retrieves only the first matching document. 601 | - **distinct**(field, filter): Returns a list of distinct values for a specific field, optionally filtered. 602 | 603 | ### Query Operators 604 | 605 | - **Comparison**: `$eq`, `$gt`, `$lt`, `$in`, `$nin`, etc. 606 | - **Logical**: `$and`, `$or`, `$not`, `$nor`, etc. 607 | - **Element**: `$exists`, `$type` 608 | - **Evaluation**: `$regex`, `$mod`, `$text` 609 | - **Geospatial**: `$geoNear`, `$geoWithin`, etc. 610 | 611 | ### Aggregation 612 | 613 | MongoDB also provides the **aggregation framework** for complex operations, using a pipeline of various stages like `match`, `group`, `sort`, `limit`, etc. 614 | 615 | ### Example: Basic Find Query 616 | 617 | Here is a Python code: 618 | 619 | ```python 620 | import pymongo 621 | 622 | client = pymongo.MongoClient("mongodb://localhost:27017/") 623 | db = client["mydatabase"] 624 | collection = db["mycollection"] 625 | 626 | # Retrieve all documents 627 | all_documents = collection.find() 628 | 629 | # Alternatively, you can iterate through the cursor: 630 | for doc in all_documents: 631 | print(doc) 632 | ``` 633 | 634 | ### Example: Querying with Filters 635 | 636 | Here is a Python code: 637 | 638 | ```python 639 | # Let's say we have the following documents in the collection: 640 | # [{ 641 | # "name": "John", 642 | # "age": 30, 643 | # "country": "USA" 644 | # }, 645 | # { 646 | # "name": "Jane", 647 | # "age": 25, 648 | # "country": "Canada" 649 | # }] 650 | 651 | # Retrieve documents where the name is "John" 652 | john_doc = collection.find_one({"name": "John"}) 653 | print(john_doc) # Output: {"name": "John", "age": 30, "country": "USA"} 654 | 655 | # Retrieve documents where age is greater than or equal to 25 and from country "USA" 656 | filter_criteria = {"age": {"$gte": 25}, "country": "USA"} 657 | docs_matching_criteria = collection.find(filter_criteria) 658 | for doc in docs_matching_criteria: 659 | print(doc) 660 | # Output: {"name": "John", "age": 30, "country": "USA"} 661 | ``` 662 | 663 | ### Projection 664 | 665 | **Projection** helps control the fields returned. It uses a dictionary where fields to include are marked with 1, and those to exclude with 0. 666 | 667 | For instance, `{"name": 1, "age": 1, "_id": 0}` only includes `name` and `age` while excluding `_id`: 668 | 669 | Here is a Python code: 670 | 671 | ```python 672 | # Retrieve the name and age fields, ignoring the _id field 673 | docs_with_limited_fields = collection.find({}, {"name": 1, "age": 1, "_id": 0}) 674 | for doc in docs_with_limited_fields: 675 | print(doc) 676 | # Output: {"name": "John", "age": 30} 677 | # {"name": "Jane", "age": 25} 678 | ``` 679 | 680 | ### Sort, Skip, and Limit 681 | 682 | **`sort`**, **`skip`**, and **`limit`** help in reordering, pagination, and limiting the result size. 683 | 684 | Here is a Python code: 685 | 686 | ```python 687 | # Sort all documents by age in descending order 688 | documents_sorted_by_age = collection.find().sort("age", -1) 689 | 690 | # Skip the first two documents and retrieve the rest 691 | documents_after_skipping = collection.find().skip(2) 692 | 693 | # Limit the number of documents returned to 3 694 | limited_documents = collection.find().limit(3) 695 | ``` 696 | 697 | ### Distinct Values 698 | 699 | Here is a Python code: 700 | 701 | ```python 702 | # Suppose, the collection has a "country" field for each document 703 | 704 | # Get a list of distinct countries 705 | distinct_countries = collection.distinct("country") 706 | print(distinct_countries) # Output: ["USA", "Canada"] 707 | ``` 708 | 709 | ### Indexes 710 | 711 | Indexes improve read performance. Ensure to use appropriate indexes for frequent and complex queries to speed up data retrieval. If the queries differ from the indexing pattern or if the collection is small, the gain from indexing might be insignificant, or it could even affect the write performance of the database. Choose an indexing strategy based on your data and usage patterns. 712 | 713 | For example, if you frequently query documents based on their "country" field, consider creating an index on that field: 714 | 715 | Here is a Python, PyMongo code: 716 | 717 | ```python 718 | collection.create_index("country") 719 | ``` 720 | 721 | This would make lookups based on the "country" field more efficient. 722 |
723 | 724 | ## 14. Explain how to update _documents_ in _MongoDB_. 725 | 726 | **MongoDB** offers several ways to update documents (equivalent to SQL's "rows"). Let’s look at the most common methods. 727 | 728 | ### Update Methods 729 | 730 | - **Replace**: Entire document is updated. This is the closest equivalence to SQL's `UPDATE` statement. 731 | - **Update**: For selective field updates, you use `$set`, `$inc`, `$push`, `$unset`, and more. This resembles SQL's `UPDATE` with selective column updates. 732 | 733 | ### Replace & Update in _MongoDB_ 734 | 735 | #### Top-Down Approach Using Replace 736 | 737 | - **Method**: `db.collectionName.updateOne()` 738 | - **Code**: 739 | 740 | ```javascript 741 | db.collectionName.updateOne( 742 | {"name": "John Doe"}, 743 | {$set: {"age": 30}} 744 | ); 745 | ``` 746 | 747 | - **Use-Case**: When replacing an entire document isn't needed. For example, when changing a user's email address. 748 | 749 | #### Bottom-Up Approach Using Update + $set 750 | 751 | - **Method**: `db.collectionName.replaceOne()` 752 | - **Code**: 753 | 754 | ```javascript 755 | db.collectionName.replaceOne( 756 | {"name": "John Doe"}, 757 | {"name": "John Doe", "age": 30} 758 | ); 759 | ``` 760 | 761 | - **Use-Case**: When an entire document needs updating or replacing, such as a product detail or a user’s information. 762 |
763 | 764 | ## 15. What are the _MongoDB commands_ for deleting _documents_? 765 | 766 | MongoDB offers several methods for deleting documents. 767 | 768 | ### Deletion Methods in MongoDB 769 | 770 | 1. **deleteOne()**: Deletes the first matched document. 771 | 772 | 2. **deleteMany()**: Removes all matching documents. 773 | 774 | 3. **remove()**: Legacy function; use `deleteOne()` or `deleteMany()` instead. 775 | 776 | ### General Syntax 777 | 778 | - For `deleteOne()`, the syntax is: 779 | - **db.collection.deleteOne({filter}, {options})** 780 | 781 | - For `deleteMany()`, the syntax is: 782 | - **db.collection.deleteMany({filter}, {options})** 783 | 784 | ### Code Example: Deleting One or Many 785 | 786 | Here is the MongoDB shell script: 787 | 788 | ```javascript 789 | // Connect to the database 790 | use myDB; 791 | 792 | // Delete a single document from 'myCollection' 793 | db.myCollection.deleteOne({ name: "Document1" }); 794 | 795 | // Delete all documents from 'myCollection' with the condition 'age' greater than 25 796 | db.myCollection.deleteMany({ age: { $gt: 25 } }); 797 | ``` 798 |
799 | 800 | 801 | 802 | #### Explore all 100 answers here 👉 [Devinterview.io - MongoDB](https://devinterview.io/questions/web-and-mobile-development/mongodb-interview-questions) 803 | 804 |
805 | 806 | 807 | web-and-mobile-development 808 | 809 |

810 | 811 | --------------------------------------------------------------------------------