[기술면접] 데이터베이스

데이터베이스 기술면접을 따로 정리해 둔 것이 있지만(저작권의 이유로 비공개글), 사람의 욕심은 끝이 없다고... 추가로 정리를 해보려 합니다. 참고한 좋은 글을 통해 오늘도 성장합니다. 

 

 

 

DB 핵심 개념

• NoSQL, RDBMS 차이
• JOIN
• 정규화
• 무결성, 트랜잭션
• Connection Pool

 

목차

• DB 정규화
• (갱신)이상 현상의 종류
• DB락의 종류
• 클러스터링 vs 리플리케이션
• 데이터베이스를 사용하는 이유
• 데이터베이스 언어(DDL, DML, DCL)
• SELECT 쿼리의 수행 순서
• JOIN에서 ON과 WHERE의 차이
• group by
• SQL Injection
• Elastic Search의 키워드 검색과 RDBMS의 LIKE 검색의 차이
• 옵티마이저(Optimizer)
• DB 튜닝(Tuning)
• 커넥션풀
• 트랜잭션을 사용할 때 주의할 점
• 교착 상태(Deadlock)의 빈도를 낮추는 방법
• 저장 프로시저(Stored PROCEDURE)
• Redis
  
   
  
  
  
  

---

 

 

 

 

 

😎 DB 정규화

1. 제1정규형: 테이블 컬럼이 원자값(하나의 값)을 갖도록 테이블을 분리시키는 것을 말한다.
   
   
2. 제2 정규형: 제1 정규형을 만족하고, 테이블의 모든 컬럼이 완전 함수적 종속을 만족해야 한다.
   쉽게 말하면, 테이블에서 기본키가 복합키(키 1, 키 2)로 묶여있을 때, 두 키 중 하나의 키만으로 다른 칼럼을 결정지을 수 있으면 안 된다는 것이다.
   
   
3. 제3 정규형: 제2 정규형을 만족하고, 이행적 종속을 없애기 위해 테이블을 분리하는 것이다.
   (여기서 이행적 종속이란 A → B, B → C면 A → C가 성립되는 것을 말한다.)
   
   
4. BCNF 정규형: 제3정규형을 만족하고, 제3 정규화를 진행한 테이블에 대해 모든 결정자가 후보키가 되도록 테이블을 분해하는 것입니다.
   

▶ 정규화의 목적?

가장 큰 목표는 테이블 간 중복된 데이터를 허용하지 않는 것이다.

중복된 데이터를 만들지 않으면, 무결성을 유지할 수 있고, DB 저장 용량 또한 효율적으로 관리할 수 있다.

또한 이상 현상을 예방하고 효과적인 연산을 하기 위해 데이터 정규화를 합니다.

• 데이터의 중복을 없애면서 불필요한 데이터를 최소화시킨다.
• 무결성을 지키고, 이상 현상을 방지한다.
• 테이블 구성을 논리적이고 직관적으로 할 수 있다.
• 데이터베이스 구조 확장에 용이해진다.

 

▶ 정규화의 장, 단점?

장점

1. 데이터베이스 변경 시 이상현상이 발생하는 문제점을 해결할 수 있다.

2. 데이터베이스 구조 확장 시 정규화된 데이터베이스는 그 구조를 변경하지 않아도 되거나 일부만 변경해도 된다.

 

단점

릴레이션의 분해로 인해 릴레이션 간의 연산(JOIN 연산)이 많아진다. 이로 인해 질의에 대한 응답 시간이 느려질 수 있다.

 

 

▶ 단점에서 미루어보았을 때 어떠한 상황에서 정규화를 진행해야 하는가? 단점에 대한 대응책은?

조회를 하는 SQL 문장에서 조인이 많이 발생하여 이로 인한 성능저하가 나타나는 경우에 반정규화를 적용하는 전략이 필요하다.

 

▶ 반정규화(De-normalization, 비정규화)란 무엇인가?

정규화된 엔티티, 속성, 관계를 시스템의 성능 향상 및 개발과 운영의 단순화를 위해 중복 통합, 분리 등을 수행하는 데이터 모델링 기법 중 하나이다.

디스크 I/O 량이 많아서 조회 시 성능이 저하되거나,

