면접 준비를 위한 CS + 프로젝트 질문 정리
끄적/개발끄적

면접 준비를 위한 CS + 프로젝트 질문 정리

728x90
반응형
프로젝트에 적용된 ES 기반 질문들 
프로젝트에서 검색 성능 향상에 무엇을 했나요?

A.

검색엔진 프로젝트에서 Elasticsearch를 사용하며 기존 RDB 의 Join 개념을 통해서는 분산환경인 엘라스틱에서 비효율적이었습니다. 

따라서 다른 방법을 찾고자 하였고, Elasticsearch 에서의 enrich policy 도입을 통해 역정규화를 진행하여 mapping 하고자 하였습니다.

enrich 필드를 사용하여 기존 src 도큐먼트의 필드들을 match_filed로 매핑 후, enrich_field들로 새롭게 필드를 추가하여 원하는 매핑과 빠른 검색 조회속도를 증가시킬 수 있었습니다. 

또한 검색의 관련성의 범위가 상황에 따라 달라져야 했습니다. 따라서 search template을 먼저 작성하여 각 상황에 맞는 쿼리들에 파라미터들만 지정하여 요청하는 방식으로 처리하여, 상황에 따른 알맞은 요구사항을 반환할 수 있었습니다. 

 

사용하신 Elasitcsearch에 대하여 간단하게 설명해주세요 

A. 

ES는 자바(루씬) 기반의 분산형 오픈소스 검색 엔진입니다. 엘라스틱서치는 역색인 구조를 지니고 있어서 fulltextSearch가 가능하며, 색인과 동시에 검색이 되는 NRT 의 특징을 지녔습니다. 또한 스키마리스, Restful API, 나눠진 여러 인덱스를 그룹으로 저장하여 서로 다른 인덱스의 데이터를 하나의 쿼리로 묶어서 검색이 가능한 멀티테넌시라는 특징을 지니고 있습니다. 

 

역색인 구조란 무엇인가요 

A. 

책 뒤에 색인 페이지에 비유할 수 있습니다. 각 해당 데이터가 어느곳에 위치되어있는 지에 대한 매핑 정보를 색인합니다. 

이 때 ES는 인덱싱 과정에서 text를 토크나이징하여 각 토큰 별로 어느 문서(도큐먼트)에 위치하는 지 기록하는 구조입니다. 이를 통해 full text search 가 가능하게 되는 이유입니다. 

 

Enrich Policy 와 Query DSL에 대해 설명해주세요 

A. Elasticsearch의 Query DSL은 모두 json 형식으로 입력이 이루어집니다. 이 떄 쿼리는 filter와 다르게 각 문서(도큐먼트)마다 해당 쿼리와 얼마나 일치하는가에 대한 값을 score를 통해 계산하게 됩니다. 

 

Enrich Policy는 도큐먼트를 ES에 Indexing 하는 과정에서 추가적인 필드 삽입 혹은 역정규화를 진행하게 되는 과정입니다. 이 때 ingest pipeline 설정에 match field와 enrich 필드를 사용하여 진행되게 됩니다. 

  • match field : 입력되는 데이터와 매핑하는데 사용될 src 도큐먼트(인덱스)의 필드 -> PK/ FK 의 역할 
  • enrich field : match field가 매핑되면 실제로 추가될 src 도큐먼트(인덱스)의 필드들 -> 매치되어 추가되어야하는 attribute 들
    • ex) 닉네임, 이름, 생년월일 등..

Enrich policy 과정 

1. src index 생성 

2. enrich policy 생성 

3. policy 실행 

4. enrich policy 적용시키기

-> matching_field : email로 지정 

5. 결과 

 

다양한 프로젝트에서 데이터 처리를 하면서 있었던 문제와 이를 해결하기 위한 예를 설명해주세요

A.

