오랜만에 커밋

2026-05-04 10:30:04 +09:00
parent c35c042afa
commit 722d5dbfaf
56 changed files with 2288 additions and 11 deletions
@@ -0,0 +1,66 @@
+---
+id: "MariaDB vs PostgreSql 20260421"
+created: "2026-04-21 16:43"
+tags:
+---
+이 두 DB는 현재 오픈소스 RDBMS 시장의 양대 산맥입니다. **MariaDB**가 MySQL의 친숙함을 계승하며 실용성에 집중한다면, **PostgreSQL**은 데이터 무결성과 고급 기능을 중시하는 학구적이고 정교한 DB라고 할 수 있습니다.
+
+## 1. 철학 및 개발 배경
+|**구분**|**MariaDB**|**PostgreSQL**|
+|---|---|---|
+|**태생**|MySQL에서 분차(Fork)되어 나온 실용주의 DB|학계에서 시작된 객체-관계형(ORDBMS) 표준 지향 DB|
+|**슬로건**|"MySQL보다 빠르고 더 많은 기능을 무료로"|"세계에서 가장 진보된 오픈소스 관계형 데이터베이스"|
+|**라이선스**|GPL v2 (비즈니스 시 소스 공개 의무 주의)|PostgreSQL 라이선스 (BSD/MIT와 유사, 매우 자유로움)|
+
+## 2. 기술적 핵심 차이
+### 🚩 SQL 표준 및 복잡한 쿼리 처리
+
+- **PostgreSQL:** SQL 표준 준수율이 매우 높습니다. 복잡한 조인(Join), 재귀 쿼리(Recursive CTE), 윈도우 함수 성능이 뛰어나며, 분석용 쿼리 최적화가 강력합니다. (MSSQL과 사용감이 비슷합니다.)
+    
+- **MariaDB:** MySQL의 문법을 따르며, 단순한 CRUD 성능에 최적화되어 있습니다. 최근 버전에서 CTE나 윈도우 함수를 지원하지만, 복잡한 비즈니스 로직 처리에서는 PostgreSQL에 비해 최적화가 덜 정교할 수 있습니다.
+    
+
+### 🚩 데이터 타입과 확장성
+
+- **PostgreSQL:** 독보적입니다. JSONB(바이너리 JSON) 지원으로 NoSQL처럼 쓸 수 있고, 지리 정보(PostGIS), 전문 검색(Full-text search) 등이 내장되어 있습니다. 사용자 정의 타입도 만들 수 있습니다.
+    
+- **MariaDB:** 동적 컬럼(Dynamic Columns) 기능을 통해 비정형 데이터를 다루지만, PostgreSQL의 JSONB 성능에는 미치지 못합니다. 대신 다양한 스토리지 엔진(InnoDB, Aria, ColumnStore 등)을 용도에 맞게 선택할 수 있는 유연성이 있습니다.
+    
+
+### 🚩 동시성 제어 (MVCC)
+
+- **PostgreSQL:** 데이터 쓰기 중에도 읽기가 차단되지 않는 MVCC(Multi-Version Concurrency Control) 방식이 매우 세련되어 있어, 동시 접속자가 많은 대형 시스템에 유리합니다.
+    
+- **MariaDB:** 스토리지 엔진(주로 InnoDB) 수준에서 MVCC를 지원하며, 읽기 위주의 서비스에서 가볍고 빠르게 동작합니다.
+
+## 3. 상세 비교 테이블
+
+| **항목**              | **MariaDB**                  | **PostgreSQL**                              |
+| ------------------- | ---------------------------- | ------------------------------------------- |
+| **주요 용도**           | 웹 서비스, CMS(워드프레스 등), 단순 CRUD | 복잡한 데이터 분석, 금융 시스템, GIS 서비스                 |
+| **성능 특징**           | 읽기(Read) 성능이 매우 빠름           | 복잡한 쓰기(Write) 및 대량 데이터 처리에 강함               |
+| **복제(Replication)** | 마스터-슬레이브 방식이 매우 쉽고 직관적       | 논리적 복제 등 다양한 방식 지원 (설정은 좀 더 복잡)             |
+| **저장 프로시저**         | 지원 (MySQL 문법)                | 강력 지원 (PL/pgSQL, Python, Perl 등 지원)         |
+| **인덱싱**             | 기본 B-Tree 위주                 | B-Tree, Hash, GiST, SP-GiST, GIN, BRIN 등 다양 |
+
+## 4. 어떤 것을 선택해야 할까?
+### 🐧 MariaDB를 선택할 때
+
+- 기존에 MySQL을 써본 적이 있어 익숙함이 중요할 때.
+    
+- 커뮤니티나 자료가 많은 것을 선호할 때.
+    
+- 단순한 웹 게시판이나 가벼운 데이터 저장용일 때.
+    
+- PHP나 구형 웹 스택과의 호환성이 중요할 때.
+    
+
+### 🐘 PostgreSQL을 선택할 때
+
+- **MSSQL 2019의 고급 기능을 오픈소스에서도 누리고 싶을 때.**
+    
+- 데이터 정합성이 무엇보다 중요한 금융, 결제, 정산 관련 프로젝트일 때.
+    
+- JSON 데이터를 빈번하게 다루면서 속도도 포기할 수 없을 때.
+    
+- 프로젝트가 커질 것을 대비해 확장성이 뛰어난 DB가 필요할 때.
@@ -0,0 +1,64 @@
+---
+id: RDBMS vs NoSQL 20260420
+created: 2026-04-20 08:43
+tags:
+---
+DB에는 크게 [[RDBMS]]와 NoSQL 두가지의 범주가 있음.
+둘 다 데이터베이스를 구축하기위한 방법론의 개념이고 상호간에 차이점들이 존재한다.
+
+하지만 데이터베이스라면 당연히 [[데이터 정합성(Data Consistency)]]을 지키는것이 최우선 목표이다.
+NoSQL이 [[데이터 정합성(Data Consistency)]]을 지키지 않는 것은 절대 아니다.
+[[데이터 정합성(Data Consistency)]]을 지키지 않는 건 데이터베이스로서 가치가 없다.
+
+
+이 둘의 가장 큰 차이점은 데이터의 중복을 어느 정도 허용할 것인가? 라고 생각된다.
+![[NoSQL#데이터 중복(Data Redundancy)]]
+
+## NoSQL이 중복을 허용하는 이유
+
+### **JOIN 연산의 배제**
+
+NoSQL은 수평적 확장을 위해 데이터를 여러 서버에 분산 저장합니다. 이때 여러 서버에 흩어진 데이터를 JOIN 하는 작업은 성능에 막대한 지장을 줍니다. 이를 피하기 위해 필요한 데이터를 한 곳에 모아(중복 저장) 한 번의 쿼리로 읽어오도록 설계합니다.
+
+### **읽기 성능 극대화**
+
+사용자가 화면을 볼 때 필요한 모든 정보를 하나의 'Document'나 'Row'에 다 담아두면, 여러 테이블을 뒤질 필요 없이 즉시 응답할 수 있습니다.
+
+
+## 데이터 중복으로 인한 기회비용
+
+중복을 허용하면 얻는 것도 있지만, 반드시 대가를 치러야 합니다.
+
+- **데이터 수정의 복잡성 (Update Anomaly):** 사용자 이름이 바뀌면, 그 이름이 중복 저장된 수천 개의 게시글 데이터를 모두 업데이트해야 합니다. 이때 일부가 누락되면 데이터 정합성이 깨집니다.
+    
+- **저장 공간 증가:** 동일한 데이터가 반복 저장되므로 저장 용량을 더 많이 차지합니다. 하지만 현대의 클라우드 인프라에서는 저장 비용보다 컴퓨팅 성능(속도) 비용이 더 중요하므로 대개 용납됩니다.
+    
+- **결과적 일관성 (Eventual Consistency):** 모든 중복 데이터를 즉시 수정하는 것이 어렵기 때문에, "잠시 동안은 데이터가 다를 수 있지만 결국에는 같아진다"는 원칙을 따르게 됩니다.
+
+
+## RDBMS vs NoSQL: 언제 무엇을 쓸까?
+
+어느 하나가 절대적으로 우월한 것이 아니라, 서비스의 성격에 맞춰 선택하거나 두 가지를 혼합해서 사용합니다.
+
+### **RDBMS를 써야 할 때**
+
+- 데이터 구조가 명확하고 변경될 일이 적을 때
+    
+- **금융 시스템**처럼 [[데이터 정합성(Data Consistency)]]과 [[트랜잭션(Transaction)|트랜젝션]]([[ACID]])이 매우 중요할 때
+    
+- 복잡한 쿼리와 JOIN 연산이 자주 필요할 때
+    
+
+### **NoSQL을 써야 할 때**
+
+- 데이터 구조가 확정되지 않았거나 자주 변경될 때
+    
+- **빅데이터, 로그 관리, 실시간 메신저**처럼 막대한 양의 데이터를 빠르게 처리해야 할 때
+    
+- [[데이터 정합성(Data Consistency)]]보다는 서비스의 [[가용성(Availability)]](항상 접속 가능함)이 더 중요할 때 
+
+[[NoSQL]]은 "데이터가 조금 틀려도 괜찮으니, 절대 죽지 않고 엄청나게 빠른 시스템"을 만들 때 씁니다. 반면 [[RDBMS]]는 "성능이 조금 답답하더라도, 데이터는 단 1원, 1글자도 틀리면 안 되는 시스템"에 씁니다.
+
+> [!warning] 그렇다고 해서 NoSQL이 데이터정합성이 안맞단건 절대 아님
+> 실시간으로 정합성을 맞춰주느냐? (RDBMS), 순간적으로는 안맞을 수 있지만 결과적으론 정합성이 맞다 (NoSQL)
+
@@ -0,0 +1,20 @@
+---
+id: RDBMS사용 시 주의점들 20260420
+created: 2026-04-20 10:55
+tags:
+---
+> [!question]
+> Q. 관계형db에서는 테이블간의 관계를 여러테이블을 조인하지 않게끔 적절히 분산시키면서 인덱스를 잘 거는게 엄청 중요하겠네?
+> A. 정확하게 짚으셨습니다! 관계형 데이터베이스(RDBMS) 운영의 핵심이자 개발자의 실력이 가장 극명하게 드러나는 지점이 바로 그 **'조인(JOIN) 최소화'와 '인덱스(Index) 전략'**입니다.
+
+## 조인 최소화: "관계는 유지하되, 데이터는 뭉친다"
+
+관계형 DB라고 해서 무조건 모든 데이터를 쪼개는 게 정답은 아닙니다. 성능을 위해 의도적으로 정합성을 조금 희생하는 기법들이 필요합니다.
+과도하게 데이터를 쪼개놓을 경우 데이터 조인이 많이 발생될 수 밖에 없는데 데이터 조인은 어느정도 느릴 수 밖에 없다.
+- [[데이터 조인이 느린 이유]]
+
+결국 RDBMS 설계의 꽃은 **인덱스를 활용해 '수학적인 탐색 비용'을 얼마나 낮게 유지하느냐**에 달려 있습니다.
+하지만 아무리 인덱스를 잘 설정해도 조인해야 할 테이블이 5개, 10개씩 늘어나면 성능은 떨어질 수밖에 없습니다.
+- **Nested Loop의 누적:** 조인이 중첩될수록 내부 루프의 횟수가 곱하기로 늘어납니다.
+
+그래서 적당한 데이터 분산이 중요합니다.