System design: Relational vs Non-Relational Databases

Jayaprasanna Roddam - Oct 6 - - Dev Community

Relational vs Non-Relational Databases

Data is the heart of any application, and how you store, retrieve, and manage it has a significant impact on your system's performance, scalability, and complexity. Choosing between relational and non-relational databases is a crucial decision, as each has its strengths and weaknesses. In this section, we’ll explore the differences between these two types of databases, their use cases, and when one might be better suited than the other.


Relational Databases (RDBMS)

Relational databases are traditional databases that store data in structured tables with rows and columns. They follow a well-defined schema and are designed to manage data using relationships between tables, making them ideal for complex data structures.

1. Structure and Schema

Relational databases use a tabular structure, meaning data is organized into tables with predefined columns (fields) and rows (records). Each table represents a distinct entity, such as users, orders, or products, and the relationships between these entities are maintained using primary keys and foreign keys.

  • Schema: Relational databases enforce a strict schema, meaning the structure of data is predefined. Every table has a specific set of fields, and data must adhere to this structure. For instance, if you have a table for users with columns like user_id, name, and email, every record must include these fields.

  • Normalization: Relational databases often use normalization to minimize data redundancy and maintain data integrity. Data is broken down into smaller, related tables to reduce duplication.

Example:

Imagine an e-commerce application with a relational database. You might have the following tables:

  • Users: Stores information about customers.
  • Products: Stores details about items available for sale.
  • Orders: Contains records of each order placed, including a reference to the user and products.

These tables are related via foreign keys, allowing you to join data and query relationships. If you want to find out all orders placed by a user, you can use an SQL query like:



SELECT Orders.id, Products.name
FROM Orders
JOIN Users ON Orders.user_id = Users.id
JOIN Order_Products ON Orders.id = Order_Products.order_id
JOIN Products ON Order_Products.product_id = Products.id
WHERE Users.name = 'Alice';

Enter fullscreen mode Exit fullscreen mode




2. ACID Properties

Relational databases adhere to ACID properties, which ensure reliability and data integrity in multi-step operations or transactions:

  • Atomicity: Ensures that all steps in a transaction are completed successfully, or none are. If one part fails, the entire transaction is rolled back.
  • Consistency: Ensures that the database transitions from one valid state to another, maintaining data integrity.
  • Isolation: Ensures that concurrent transactions do not interfere with each other.
  • Durability: Ensures that once a transaction is committed, it is permanently saved, even in the event of a system failure.

Practical Example:

In an e-commerce app, placing an order might involve multiple steps, such as reducing the stock quantity, updating the order status, and charging the customer. Using ACID-compliant transactions ensures that all these operations are either successfully completed or none are, preventing issues like over-selling an out-of-stock product.

3. Advantages of Relational Databases

  • Data Integrity: The predefined schema and relationships between tables ensure that data remains consistent and valid.
  • Complex Queries: SQL allows for powerful and complex queries, especially with JOINs to combine data from multiple tables.
  • ACID Compliance: Relational databases are ideal for applications that require strong data consistency, like financial systems or order management.

4. Disadvantages of Relational Databases

  • Scalability: Scaling relational databases can be challenging, especially as the size of the data grows. While vertical scaling (adding more resources to a single server) is possible, horizontal scaling (distributing data across multiple servers) is difficult due to the complexity of managing relationships across servers.
  • Schema Rigidity: The predefined schema can make it hard to adapt to changing requirements. For instance, adding a new field to a table might require downtime or significant changes to the schema.

Popular Relational Databases:

  • MySQL
  • PostgreSQL
  • Oracle
  • SQL Server

Non-Relational Databases (NoSQL)

Non-relational (NoSQL) databases are designed to handle large amounts of unstructured or semi-structured data. Unlike relational databases, NoSQL databases are schema-less, meaning data can be stored in a more flexible format, without predefined relationships between entities.

1. Structure and Flexibility

