가상화 (Virtualization)

가상화란?

쉽게 말하면, 물리적인 하드웨어를 논리적으로 구분하는 것

 

서버의 CPU와 메모리 등의 자원을 최대한 활용할 수 있는 방법을 생각했을 때, 간단하게 생각하면 동시에 여러 개의 서버를 한번에 올리면 되지 않을까 싶다. 하지만, 서로 영향을 받게 되고, 보안 문제나 서버가 다운되면 모든 서비스가 중단되는 위험이 있다. 그래서 가상화의 개념이 등장하였다.

 

VM과 컨테이너

가상화의 핵심은 Isolation이다. 논리적으로 격리가 제대로 이루어지면, 각각의 가상 환경에서 문제가 생겨도, 다른 영역에 영향을 미치지 않는다.

 

가상화는 크게 2가지 유형으로 나뉘는데, 가상머신(vm)과 컨테이너(container)이다. 클라우드 환경에서 서비스를 운영하고자 한다면 꼭 알아두어야 하는 개념이다.

가상화 관점에서 두 개의 차이점을 간단하게 설명하자면, 가상머신은 하이퍼바이저를 이용하여 리소스 전체를 가상화하는 방법이고, 컨테이너는 OS 수준에서 프로세스를 컨테이너 형태로 격리하는 방법이다.

 

두 방식은 차이점이 확실하여 그에 따른 장단점도 분명하기 때문에, 각각의 기술에 대한 배경과 철학을 이해하면 좋을 것이다. 이번에는 하이퍼바이저 가상화에 대해 다루어보겠다.

 

 

하이퍼바이저 (Hypervisor)

하이퍼바이저란?

가상화에서 계속 하이퍼바이저라는 단어를 언급했는데, 하이퍼바이저란 대체 무엇일까?

 

  • 가상 머신(VM)을 생성하고 구동하는 소프트웨어
  • 가상 머신 모니터(VMM)라고도 불림
  • 하이퍼바이저 운영 체제와 가상 머신의 리소스를 분리해 VM의 생성과 관리를 지원함
  • 서로 다른 여러 개의 운영 체제를 나란히 구동할 수 있음

 

아직 잘 이해가 안 된다면, Hypervisor라는 이름을 뜯어보자!

In general, operating systems are referred as supervisors.
As a hypervisor software is a supervisor of a “supervisor”, it is called hypervisor.

일반적으로 운영체제를 supervisor라고 부르는데, 하이퍼바이저는 supervisor의 supervisor라고 한다.

 

 

Type 1 vs Type 2

가상화는 크게 Type1와 Type2로 분류된다.

Type1 방식은 Native 혹은 베어메탈(Bare Metal)형 하이퍼바이저 가상화라고도 부른다. 베어메탈이란 하드웨어 상에 어떤 소프트웨어도 설치되어 있지 않은 상태이다. Type1은 베어메탈 하드웨어 위에 직접 설치되어 구동된다. ESX-i(vmware), Xen, KVM, XenServer(citrix), Hyper-V(Microsoft) 등이 있다. 하이퍼바이저는 전가상화와 반가상화로 나뉜다.

 

Type2 방식은 Host 가상화라고 부른다. 베어메탈 하드웨어 위에 Host OS가 설치되고, 그 위에 하이퍼바이저가 실행되는 형태이다. 테스트 환경을 구성할 때 자주 사용하는 Oracle VirtualBox나 VMware Workstation이 여기에 해당된다.

 

Type2 방식 Host OS라는 하나의 레이어가 더 존재하므로, 성능 면에서 Type1이 Type2보다 유리하다. 실제 IDC 클라우드화 시키는데 사용되는 하이퍼바이저도 모두 Type1 방식이다.

 

 

 

 

 

 

참고링크

팀 수석님께서 데이터 모델링을 주제로 사내교육을 진행하셔서 참여할 수 있는 기회가 생겼다. 참여형 실습도 있고 완전 유익하고 재밌는 교육이라고 하셔서 기대를 잔뜩 하고 갔다.

학교에서 데이터베이스 설계 수업 때 배운 내용도 새록새록 생각이 나고 최근에 계속 모델링 작업을 하고 있어서 내용이 더 잘 들리기도 하고, 현업 포인트까지 알 수 있는 값진 시간이었다.

