Dr. Hasan Dalmaz

› SELECT inst_id, instance_name, status FROM gv$instance ORDER BY inst_id;

▸ 핵심

RAC에서는 여러 서버가 같은 데이터베이스를 함께 운영하므로 한 대에 장애가 나도 시스템은 계속 동작한다.

✓ 강점

무중단 운영과 재해 복구(Data Guard)를 위한 가장 성숙한 엔터프라이즈 선택지.

⚠ 주의점

라이선스 비용이 높고 전문 지식이 필요하다. 소규모 프로젝트에는 과하다.

→ 적합한 용도

다운타임을 허용할 수 없는 대규모 엔터프라이즈 시스템: 은행, ERP.

› CREATE EXTENSION vector;

▸ 핵심

오픈 소스. 익스텐션으로 기능을 확장할 수 있다 — 지도 데이터나 AI용 벡터 검색 등.

✓ 강점

무료이면서 강력하고 표준을 따른다. 단순한 레코드부터 복잡한 쿼리까지 모두 처리한다.

⚠ 주의점

갱신/삭제가 많은 시스템은 정기적인 VACUUM 유지보수와 튜닝이 필요하다.

→ 적합한 용도

웹·모바일 앱 백엔드, 지도(GIS), AI 프로젝트.

› CREATE AVAILABILITY GROUP ag_prod;

▸ 핵심

Microsoft의 데이터베이스. Windows/.NET 환경과 매끄럽게 연동되며 강력한 도구(SSMS)를 제공한다.

✓ 강점

일상적인 트랜잭션과 리포팅/분석을 하나의 시스템에서 모두 잘 처리한다.

⚠ 주의점

Windows에서 가장 잘 동작한다. Enterprise Edition 라이선스는 비싸다.

→ 적합한 용도

엔터프라이즈 .NET 애플리케이션과 비즈니스 인텔리전스/리포팅 시스템.

› START REPLICA;

▸ 핵심

웹에서 가장 널리 쓰이는 데이터베이스. 설치와 사용이 쉽고 커뮤니티가 매우 크다.

✓ 강점

가볍고 빠르다. 특히 읽기 위주의 사이트에서 쉽게 확장된다.

⚠ 주의점

매우 복잡한 분석과 고급 쿼리에서는 Oracle/PostgreSQL만큼 깊이 있지 않다.

→ 적합한 용도

WordPress 같은 사이트와 트래픽이 많고 읽기 위주인 웹 앱.

› db.orders.find({ status: "paid" })

▸ 핵심

데이터를 테이블 대신 유연한 “문서”(JSON 유사) 형태로 저장한다. 고정된 스키마가 필요 없다.

✓ 강점

빠른 개발이 가능하고, 크고 자주 바뀌는 데이터에 적합하며, 쉽게 수평 확장된다(샤딩).

⚠ 주의점

설계가 부실하면 중복과 불일치가 생길 수 있다. 엄격한 관계 무결성이 필요한 곳에서는 우선 선택지가 아니다.

→ 적합한 용도

카탈로그, 콘텐츠 관리, 구조가 자주 바뀌는 앱.

› SET session:42 online EX 3600

▸ 핵심

데이터를 디스크가 아닌 메모리(RAM)에 보관하므로 거의 즉시 응답한다.

✓ 강점

매우 빠르다. 캐싱, 세션, 실시간 카운터에 적합하다.

⚠ 주의점

데이터가 RAM에 모두 들어가야 하며, 영속성(persistence) 설정이 올바르지 않으면 데이터가 손실될 수 있다.

→ 적합한 용도

캐싱, 세션 저장, 리더보드 등 속도가 중요한 모든 곳.

› GET /products/_search?q=laptop

▸ 핵심

텍스트 검색을 위해 만들어진 엔진. 역색인으로 수백만 건의 문서를 검색하고 관련도순으로 결과를 정렬한다.

✓ 강점

매우 빠른 검색, 자동 완성, 로그/분석(ELK 스택). 쉽게 수평 확장된다.

⚠ 주의점

주 데이터베이스가 아니다. 보통 메인 데이터베이스와 함께 검색/로그 계층으로 운영된다.

→ 적합한 용도

사이트·상품 검색, 로그 분석, 관측성.

› SELECT * FROM orders JOIN users USING (id);

▸ 핵심

데이터를 서로 연결된 테이블에 정돈해 저장하고 SQL로 조회한다. 수십 년간 검증된 모델.

✓ 강점

강한 일관성: 트랜잭션은 완전히 수행되거나 전혀 수행되지 않는다(ACID). 복잡한 쿼리에 매우 강력하다.

⚠ 주의점

여러 서버로 분산(샤딩)하기 어렵고, 나중에 스키마를 변경하려면 신중한 계획이 필요하다.

→ 적합한 용도

금융, 재고 등 정확성이 중요한 모든 시스템.

› { "user": "hd", "roles": ["dba"] }

▸ 핵심

고정된 테이블 대신 유연한 구조(문서, 키-값…)를 사용한다. 대규모를 위해 설계되었다.

✓ 강점

여러 서버로 쉽게 분산되고 많은 쓰기 부하도 무리 없이 처리한다.

⚠ 주의점

대개 SQL의 강한 일관성 보장과 테이블 조인(JOIN)이 없다.

→ 적합한 용도

대규모 웹, 실시간 분석, 유연한 구조의 데이터.

› BEGIN; UPDATE acct SET bal = bal - 100; COMMIT;

▸ 핵심

두 가지 일관성 철학: ACID는 모든 트랜잭션이 온전히 완료됨을 보장하고, BASE는 속도와 가용성을 위해 이를 완화한다.

✓ 강점

ACID는 금융 거래처럼 중요한 데이터에 신뢰성을 주고, BASE는 대규모 확장과 상시 접근을 가능하게 한다.

⚠ 주의점

BASE에서는 데이터가 잠시 “최신이 아닐” 수 있으므로 앱에서 이를 고려해야 한다.

→ 적합한 용도

ACID: 결제 시스템. BASE: 소셜 미디어 피드, 좋아요 수.

› -- OLTP: point writes · OLAP: aggregate scans

▸ 핵심

두 종류의 워크로드: OLTP는 수많은 일상적 소규모 트랜잭션(주문, 결제), OLAP는 대용량 데이터 분석.

✓ 강점

올바르게 분리하면 둘 다 빨라진다. 하나는 일상 업무를, 다른 하나는 리포팅을 담당한다.

⚠ 주의점

하나의 시스템에서 둘 다 실행하면 서로 느려지므로 보통 분리한다.

→ 적합한 용도

OLTP: 주문/결제. OLAP: 리포트, 대시보드, 데이터 웨어하우스.