OVEN 프로젝트를 진행하면서 각 PVP 대전에 대한 캐릭터(쿠키)에 대한 정보와 전투에서의 수치 정보들을 한 도큐먼트에 넣었습니다. 승률이 좋은 쿠키들과 픽률이 좋은 쿠키들에 대한 정보를 획득하는 것이 또 하나의 요구사항이었습니다. 하지만 인덱싱 과정에서 각 승률과 픽률에 대한 정보를 계산하지 않고 인덱싱하였기에, 해당 데이터들에 대한 픽률과 승률은 Kibana의 차트를 통해 해결할 수 있을 것이라 생각했습니다. 

그러나 첫 ELK 프로젝트에서 Kibana 에 대한 조작은 미숙하여 원하는 결과를 도출하는 차트 기능을 완성할 수 없었습니다. 따라서 다시 처음부터 인덱싱과정을 할 수 밖에 없던 고민하던 찰나, ELK 를 공식 도큐먼트의 내용에서 공부하던 것 중 Runtime field와 script 기능을 사용하고자 하였습니다. 기존에 있던 도큐먼트들의 승리 횟수와 모든 픽 횟수를 참조하여 계산하여 _mapping을 통해  승률 필드를 새롭게 추가하였습니다. 또한 aggregation 기능을 통해 각 쿠키들에  대한 픽률을 계산하여 업데이트에 트렌드인 쿠키에 대한 정보 즉, 인사이트를 도출할 수 있었습니다. 

 

 

전반적인 CS 면접 질문 List-Up
Java
Call By Value Vs Call by Reference

결론 - 자바는 Call by Value 다

 

Primitive Type의 경우에는 Call by Value -  int, short , long, float, char, boolean 

Reference Type 의 경우 Call by Value - Array , 참조 타입 

 

자바에서는 함수의 인자로 전달되는 타입이 기본형인 경우 값을 넘기게 되어있다. 이 경우 메모리에는 함수를 위한 별도의 공간이 생성됨

이는 함수 종료시 사라진다. 따라서 함수 안에서 해당 인자의 값을 변경되더라도 원본 값이 바끼지 않는 특징이 있다. 

 

하지만 참조형의 경우 변수가 가지는 값이 주소 값이기 때문에, Call by Value 에 의해 주소 값이 전달된다. 따라서 함수안에서 해당 인자의 값이 변경되므로 원본의 값도 바뀐다. 

 

객체지향 프로그래밍 

OOP - 데이터를 추상화 시켴 상태와 행위를 가진 객체를 만들고, 각 객체의 상호작용을 통해 로직을 구성한다. 

 

특징 

  • 추상화 -  불필요한 정보를 숨기고 필요한 정보만을 표현하여 공통의 속성이나 기능을 묶어 이름을 붙인다.(Class)
  • 캡슐화 - 속성과 기능을 정의하는 멤버 변수와 메소드를 클래스안에 넣는다. 이를 통해 수정 없이 재활용이 가능하다 
  • 다형성 - 하나의 변수명 혹은 함수명이 상황에 따라 다르게 해석될 수 있다 (Overloading , Overriding)
  • 상속 - 부모클래스의 속성과 기능을 그대로 이어받거나 혹은 일부분을 변경해서 사용할 수 있게 한다. 이를 통해 공통적으로 관리하고 변경을 최소화한다. 

장점

  • 코드의 재사용성이 높다
  • 유지보수가 쉽다
  • 대형 프로젝트에 적합(클래스 단위로 모듈화가 개발할 수 있다) 

단점 

  • 처리 속도가 상대적으로 느리다
  • 객체가 많으면 용량이 커진다
  • 설계시 많은 비용이 필요하다 
객체지향 설계 원칙 (SOLID 원칙)

 

1. SRP (Single Responsibility Principle) : 단일 책임 원칙 

- 하나의 클래스는 단 하나의 책임을 가져야 한다. 

 

2. OCP(Open Closed Principle) : 개방 폐쇄 원칙

- 확장에는 열려있고 수정에는 닫혀있어야 한다. 

 

3. LSP(Liskov Substitution Principle) : 리스코프 치환 원칙

- 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상 작동해야한다. 

 