테이블끼리의 경로가 너무 멀어 조인으로 인한 성능 저하가 예상되거나,

칼럼을 계산하여 조회할 때 성능이 저하될 것이 예상되는 경우 반정규화를 수행하게 된다.

 

일반적으로 조회에 대한 처리 성능이 중요하다고 판단될 때 부분적으로 반정규화를 고려하게 된다.

 

  ▶ 무엇이 반정규화의 대상이 되는가?

1. 자주 사용되는 테이블에 액세스하는 프로세스의 수가 가장 많고, 항상 일정한 범위만을 조회하는 경우
2. 테이블에 대량 데이터가 있고 대량의 범위를 자주 처리하는 경우, 성능 상 이슈가 있을 경우
3. 테이블에 지나치게 조인을 많이 사용하게 되어 데이터를 조회하는 것이 기술적으로 어려울 경우

  ▶반정규화 과정에서 주의할 점은?

  반정규화를 과도하게 적용하다 보면 데이터의 무결성이 깨질 수 있다.

  또한 입력, 수정, 삭제의 질의문에 대한 응답 시간이 늦어질 수 있다.

 

 

 

😎 (갱신)이상 현상의 종류

이상 현상은 테이블을 설계할 때 잘못 설계하여 데이터를 삽입, 삭제, 수정할 때 생기는 논리적 오류를 말합니다. 이러한 이상 현상을 예방하고 효과적인 연산을 하기 위해 데이터 정규화를 합니다.

• 삭제 이상: 튜플 삭제 시 같이 저장된 다른 정보까지 연쇄적으로 삭제되는 현상
• 삽입 이상: 튜플 삽입 시 특정 속성에 해당하는 값이 없어 NULL을 입력해야 하는 현상
• 수정 이상: 튜플 수정 시 중복된 데이터의 일부만 수정되어 일어나는 데이터 불일치 현상

 

 

😎 DB락의 종류

DB 락은 여러 개의 트랜잭션들이 하나의 데이터로 동시에 접근하려고 할 때 이를 제어해 주는 도구이다. 

• 공유락(LS, Shared Lock): 트랜잭션이 읽기를 할 때 사용하는 락, 데이터를 읽을 수 있지만 쓸 수 없음
• 베타락(LX, Exclusive Lock): 트랜잭션이 읽고 쓰기를 할 때 사용하는 락, 데이터를 읽고 쓸 수 있음

 

 

😎 클러스터링 vs 리플리케이션

클러스터링이란 여러 개의 DB를 수평적인 구조로 구축하는 방식입니다. 동기 방식으로 사용되며, 다음과 같은 장단점이 있습니다.

장점 :
DB 간의 데이터를 동기화하여 항상 일관성있는 데이터를 얻을 수 있다.
1개의 DB가 죽어도 다른 DB가 살아 있어 시스템을 장애 없이 운영할 수 있다. (높은 가용성)
기존에 하나의 DB서버에 몰리던 부하를 여러 곳으로 분산시킬 수 있다. (로드밸런싱)

단점 :
저장소 하나를 공유하면 병목현상이 발생할 수 있다.

서버를 동시에 운영하기 위한 비용이 많이 든다.

 

 

리플리케이션은 여러 개의 DB를 권한에 따라 수직적인 구조로 구축하는 방식입니다. 비동기 방식으로 사용되며, 다음과 같은 장단점이 있습니다.

장점 :
DB 요청의 60~80% 정도가 읽기 작업이기 때문에 Replication만으로도 충분히 성능을 높일 수 있다.
비동기 방식으로 운영되어 지연 시간이 거의 없다.

단점 :
노드들 간 데이터 동기화가 보장되지 않아 일관성있는 데이터를 얻지 못할 수 있다.
Master DB가 다운되면 복구 및 대처가 까다롭다.

 

 

 

😎 데이터베이스를 사용하는 이유

데이터베이스가 존재하기 이전에는 파일 시스템을 이용하여 데이터를 관리하였다. 데이터를 각각의 파일 단위로 저장하며 이러한 일들을 처리하기 위한 독립적인 애플리케이션과 상호 연동이 되어야 한다. 이때의 문제점은 데이터 종속성 문제와 중복성, 데이터 무결성이다.

 

▶데이터베이스의 특징

