* 테이블스페이스: 논리적(메모리) - 오라클 데이터베이스는 하나 이상의 논리적 저장영역 테이블스페이스가 있고 데이터를 집합적으로 저장합니다. - 하나 이상의 데이터 파일로 구성되어 있습니다. 1. 테이블 스페이스 유형 1.1. 시스템 테이블스페이스(사용자가 건드릴수 없다) - 데이터 베이스와 함께 생성됩니다. - 데이터 딕셔너리 포함 - 시스템 Undo Segment를 포함합니다. 1.2. 비시스템 테이블스페이스(사용자가 필요하면 만들고, 지우면서 사용가능) - 데이터베이스 관리와 공간 관리를 용이하게 할 수 있습니다. - Undo Segment, Temporary Segment, 응용 프로그램 데이터 세그먼트 및 인덱스 세그먼트를 분할합니다. - 사용자에게 할당된 공간의 양을 제어합니다. 2. 테이블..

SQL 튜닝은 "SQL + 튜닝"입니다. 즉, SQL 튜닝이란 튜닝 대상이 되는 SQL을 이해하고, SQL이 가진 정보(테이블/인덱스/컬럼의 정보 및 업무적 성격 등)를 치밀하게 분석하여 얻어지는 결과라고 생각합니다. SQL 튜닝을 시작하기 위해서는 SQL에 대한 이해가 선행되어야 한다고 생각합니다. 왜냐하면, SQL의 작성형태에 따라 다양한 성능 문제가 발생되기 때문입니다. SQL 튜닝의 시작은 SQL의 의미(작성 의도)를 제대로 파악하는 것입니다. SQL의 의미를 정확히 파악하지 못한다면, 원본 SQL에서 추출하고자 했던 결과 집합이 아닌 다른 집합을 추출하게 될지도 모릅니다. 이러한 개선안은 개선안이라고 할 수 없습니다. 즉, 원본 SQL의 작성 의도를 제대로 파악하지 않고, 단순히 I/O 발생량을..

파티션 개요오늘날 기업에서 관리하는 데이터는 수백테라 바이트에 이르는 데이터베이스를 관리합니다. 하지만 이런 데이터들 중 몇몇의 Big Transaction Table이 거의 모든 데이터를 가지고 있고 나머지 테이블들은 이 Big Transaction Table을 경유하여 액세스하는 용도로 사용됩니다. 이렇게 데이터 크기가 크고 중요한 Big Transaction Table을 관리하는 부분에서 Troubleshooting이 발생될 경우 데이터베이스의 성능 및 관리작업에 심각한 영향을 받을 수 있습니다. 이러한 리스크가 있는 Big Transaction Table을 보다 효율적으로 관리하기 위해 Table을 작은 단위로 나눔으로써 데이터 액세스 작업의 성능 향상을 유도하고 데이터 관리를 보다 수월하게 하고..

테이블을 저장하는 공간이란 의미도 틀린것은 아니지만 정확한 의미는 아닙니다. 오라클은 데이터베이스 관리 시스템이고 말 그대로 데이터들을 관리합니다. 즉 어딘가에 데이터들을 저장, 추출, 삭제, 변경하는 작업을 할 수 있는 것입니다. 그렇다면 데이터는 어디에 저장되는 것일까요? 물론 파일에 저장됩니다. 오라클 데이터베이스는 데이터 파일들을 가지고 있으며, 이 파일들에 데이터가 저장됩니다. 그런데 파일은 데이터가 저장되는 물리적인 공간을 말하는 것입니다. 오라클 내부에서는 데이터 블록(data block), 익스텐트(extent), 세그먼트(segment), 테이블스페이스(tablespace)라는 논리적인 개념으로 데이터 들을 관리합니다. 오라클에서 데이터를 저장하는 가장 최소의 논리적인 단위가 데이터 블록..

쿼리 튜닝은 온라인 SQL이냐 대용량 배치 SQL이냐에 따라 튜닝방법이 달라집니다. 하지만 대용량 배치는 프로그램 수가 많지 않은 편입니다. 온라인 SQL 튜닝에서도 관점에 따라 튜닝방법이 다르게 됩니다. 예를 들어 Peak Time에 Insert 문이나 Update 문, Select 문이 집중적으로 몰릴 때의 튜닝 방법이 있고, 단순히 SQL 하나에 집중해서 응답시간을 최소화하는 튜닝방법이 있습니다. 본 포스팅은 일반적으로 가장 많은 튜닝 사례에 해당하는 Select문 튜닝방법론을 기술한 포스팅입니다. 학습 용도로 작성한 포스팅으로 본 포스팅의 원본 출처는 Science of Database 블로그 SQL 튜닝방법론 입니다. 온라인 Select문 튜닝 방법론온라인 SQL의 튜닝방법은 여러 가지가 있을 ..