4. ISP(Interface Segregation Principle) : 인터페이스 분리 원칙 

- 인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야한다. 

 

5. DIP(Dependency Injection Principle) : 의존성 주입 원칙

- 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다. 

 

 

추상 클래스와 인터페이스 
  • 추상 클래스

- 미완성된 클래스이다. 

- 목적  : 기존의 클래스에서 공통된 부분을 추상화하여 상속하는 클래스에게 구현을 강제화하여 메소드의 동작을 구현하는 자식클래스에게 위임한다. 

- 특징 :

  • 추상 메서드를 반드시 하나라도 포함해야한다. 
  • 동작이 정의되지 않은 메서드를 포함하고 있기 때문에 인스턴스를 생성할 수 없다. 

 

  • 인터페이스 

- 인터페이스를 구현하는 모든 클래스에 대해 특정한 메소드가 반드시 존재하도록 강제한다. 

- 일종의 추상 클래스이자, 추상화정도가 더욱 높다. 멤버 변수를 구성원으로 가질 수 없다. 

- 자바는 다중 상속을 할 수 없기 때문에 (다이아몬드 문제 존재) , 인터페이스를 통해 다중 상속과 같은 효과를 구현할 수 있다. 

- 목적 : 구현 객체의 같은 동작을 보장하기 위함 

 

Reflection 

자바에서 이미 로딩이 완료된 클래스에서 또는 다른 클래스를 동적으로 로딩하여 구체적인 타입을 알지 못하더라도 생성자, 멤버 필드, 멤버 메소드를 사용할 수 있는 기법 

- 즉, 컴파일 타임이 아닌 런타임에 동적으로 특정 클래스의 정보를 객체화하여 분석 및 추출해낼 수 있는 프로그래밍 기법 

- 사용 이유 : 

런타임에 다른 클래스를 동적으로 로딩하여 접근할 필요가 있을 때 

 

 

JVM 

운영체제와 독립적 작동이 가능하다. 

구조 

  • 클래스 로더 
    • 자바 컴파일러가 .java 파일을 컴파일하면 바이트 코드가 생성된다(.class )
    • 생성 클래스 파일들을 로드하고 링크를 통해 배치하는 작업을 한다. 
  • 실행 엔진 (Execute Enginee)
    • 클래스를 실행하는 역할 
    • 실행 방식
      • 인터프리터 : 바이트코드를 명령어 단위로 읽어서 수행 -> 한 줄 씩 수행하므로 느리다.
      • JIT : 인터프리터 방식으로 실행하다가 적절한 시점에서 바이트 코드 전체를 컴파일 하여 네이티브 코드로 변경한다. 
        • 네이티브 코드는 캐시에 저장되기 떄문에 자주 실행되는 코드에 유리하다 
  • GC (Garbage Collection)
    • 힙 영역 내의 참조되지 않는 객체가 아닌 Reachability라는 개념을 통해 도달되지 않는 객체를 마크하고 스윕하여 압축하는 방식으로 진행된다.
    • New / Young 객체들을 대상으로 하는 Minor GC와 Old 영역의 대상으로 하는 Major GC의 동작이 나뉘어 진행된다. 
  • Runtime Data Area
  •  
    • 프로그램 수행을 위해 OS에서 할당받은 메모리 공간
    • 스레드 별 내부 공간이 존재한다. 
      • pc register
      • JVM 스택
      • Native Method Stack 
    • Method Area(Static Area)
      • 처음 메모리 공간을 올릴 떄 초기화 대상을 저장하기 위한 공간
    • Heap 
      • 객체를 저장하는 가상 메모리 공간
      • New / Young 영역
      • Old 영역
      • Permanent Generation 영역 (생성된 객체 정보 주소값 저장) 
Java 내 Thread 구현 

구현 방법

  1. Runnable 인터페이스 구현
  2. Thread 클래스 상속

두 방식 모두 run() 메소드를 오버라이딩 하여 한다. 