다른 부서분들을 만나는 자체도 재밌었는데 다들 잘 참여해주시고, 얘기도 잘 통해서 즐거운 시간이었다. 특히 실습에서 작은 모델들이 모여서 마지막에 하나의 모델로 탄생할 때 감동이었다..🥺 (수석님 존경합니다..)

 

데이터 표준화의 기본

데이터가 중요하다!

  • 비즈니스의 목적이 바뀌지 않는 한, 중요 데이터는 변하지 않는다.
  • 데이터 구조를 만드는게 개발의 도구일까?
  • 데이터가 목적일 수 있다. 비즈니스 데이터가 그만큼 중요하다.
  • 모델링을 할 때 어떤 점을 주안점으로 둘까?
    • 전략과 프로세스가 바뀌어도 데이터는 변하지 않는다
    • 데이터만 봐도 업무 규칙을 알 수 있게
      예) 고객 상품 주문 결제 계약 -> 프로세스나 툴이 바뀌어도 모델 구조가 바뀌지 않게 -> 독립적이고 안정적이게

 

데이터 모델링의 목적

  • 일관성, 무결성, 정확성이 보장된 신뢰할 수 있는 고품질 데이터
  • 가치 있는 정보, 최상의 성능
    • 데이터 규칙에 대한 명시적인 의사소통의 도구
      예) 만약 내 집을 짓는다면...? 정확한 제대로 된 설계 도면 인력 물량 공사진행 시공

 

데이터 모델링의 절차

개념

  • 논리 모델링(비즈니스 중심)
  • 물리 모델링(성능 중심) : DBMS 특성을 고려해서 성능, 주요 인덱스 및 파티션 설계
  • DB구축 : DDL 작성, 물리 DB 구축, 마이그레이션

데이터 표준 (용어, 도메인, 코드)

 

데이터운영팀에서 검수 중인 것

  • 논리와 물리 모델링의 결과에 표준화를 적용 -> DA (사람과 가깝고 좀 더 논리적인 부분)
  • 인덱스 설계, 파티션 설계 ~ DB 구축 -> DBA (DBMS와 가까운 사람들, 좀 더 물리적인 부분)

 

논리 모델링의 기본

검수 시 가장 말씀 드리는 3가지

  • 시간적으로 달라지는 절차적 사고보다는 집합적 사고
  • 중복과 불일치는 NO
  • 애매함 < 명확함

 

논리 모델의 구성 요소 - 1

  • 엔터티 : 업무가 다루는 어떤 것
  • 관계 : 업무가 다루는 것들 사이에 존재하는 연관
  • 속성 : 각 사물(엔터티)이 가지고 있는 상세한 특성

 

논리 모델의 구성 요소 - 2

  • 예) 은행
    • 엔터티 : 고객 계약 상품 직원
    • 관계 : 계약의 주체, 계약의 대상, 상품담당자, ...
    • 속성 : 세부 속성들이 필요하고

 

논리 모델의 구성 요소 - 3

  • ERD를 그린다면
    • 체크리스트를 확인해야 함
      예) 엔터티 : 서비스에서 관리할 필요가 있나? 관리하려는 데이터의 범위는 어디까지? 엔터티인지 속성인지 관계인지

 

논리 모델링의 기본

  • ERD 표기법
    • 사내에서 사용하는 툴 : PowerDesigner (IE법 사용, ER-Win도 있음)
    • Barker법 툴 : DA# (집합 개념을 조금 더 나타낸다는 점)

 

관계의 표현 - 1

  • 카디널리티(1:1, 1:다, ...), 식별성(식별자 상속, 일반속성 상속), 선택성(0개 nullable 설정)
  • 계층, 순환, BOM / Barker법 : 배타관계

 

관계의 표현 - 2

  • 부서와 사원 관계의 예시
    • 식별 상속 : 한 명의 사원은 여러 부서에 소속될 수 있음 (사원 엔터티의 도출 필요)
    • 비식별 상속 : 한 명의 사원은 하나의 부서에 소속될 수 있음

겸직 부서 - 사원소속부서 - 사원

 

관계의 표현 - 3

  • 직접 종속 관계 만을 표현, 간접 종속 관계는 표현하지 않음 (부모-자식 간만 표현하면 됨)
  • 두 엔터티 간에 둘 이상의 관계가 존재할 수 있음 -> 관계명 표현, 컬럼명 수식어(역할 명 role name) 사용
  • 가능한 모든 관계를 표현
  • 너무 많은 관계선은 피하기 위해 뺄 수도 있음 (공통코드 테이블 등)

