NoSQL
NoSQL, meaning 'Not Only SQL,' refers to a broad class of database management systems that differ from traditional relational databases by not primarily using t...
NoSQL ('Not Only SQL') 데이터베이스는 데이터 모델과 쿼리 메커니즘에서 전통적인 관계형(SQL) 데이터베이스와 다른 다양한 데이터베이스 관리 시스템을 나타냅니다. 이들은 대량의 빠르게 변화하는 비정형 또는 반정형 데이터를 처리하는 데 있어 관계형 데이터베이스의 한계를 해결하고 더 큰 확장성과 유연성을 제공하기 위해 개발되었습니다. 일반적인 NoSQL 데이터 모델에는 key-value stores (예: Redis, DynamoDB), document databases (예: MongoDB, Couchbase), column-family stores (예: Cassandra, HBase), graph databases (예: Neo4j, Amazon Neptune)가 포함됩니다. Key-value stores는 고유한 키를 기반으로 간단하고 고성능의 검색을 제공합니다. Document databases는 유연한 JSON과 유사한 문서에 데이터를 저장하여 스키마 진화를 가능하게 합니다. Column-family stores는 데이터를 행이 아닌 열로 구성하여 대규모 데이터셋에 대한 읽기 및 쓰기를 최적화합니다. Graph databases는 개체 간의 복잡한 관계를 표현하고 쿼리하는 데 탁월합니다. NoSQL 데이터베이스는 종종 CAP theorem을 따르면서 엄격한 일관성보다 가용성과 파티션 내성을 우선시하며, 조정 가능한 일관성 수준을 제공합니다. 이들은 일반적으로 관계형 데이터베이스에서 자주 요구되는 수직적 확장과 달리, 더 많은 범용 서버를 추가하여 수평적으로 확장합니다. 단점으로는 모든 유형에 걸쳐 표준화된 쿼리 언어가 부족하고, 데이터 중복 가능성이 있으며, SQL에서 표준적인 복잡한 join이나 트랜잭션을 수행하는 데 어려움이 있을 수 있습니다.
graph LR
Center["NoSQL"]:::main
Pre_data_structures["data-structures"]:::pre --> Center
click Pre_data_structures "/terms/data-structures"
Pre_distributed_systems["distributed-systems"]:::pre --> Center
click Pre_distributed_systems "/terms/distributed-systems"
Rel_relational_databases["relational-databases"]:::related -.-> Center
click Rel_relational_databases "/terms/relational-databases"
Rel_big_data["big-data"]:::related -.-> Center
click Rel_big_data "/terms/big-data"
Rel_vector_database["vector-database"]:::related -.-> Center
click Rel_vector_database "/terms/vector-database"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 5살도 이해할 수 있게 설명
NoSQL 데이터베이스는 컴퓨터 정보를 저장하는 다양한 종류의 상자와 같습니다. 파일 캐비닛([SQL](/ko/terms/sql))처럼 모든 것을 정리하는 한 가지 방법 대신, 많은 유사한 항목을 위한 큰 통이나 연결된 메모를 위한 특별한 바인더처럼 다양한 요구에 맞는 특별한 상자를 사용할 수 있습니다.
🤓 Expert Deep Dive
NoSQL databases diverge significantly from the ACID (Atomicity, Consistency, Isolation, Durability) properties typically guaranteed by relational databases, often embracing BASE (Basically Available, Soft state, Eventually consistent) principles, particularly in distributed systems prioritizing availability and partition tolerance (AP systems in CAP theorem). Key-value stores leverage hash tables or similar structures for O(1) average-case lookups. Document databases use formats like BSON or JSON, allowing for nested structures and dynamic schemas, often indexed for efficient querying. Column-family stores (wide-column stores) partition data by row key and then group related columns into column families, optimizing for queries that access specific column subsets across many rows. Graph databases use nodes, edges, and properties, with traversal algorithms optimized for relationship exploration. Architectural trade-offs center on the CAP theorem: choosing between Consistency and Availability in the presence of network partitions. Scalability is typically achieved via sharding and replication. Vulnerabilities can arise from insecure default configurations, lack of robust transaction support, and potential data inconsistencies if not managed carefully.