이 때 Runnable 구현의 경우에는 Thread 클래스의 static 메소드 currentThread() 호출을 통해 현재 스레드에 대한 참조를 얻어와야 호출이 가능하다는 점 

 

 

 

대용량 트래픽 처리

지원서에 작성한 것처럼 대용량 트래픽 처리를 위한 방법 + 기술은 무엇이 있는지 설명해주세요 
  • Load Balance 사용 

로드밸런싱을 통해 트래픽이 많을 때 여러 대의 서버가 분산처리하여 서버의 로드율을 증가시키기고, 부하량 속도저하 등의 문제를 고려하여 분산처리할 수 있다. 

 

- 장점 :

로드밸런싱을 통해 다른 서버가 다운되도 밸런싱한 다른 서버를 통해 서비스를 지속하여 사용자는 문제를 인지하지 못함

노드를 추가하는 것만으로도 서비스의 확장성 부여 

 

L4 혹은 L7 로드밸런서를 통해 패킷 혹은 7계층 프로토콜을 사용하여 트래픽을 분산한다. 

이 때 랜덤 , RR 등의 알고리즘을 통해 로드밸런싱을 결정하여 서비스 요청을 진행한다. 

 

  • L4 로드밸런싱 
    • IP 주소 / 패킷 등에 따라 트래픽을 나누고 분산처리를 진행한다. 
    • 이 때 다양한 처리 방식이 존재한다. 
      • RR 기반 - 각 세션을 서버에 순차적으로 맺어준다. 
      • 가중치 혹은 비율 할당 방식 - 서버마다 가중치를 통해 비율만큼 세션을 맺어준다. 
      • Least Connection(최소 연결) 방식 : 가장 적은 세션을 가진 서버로 트래픽을 보낸다.
      • Response Time(응답 시간) 방식 : 가장 빠른 응답 시간을 보내는 서버로 트래픽을 보낸다. 
      • Hash 기반 - 특정 클라이언트는 특정 서버로만 할당한다. 
      •  BandWidth 기반 - 서버들과 대역폭을 고려하여 트래픽을 분산 처리 
    • L7 로드밸런싱 
      • URL 스위칭 : 특정 하위 URL 을 특정 서버로 처리 
      • Context Switching : 클라이언트가 요청한 특정 리소스에 대해 특정 서버로 연결
      • 쿠키 지속성 : 쿠키 정보를 바탕으로 클라이언트가 연결했던 동일한 서버에 할당 
  • 클러스터링
    • 여러 대의 컴퓨터를 똑같은 구성의 서버군을 병렬로 연결하여 하나의 컴퓨터 처럼 사용하는 것을 의미
    • 특정 장비에 문제가 생겨도 전체 서비스에 영향을 주지 않는다.
    • 로드밸런서에 의해 각 clusting 된 서버에 의해 서비스가 진행된다. 
  • 오토 스케일링(Auto Scaling)
    • 서버의 부하를 체크하여 서버를 생성하는 방식 
    • 많은 클라우드 서비스 제공 업체는 오토 스케일링 지원 
  • DB 샤딩
    • DB 테이블을 수평 분할하여 물리적으로 서로 다른 곳에 분산하여 관리 
    • 이를 통한 scale-out을 지원
  • DB 레플리카 
    • 마스터 서버에 쓰기 작업을 진행 후, 서버의 데이터를 복제하여 여러 대의 slave 서버를 만들어 읽기 작업 수행 
  • Scale - Out 
    • 서버 장비의 수를 늘려 성능 향상 
  • Scale - Up
    • 서버 장비의 스펙을 업그레이드를 통해 성능 향상 

 

 

Data Structure

Array Vs LinkedList 
  • Array 

ㄹ배열이며, 논리적 저장순서와 물리적 저장 순서가 일치한다. 

연속적으로 이루어져있다. 

인덱스를 통해 접근하며, 인덱스를 알고 있다면 O(1)의 시간 복잡도로 원소에 접근이 가능하다. 

하지만 삭제 삽입 과정에서 shift 해줘야 하므로 O(n)의 비용이 들어간다. 