데이터 표준화의 기본

  • 일관성 유지
  • 가독성 강화
  • 명확하고 신속한 의사소통, 원하는 시기에 정확한 정보 전달 (개발까지) // 데이터 활용도 증가 정제 비용 감소, 데이터 품질 향상
  • 표준화는 대형 시스템에서는 표준화 담당자가 따로 있을 정도로 어려운 부분

 

단어

표준 단어

  • DB 오브젝트의 이름 부여 시 사용하기 위한 원자 단위(최소 의미 단위)의 표현을 미리 정해 놓은 것
  • 우리 회사는 전사 표준이 따로 있지는 않음, 우리 회사의 경우 다양한 서비스가 있기 때문에 전사 표준 관리는 어려움, 우리 회사 특성상 서비스 별 표준, 조직별 표준이 있음
  • 표준 단어(영문, 한글)에는 띄어쓰기, /, _ 등 특수 문자 사용 금지
  • 영문 단어는 약어 혹은 full 단어로 정하여 사용
    • 오라클 쓸 때는 컬럼명 길이 제한이 있어서 약어를 많이 썼는데, 요즘엔 mysql 쓰니까 full 단어로 씀
  • 복합 단어는 두 개 이상의 단어를 결합하여 하나의 단어로 사용(blacklist, zipcode)

 

표준 용어

  • 표준 단어를 조합하여 엔터티명(테이블명)과 속성명(컬럼명)에 사용되는 용어를 구성함
  • 동일한 데이터 집합은 동일한 용어를 사용
  • 용어의 마지막에는 분류어에 속하는 단어를 사용 (수 count, 일자 date ymd, datetime ymdt 등)

 

도메인

  • 속성에 대한 성질을 그룹핑한 개념
  • 동일 성질을 가진 컬럼의 데이터 타입 및 데이터 길이를 일관되게 관리함
  • 여러 시스템에서 사용되면 공통 도메인을 선정해서 쓰기도 함
  • 텍스트, 숫자 도메인은 최대한 통합

분류어 -> 도메인 -> 데이터 타입(길이)

 

코드

  • 특수도메인
  • 특정 도메인 값(코드 값)이 미리 정의되어 있는 도메인
  • 공통코드와 목록성코드(조직코드,...)
    • 3개 이상의 구분 값을 사용하는 경우 '코드' 도메인 사용
    • Yes/No 혹은 True/False의 2가지 값 만을 사용하는 경우 '여부' 도메인 사용
    • 기본 : Not Null, default 값 정의를 권장함

 

명명 규칙

  • 엔터티 명명
    • 단수형
    • 부모 엔터티와 강하게 엮인 자식 엔터티는 가급적 부모 엔터티의 이름을 상속받음 (게시물첨부파일, 게시물스크랩)
    • 관계 엔터티의 경우, 두 엔터티의 이름을 상속받아 명명(주문 상품 -> 주문상품)
    • 통계성 테이블의 경우, 통계 주기와 기준이 나타나도록 명명
    • 엔터티 명 마지막 단어에서 엔터티의 유형을 나타내도록 정함
    • 바람직하지 않은 예 : 회원리스트, 주문처리, 급여관리, 쿠폰목록 -> 데이터 관점에서 생각하고, 기능이나 화면의 이름은 필요없음
  • 속성 명명
    • 단어의 뒤를 먼저 보면 되도록 명명
  • 표준 용어 사전
    • 각 서비스에 해당하는 단어, 도메인, 코드 표준이 정의되면 이를 바탕으로 표준 용어를 구성 함
    • 업무적으로나 DBMS 적용 상 무리가 없는지 검토
    • 누락된 단어 및 도메인, 코드 등이 없는지 확인하고 추가 보완 작업을 수행 함

 

물리 모델링을 하다가 마주치는 고민들