1. 데이터의 독립성
   • 물리적 독립성 : 데이터베이스 사이즈를 늘리거나 성능 향상을 위해 데이터 파일을 늘리거나 새롭게 추가하더라도 관련된 응용 프로그램을 수정할 필요가 없다.
   • 논리적 독립성 : 데이터베이스는 논리적인 구조로 다양한 응용 프로그램의 논리적 요구를 만족시켜줄 수 있다.
2. 데이터의 무결성
   여러 경로를 통해 잘못된 데이터가 발생하는 경우의 수를 방지하는 기능으로 데이터의 유효성 검사를 통해 데이터의 무결성을 구현하게 된다.
   
   
3. 데이터의 보안성
   인가된 사용자들만 데이터베이스나 데이터베이스 내의 자원에 접근할 수 있도록 계정 관리 또는 접근 권한을 설정함으로써 모든 데이터에 보안을 구현할 수 있다.
   
   
4. 데이터의 일관성
   연관된 정보를 논리적인 구조로 관리함으로써 어떤 하나의 데이터만 변경했을 경우 발생할 수 있는 데이터의 불일치성을 배제할 수 있다. 또한 작업 중 일부 데이터만 변경되어 나머지 데이터와 일치하지 않는 경우의 수를 배제할 수 있다.
   
   
5. 데이터 중복 최소화
   데이터베이스는 데이터를 통합해서 관리함으로써 파일 시스템의 단점 중 하나인 자료의 중복과 데이터의 중복성 문제를 해결할 수 있다.

 

▶ 데이터베이스의 성능?

데이터베이스의 성능 이슈는 디스크 I/O 를 어떻게 줄이느냐에서 시작된다.

디스크 I/O 란 디스크 드라이브의 플래터(원판)를 돌려서 읽어야 할 데이터가 저장된 위치로 디스크 헤더를 이동시킨 다음 데이터를 읽는 것을 의미한다. 이때 데이터를 읽는 데 걸리는 시간은 디스크 헤더를 움직여서 읽고 쓸 위치로 옮기는 단계에서 결정된다. 즉 디스크의 성능은 디스크 헤더의 위치 이동 없이 얼마나 많은 데이터를 한 번에 기록하느냐에 따라 결정된다고 볼 수 있다.

 

그렇기 때문에 순차 I/O 가 랜덤 I/O 보다 빠를 수 밖에 없다.

하지만 현실에서는 대부분의 I/O 작업이 랜덤 I/O이다. 랜덤 I/O 를 순차 I/O로 바꿔서 실행할 수는 없을까? 이러한 생각에서부터 시작되는 데이터베이스 쿼리 튜닝은 랜덤 I/O 자체를 줄여주는 것이 목적이라고 할 수 있다.

 

 

 

😎 데이터베이스 언어(DDL, DML, DCL)에 대해 설명해주세요.

• DDL (정의어 : Data Definition Language) : 데이터베이스 구조를 정의, 수정, 삭제하는 언어 ( alter, create, drop )
• DML (조작어 : Data Manipulation Language) : 데이터베이스 내의 자료 검색, 삽입, 갱신, 삭제를 위한 언어 ( select, insert, update, delete )
• DCL (제어어 : Data Control Language) : 데이터에 대해 무결성 유지, 병행 수행 제어, 보호와 관리를 위한 언어 ( commit, rollback, grant, revoke )

 

 

😎 SELECT 쿼리의 수행 순서를 알려주세요.

FROM, ON, JOIN > WHERE, GROUP BY, HAVING > SELECT > DISTINCT > ORDER BY > LIMIT

 

 

1. FROM

- 각 테이블을 확인한다.

 

2. ON

- JOIN 조건을 확인한다.

 

3. JOIN

- JOIN이 실행되어 데이터가 SET으로 모아지게 된다. 서브쿼리도 함께 포함되어 임시 테이블을 만들 수 있게 도와준다.

 

2. WHERE

- 데이터셋을 형성하게 되면 WHERE의 조건이 개별 행에 적용된다. WHERE절의 제약 조건은 FROM절로 가져온 테이블에 적용될 수 있다.

 

3. GROUP BY