실시간 로그 집계와 같은 대용량 데이터 처리를 위해서는 애플리케이션의 처리량(Throughput)이 높아야 한다. 카프카에서는 대용량의 실시간 데이터 처리를 위해 배치 전송, 파티션, 분산 기능을 구현했다. 또한 중앙 시스템의 역할을 하는 중요한 서비스에서 서버 장애가 발생하더라도 서비스에 영향이 없도록 데이터의 안정적인 저장을 위해 리플리케이션 기능과 분산된 서버에서 자동으로 파티션의 리더를 선출하는 기능을 구현했다. 카프카는 분산된 데이터 파이프라인을 표준화하고 통합하길 원했고, 처리량에 중점을 두고 설계되었다. 이에 따라 카프카에는 높은 처리량과 빠른 메시지 전송, 운영 효율화 등을 위해 분산 시스템, 페이지 캐시, 배치 전송 처리 등의 기능이 구현되었다. 카프카 디자인의 특징1) 분산 시스템동일한..

카프카는 대용량, 대규모 메시지 데이터를 빠르게 처리하도록 개발된 메시징 플랫폼이다. 서비스를 유지하려면 기본적으로 다음과 같은 데이터 시스템이 필요하다.시스템설명메트릭 모니터링용 데이터 시스템앱이나 서비스에서 일어나는 미터링(사용량, 응답 시간, 에러 카운트 등) 정도를 저장할 시계열 데이터 처리용 시스템로그 모니터링용 데이터 시스템앱/서비스에서 발생하는 로그를 저장하고, 이것을 기반으로 실시간/배치로 분석할 수 있도록 데이터를 저장하는 시스템서비스에 필요한 컨텐츠와 고객 정보 데이터들을 저장하는 메인 데이터 시스템대부분의 앱들에서 보낸 OLT(Online Transaction Process) 쿼리(주로 데이터 갱신)를 실행한다.추천이나 장바구니와 같이 트랜잭션 처리까진 필요없지만 실시간으로 처리를 해..

카프카는 여러대의 서버에 분산되어 실행되고, 각 토픽은 여러 개의 파티션으로 분리되어 있으며 각 브로커에 복제되어 분산되어 저장되는 등 복잡하게 운영되는 애플리케이션이다. 따라서 카프카 클러스터를 운영하다 보면 다양한 이슈가 발생하게 되고, 이슈들을 대응하기 위해 토픽의 상태 정보, 토픽의 설정 변경 작업 등이 매우 빈번하게 발생한다. 1) 토픽 설정 변경카프카를 운영하면서 토픽의 설정을 변경해야 하는 경우가 있다. 운영 중인 카프카의 디스크 공간을 확보하는 가장 좋은 방법은 디스크 공간을 가장 많이 차지하는 토픽의 보관 주기를 줄여주는 것이다. 토픽 보관주기의 기본값은 7일이다. 토픽의 보관주기 설정을 변경하기 위해 kafka-configs.sh 명령어를 이용한다. 추가 옵션으로는 --zookeeper..

카프카 프로듀서 주요 옵션 (https://kafka.apache.org/documentation/#producerconfigs) 옵션 설명 bootstrap.servers 카프카 클러스터는 클러스터 마스터라는 개념이 없기 때문에 클러스터 내 모든 서버가 클라이언트의 요청을 받을 수 있다. 해당 옵션은 카프카 클러스터에 처음 연결을 하기 위한 호스트와 포트 정보로 구성된 리스트 정보를 나타낸다. 정의된 포맷은 "호스트 이름:포트, 호스트 이름:포트, 호스트 이름:포트"이다. 전체 카프카 리스트가 아닌 호스트 하나만 입력해 사용할 수 있지만, 이 방법을 추천하지는 않는다. 카프카 클러스터는 살아있는 상태이지만 해당 호스트만 장애가 발생하는 경우 접속이 불가하기 때문에, 리스트 전체를 입력하는 것을 권장한다..

토픽의 파티션 수가 증가함에 따라 빠른 전송이 가능하다. 그렇다면 토픽의 파티션 수를 많이 늘리는 것이 무조건 좋은 것은 아니다. 파티션 수가 늘어나면 오히려 카프카에 좋지 않은 영향을 미칠 수도 있다. (1) 파일 핸들러의 낭비각 파티션은 브로커의 디렉토리와 매핑되고, 저장되는 데이터마다 2개의 파일(인덱스와 실제 데이터)이 있다. 카프카에서는 모든 디렉토리의 파일들에 대해 파일 핸들을 열게 된다. 결국 파티션의 수가 많을수록 파일 핸들 수 역시 많아지게 되어 리소스를 낭비하게 된다. (2) 장애 복구 시간 증가카프카는 높은 가용성을 위해 리플리케이션을 지원한다. 브로커에는 토픽이 있고, 토픽은 여러 개의 파티션으로 나뉘어 있으므로, 브로커에는 여러 개의 파티션이 존재하게 된다. 또한, 각 파티션마다 ..