정규화 vs. 반정규화

  • 정규화 : 중복을 안 만들고자 하는 구조
  • 반정규화
    • 물리모델링 시 정규화된 논리모델을 조정하여 반정규화를 하는 경우가 있음
    • 조상테이블 속성을 자식테이블에 갖다놓는..
    • 테이블의 통합/분리, 속성의 추가, 관계의 중복 등이 포함
    • 데이터의 정합성과 무결성의 유지를 위한 방안과 노력이 반드시 필요함
    • 조회의 성능과 개발의 편의를 위해 반정규화를 한 경우, 그에 따라 변경 작업시의 성능이 저하되는 경우가 많으므로 트레이드-오프를 따져서 적용해야 함

방법

테이블 반정규화

  1. 테이블 통합
  2. 1:1, 1:N, 수퍼타입/서브타입
  3. 테이블 분할
    수직, 수평
  4. 테이블 추가
    통계, 이력, 부분-업데이트가 자주 발생하면 따로 떼어내기, 복제-저장소가 다른 경우 원격지에 있는걸 가져다 놓기

컬럼 반정규화

  1. 중복컬럼 추가
    테이블 간의 조인을 감소시키기 위해서, 그 컬럼이 잘 바뀌지 않는다는 가정 하에
  2. 추출(derived)컬럼 추가
    매번 계산되지 않도록 미리 계산해서 갖다놓기(주문총금액)
  3. 이력테이블 컬럼 추가
    최근 값에 대한 컬럼을 미리 추가해놓기

관계 반정규화

  • 관계의 중복
  • 하기 전에
    • 다른 방법이 있는지 고려해보고 도저히 안 되면 반정규화하기
  • 하고 나서
    • ERD 등에 해당 내용을 공유하기

통합 vs. 분리

논리모델에서 설계한 수퍼타입과 서브타입을 물리모델로 전환할 경우 트랜잭션 패턴 및 생성되는 데이터 건수 등에 따라 테이블의 통합 혹은 분리를 검토하여 결정

 

트랜잭션 유형에 의한 결정

  1. 개별 트랜잭션 발생 유형
    공용 컬럼을 최대한 도출해서 수직분할 (결제수단코드- ...) or 통합 (모든 값을 한 테이블에, join이나 union all이 너무 많이 발생할 것 같을 때)
  2. 수퍼타입+서브타입 트랜잭션 발생 유형
    수평분할 (주문번호 - 카드결제내역 / 휴대폰결제내역 / 계좌이체결제내역) 결제번호가 겹치는 문제가 있을 수 있음

통합을 고려해 보게 되는 경우

  1. 식별자가 동일 할 때
  2. 관리하는 정보가 유사할 때
  3. 자주 join 되거나 union all 되는 경우
  4. ARC 관계로 정의되는 경우, 상속이 계속 된다면 부모 테이블의 통합이 가능한지 검토

 

인조 키 vs. 본질 키

인조 키 vs. 본질 키 - 1

PK 선정

  • 그 중 식별자 정의, 생성 주체의 단위를 정하는 것
  • 본질식별자 혹은 인조식별자 사용 여부도 논리 모델링 단계에서 결정하는 것이 바람직함
  • 특징
    • 유일성
    • 안정성 : 절대 변경되지 않아야 함(~명 등 텍스트 성 정보는 하지 않기)
    • 최소성 : 복합 식별자로 구성된 경우 유일성에 기여하지 않는 속성은 제외하고 최소의 조합으로 함
    • 활용성 : 업무에서 가장 많이 사용되는 속성 선택, PK는 자식 테이블에 상속이 됨
    • 보안성 : 주민등록번호, 여권번호 등

 

인조 키 vs. 본질 키 - 2

본질식별자

  • 해당 엔터티의 의미상의 주어, 인스턴스를 유일하게 식별하는 최소한의 속성 조합
  • 집합의 인스턴스가 생성되는 단위

인조식별자

  • 쿼리 복잡도 감소
  • 검색에 활용 불가 -> 반정규화의 원인이 되는 경우가 있음
  • 중요 데이터의 중복 가능성


인조 키 vs. 본질 키 - 3

  • 본질식별자 사용을 먼저 고려
  • 인조식별자를 사용한다면, 하위 엔터티에서 다수의 조인이 발생하거나, 반정규화의 원인이 되기도 함
  • 인조식별자를 선택하는 경우
    • 본질식별자가 식별자의 조건에 부합하지 않는 경우(로그 성격의 데이터를 보관하는 테이블, 본질식별자를 종종 수정해야 하는 경우)
    • 상속 시 식별자의 증가로 복잡도가 지나치게 증가하는 경우(mysql의 경우는 PK의 개수가 성능에 영향을 미침)
    • 타 영역에서 자주 참조하는 주요 엔터티의 식별자인 경우 인조 식별자의 사용을 검토해야 함
  • ~번호, ~일련번호, ~ID를 구분해서 쓰기도 함

 