- WHERE의 조건 적용 후 나머지 행은 GROUP BY절에 지정된 열의 공통 값을 기준으로 그룹화된다. 쿼리에 집계 기능이 있는 경우에만 이 기능을 사용해야 한다.

 

4. HAVING

- GROUP BY절이 쿼리에 있을 경우 HAVING 절의 제약조건이 그룹화된 행에 적용된다.

 

5. SELECT

- SELECT에 표현된 식이 마지막으로 적용된다.

 

6. DISTINCT

- 표현된 행에서 중복된 행은 삭제

 

7.ORDER BY

- 지정된 데이터를 기준으로 오름차순, 내림차순 지정

 

8. LIMIT

- LIMIT에서 벗어나는 행들은 제외되어 출력된다.

 

 

 

😎 JOIN에서 ON과 WHERE의 차이를 설명해 주세요.

ON 이 WHERE 보다 먼저 실행되어 JOIN을 하기 전에 필터링을 하고

(=ON 조건으로 필터링이 된 레코들 간 JOIN이 이뤄진다)

WHERE은 JOIN을 한 후에 필터링을 합니다.

(=JOIN을 한 결과에서 WHERE 조건절로 필터링이 이뤄진다)

 

 

 

😎 group by의 역할, 사용하는 이유에 대해 설명해 주세요.

GROUP BY 명령어를 통해 특정 컬럼을 기준으로 그룹화할 수 있습니다.
그룹화를 하면 조회된 데이터의 통계를 내기 위한 집계함수(count, avg, sum, max, min)를 사용하기에 용이해집니다.

 

집계함수를 사용하여 특정 GROUP으로 분류하고 정렬이 필요하다면 GROP BY절을,
특정 GROUP 구분 없이 단순히 중복 제거가 필요할 경우 DISTINCT를 사용하는 것이 좋습니다. 

 

▶ HAVING 이란?

GROUP BY 절에서 조건을 주려면 WHERE이 아닌, HAVING 절을 사용해야 합니다.

HAVING 은 GROUP BY 뒤에 작성하며, WHERE와 동일한 형식으로 조건을 작성할 수 있습니다.

 

▶ HAVING과 WHERE의 차이를 설명해 주세요.

having은 그룹을 필터링하는 데 사용되고, where은 개별 행을 필터링하는 데 사용됩니다.

집계 함수(COUNT, SUM, AVG, MAX, MIN 등)는 having절과 함께 사용할 수 있으나,
where절은 사용할 수 없습니다.( 집계함수를 사용할 수 있는 GROUP BY 절보다 WHERE절이 먼저 수행)

having은 그룹화 또는 집계가 발생한 후 필터링하는데 사용되고,
where은 그룹화 또는 집계가 발생하기 전에 필터링하는데 사용됩니다.

 

 

 

😎 SQL Injection이 무엇인지 설명해 주세요.

SQL Injection이란 공격자가 악의적인 의도를 갖는 SQL 구문을 삽입하여 데이터베이스를 비정상적으로 조작하는 공격 기법입니다.

 

▶ SQL Injection을 방어 및 방지하기 위한 방법에 대해 설명해 주세요.

1. 입력값을 검증하여 사용자의 입력이 쿼리에 동적으로 영향을 주는 경우 입력된 값이 개발자가 의도한 값(유횻값) 인지 검증합니다.

 

2. 저장 프로시저를 사용합니다.

저장 프로시저란 사용하고자 하는 Query에 미리 형식을 지정하는 것을 말한다. 지정된 형식의 데이터가 아니면 Query가 실행되지 않기 때문에 보안성이 크게 향상한다.

 

 

 

😎 Elastic Search의 키워드 검색과 RDBMS의 LIKE 검색의 차이에 대해 설명해 주세요.

• RDBMS는 단순 텍스트매칭에 대한 검색만을 제공해 동의어나 유의어 같은 검색은 불가능합니다.
  • (MySQL 최신 버전에서 n-gram 기반의 Full-Text 검색을 지원하긴 하지만, 한글 검색의 경우 아직 많이 빈약한 감이 있습니다.)
• 하지만 엘라스틱 서치는 동의어나 유의어를 활용한 검색이 가능하며, 비정형 데이터의 색인과 검색이 가능하고, 역색인 지원으로 매우 빠른 검색이 가능합니다.

 

 