메모리 공간 활용에 제약이 존재한다. 

 

  • LinkedList 

데이터 검색 시 처음 노드부터 순회해야하기 때문에 O(n)

논리적 저장 순서와 물리적 저장 순서가 다르다. 

노드가 연속적으로 이루어져있지 않기 때문에, 각 노드는 자신의 다음 노드의 위치를 알고 있는 형태이다. 

검색과 삽입 , 삭제 모두 O(n)의 시간 복잡도를 가진다. 

 

  • 데이터 접근 속도 
    • Array - 인덱스를 통한 접근으로 시간 복잡도 O(1)
    • LinkedList - 특정 원소로 접근하기 위해서는 결국 순차적으로 검색하기 때문에 O(n)이다
  • 삽입 속도
    • Array - 데이터를 중간 혹은 맨 앞에 삽입할 경우 Shift가 필요하므로 O(n)
    • LinkedList - 중간 삽입 없이 맨 앞 , 맨 뒤는 O(1)의 시간복잡도 
      • 그렇지 않다면 삽입할 위치를 찾아햐 하므로 O(n)
      • 그럼에도 불구하고 삽입에서는 Array보다 좋은 성능
  • 삭제 속도
    • Array - 삭제 이후의 shift가 필요하므로 - O(n)
    • LinkedList - 삭제할 원소를 찾기 위한 O(n) but array보다 빠르게 삭제 연산
결론 : 삽입과 삭제가 빈번하다면 LinkedList - 효율 굳 
하지만 데이터에 대한 검색 및 접근이 빈번하다면 Array 

 

 

LinkedList VS ArrayLIst 
  • LinkedList
    • 이름처럼 내부적으로 배열을 사용하여 데이터를 관리한다. 
    • 인덱스를 가지고 있어 데이터 검색에 적합 - O(1)
    • 데이터의 삽입 삭제 시 임시 배열을 생성 후 복사하므로 시간 복잡도가 부적합하다. O(n)
  • LinkedList 
    • 데이터를 저장하는 각 노드가 이전 노드와 다음 노드의 상태를 알고 있으면 된다. 
    • 검색 시 처음부터 노드를 순회하므로 오래걸린다 - O(n)
    • 삽입 삭제 시 불필요한 데이터 복사가 발생하지 않아 효율적 - O(1)
      • 경우에 따라 다르기도 함 결국 중간 요소의 삽입 삭제라면 오래걸린다. 
결론 : 데이터의 검색에는 배열의 특성을 닮은 ArrayList가 좋다.
데이터의 삽입 , 삭제가 빈번하다면 LinkedList가 좋은 편

 

DataBase
SQL injection
  • 해커에 의해 조작된 SQL 쿼리문이 DB에 그대로 전달되어 비정상적 명령을 실행시키는 공격 기법
  • 최근 Log4j 보안 이슈에서 사용된 기법 

 

input 창에 비밀번호를 입력함과 동시에 다른 쿼리문을 insert 함으로써 뒤의 쿼리문이 DB에 영향을 주게 되어 수정 뒤 DB의 영향을 주는 방법

 

데이터 노출 공격 방법

- 해커가 Get 방식으로 동작하는 URL 쿼리 스트링을 추가하여 에러를 발생시킨다. 

이를 통해 오류가 발생하며 웹앱의 DB 구조를 유추하고 해킹에 활용한다. 

 

방어 방법

  • input 값을 받을 떄 특수 문자 여부검사
  • SQL 서버 오류 발생 시 , 해당 에러 메시지 감추기
    • view를 활용하여 원본 DB 테이블에 대한 접근 권한을 높인다. 
  • prepare statement 사용하기
    • 특수문자를 자동으로 escaping 해준다. 

 

SQL vs NoSQL 
  • SQL 
    • 데이터는 정해진 데이터 스키마에 따라 테이블에 저장된다.
    • 데이터는 관계를 통해 여러 테이블에 분산된다.
    • 데이터의 중복을 최소화(피하기)위해 관계를 사용한다. 