시스템 속성의 관리

  • 모든 테이블에 공통으로 추가하여 관리할 필수 속성을 정의하는 것
  • 데이터 추적 관리 용도, 마이그레이션 작업 시, 데이터 분리 보관 작업 시 등 중요한 기준 정보로 활용됨
  • 주의 사항
    • 업무 용도로 사용하지 않는 것을 권장함(등록일시:데이터의 실제 Insert 일시와 가입일시는 구분해서 쓰기..)

 

이력의 관리의 형태

이력 관리의 형태 - 1

  • 이력 관리 모델
    데이터 복구나 추적이나 고객 응대를 위해서
  • 형태
    • 시점이력(변경된 시점에 대한..) 선분이력(유효시작일자, 이런 식으로 구간 관리)
    • 분리형 통합형
    • row column subject

 

데이터 모델 검수

앞을 내다보고, 나중에 관리 측면까지 고려함

6장. 구매 및 상담

24 구매 및 상담

구매처 선정

방문 목적

업체 선정

비교 견적

도입 테스트

해외 구매

 

25 자산 관리

자산 관리 대상

자산 관리 방법

재고

감가상각

재고 조사

폐기 처리

5장. 스토리지

 

21 스토리지

  • 스토리지 : 데이터를 저장하는 장치
    • 로컬 스토리지 : 서버 내부의 저장 영역
    • 외부 스토리지 : 서버 외부의 저장 영역
      • DAS : 서버에 직접 연결하는 것
      • NAS : 네트워크를 통해 연결하는 것

 

로컬 스토리지

서버 내부에 디스크를 설치해서 이용하는 저장 영역

외부 스토리지를 사용하지 않으므로 설치 공간을 절약할 수 있음

대신, 설치할 수 있는 디스크 개수와 확장성이 줄어듦

 

외부 스토리지

서버 외부에 준비한 스토리지 장치, 영역

 

1. DAS

  • Direct Attached Storage, 서버에 직접 연결하는 스토리지
  • 로컬 스토리지만으로 용량이 부족할 때 사용
  • DAS에는 많은 디스크를 설치할 수 있으므로 스트라이핑 수가 많은 RAID로 구성하여 디스크 I/O 성능을 높임
  • OS는 DAS와 내장 디스크를 구분하지 않고 다룸
  • DAS 선택시 고려 항목 : 필요한 실제 용량, 성능, 내장애성 및 확장성
  • 형태
    • 서버에 RAID 컨트롤러 보드를 꽂아 연결하는 형태 : RAID 컨트롤러 보드가 RAID 구성을 관리
    • HBA(Host Bust Adaptor)보드를 꽂아 연결하는 형태 : 스토리지에 내장된 RAID 컨트롤러가 RAID 구성을 관리
  • 트렌드
    • 매년 하드디스크가 대용량화 되면서 랙 마운트 형 서버에서도 탑재할 수 있는 디스크 개수가 증가함
    • 굳이 DAS를 사용하지 않고 로컬 스트로지를 선택하는 사례도 늘고 있음
    • DAS를 사용하지 않으면 장비 구매 비용과 데이터 센터의 랙을 절약할 수 있음

 

2. NAS

  • Network Attached Storage, 네트워크를 통해 여러 대의 서버가 액세스할 수 있는 스토리지
  • 여러 대의 서버에서 데이터를 공유할 때나 발생하는 백업 및 로그 파일을 한 군데에 모으는 용도로 사용됨
  • 서버와 NAS 간에는 NFS, SMB/CIFS, AFP와 같은 프로토콜을 이용해서 통신함

 