😎 옵티마이저(Optimizer)에 대해 아는 대로 말해주세요.

• 옵티마이저는 SQL을 가장 빠르고 효율적으로 수행할 최적의 처리 경로를 생성해 주는 DBMS 내부의 핵심 엔진입니다.
• 컴퓨터의 두뇌가 CPU인 것처럼 DBMS의 두뇌는 옵티마이저라고 할 수 있습니다.
  • 개발자가 SQL을 작성하고 실행하면 즉시 실행되는 것이 아니라 옵티마이저라는 곳에서 “이 쿼리문을 어떻게 실행시키겠다!”라는 여러 가지 실행 계획을 세우고, 최고의 효율을 갖는 실행계획을 판별한 후 그 실행계획에 따라 쿼리를 수행하게 되는 것입니다.

 

 

😎 DB 튜닝(Tuning)이 무엇인지 그리고 튜닝의 3단계에 대해 설명해 주세요.

• DB 튜닝이란 DB의 구조나, DB 자체, 운영체제 등을 조정하여 DB 시스템의 전체적인 성능을 개선하는 작업을 말합니다.
• 튜닝은 DB 설계 튜닝 → DBMS 튜닝 → SQL 튜닝 단계로 진행할 수 있습니다.
• 1단계 - DB 설계 튜닝(모델링 관점)
  • DB 설계 단계에서 성능을 고려하여 설계
  • 데이터 모델링, 인덱스 설계
  • 데이터파일, 테이블 스페이스 설계
  • 데이터베이스 용량 산정
  • 튜닝 사례 - 반정규화, 분산파일배치
• 2단계 - DBMS 튜닝(환경 관점)
  • 성능을 고려하여 메모리나 블록 크기 지정
  • CPU, 메모리 I/O에 관한 관점
  • 튜닝 사례 - Buffer 크기, Cache 크기
• 3단계 - SQL 튜닝(App 관점)
  • SQL 작성 시 성능 고려
  • Join, Indexing, SQL Execution Plan
  • 튜닝 사례 - Hash / Join

 

 

😎DBCP(DataBase Conncetion Pool), 커넥션풀 이란?

커넥션 풀이란 DB와 미리 connection( 연결 )을 해놓은 객체들을 pool( 웅덩이 )에 저장해 두었다가,

클라이언트 요청이 오면 커넥션을 빌려주고, 볼일이 끝나면 다시 커넥션을 반납받아 pool에 저장하는 방식을 말합니다.

 

▶ 특징, 장단점

서비스가 커져서 유저가 한 명이 아니라, 100명의 유저가 동시 접속 중이라고 가정해 보겠습니다.

원래는 매번 DB와 커넥션을 맺고 끊는 과정이 필요한데 커넥션 풀을 사용하게 되면,

미리 연결을 맺고 있는 커넥션들이 있기 때문에 커넥션을 맺고 끊는 과정이 불필요합니다.

즉, DB 접근 시 불필요한 작업( 커넥션 생성, 끊기 )이 사라지므로 성능향상을 기대할 수 있습니다.

 

 

DB에서는 기본적으로 커넥션을 일정량 제공해 줍니다.

그런데 유저가 많아져서 커넥션이 모자랄 경우, 즉 기본으로 제공된 커넥션이 모자랄 경우 원활한 서비스가 이루어지지 않습니다. 커넥션이 반납될 때까지 기다려야 하기 때문이죠.

따라서 유저수에 따라 커넥션을 조절할 필요가 있습니다.

 

 

그렇다고 커넥션을 막 늘리는 것은 좋지 않습니다.

컴퓨터 세계에서는 항상 trade off가 있듯이, 커넥션 풀을 통한 장점도 있지만 단점도 있습니다.

커넥션 또한 객체이므로 메모리를 차지하게 됩니다.

따라서 무작정 많이 늘리는 것은 메모리를 많이 차지하게 되므로 오히려 성능이 떨어지는 결과를 가져옵니다.

 

 

 

😎트랜잭션 격리 수준

트랜잭션 격리 수준(Isolation level)이란 동시에 여러 트랜잭션이 처리될 때, 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있도록 허용할지 말지를 결정하는 것이다. 격리 수준은 다음과 같이 크게 4가지로 정의할 수 있다.