장점 :

명확하게 정의된 스키마와 데이터의 무결성을 보장한다. 

관계는 데이터를 중복없이 한 번만 저장하게 된다. 

 

단점 : 

덜 유연한 편이다. 

한 번 정의된 이후에는 수정하기 힘듦

수직적 확장만 가능하다. 

 

 

  • NoSQL
    • 스키마도 없고 관계도 존재하지 않는다.
    • NoSQL에서는 레코드를 도큐먼트라 칭한다. 
    • Join에 의존하지 않고 필요한 정보들을 모두 담고있다. 

장점 : 스키마가 없어 유연하다. 언제든지 저장된 데이터를 조정하고 새로운 필드 추가가 가능하다.

데이터를 읽어오는 속도가 빠르다.

수직 및 수평 확장에 용이하여 읽기 / 쓰기 요청 처리가 가능하다. 

 

단점 : 

유연성으로 인하여 데이터 구조 결정이 미루어진다. 

데이터의 중복을 계속해서 업데이트해야한다. 

여러 데이터가 중복되므로 수정시 해당 데이터에 대한 수정이 필요하다. 

 

결론 : 
관계를 맺고 데이터가 자주 변경되는 경우 -> SQL 
변경될 여지가 없거나 명확한 스키마가 사용자와 데이터에게 중요한 경우 -> SQL

정확한 데이터의 구조를 알 수 없거나, 변경/확장이 될 수 있는 경우
읽기를 자주하지만 데이터 변경은 자주 없는 경우
빅데이터 혹은 수평으로 확장해야 하는 경우 -> NoSQL 

 

Transcation

- DB의 상태를 변화시키기 위해 수행하는 작업 단위 ( 작업의 완전성을 보장해주는 것) 

상태를 변화시킨다는 것 = SQL 질의어를 통해 DB에 접근 

하나의 트랜잭션 설계를 잘 만드는 것이 데이터를 다룰 때 많은 이점을 가져온다. 

 

  • 트랜잭션의 특징 (ACID - Atomicity / Consistency / Isolation / Durability) 
    • 원자성 - 트랜잭션이 DB에 모두 반영 or 전혀 반영되지 않음
    • 일관성 - 트랜잭션의 작업 처리 결과는 항상 일관성 있어야 함
    • 독립성 - 둘 이상의 트랜잭션이 동시에 병행 실행될 때, 어떤 트랜잭션도 다른 트랜잭션에 영향을 주어선 안된다. 
    • 지속성 - 트랜잭션이 성공적으로 완료되면 결과는 영구적으로 반영된다. 
  • Commit 
    • 하나의 트랜잭션이 성공적으로 끝나고, DB가 일관성있는 상태일 때 이를 알려주기 위한 연산
  • RollBack
    • 하나의 트랜잭션이 비정상처리될 경우 트랜잭션이 원자성이 깨진다
    • 따라서 정상적으로 종료되지 않을 때 last consistent state로 roll back 할 수 있다 . 
Anomaly (이상 현상) 

배경 : 잘못된 테이블 설계로 인해서 Anomaly 현상이 발생한다. -> 따라서 정규화가 필요하다 

ex) {Student_id , Course_id , Department , Grade , Course_id}

 

  1. 삽입 이상 
    • 기본키가 {Student_id , Course_id} 인 경우
    • Course를 수강하지 않는 학생은 course_id가 없는 현상이 발생한다 따라서 course_id가 null 로 처리되야 함
    • 하지만 기본키는 null 이 될 수 없으므로 테이블에 추가될 수 없음
    • 굳이 삽입 하기 위해서는 미수강 같은 course_id를 만들어야함
    • 하지만 이는 불필요한 데이터를 추가해야 삽입할 수 있는 상황 =  삽입 이상
  2. 갱신 이상
    • 만약 어떤 학생의 전공이 컴퓨터 -> 음악이 되는 경우
    • 모든 department를 음악으로 바꾸어야 한다. 하지만 일부를 놓쳐 바꾸지 못하는 경우, 제대로 파악이 불가
    • 일부만 변경되어 데이터의 불일치가 발생하는 모순의 경우 = 갱신 이상
  3. 삭제 이상
    • 만약 어떤 학생이 수강을 철회하는 경우 {Student_id , Course_id, Department , Course_id, Grade}의 정보 중 Course_id를 삭제하면 Student_id, Department 와 같은 학생에 대한 정보도 함께 삭제
    • 튜플 삭제로 인하여 꼭 필요한 데이터까지 함께 삭제되는 문제 = 삭제 이상 

 