3. SAN

  • Storage Area Network, 블록 단위의 데이터 스토리지 전용 네트워크
  • 고속 고품질 환경을 요구하는 환경에서 이용됨
  • FC-SAN
    • Fibre Channel SAN, 파이버 채널 기반으로 구축된 고속 고품질 스토리지 전용 네트워크
    • 중요한 데이터를 다루는 환경에서 이용됨
    • HBA 보드를 설치하여 SAN 스위치를 통하거나 SAN 스토리지를 직접 연결함
  • IP-SAN
    •  Internet Protocol SAN, 통신 부분에 이더넷을 이용해서 SAN보다 저렴하게 구축함
    • iSCSI(서버와 스토리지 통신에 사용하는 SCSI 커맨드를 IP 네트워크를 통해 송수신하는 프로토콜) 스토리지가 주로 이용됨
    • 서버와 iSCSI는 모두 L2/L3 스위치 등을 통해 연결함

 

RAID와 핫스페어

  • 볼륨 : 인클로저 안에 탑재된 여러 개의 디스크로 RAID를 구성해 사용하는 큰 스토리지 영역
  • 핫스페어 : 다른 디스크가 망가졌을 때를 위해 대기하는 스탠바이 디스크
    • 자동 활성화 : 스토리지 인클로저가 디스크 고장을 감지
    • 고장난 디스크 대신 RAID 그룹에 들어감
    • 망가진 디스크는 고장 상태로 처리되어 시스템에서 분리되고 새 디스크가 핫스페어로 대기
    • 몇 개든 할당할 수 있으므로 넉넉하게 할당

 

22 외부 스토리지 이용

  • 저장 영역 확보
  • 디스크 I/O 성능 향상
  • 스토리지 통합 집중 관리
    • 복수의 스토리지를 통합 스토리지로 집약하면, 저장 영역을 낭비하지 않고 유용하게 활용 가능
  • 복수의 서버에서 데이터 공유
    • NAS 이용시 데이터베이스 클러스터링 환경에서 어느 서버든지 같은 데이터에 쉽게 액세스 가능

 

23 | 스토리지의 고급 기능

씬 프로비저닝

  • Thin Provisioning, 물리 스토리지 용량보다 많은 논리 볼륨을 할당할 수 있는 기능
  • 실제로 필요한 물리 스토리지만 준비할 수 있어 투자 비용 억제 가능
  • 가상 서버 환경처럼 게스트 운영체제마다 논리 볼륨을 만드는 환경에서 특히 효과적

 

자동 계층화

  • 서로 다른 디스크를 조합해서 데이터 이용 빈도에 따라 장비를 할당하는 기능
  • 구현 방식
    • 미리 특정한 규칙을 설정해두는 방법
    • 각 파일의 이용 상황을 스토리지가 스스로 판단해서 자동으로 적절한 계층으로 이동시키는 방법

 

디둡

  • De-duplication, 스토리지 백업 시 먼저 저장된 데이터는 복사하지 않는 기능, 중복 제거 기능
  • 디둡을 구현한 제품 대부분이 데이터 압축 기능도 탑재되어 있음

 

스냅샷

  • 어떤 순간의 파일 시스템의 정지점을 순간적으로 보존해 두는 기능
  • 파일이 갱신될 때마다 갱신 이력 + 갱신 전의 파일 -> 스냅샷용 스토리지 공간에 기록
  • 그 시점의 모든 파일을 복사하는 것이 아니라, 갱신 이력 정보를 함께 관리함

7장 데이터 센터

26 데이터 센터를 사용한다

데이터 센터 냉각 시스템

1. 이중 마루 냉각 방식

2. 열 복도/냉 복도 냉각 방식(배열 흡인 방식)

3. 외기 냉각 방식

 

데이터 센터 선정 포인트

  1. 입지
  2. 서버 설치 대수
  3. 랙 반입 or 대여
  4. 이용 가능한 전원
  5. 무거운 하중에 대한 대응
  6. 방재 수준
  7. UPS(무정전 장치)와 발전기 성능
  8. 폐기물 처리
  9. 반입 공간과 주차장 유무
  10. 리모트 핸드 서비스 유무
  11. 사용자 룸 유무
  12. 케이지 유무
  13. 네트워크 회선의 커넥티비티
  14. 비정기적 요구
  15. 물품 대여의 유연성
  16. 매점과 숙박 시설 유무
  17. 비용

 

27 랙에 장비를 설치한다

  • 네트워크 장비 설치
    • 랙의 맨 위나 중간에 설치
  • 공기 흐름
  • 전력 용량 문제

 

28 자체 서버 룸을 사용한다