• READ UNCOMMITTED (커밋되지 않은 읽기)
• READ COMMITTED (커밋된 읽기)
• REPEATABLE READ (반복 가능한 읽기)
• SERIALIZABLE (직렬화 가능)

 

▶ 각 트랜잭션 격리 수준을 설명하라.

• READ UNCOMMITTED
  • 한 트랜잭션의 변경된 내용을 커밋이나 롤백과 상관없이 다른 트랜잭션에서 읽을 수 있는 격리 수준
  • 모든 부정합 문제 발생
• READ COMMITTED
  • COMMIT이 완료된 데이터만 조회 가능한 격리 수준
  • 더티 리드 해결
• REPEATABLE READ
  • 트랜잭션이 시작되기 전에 커밋된 내용에 관해서만 조회할 수 있는 격리 수준
  • NON-REPEATABLE-READ 해결
  • InnoDB에서는 PHANTOM READ 해결
• SERIALIZABLE
  • 한 트랜잭션을 다른 트랜잭션으로부터 완전히 분리하는 격리 수준
  • 모든 부정합 문제 해결

 

▶ 부정합 문제를 모두 설명하라

• 더티 리드
  • 다른 트랜잭션에서 처리한 작업이 완료되지 않았음에도 불구하고 다른 트랜잭션에서 볼 수 있게 되는 현상을 말한다.
• NON-REPEATABLE READ
  • 하나의 트랜잭션 내에서 동일한 SELECT 쿼리를 실행했을 때 항상 같은 결과를 보장해야 한다는 REPEATABLE READ 정합성에 어긋나는 것을 말한다.
• PHANTOM READ
  • SELECT ... FOR UPDATE 쿼리와 같은 쓰기 잠금을 거는 경우 다른 트랜잭션에서 수행한 변경 작업에 의해 레코드가 보였다가 안 보였다가 하는 현상을 말한다.

 

 

▶ 부정합 문제를 해결하는 방법을 설명하라

• 더티 리드
  • READ COMMITTED 격리 수준 이상을 사용한다.
  • 언두 영역을 사용하여 커밋되기 이전 데이터만을 다른 트랜잭션에게 보여준다.
• NON-REPEATABLE READ
  • REPEATABLE READ 격리 수준 이상을 사용한다.
  • 언두 영역에서 조회를 원하는 트랜잭션의 이전 트랜잭션에서 변화를 준 데이터만 보여준다.
• PHANTOM READ
  • SERIALIZABLE 격리 수준을 사용하거나, REPEATABLE READ 격리 수준을 사용하는 InnoDB 스토리지 엔진을 이용한다.

 

 

😎 트랜잭션을 사용할 때 주의할 점

트랜잭션은 꼭 필요한 최소의 코드에만 적용하는 것이 좋다. 즉 트랜잭션의 범위를 최소화하라는 의미다.

일반적으로 데이터베이스 커넥션은 개수가 제한적이다. 그런데 각 단위 프로그램이 커넥션을 소유하는 시간이 길어진다면 사용 가능한 여유 커넥션의 개수는 줄어들게 된다.

그러다 어느 순간에는 각 단위 프로그램에서 커넥션을 가져가기 위해 기다려야 하는 상황이 발생할 수도 있는 것이다.

 

 

😎 교착 상태(Deadlock)의 빈도를 낮추는 방법

• 트랜잭션을 자주 커밋한다.
• 정해진 순서로 테이블에 접근한다.
• 읽기 잠금 획득 (SELECT ~ FOR UPDATE)의 사용을 피한다.
• 한 테이블의 복수 행을 복수의 연결에서 순서 없이 갱신하면 교착상태가 발생하기 쉽다, 이 경우에는 테이블 단위의 잠금을 획득해 갱신을 직렬화하면 동시성은 떨어지지만 교착상태를 회피할 수 있다.

 

😎 저장 프로시저(Stored PROCEDURE)

일련의 쿼리를 마치 하나의 함수처럼 실행하기 위한 쿼리의 집합

 

데이터베이스에서 SQL을 통해 작업을 하다 보면, 하나의 쿼리문으로 원하는 결과를 얻을 수 없을 때가 생긴다.