NoSQL databases are not limited to a single structure; they can be document-based, key-value stores, column-family stores, or graph-based.

  • Document Stores: These databases store data in JSON-like documents, making them flexible and allowing for varying structures between records.

    • Example: MongoDB.
  • Key-Value Stores: These databases store data as simple key-value pairs, similar to a hash map or dictionary.

    • Example: Redis.
  • Column-Family Stores: These databases store data in columns rather than rows, making them efficient for storing large amounts of sparse data.

    • Example: Cassandra.
  • Graph Databases: These databases are optimized for managing relationships between data, representing data as nodes (entities) and edges (relationships).

    • Example: Neo4j.

Practical Example:

In a social media application, you might store user profiles in a document store like MongoDB. Each user's profile could contain different fields (some users might have added profile pictures or links to other social accounts), and this flexibility allows you to easily handle these variations without a predefined schema.

2. BASE Properties

Unlike relational databases that adhere to ACID, many NoSQL databases follow the BASE model:

  • Basically Available: The system guarantees availability even in the case of partial failures.
  • Soft State: The state of the system may change over time, even without input (due to eventual consistency).
  • Eventual Consistency: The system may not be immediately consistent, but it will eventually reach a consistent state.

Practical Example:

Consider a distributed system for online shopping with a NoSQL database like Cassandra. In a distributed setup, the same item could be viewed by users across different regions, and due to network delays, the stock levels might be temporarily inconsistent. However, the system will eventually sync up and provide a consistent view.

3. Advantages of NoSQL Databases

  • Scalability: NoSQL databases are designed to scale horizontally by distributing data across multiple servers or nodes. This makes them suitable for handling massive datasets in real-time applications.
  • Flexibility: The schema-less design allows for easy changes to the data model without downtime or complex migrations.
  • Performance: For certain types of queries, like retrieving a document by key or scanning a column, NoSQL databases can be extremely fast.

4. Disadvantages of NoSQL Databases

  • Limited Querying Capabilities: NoSQL databases often lack the sophisticated querying capabilities of relational databases, especially when it comes to JOINs. Instead, data may need to be denormalized, leading to redundancy.
  • Consistency Trade-offs: Many NoSQL databases prioritize availability and partition tolerance over consistency, leading to scenarios where the system may return stale data (eventual consistency).
  • Complexity in Transactions: NoSQL databases may not support multi-document ACID transactions, making them less suitable for applications that require strict data consistency.

Popular NoSQL Databases:

  • MongoDB (Document Store)
  • Cassandra (Column-Family Store)
  • Redis (Key-Value Store)
  • Neo4j (Graph Database)

When to Use Relational vs. Non-Relational Databases

Use Relational Databases When:

  • Data Integrity is Critical: If your application requires strong consistency and needs to enforce data integrity through foreign keys and relationships, an RDBMS is ideal.
  • Complex Queries are Necessary: If you need to perform complex queries, especially involving multiple tables and relationships, relational databases offer powerful tools for querying and managing data.
  • Transactional Support: Applications that rely on multi-step transactions, such as financial systems, benefit from the ACID properties of relational databases.

Use Non-Relational Databases When:

  • Scalability is a Priority: NoSQL databases excel at horizontal scaling, making them suitable for applications with massive amounts of data, like social media platforms or real-time analytics.
  • Data Structure is Flexible: If your data schema is likely to evolve or vary between records, NoSQL databases offer more flexibility without the need for predefined schemas.
  • High Throughput, Low Latency: In scenarios where performance and low-latency access to data are more important than strict consistency (e.g., caching layers), NoSQL databases can provide significant advantages.

Conclusion

The choice between relational and non-relational databases depends on your application’s requirements. Relational databases provide consistency, structure, and powerful querying capabilities, making them suitable for applications with complex data relationships. On the other hand, non-relational databases offer scalability, flexibility, and high performance, making them ideal for large-scale, distributed systems where data structure may evolve over time. Understanding the strengths and weaknesses of each type will help you design systems that can handle your application’s specific needs

. . . . . . . . . . . .
Terabox Video Player