자사 서버 룸 설치 포인트

  1. 면적
  2. 전력 용량
  3. 냉각
  4. 내하중
  5. 지진 대책
  6. 먼지 대책
  7. 법정 점검 대책
  8. 보안
  9. 비품 보관장소

 

CentOS 7.9 환경에 PostgreSQL 8.4.0 버전을 설치하는 중 ./configure를 실행하니 다음과 같은 에러가 발생했다.

checking for gcc... no
checking for cc... no
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details.

 

gcc나 cc가 없어서 나는 에러인 것 같다.

 

아래 코드를 실행해 필요한 컴파일러를 설치해준다.

sudo yum install gcc glibc glibc-common gd gd-devel

 

설치 후 다시 configure를 해보면 잘 실행된다!

 

 

참고링크

https://sojinhwan0207.tistory.com/90

클러스터 테이블 vs 논클러스터 테이블 비교

클러스터란?

  • 디스크로부터 데이터를 읽어오는 시간을 줄이기 위해서 자주 사용되는 테이블의 데이터를 디스크의 같은 위치에 저장하는 방법
  • 비슷한 레코드들을 동시에 조회하는 경우가 많아 효율적으로 조회하는 방법으로 고안됨
  • PK가 비슷한 레코드끼리 묶어서 저장하는 것 (MySQL)

 

클러스터 테이블(인덱스)

  • 테이블당 1개씩만 허용됨
  • PK 생성 시 그 컬럼은 자동으로 클러스터 인덱스가 생성됨
    * 일반 인덱스와의 차이
    • 클러스터링 되어 있다는 요소가 추가됨
    • 옵티마이저에서 일반 인덱스보다 높은 랭킹
  • PK를 설정하지 않은 경우는? InnoDB가 다음의 우선순위대로 대체 컬럼을 선택
    • UNIQUE NOT NULL 중 첫번째 인덱스를 클러스터 키로 선택
    • 자동으로 유니크한 값을 가지도록 AUTO_INCREMENT 컬럼을 내부적으로 추가해 클러스터 키로 선택
      * 하지만, 자동으로 추가되는 컬럼은 사용자에게 보이지 않아서 SQL에서 사용할 수가 없음
  • PK에 의해 레코드 저장 위치가 결정됨
    • PK값이 변경되면 -> 레코드의 물리적으로 행을 재배열함 -> 랜덤 액세스가 많이 발생해서 I/O 증가
    • PK를 신중히 결정해야 함
  • 인덱스 페이지의 리프 페이지가 곧 데이터. 즉, 테이블 자체가 인덱스
  • InnoDB 스토리지 엔진에서만 지원함
  • 장점
    • 그룹된 컬럼 데이터 행들이 같은 데이터 블록에 저장되기 때문에 디스크 I/O가 줄어 SELECT 시 처리 성능이 매우 빠름
    • 클러스터된 테이블 사이에 조인이 발생하면 처리 시간이 단축됨
    • INSERT, UPDATE, DELETE 시 항상 정렬 상태를 유지함
    • 이미 정렬된 상태로 저장되기 때문에 인덱스 테이블이 필요하지 않아 논클러스터보다 DB 용량을 덜 차지함
    • 테이블의 모든 보조 인덱스가 PK를 가지고 있기 때문에 인덱스만으로 처리될 수 있는 경우가 많음(커버링 인덱스)
  • 단점
    • 논클러스터보다 검색 속도는 더 빠르지만 INSERT, UPDATE, DELETE는 느림

 

논클러스터 테이블(인덱스)

  • 테이블당 249개 허용됨
  • 레코드의 원본은 정렬되지 않고, 인덱스 테이블만 정렬됨
    • 인덱스 페이지는 로그파일에 저장됨
  • 인덱스 자체의 리프 페이지는 데이터가 아니라 데이터가 위치하는 포인터(RID)이기 때문에 클러스터보다 검색 속도는 느리지만 INSERT, UPDATE, DELETE는 더 빠름

 

비교

  • 쉽게 책에 비유하자면 클러스터 테이블은 페이지를 알기 때문에 바로 그 페이지를 펴는 것(바로 접근)이고, 논클러스터 테이블은 목차에서 찾고자 하는 내용의 페이지를 찾고 그 페이지로 이동하는 것(한번 거쳐서 접근)과 같음

 

참고링크

+ Recent posts

티스토리툴바