SQL과 NoSQL 데이터베이스

Welcome! In this lesson, we'll dive into the world of databases, specifically comparing two major categories: SQL and NoSQL.

Understanding their differences is crucial for any system designer, as the choice impacts scalability, performance, and data integrity.

SQL stands for Structured Query Language. These databases are also known as Relational Databases.

• They store data in tables with rows and columns.
• Each table has a predefined schema (structure).
• Relationships between tables are defined using keys.
• Examples: MySQL, PostgreSQL, Oracle, SQL Server.

SQL databases are known for their ACID properties, which ensure reliable transaction processing:

• Atomicity: All or nothing for transactions.
• Consistency: Data always valid after a transaction.
• Isolation: Concurrent transactions don't interfere.
• Durability: Committed data is permanent.

This makes them ideal for financial transactions and applications needing high data integrity.

The rigid schema of SQL databases ensures data consistency and makes it easy to manage structured data.

SQL, the query language, is powerful for:

• Performing complex joins across multiple tables.
• Filtering and aggregating data efficiently.
• Ensuring data integrity through constraints.

While powerful, SQL databases have some downsides:

• Schema Rigidity: Changes to the data structure (schema) can be complex and time-consuming, especially for large databases.
• Vertical Scaling: They typically scale vertically, meaning you add more power (CPU, RAM) to a single server. This has limits and can be expensive.

NoSQL stands for "Not Only SQL." These are non-relational databases that offer more flexibility than traditional SQL databases.

They don't use tables, rows, or fixed schemas. Instead, they store data in various ways:

• Key-Value: Simple key-value pairs (e.g., Redis).
• Document: Stores data as semi-structured documents (e.g., MongoDB).
• Column-Family: Stores data in columns (e.g., Cassandra).
• Graph: Stores data as nodes and edges (e.g., Neo4j).

NoSQL databases shine in scenarios requiring high scalability and flexible data models:

• Horizontal Scaling: They easily scale out by adding more servers, distributing the load. This is often more cost-effective.
• Flexible Schema: They can handle unstructured or semi-structured data, allowing for rapid development and evolving data requirements.
• High Availability: Designed for distributed environments, they can remain available even if some servers fail.

The flexibility and scalability of NoSQL come with trade-offs:

• Eventual Consistency: Data might not be immediately consistent across all servers, leading to "eventual consistency."
• Complex Transactions: Multi-document or multi-table transactions can be challenging or require application-level logic.
• No Complex Joins: They typically don't support complex joins like SQL, requiring data denormalization or application-side joining.

The best database depends on your specific needs. Consider SQL for:

• Applications requiring strong ACID compliance (e.g., banking, e-commerce orders).
• Highly structured data with clear relationships.
• Complex queries and reporting needs.
• Smaller to medium-sized datasets that can be managed on a single powerful server.

Consider NoSQL for:

• Large volumes of rapidly changing, unstructured, or semi-structured data (e.g., IoT data, social media feeds).
• Applications requiring extreme horizontal scalability and high availability.
• Real-time applications with low latency requirements.
• Rapid prototyping and agile development where schema changes are frequent.

Imagine you're designing a new system. Which database type would be *most appropriate* for storing user profiles with flexible attributes (like custom social media links, optional bio fields) and needing to scale to millions of users globally?

Great job! You've learned the key differences between SQL (relational) and NoSQL (non-relational) databases.

• SQL excels with structured data, ACID transactions, and complex queries.
• NoSQL offers flexibility, horizontal scalability, and handles unstructured data well.
• The best choice depends on your specific project requirements for data structure, consistency, and scale.

Keep exploring and designing!