Index

- DBMS에서 원하는 데이터를 검색해서 불러오는 것은 시간이 오래걸린다. 따라서 해당 데이터의 저장 주소값과 인덱스를 통해 key : value 형태로 저장하여 빠르게 불러오기 위해 index를 사용하낟. 

 

- index는 항상 정렬된 상태를 유지하기 때문에, 원하는 값을 탐색하는데는 빠르지만 새로운 값을 추가하거나 삭제, 수정하는 경우에는 많은 시간이 소비된다. 따라서 데이터의 저장 성능을 희생하고 대신 데이터를 검색하는데 힘을 준것이다. 

 

Index의 자료구조 
  1. B Tree 인덱스 알고리즘 
    • 일반적으로 사용되는 인덱스 알고리즘으로 해당 칼럼의 값을 변경하지 않고 그대로 값을 이용하여 인덱싱하는 알고리즘이다. 
    • 데이터에 접근하는 시간복잡도는 해시 알고리즘이 더 우월하지만 쿼리문에서 부등호 연산을 사용할 경우에는 해당 연산을 사용하는데 해시 알고리즘 에서는 문제가 발생한다. 따라서 일반적으로 B Tree 인덱스 자료구조를 사용한다. 
  2. Hash 인덱스 알고리즘
    • 칼럼의 값을 해시 값을 통해 인덱싱 처리한다. 따라서 빠른 검색을 지원한다. 
    • 하지만 값을 변형해서 인덱싱이 이루어지기 때문에 전방 일치 등의 부분 조건 검색을 통해서는 해당 해시 인덱스를 사용할 수 없다
    • 메모리 기반 DB에 자주 사용된다. 

 

정규화 (Normalized)

배경 : 제대로된 테이블 구조 설계가 이루어지지 않아 중복된 정보가 저장되어 이상현상이 발생한다. 이러한 문제 해결을 위해 정규화 과정을 펼치게 된다. 

 

애트리뷰트 간의 함수적 종속성을 판단하여 이를 만족하는 지에 따라 정규형을 정의하여 나쁜 릴레이션들을 정규화해나간다. 

 

  • 제 1 정규형
    • 애트리뷰트의 도메인이 오직 원자값만을 포함한다.
    • 튜플의 모든 애트리뷰트가 도메인에 속하는 하나의 값을 가져야 한다. (중복되느 애트리뷰트가 있어서는 안된다) 
  • 제 2정규형
    • 모든 비주요 애트리뷰트들은 주요 애트리뷰트에 대해 완전 함수적 종속인 형태
    • 즉 키가 아닌 열들은 각 후보키에 대해 결정되는 릴레이션 형태 
  • 제 3정규형
    • 어떠한 비주요 애트리뷰트도 기본키에 대해 이행적으로 종속되지 않는 형태 
    • X -> Y , Y -> Z  => X -> Z 이러한 관계가 없는 형태 
  • BCNF 정규형
    • 여러 후보키가 존재하는 릴레이션에 대한 정규화가 진행 

 

정규화의 단점 - 정규화를 통해 중복되는 데이터가 없기 때문에 조인이 많이 발생하게 되어 성능저하를 일으킬 수 있다. 

 

728x90
반응형

'끄적 > 개발끄적' 카테고리의 다른 글

2PC[Two-Phase-Commit]과 SAGA 패턴  (0) 2022.12.08

    티스토리툴바