데이터베이스 면접 질문 모음집
데이터베이스 면접 질문 모음집
관계형 Database Modeling vs. 분석 데이터베이스(OLAP) Modeling:
관계형 Database Modeling: 관계형 데이터베이스 모델링은 데이터를 테이블 형태로 구조화하는 방법입니다. 이 모델링은 개체 간의 관계를 정의하고 데이터의 일관성과 무결성을 유지하기 위해 테이블, 열, 기본 키, 외래 키 등의 구성 요소를 사용합니다. 주로 OLTP(On-Line Transaction Processing) 시스템에서 사용됩니다.
분석 데이터베이스(OLAP) Modeling: OLAP 모델링은 의사 결정 지원을 위해 대규모 데이터 집합을 분석하는 데 사용됩니다. OLAP 모델링은 다차원 데이터 구조를 사용하여 데이터를 조직화하고 집계 및 분석 기능을 제공합니다. OLAP 시스템은 대량의 데이터에서 복잡한 쿼리를 수행하고 결과를 다차원 형태로 표시하여 비즈니스 인텔리전스(Business Intelligence)를 지원합니다.
정규화(Normalization) vs. 비정규화(Denormalization):
정규화(Normalization): 정규화는 데이터베이스 설계에서 중복을 최소화하고 데이터의 일관성과 무결성을 유지하기 위한 과정입니다. 이를 통해 데이터를 여러 테이블로 분해하고 테이블 간의 관계를 설정합니다. 주요 목표는 데이터 중복을 피하고 삽입, 갱신, 삭제 이상을 방지하는 것입니다. 정규화는 주로 OLTP 시스템에서 사용됩니다.
비정규화(Denormalization): 비정규화는 데이터베이스 성능을 향상시키기 위해 데이터 중복을 일부로 허용하는 과정입니다. 이를 통해 데이터 검색 속도를 높이거나 복잡한 조인을 줄일 수 있습니다. 비정규화는 OLAP 시스템에서 주로 사용되며, 데이터의 읽기 성능을 최적화하기 위해 데이터를 조합하거나 중복을 추가할 수 있습니다.
CDC(Capture, Deletion, Change Data Capture) 접근 방식의 비교:
Trigger: 트리거는 데이터베이스의 특정 이벤트(INSERT, UPDATE, DELETE 등)가 발생할 때 자동으로 실행되는 저장 프로시저입니다. 트리거를 사용하여 변경된 데이터를 캡처하고 처리할 수 있습니다.
Query: 쿼리 기반 CDC 접근 방식은 주기적으로 변경된 데이터를 추출하기 위해 쿼리를 실행하는 방법입니다. 예를 들어, 일정 간격으로 변경된 데이터를 추출하기 위해 특정 테이블을 조회하는 쿼리를 실행합니다.
Log Reader: 로그 리더 기반 CDC 접근 방식은 데이터베이스의 트랜잭션 로그를 분석하여 변경된 데이터를 식별합니다. 트랜잭션 로그는 데이터베이스의 변경 작업에 대한 상세한 정보를 포함하고 있으므로 로그 리더를 사용하여 변경 사항을 캡처할 수 있습니다.
ER 모델에서 Constraint와 테이블 설계시 Key의 역할:
Primary key (기본 키): 테이블에서 각 행을 고유하게 식별하는 데 사용되는 열이나 열의 집합입니다. 주로 테이블의 기본 키는 테이블 간의 관계를 설정하는 데 사용됩니다.
Unique key (고유 키): 테이블에서 각 행을 고유하게 식별하는 데 사용되는 열이나 열의 집합입니다. 기본 키와 유사하지만, 고유 키는 NULL 값을 허용할 수 있습니다. 주로 데이터 무결성을 유지하기 위해 사용됩니다.
Foreign key (외래 키): 다른 테이블의 기본 키를 참조하는 열이나 열의 집합입니다. 외래 키를 사용하여 테이블 간의 관계를 설정하고 참조 무결성을 유지할 수 있습니다.
인덱스 스캔 방식 비교:
Index Range Scan: 범위 검색을 위해 인덱스를 사용하는 방식입니다. 인덱스의 일부 또는 전체를 스캔하여 지정된 범위 내의 데이터를 찾습니다.
Index Full Scan: 인덱스의 모든 엔트리를 스캔하여 데이터를 찾는 방식입니다. 인덱스 자체가 데이터를 포함하고 있으므로 인덱스를 스캔하는 것만으로 데이터를 가져올 수 있습니다.
Index Unique Scan: 유일한 값을 가진 엔트리를 찾기 위해 인덱스를 스캔하는 방식입니다. 주로 기본 키나 고유 인덱스를 사용하여 특정 레코드를 찾을 때 사용됩니다.
Index Skip Scan: 다중 컬럼 인덱스에서 앞의 컬럼 값이 주어지지 않더라도 인덱스를 스캔하여 데이터를 찾는 방식입니다. 일부 컬럼 값이 주어지면 해당 값에 대한 인덱스 스캔을 수행하고, 나머지 컬럼 값은 인덱스 내에서 스킵하여 데이터를 찾습니다.
CDC에서 Debezium의 구성 방식과 역할:
Debezium은 오픈 소스 CDC 플랫폼으로, 데이터베이스의 변경 사항을 실시간으로 캡처하고 변경 데이터를 안정적인 메시징 시스템으로 전송합니다. Debezium은 데이터베이스의 로그를 모니터링하고 변경 사항을 이벤트로 캡처하기 위해 데이터베이스의 로그 마이닝 기술을 활용합니다.
Debezium은 일반적으로 데이터베이스의 로그를 읽기 위해 데이터베이스의 로그 마이닝 API 또는 로그 스트리밍 기능을 사용합니다. 이를 통해 변경 데이터를 캡처하고 이벤트 메시지로 변환하여 메시징 시스템(Kafka 등)으로 전송합니다. 이렇게 전송된 변경 데이터는 다른 시스템에서 실시간으로 소비되어 데이터 동기화, 스트리밍 처리, 데이터 분석 등에 활용될 수 있습니다.
View vs. Materialized View:
View: View는 하나 이상의 테이블로부터 유도된 가상 테이블입니다. View는 쿼리 결과를 저장하지 않고 실행 시에 해당하는 테이블의 데이터를 동적으로 가져옵니다. 주로 데이터의 가독성과 쿼리의 간소화를 위해 사용됩니다.
Materialized View: Materialized View는 View와 유사하지만, 쿼리 결과를 실제로 저장하는 물리적인 테이블입니다. 쿼리를 실행하여 데이터를 집계하고 결과를 Materialized View에 저장합니다. 이렇게 저장된 데이터는 미리 계산되어 있으므로 쿼리의 성능을 향상시킬 수 있습니다. 주로 데이터 웨어하우스나 OLAP 시스템에서 사용됩니다.
Raft 알고리즘을 기준으로 Kafka의 KRaft와 ZooKeeper의 알고리즘을 비교:
KRaft: KRaft는 Kafka의 분산 일관성 보장을 위한 새로운 리더 선출 알고리즘입니다. KRaft는 Raft 알고리즘을 기반으로 하며, Kafka 클러스터의 리더 선출을 안정적으로 수행하여 데이터의 일관성과 가용성을 보장합니다.
ZooKeeper: ZooKeeper는 기존 버전의 Kafka에서 리더 선출을 처리하기 위해 사용되던 분산 코디네이션 시스템입니다. ZooKeeper는 ZAB(ZooKeeper Atomic Broadcast) 알고리즘을 사용하여 데이터의 일관성과 리더 선출을 보장합니다.
KRaft는 Kafka 자체적으로 리더 선출을 처리하므로 ZooKeeper에 대한 의존성을 제거합니다. 이를 통해 Kafka 클러스터의 운영 및 관리가 단순화되고, 데이터 일관성과 가용성이 개선됩니다.
Streaming 처리 방식 비교: Kafka Streaming과 Ksql
Kafka Streaming: Kafka Streaming은 Kafka에서 데이터 스트림을 처리하기 위한 라이브러리입니다. Kafka Streaming을 사용하면 실시간으로 데이터를 읽고 변환, 집계, 조인 등의 연산을 수행할 수 있습니다. 주로 데이터 처리 및 실시간 분석 등의 시나리오에서 사용됩니다.
Ksql: Ksql은 Kafka 상에서 실시간 스트리밍 데이터를 처리하기 위한 SQL 기반의 처리 엔진입니다. Ksql을 사용하면 SQL 문법을 사용하여 데이터를 쿼리하고 변환할 수 있습니다. 이를 통해 비전문가도 쉽게 스트림 처리를 수행할 수 있습니다.
Kafka Streaming은 자바 기반의 라이브러리로 좀 더 유연한 커스터마이징이 가능하며, Ksql은 간편한 SQL 기반의 인터페이스를 제공합니다. 선택은 사용자의 요구사항과 개발/운영 환경에 따라 달라질 수 있습니다.
주기적 배치 데이터와 실시간 성의 데이터를 취합하여 데이터를 Druid로 구축(Kafka vs. Redpanda):
Kafka: Kafka는 분산 스트리밍 플랫폼으로, 대량의 데이터를 실시간으로 처리하고 전달하기 위해 설계되었습니다. 주기적 배치 데이터와 실시간 데이터를 Kafka에 적재하여 데이터를 취합하고, 필요한 경우 Kafka Connect나 Kafka Streams 등을 통해 데이터를 Druid로 전송할 수 있습니다.
Redpanda: Redpanda는 Kafka 호환 분산 스트리밍 플랫폼으로, Kafka와 유사한 인터페이스와 호환성을 제공합니다. Redpanda는 Kafka와 비교해 메모리 사용량을 줄이고 대량의 데이터 처리를 위한 성능 향상을 목표로 개발되었습니다. 따라서 Redpanda를 사용하여 주기적 배치 데이터와 실시간 데이터를 취합하고, Druid로 데이터를 전송할 수 있습니다.
Kafka와 Redpanda는 기본적으로 비슷한 기능을 제공하지만, Redpanda는 Kafka에 비해 일부 성능 및 운영 측면에서 차이가 있을 수 있습니다. 선택은 사용자의 요구사항과 운영 환경에 따라 달라질 수 있습니다.
SQL 문장에서 GROUP BY 절과 Window Function 비교:
GROUP BY 절: GROUP BY 절은 데이터를 그룹화하여 집계 함수를 적용하는 데 사용됩니다. GROUP BY 절은 주로 집계된 결과를 기준으로 데이터를 분류하고 요약하는 데 사용됩니다. 그룹 단위로 데이터를 처리하고 집계된 결과를 반환합니다.
Window Function: Window Function은 SQL에서 제공하는 특별한 함수로, 데이터를 그룹화하지 않고도 그룹 내에서의 계산을 수행할 수 있습니다. Window Function은 각 행에 대해 결과를 계산하고, PARTITION BY 절로 그룹을 지정하여 각 그룹 내에서의 계산 결과를 반환합니다.
GROUP BY 절은 데이터를 그룹화하여 집계를 수행하며, 집계된 결과를 반환합니다. 반면에 Window Function은 그룹화하지 않고도 각 행에 대해 계산을 수행하고, 그룹 내에서의 계산 결과를 반환합니다.
Join (Inner-Join, Outer-Join, Full-Join) 비교:
Inner Join: Inner Join은 두 개 이상의 테이블을 조인할 때, 두 테이블 간의 공통된 값을 가진 행만을 결과로 반환하는 조인입니다. 즉, 조인 조건을 충족하는 행들을 선택합니다.
Outer Join: Outer Join은 두 개 이상의 테이블을 조인할 때, 조인 조건을 충족하지 못하는 행들도 결과에 포함시키는 조인입니다. 왼쪽 Outer Join과 오른쪽 Outer Join, 그리고 전체 Outer Join이 있습니다.
Left Outer Join: 왼쪽 Outer Join은 왼쪽 테이블의 모든 행을 결과에 포함시키고, 오른쪽 테이블과 조인 조건을 충족하는 경우 오른쪽 테이블의 해당 행을 포함시킵니다. 조인 조건을 충족하지 못하는 경우에는 NULL 값으로 채워집니다.
Right Outer Join: 오른쪽 Outer Join은 오른쪽 테이블의 모든 행을 결과에 포함시키고, 왼쪽 테이블과 조인 조건을 충족하는 경우 왼쪽 테이블의 해당 행을 포함시킵니다. 조인 조건을 충족하지 못하는 경우에는 NULL 값으로 채워집니다.
Full Outer Join: 전체 Outer Join은 왼쪽 테이블과 오른쪽 테이블 모두의 모든 행을 결과에 포함시킵니다. 조인 조건을 충족하지 못하는 경우에는 NULL 값으로 채워집니다.
Inner Join은 공통된 값을 가진 행만을 선택하고, Outer Join은 조인 조건을 충족하지 못하는 행들도 결과에 포함시킵니다. Full Outer Join은 왼쪽과 오른쪽 테이블의 모든 행을 결과에 포함시킵니다.
Table vs. View 비교:
Table: 테이블은 데이터베이스에서 실제로 데이터가 저장되는 물리적인 구조입니다. 테이블은 행과 열로 구성되며, 데이터의 인스턴스를 나타냅니다. 테이블은 데이터를 저장하고 조회하며, 쿼리를 실행하는 데 사용됩니다. 테이블은 스키마, 도메인, 키 등의 구성 요소를 가지고 있습니다.
View: View는 하나 이상의 테이블로부터 유도된 가상 테이블입니다. View는 쿼리 결과를 저장하지 않고 실행 시에 해당하는 테이블의 데이터를 동적으로 가져옵니다. View는 데이터의 가독성을 높이고 쿼리의 간소화를 위해 사용됩니다.
Inline View: Inline View는 쿼리의 일부로 사용되는 서브쿼리 결과를 가진 가상 테이블입니다. 주로 쿼리 내에서 임시로 사용되는 뷰로, 해당 쿼리의 결과에 직접적으로 포함됩니다.
With View: With View는 쿼리 내에서 사용되는 재사용 가능한 뷰로, 별도의 WITH 절을 사용하여 정의됩니다. With View는 가독성을 높이고 복잡한 쿼리를 단순화하는 데 사용됩니다.
Table은 데이터의 저장과 조회를 위한 물리적인 구조이며, View는 가상의 테이블로 쿼리 결과를 동적으로 생성합니다. Table은 데이터의 인스턴스를 나타내는 반면, View는 쿼리 결과를 가지고 있습니다.
Data Mesh vs. Data Fabric 및 ETL vs. ELT:
Data Mesh: Data Mesh는 기업 내에서 데이터를 분산하고 탄력적으로 관리하기 위한 접근 방법입니다. Data Mesh는 조직 내에서 데이터를 소유하는 도메인 팀에 책임을 부여하고, 도메인 팀이 데이터를 소유하고 관리하며 서비스로써 제공하는 방식을 강조합니다. 이를 통해 조직 내의 데이터 관리를 분산시키고, 데이터의 활용을 개선하고자 합니다.
Data Fabric: Data Fabric은 기업 내의 데이터 생태계를 연결하고 통합하는 프레임워크입니다. Data Fabric은 데이터의 흐름을 관리하고, 데이터의 품질과 일관성을 유지하며, 데이터의 액세스를 표준화합니다. 데이터 소스, 데이터 웨어하우스, 데이터 레이크 등 다양한 데이터 스토리지 및 서비스를 통합하여 일관된 데이터 생태계를 제공합니다.
ETL (Extract, Transform, Load): ETL은 데이터 웨어하우스나 데이터 레이크에 데이터를 적재하기 위해 데이터를 추출(Extract), 변환(Transform), 적재(Load)하는 과정을 말합니다. ETL은 데이터 통합과 전처리를 수행하여 분석이나 보고서 작성에 필요한 형식으로 데이터를 가공합니다.
ELT (Extract, Load, Transform): ELT는 ETL과 유사한 프로세스지만, 추출한 데이터를 먼저 데이터 저장소에 적재한 후에 변환 작업을 수행하는 방식입니다. ELT는 대량의 데이터를 저장소에 적재한 뒤에 데이터 처리를 수행하므로, 분석 엔진에서 직접 데이터를 처리할 수 있습니다.
Data Mesh는 데이터 관리를 분산시키고 탄력성을 높이는 접근 방식이며, Data Fabric은 데이터 생태계를 통합하고 관리하는 프레임워크입니다. ETL은 데이터 추출, 변환, 적재 과정을 거치는 반면, ELT는 데이터를 적재한 후에 변환 작업을 수행합니다.
Data warehouse, Data Lake, Data Lake House 비교:
Data Warehouse: Data Warehouse는 기업의 다양한 데이터를 통합하여 저장하고, 분석과 보고를 위한 중앙 집중식 데이터 저장소입니다. 데이터 웨어하우스는 정형화된 데이터를 주로 다루며, ETL 과정을 통해 데이터를 추출, 변환, 적재하여 일관성과 통합성을 유지합니다. 주로 비즈니스 인텔리전스(Business Intelligence) 및 의사 결정 지원에 사용됩니다.
Data Lake: Data Lake는 기업의 다양한 종류와 형태의 원시 데이터를 저장하는 대규모 저장소입니다. 데이터 레이크는 정형 및 비정형 데이터를 모두 저장하며, 데이터를 추출, 변환, 적재하지 않고 원시 상태로 보관합니다. 이는 데이터의 탐색, 분석, 기계 학습 등 다양한 용도로 활용할 수 있도록 합니다.
Data Lake House: Data Lake House는 Data Warehouse와 Data Lake의 장점을 결합한 개념입니다. Data Lake House는 데이터 레이크의 유연성과 확장성을 제공하면서도 데이터 웨어하우스와 유사한 구조와 기능을 제공합니다. 즉, Data Lake House는 데이터 레이크에 저장된 원시 데이터를 필요에 따라 정형화하고 인덱싱하여 쿼리 및 분석에 활용할 수 있는 기능을 제공합니다.
Data Warehouse는 중앙 집중식 데이터 저장소로 정형화된 데이터를 다루며, Data Lake는 원시 데이터를 저장하는 대규모 저장소입니다. Data Lake House는 Data Warehouse와 Data Lake의 장점을 결합한 형태로, 원시 데이터를 정형화하여 다양한 용도로 활용할 수 있습니다.
SQL 문장에서 UNION, INTERSECT, MINUS 비교:
UNION: UNION 연산은 두 개의 SELECT 문의 결과를 합쳐서 중복을 제거한 결과를 반환합니다. UNION은 두 개의 결과 집합을 수직으로 결합합니다.
INTERSECT: INTERSECT 연산은 두 개의 SELECT 문의 결과에서 공통된 행만을 선택하여 반환합니다. INTERSECT는 두 개의 결과 집합 간의 교집합을 구합니다.
MINUS: MINUS 연산은 첫 번째 SELECT 문의 결과에서 두 번째 SELECT 문의 결과와 중복된 행을 제외한 결과를 반환합니다. MINUS는 첫 번째 결과 집합에서 두 번째 결과 집합을 차집합으로 구합니다.
UNION은 두 개의 결과를 합칠 때 중복을 제거하고, INTERSECT는 두 개의 결과에서 공통된 행을 선택하며, MINUS는 첫 번째 결과에서 두 번째 결과와 중복된 행을 제외합니다.
Transaction의 ACID property:
ACID: ACID는 데이터베이스 트랜잭션의 원자성(Atomicity), 일관성(Consistency), 독립성(Isolation), 지속성(Durability)을 나타내는 속성의 약어입니다.
Atomicity (원자성): 트랜잭션의 작업은 모두 완전히 수행되거나 아무것도 수행되지 않아야 합니다. 트랜잭션의 모든 작업이 성공적으로 완료되거나, 어떠한 작업도 수행되지 않은 상태를 보장합니다.
Consistency (일관성): 트랜잭션이 수행되기 전과 수행된 후에도 데이터베이스의 일관성이 유지되어야 합니다. 데이터베이스의 제약 조건이 항상 만족되어야 하며, 일관성 있는 상태를 보장합니다.
Isolation (독립성): 동시에 여러 트랜잭션이 실행될 때, 각각의 트랜잭션은 다른 트랜잭션에 영향을 주지 않고 독립적으로 수행되어야 합니다. 각 트랜잭션은 마치 다른 트랜잭션이 없는 것처럼 실행되어야 합니다.
Durability (지속성): 트랜잭션이 성공적으로 완료되면, 해당 트랜잭션에 의한 변경은 영구적으로 데이터베이스에 반영되어야 합니다. 시스템 오류, 전원 장애 등에도 데이터의 지속성이 보장되어야 합니다.
ACID 속성은 데이터베이스 트랜잭션의 안전성과 일관성을 보장하기 위한 기본 원칙입니다.
Trigger, Function, Procedure 비교:
Trigger: Trigger는 데이터베이스의 특정 이벤트(INSERT, UPDATE, DELETE 등)가 발생할 때 자동으로 실행되는 저장 프로시저입니다. 트리거는 데이터의 일관성과 무결성 유지, 데이터 갱신 로그 기록 등의 작업을 수행하는 데 사용됩니다.
Function: Function은 입력값을 받아 처리하고 결과값을 반환하는 일련의 로직을 가진 프로그램 단위입니다. 함수는 데이터베이스에서 계산, 변환, 집계 등 다양한 작업을 수행하는 데 사용됩니다. 함수는 SELECT 문에서 호출되어 사용될 수 있습니다.
Procedure: Procedure는 일련의 작업을 수행하는 저장 프로시저입니다. 프로시저는 매개변수를 입력받을 수 있으며, 데이터의 검증, 처리, 로깅 등을 수행하는 데 사용됩니다. 프로시저는 호출되어 실행되는 것이며, 결과를 반환하지 않습니다.
Trigger는 데이터베이스의 이벤트에 반응하여 자동으로 실행되는 저장 프로시저입니다. Function은 입력값을 받아 처리하고 결과값을 반환하는 프로그램 단위로, SELECT 문에서 호출될 수 있습니다. Procedure는 일련의 작업을 수행하는 저장 프로시저로, 호출되어 실행되며 결과를 반환하지 않습니다.
Clustered Index vs. Non-clustered Index:
Clustered Index: Clustered Index는 테이블의 데이터를 물리적으로 정렬하는 인덱스입니다. 테이블당 하나의 클러스터드 인덱스를 가질 수 있으며, 클러스터드 인덱스에 의해 데이터가 저장되는 순서가 결정됩니다. 클러스터드 인덱스는 테이블의 기본 정렬 순서를 결정하므로, 특정 열에 대한 검색 속도를 향상시킬 수 있습니다.
Non-clustered Index: Non-clustered Index는 테이블의 데이터를 별도의 인덱스 구조로 저장하는 인덱스입니다. Non-clustered Index는 테이블의 논리적인 정렬 순서를 결정하며, 테이블 데이터와는 별도로 관리됩니다. Non-clustered Index는 특정 열 또는 열의 조합에 대한 검색 속도를 향상시키는 데 사용됩니다.
Clustered Index는 데이터를 물리적으로 정렬하여 저장하며, 테이블당 하나만 생성할 수 있습니다. Non-clustered Index는 테이블의 데이터와 별도로 인덱스를 생성하여 검색 속도를 향상시킵니다.
CDC(Change Data Capture)의 정의와 역할:
CDC(Change Data Capture)는 데이터베이스의 변경 사항을 실시간으로 감지하고 캡처하여 추적하는 기술 또는 프로세스입니다. CDC는 데이터베이스 내에서 발생하는 INSERT, UPDATE, DELETE와 같은 변경 작업을 식별하고, 이러한 변경 작업에 대한 상세 정보를 캡처하여 저장합니다. 이를 통해 데이터의 변경 이력을 추적하고 외부 시스템이나 데이터 웨어하우스로 전파할 수 있습니다.
CDC의 역할은 다음과 같습니다:
데이터 변경 추적: 데이터베이스에서 발생하는 변경 작업을 실시간으로 감지하고, 어떤 데이터가 어떻게 변경되었는지를 캡처합니다.
데이터 이력 유지: 변경 작업의 상세 정보를 저장하여 데이터의 이력을 추적하고, 필요한 경우 변경 전/후의 데이터 값을 확인할 수 있습니다.
데이터 동기화: 변경된 데이터를 외부 시스템이나 데이터 웨어하우스로 전파하여 데이터의 일관성을 유지하고 동기화합니다.
실시간 분석 및 보고: 변경 사항을 실시간으로 캡처하고 분석하여 실시간 대시보드나 보고서 작성에 활용할 수 있습니다.
Kafka의 Producer vs. Consumer 비교:
Kafka Producer: Kafka Producer는 메시지를 생성하고 Kafka 클러스터로 전송하는 역할을 담당합니다. Producer는 데이터를 토픽(Topic)에 기록하고, 메시지를 파티션(Partition)에 분배합니다. 여러 개의 Producer가 동시에 작동할 수 있으며, 데이터를 비동기적으로 보낼 수 있습니다.
Kafka Consumer: Kafka Consumer는 Kafka 클러스터로부터 메시지를 읽어오고 처리하는 역할을 담당합니다. Consumer는 토픽의 파티션에서 메시지를 소비하며, 소비한 메시지의 오프셋(Offset)을 기록하여 읽은 위치를 추적합니다. Consumer는 메시지를 동기적 또는 비동기적으로 처리할 수 있으며, 여러 개의 Consumer가 동시에 동일한 토픽을 구독할 수 있습니다.
Producer는 메시지를 생성하고 전송하는 역할을 하며, Consumer는 메시지를 읽고 처리하는 역할을 합니다. Producer는 데이터를 Kafka에 보내고, Consumer는 Kafka에서 데이터를 가져와서 처리합니다.
GROUP BY ~ HAVING 절과 WHERE ~ ORDER BY 절 비교:
GROUP BY ~ HAVING 절: GROUP BY 절은 특정 열을 기준으로 데이터를 그룹화하는 데 사용되며, HAVING 절은 그룹화된 데이터에 조건을 적용하여 특정 그룹을 필터링하는 데 사용됩니다. GROUP BY 절은 데이터를 그룹화하고, HAVING 절은 그룹에 대한 조건을 지정합니다.
WHERE ~ ORDER BY 절: WHERE 절은 데이터를 조회할 때 특정 조건을 지정하여 필터링하는 데 사용됩니다. WHERE 절은 데이터의 특정 조건을 만족하는 행만을 선택합니다. ORDER BY 절은 데이터를 정렬하는 데 사용되며, 지정된 열을 기준으로 오름차순 또는 내림차순으로 데이터를 정렬합니다.
GROUP BY ~ HAVING 절은 데이터를 그룹화하고 그룹에 대한 조건을 지정하여 필터링하는 데 사용되며, WHERE 절은 데이터의 조건에 따라 행을 선택하고, ORDER BY 절은 데이터를 정렬하는 데 사용됩니다.
Message Queue 동작 방식과 Message Queue의 종류:
Message Queue 동작 방식: Message Queue는 비동기적인 메시지 전달을 지원하는 소프트웨어 패턴입니다. 메시지 송신자(Producer)는 메시지를 큐(Queue)에 전송하고, 메시지 수신자(Consumer)는 큐에서 메시지를 가져와 처리합니다. 메시지는 큐에 순서대로 저장되며, 송신자와 수신자가 동시에 실행되지 않아도 됩니다.
Message Queue의 종류:
RabbitMQ: RabbitMQ는 AMQP(Advanced Message Queuing Protocol)를 기반으로 동작하는 오픈 소스 메시지 큐입니다. 다양한 클라이언트 라이브러리와 프로토콜을 지원하며, 확장성과 유연성이 높습니다.
Kafka: Kafka는 대용량 실시간 스트리밍 데이터를 처리하기 위한 분산 메시지 큐 시스템입니다. 데이터의 지속성과 확장성을 중요시하며, 높은 처리량과 낮은 지연 시간을 제공합니다.
CDC에서 Source Connector vs. Sink Connector 비교:
Source Connector: CDC에서 Source Connector는 데이터베이스의 변경 사항을 감지하여 이벤트 스트림으로 전송하는 역할을 합니다. Source Connector는 데이터베이스 로그를 모니터링하거나 트리거를 사용하여 변경 사항을 캡처하고, 이를 외부 시스템으로 전달합니다. 예를 들어, Debezium은 Source Connector의 한 예입니다.
Sink Connector: CDC에서 Sink Connector는 외부 시스템으로부터 데이터를 수신하여 데이터베이스에 적용하는 역할을 합니다. Sink Connector는 외부 시스템에서 전달된 데이터를 데이터베이스에 적절한 형식으로 변환하고, 해당 데이터를 데이터베이스에 삽입, 갱신 또는 삭제하여 변경 사항을 반영합니다.
Source Connector는 데이터베이스의 변경 사항을 감지하고 이벤트 스트림으로 전송하는 역할을 하며, Sink Connector는 외부 시스템으로부터 데이터를 수신하여 데이터베이스에 적용하는 역할을 합니다.
Event Sourcing vs. CQRS(Command Query Responsibility Segregation):
Event Sourcing: Event Sourcing은 모든 시스템 변경을 이벤트의 연속으로 간주하는 소프트웨어 개발 패턴입니다. 모든 변경 사항이 이벤트로 기록되고 저장되며, 상태는 이벤트를 통해 재구성됩니다. 이벤트 소싱은 시스템의 상태 변경 이력을 추적하고 재생성할 수 있는 높은 확장성과 시스템 내 문제 해결을 제공합니다.
CQRS(Command Query Responsibility Segregation): CQRS는 명령(Command)과 조회(Query)의 책임을 분리하는 소프트웨어 개발 패턴입니다. CQRS에서는 시스템의 데이터 변경 요청과 데이터 조회 요청을 별도의 모델로 처리합니다. 명령 모델은 데이터 변경을 처리하고, 조회 모델은 데이터 조회를 처리합니다. CQRS는 복잡한 도메인 모델을 구현하고 성능을 향상시키는 데 도움을 줍니다.
Event Sourcing은 변경 사항을 이벤트로 기록하고 상태를 재구성하는 패턴이며, CQRS는 명령과 조회의 책임을 분리하는 패턴입니다. 두 패턴은 시스템의 복잡성을 다루고 성능을 개선하는 데 도움이 됩니다.