🧊 NoSQL Databases
The Senior Mindset: NoSQL is not a replacement for SQL; it is a specialized tool. Choosing NoSQL is a trade-off: you often sacrifice ACID compliance and complex joins in exchange for horizontal scalability, high availability, and schema flexibility.
📄 Document Stores (e.g., MongoDB, CouchDB)
Section titled “📄 Document Stores (e.g., MongoDB, CouchDB)”Data is stored in JSON-like documents.
- Best for: Content management, user profiles, and catalogs where the schema evolves rapidly.
- Key Concept: Data Locality. You store related data together in one document to avoid joins.
- Trade-off: Harder to perform cross-document analytics.
🔑 Key-Value Stores (e.g., Redis, DynamoDB, Riak)
Section titled “🔑 Key-Value Stores (e.g., Redis, DynamoDB, Riak)”The simplest form of NoSQL. Data is a blind “blob” indexed by a unique key.
- Best for: Caching, session management, and real-time leaderboards.
- Key Concept: O(1) Access. Retrieval is incredibly fast because there is no query parsing logic.
- Trade-off: You cannot query by the “value” efficiently; you must know the “key.”
🏛️ Wide-Column Stores (e.g., Cassandra, ScyllaDB, HBase)
Section titled “🏛️ Wide-Column Stores (e.g., Cassandra, ScyllaDB, HBase)”Data is stored in column families rather than rows.
- Best for: Massive datasets (petabytes), time-series data, and high-write throughput (logging, IoT).
- Key Concept: Partition Keys. Data is distributed across nodes based on a partition key, allowing for linear horizontal scaling.
- Trade-off: Requires a deep understanding of your query patterns before designing the schema (Query-First Design).
🕸️ Graph Databases (e.g., Neo4j, Amazon Neptune)
Section titled “🕸️ Graph Databases (e.g., Neo4j, Amazon Neptune)”Focuses on the relationships between data points (Nodes and Edges).
- Best for: Social networks, recommendation engines, and fraud detection.
- Key Concept: Index-free Adjacency. Navigating a relationship doesn’t require an index lookup; you just follow a pointer to the next node.
- Trade-off: Not suited for bulk data processing or simple CRUD operations.
⚖️ The NoSQL Decision Matrix (The Senior Perspective)
Section titled “⚖️ The NoSQL Decision Matrix (The Senior Perspective)”| Feature | SQL (Relational) | NoSQL (Non-Relational) |
|---|---|---|
| Scaling | Vertical (Bigger Server) | Horizontal (More Servers) |
| Schema | Rigid / Fixed | Flexible / Dynamic |
| Joins | Native / Complex | Application-side or Denormalized |
| Transactions | Strong ACID | Usually Base (Basically Available, Soft state, Eventual consistency) |
When to stay with SQL?
Section titled “When to stay with SQL?”If your data is highly relational and requires strict consistency (e.g., Ledger/Banking), SQL is almost always the safer bet. Don’t use NoSQL just to avoid writing a migration script.
When to go NoSQL?
Section titled “When to go NoSQL?”- Scale: When your write volume exceeds what a single primary SQL node can handle.
- Unstructured Data: When you don’t know the schema in advance.
- Specific Access Patterns: When your queries perfectly map to a Graph or a Wide-Column structure.
💡 Seniority Note: Beware of Eventual Consistency. In many NoSQL systems, a “Write” might take a few milliseconds to propagate to all nodes. If a user refreshes the page immediately, they might see old data. Designing the UX to handle this (or choosing “Strong Consistency” at the cost of latency) is a key architectural decision.
🔗 Related Links
Section titled “🔗 Related Links”- [[Relational-Databases]]
- [[Arquitetura-Sistemas-Escalaveis]]
- [[Caching-Redis-CDN]]