MongoDB vs MySQL: Interview Insights on NoSQL, Relational Databases, and Search Engines

1. MongoDB and MySQL

Interviewer asks: "Explain the differences between MongoDB and MySQL."

The author prepared for this question because MongoDB is listed on the résumé. MongoDB is a NoSQL document database that stores data as JSON/BSON, offering a flexible schema‑less design.

Key points:

Data is stored in JSON, which is self‑describing and easier to work with than XML.

Reading a non‑existent field in MongoDB does not cause a syntax error, unlike SQL.

MongoDB Advantages

The no‑schema nature brings several benefits:

(1) Adding new fields never causes errors.

For example, adding a nickname field to a user document does not require an ALTER TABLE statement; the field appears automatically when the document is retrieved.

(2) Historical data queries remain safe.

Older documents lacking the new field simply return null for that field, requiring compatibility handling in code.

(3) Easy storage of complex data.

JSON can represent arrays and nested objects, making MongoDB suitable for e‑commerce scenarios with highly variable product attributes.

However, document databases also have drawbacks:

MongoDB Disadvantages

(1) Multi‑document transactions were unsupported before version 4.0.

MongoDB 4.0 introduced cross‑collection transactions for replica sets, and version 4.2 added distributed transactions for sharded clusters.

Transaction usage is straightforward: place the sequence of updates that must be atomic inside a session startTransaction and commitTransaction . Below is a Java example (code omitted for brevity).

(2) No native join support.

Relational databases can retrieve related data with a single JOIN query, while MongoDB often requires multiple queries (e.g., fetch orders, then fetch users).

2. Drawbacks of Relational Databases

Interviewer asks: "Why not use a relational database for this project? What are its disadvantages?"

Key shortcomings of row‑oriented databases:

Row storage : Cannot store arrays or nested fields.

Difficult schema evolution : Adding columns requires ALTER statements and may lock tables ( lock table ), impacting online services.

High memory consumption : Full rows are read into memory even when only a few columns are needed.

Poor full‑text search performance : Relies on LIKE scans, which are inefficient for fuzzy matching.

Because of these issues, the project adopts two non‑relational solutions: MongoDB for flexible document storage and Elasticsearch for full‑text search.

3. NoSQL Classification and Characteristics

Interviewer asks: "Which NoSQL databases do you know and what are their characteristics?"

The author lists four popular NoSQL systems:

Key‑Value stores (e.g., Redis) – store values of various types such as strings, hashes, lists, sets, bitmaps.

Document stores (e.g., MongoDB) – store JSON documents, allowing schema‑less, nested, and array data.

Column‑family stores (e.g., HBase) – store data by column, suited for big‑data I/O scenarios.

Search engines (e.g., Elasticsearch) – provide powerful full‑text search and analytics.

The article also explains why relational databases struggle with efficient full‑text search and introduces the inverted‑index mechanism used by Elasticsearch.

4. Choosing Between Relational and NoSQL

Interviewer asks: "How do you decide between relational and NoSQL databases?"

Selection criteria include data volume, concurrency, real‑time requirements, consistency, read/write separation, security, and operational complexity. Typical use‑cases:

Management systems (e.g., admin dashboards) – prefer relational databases.

High‑traffic systems with rapidly growing schemas – prefer NoSQL.

Log‑type systems – prefer Elasticsearch.

Search‑type systems – also prefer Elasticsearch.

Transactional systems (inventory, accounting) – combine relational DBs with caching and consistency protocols.

Offline analytics – favor columnar databases.

Real‑time monitoring – consider time‑series or columnar stores.

Finally, the interview result: the technical lead was satisfied, but HR was unavailable, and the author never received a follow‑up.