프로시저를 만들어두면, 애플리케이션에서 여러 상황에 따라 해당 쿼리문이 필요할 때 인자 값만 전달하여 쉽게 원하는 결과물을 받아낼 수 있다.

 

 

프로시저 생성 및 호출

CREATE OR REPLACE PROCEDURE 프로시저명(변수명1 IN 데이터타입, 변수명2 OUT 데이터타입) -- 인자 값은 필수 아님
IS
[
변수명1 데이터타입;
변수명2 데이터타입;
..
]
BEGIN
 필요한 기능; -- 인자값 활용 가능
END;

EXEC 프로시저명; -- 호출

 

예시

CREATE OR REPLACE PROCEDURE test( name OUT VARCHAR2 ) 
IS
BEGIN 
	name := 'Lea'
END;

DECLARE
out_name VARCHAR2(100);

BEGIN
test(out_name);
dbms_output.put_line('내 이름은 '||out_name);
END;

결과

내 이름은 Lea

 

▶ 프로시저 장점

• 최적화 & 캐시
  • 프로시저의 최초 실행 시 최적화 상태로 컴파일이 되며, 그 이후 프로시저 캐시에 저장된다.
  • 만약 해당 프로세스가 여러 번 사용될 때, 다시 컴파일 작업을 거치지 않고 캐시에서 가져오게 된다.
• 유지 보수
  • 작업이 변경될 때, 다른 작업은 건드리지 않고 프로시저 내부에서 수정만 하면 된다.
• 트래픽 감소
  • 클라이언트가 직접 SQL문을 작성하지 않고, 프로시저명에 매개변수만 담아 전달하면 된다. 즉, SQL문이 서버에 이미 저장되어 있기 때문에 클라이언트와 서버 간 네트워크 상 트래픽이 감소된다.
• 보안
  • 프로시저 내에서 참조 중인 테이블의 접근을 막을 수 있다.

 

▶ 프로시저 단점

• 호환성
  • 구문 규칙이 SQL / PSM 표준과의 호환성이 낮기 때문에 코드 자산으로의 재사용성이 나쁘다.
• 성능
  • 문자 또는 숫자 연산에서 프로그래밍 언어인 C나 Java보다 성능이 느리다.
• 디버깅
  • 에러가 발생했을 때, 어디서 잘못됐는지 디버깅하는 것이 힘들 수 있다.

 

 

😎 Redis

빠른 / 오픈 소스 /  인 메모리 / 키 값 데이터 구조 스토어

데이터 구조가 key/value 값으로 이루어져 있는

비정형 데이터를 저장하는 비관계형 데이터베이스 관리 시스템이다.

 

▶ 레디스 장점

1. 보통 데이터베이스는 하드 디스크나 SSD에 저장한다. 하지만 Redis는 메모리(RAM)에 저장해서 디스크 스캐닝이 필요 없어 매우 빠른 장점이 존재함

2. 캐싱도 가능해 실시간 채팅에 적합하며 세션 공유를 위해 세션 클러스터링에도 활용된다.

3. 다양한 자료구조 제공

1. String (text, binary data) - 512MB까지 저장이 가능함
2. set (String 집합)
3. sorted set (set을 정렬해 둔 상태)
4. Hash
5. List (양방향 연결리스트도 가능)

 

▶ 레디스 단점

RAM은 휘발성이라는 단점이 있지만 이를 막기 위한 백업 방법이 존재합니다. 

• snapshot : 특정 지점을 설정하고 디스크에 백업
• AOF(Append Only File) : 명령(쿼리)들을 저장해 두고, 서버가 셧다운 되면 재실행해서 다시 만들어 놓는 것

 

 

 

 

 

 

 

 

 

 

 

---

참고한 포스팅, 덕분에 데이터베이스 지식을 쌓고 갑니다, 감사합니다.💪

 

Elastic Search의 키워드 검색과 RDBMS의 LIKE 검색

https://youngkyonyou.github.io/interview/2021/12/13/Interview-Dangeun-01.html

 

Connection Pool

https://victorydntmd.tistory.com/42

 

트랜잭션 격리 수준

https://steady-coding.tistory.com/562

 

전반적으로 참고한 사이트 :

https://github.com/gyoogle/tech-interview-for-developer

https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/Database

https://dev-coco.tistory.com/158

https://mangkyu.tistory.com/93