• createdAt: 레코드(엔티티)가 처음 생성된 시각
• updatedAt: 레코드(엔티티)가 마지막으로 수정된 시각
• 관리 방식은 크게 2가지: 1) DB가 자동으로 채움/갱신 2) 애플리케이션(JPA/Hibernate)이 채움/갱신

2) 방식 A: DB에서 관리 (DEFAULT / ON UPDATE 등)

예시 코드

@Column(
  columnDefinition = "TIMESTAMP DEFAULT CURRENT_TIMESTAMP",
  insertable = false,
  updatable = false
)
private LocalDateTime createdAt;

@Column(
  columnDefinition = "TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP",
  insertable = false,
  updatable = false
)
private LocalDateTime updatedAt;

동작 방식

• INSERT/UPDATE 시점에 DB가 createdAt/updatedAt을 자동으로 세팅/갱신
• insertable=false, updatable=false로 인해 JPA는 해당 컬럼을 INSERT/UPDATE SQL에 포함하지 않음
• → 애플리케이션에서 값을 넣거나 변경할 수 없음*

장점

• 시간 기준이 DB 서버로 통일(멀티 앱 인스턴스에서도 일관성)
• 애플리케이션 실수로 시간값을 변경하기 어려움(강제력)

단점 / 주의사항

• DB 종속성이 큼
• ON UPDATE CURRENT_TIMESTAMP는 주로 MySQL 계열에 친화적
• PostgreSQL은 보통 트리거로 처리
• H2 등은 모드에 따라 동작이 달라질 수 있음
• 저장 직후 엔티티 객체의 createdAt/updatedAt이 즉시 채워지지 않을 수 있음
• DB가 채운 값을 엔티티에서 바로 쓰려면 flush() 후 refresh() 또는 재조회가 필요할 수 있음
• DB 자동 갱신은 “UPDATE가 실제로 발생”해야 반영됨(변경이 없으면 update가 안 나갈 수 있음)

3) 방식 B: 애플리케이션(JPA)에서 관리 (@PrePersist / @PreUpdate)

예시 코드

@Column(name = "created_at", nullable = false, updatable = false)
private LocalDateTime createdAt;

@Column(name = "updated_at", nullable = false)
private LocalDateTime updatedAt;

@PrePersist
protected void onCreate() {
  LocalDateTime now = LocalDateTime.now();
  this.createdAt = now;
  this.updatedAt = now;
}

@PreUpdate
protected void onUpdate() {
  this.updatedAt = LocalDateTime.now();
}

동작 방식

• 엔티티가 처음 저장되기 직전: @PrePersist 실행 → createdAt, updatedAt 세팅
• 엔티티가 수정되기 직전: @PreUpdate 실행 → updatedAt 갱신
• JPA Dirty Checking으로 “변경이 감지되어 UPDATE가 발생”할 때 @PreUpdate가 호출됨

장점

• DB 종류에 독립적(이식성 좋음): MySQL/PG/H2 등 대부분 동일하게 동작
• 저장 직후에도 엔티티에 값이 들어있어 응답/테스트가 편함
• nullable=false 등 제약을 코드로 명확히 표현 가능

단점 / 주의사항

• 시간 기준이 애플리케이션 서버 시간
• 멀티 서버 환경에서는 NTP 등으로 시간 동기화가 필요(보통 운영에서 해결)
• save()를 호출했다고 항상 @PreUpdate가 실행되는 것은 아님
• 실제로 값 변경이 없으면 UPDATE가 발생하지 않아 콜백도 실행되지 않을 수 있음

NTP란?

• NTP는 Network Time Protocol의 약자이며, 서버/컴퓨터들이 현재 시간을 정확하게 동기화하도록 해주는 표준 프로토콜이다.

• 여러 서버의 “시계”를 같은 시간으로 맞춰주는 동기화 시스템

  왜 필요할까?

• 서버가 여러 대인 환경에서는 각 서버의 시스템 시간이 조금씩 어긋날 수 있다.
• 이런 상태에서 LocalDateTime.now()로 createdAt/updatedAt을 찍으면:
  • 서버 A와 서버 B의 시간이 달라 시간 순서가 뒤바뀌거나
  • 로그/정렬/감사 기록이 일관되지 않게 될 수 있다.

    NTP가 해주는 일

• NTP 서버(시간 기준 서버)와 주기적으로 통신해 각 서버의 시간을 동일한 기준(보통 UTC)으로 맞춘다.

  실무에서는 보통 어떻게 쓰나?

• OS 수준에서 자동으로 동기화가 설정되어 있는 경우가 많다.
  • Linux: chrony 또는 ntpd
  • 클라우드(AWS/GCP/Azure)도 기본적인 시간 동기화 체계를 제공하는 편

1. HTTP란?

• 정의: 웹 브라우저(클라이언트)와 웹 서버 간에 데이터를 주고받기 위한 응용 계층(Application Layer) 프로토콜입니다.
• 특징: 주로 TCP/IP 위에서 동작하며, 기본 포트는 80번을 사용합니다.

2. 핵심 특징 (면접 단골 질문 ⭐)

① 비연결성 (Connectionless)

• 클라이언트가 요청을 보내고 서버가 응답을 마치면 즉시 연결을 끊는 방식입니다.
• 장점: 서버 자원을 효율적으로 관리할 수 있습니다.
• 단점: 매 요청마다 새로운 연결을 맺는 오버헤드가 발생합니다. (HTTP/1.1부터 Keep-Alive로 보완)

② 무상태 (Stateless)

• 서버가 클라이언트의 이전 상태를 기억하지 않습니다.
• 장점: 서버의 확장성이 높습니다 (어느 서버가 응답해도 상관없음).
• 단점: 로그인을 유지하기 위해 쿠키(Cookie), 세션(Session), 토큰(JWT) 같은 추가 메커니즘이 필요합니다.

3. HTTP 메시지 구조

[Image of HTTP request and response message structure]

1. 시작줄 (Start Line / Status Line)
   • 요청: 메소드 URL 버전 (예: GET /index.html HTTP/1.1)
   • 응답: 버전 상태코드 상태문구 (예: HTTP/1.1 200 OK)
2. 헤더 (Header): 메시지 전송에 필요한 부가 정보 (Host, User-Agent, Content-Type 등)
3. 본문 (Body): 실제 전송할 데이터 (HTML, JSON, 이미지 등)

4. HTTP 주요 메소드

5. 필수 응답 상태 코드 (Status Code)

• 2xx (Success): 성공. 200(OK), 201(Created)
• 3xx (Redirection): 요청 완료를 위해 추가 동작 필요. 301(영구 이동), 302(임시 이동)
• 4xx (Client Error): 클라이언트 요청 오류. 400(Bad Request), 401(미인증), 404(Not Found)
• 5xx (Server Error): 서버 처리 오류. 500(Internal Server Error), 503(서비스 이용 불가)

6. HTTP의 발전 요약

• HTTP/1.1: 커넥션 재사용(Keep-Alive) 도입.
• HTTP/2.0: 멀티플렉싱을 통한 속도 개선.
• HTTP/3.0: UDP(QUIC) 기반으로 지연 시간 최소

• 함수형 컴포넌트 vs 클래스형 컴포넌트
  • 함수형: function MyComp() { … } 또는 const MyComp = () => { … }
  • 클래스형: class MyComp extends React.Component { render() { … } } (현재는 거의 사용하지 않음)
• 컴포넌트는 재사용 가능한 UI 조각
• 부모–자식 관계로 컴포넌트를 조립하여 최종 UI를 구성

2. JSX 문법 심화

• 한 번에 하나의 최상위 태그로 감싸기 (<div> 또는 <></>)
• JavaScript 표현식은 {} 안에 작성
• 일부 속성 이름 변경:
  • class → className
  • for → htmlFor
• Self-Closing 태그: <input />, <img /> 등 반드시 닫기
• 조건부 렌더링:
  • 삼항 연산자: {cond ? <A /> : <B />}
  • && 연산자: {cond && <A />}
• 리스트 렌더링:

    {items.map(item => <li key={item.id}>{item.name}</li>)}

3. Props

• 부모 → 자식으로 데이터(속성) 전달

• 컴포넌트 함수의 매개변수(props)로 받음

• 구조 분해 할당으로 간결화:

  function Profile({ name, age }) { … }

• 전개 연산자를 이용해 객체를 한 번에 넘길 수도 있음:

  <Profile {...person} />

• defaultProps 로 기본값 설정

4. State

✅ State란?

• 컴포넌트 내부에서 관리되는 동적인 데이터
  == 컴포넌트 내부에서 관리하는 “변할 수 있는 값”
• 시간이 지남에 따라 바뀔 수 있는 값 (ex. 버튼 클릭 수, 입력 값, 토글 상태 등)
• 컴포넌트가 리렌더링되는 이유가 되는 핵심 데이터

🛠️ 사용법: useState 훅

import { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0); // 초기값 0

  return (
    <div>
      <p>현재 카운트: {count}</p>
      <button onClick={() => setCount(count + 1)}>+1</button>
    </div>
  );
}

• useState(초기값) 호출 시 → [값, 설정함수] 배열 반환

• setCount(newValue) 를 호출하면:

  1. React가 내부 state 값을 변경
  2. 변경된 값을 기반으로 컴포넌트를 자동 리렌더링

🧠 state의 메모리 구조

• useState는 React 내부의 Hooks 메모리 저장소에 상태값을 저장
• 이 저장소는 브라우저의 메모리(RAM) 위에 위치하며, 가상 DOM과 함께 관리됨
• setState를 사용하지 않고 변수만 바꾸면 리렌더링되지 않음 → React는 setState 호출을 기준으로 변경을 감지

🔁 재렌더링 vs 초기화

• 컴포넌트가 리렌더링될 때도 useState의 값은 유지됨
• useState(초기값)의 초기값은 처음 마운트 시 딱 한 번만 사용됨
• 상태는 브라우저가 꺼지거나 새로고침되기 전까지 유지됨

⚠️ 상태 변경은 비동기일 수 있음

setCount(count + 1);
setCount(count + 1);

이렇게 두 번 호출해도 값이 1씩 증가하지 않음.

setCount(prev => prev + 1);
setCount(prev => prev + 1); // 이러면 2 증가

📌 주의할 점 정리

💡 상태가 필요한 경우 예시

• 버튼 클릭 수
• 입력 폼 제어값
• 모달 열림/닫힘 상태
• 탭 선택 상태
• API 데이터 로딩 상태

5. State 저장 및 렌더링 흐름

1. 마운트 시 useState(initial)의 initial은 한 번만 사용
2. 이후 렌더링에서는 React가 내부 메모리에 저장한 값을 꺼내 사용
3. 상태 변경 → React가 가상 DOM(diff) 비교 → 변경된 부분만 실제 DOM에 반영
4. 상태는 브라우저 새로고침 전까지 유지됨

6. 브라우저 · React · 메모리 관계

• 노트북 물리적 RAM: OS와 모든 앱이 공유
• 브라우저 RAM: 브라우저 프로세스(탭)별로 JS 실행, DOM/CSS/가상 DOM, React state 저장
• React state는 브라우저 프로세스의 메모리(물리적 RAM 할당 영역)에 저장
• 브라우저가 React 컴포넌트를 실행·관리하며, 화면은 실제 DOM을 통해 렌더링

7. 주요 키워드

• 함수형 컴포넌트, 클래스형 컴포넌트
• JSX, Fragment, 표현식 {}, self-closing
• Props, 구조분해, 전개 연산자, defaultProps
• State, useState, setState, 리렌더링
• 가상 DOM(diff), 실제 DOM 업데이트
• 브라우저 RAM vs 물리적 RAM

MySQL에서 대량의 텍스트 데이터를 빠르게 검색하려면 FULLTEXT INDEX가 효과적입니다. 이 글에서는 Fulltext 인덱스의 개념, 사용법, 검색 모드, Boolean 연산자 등을 예시와 함께 정리합니다.

🔍 Fulltext Index란?

FULLTEXT INDEX는 문자열 컬럼에 대한 자연어 기반 검색을 빠르게 수행할 수 있도록 지원하는 전용 인덱스입니다.

• 적용 가능한 컬럼: CHAR, VARCHAR, TEXT
• 지원 엔진: InnoDB, MyISAM
• MySQL 5.6+부터 InnoDB에서도 사용 가능

🛠️ 생성 방법

-- 테이블 생성 시
CREATE TABLE articles (
  id INT PRIMARY KEY,
  title VARCHAR(100),
  body TEXT,
  FULLTEXT(title, body)
);

-- 기존 테이블에 추가
ALTER TABLE articles ADD FULLTEXT(title, body);

🔍 기본 사용법

SELECT * FROM articles
WHERE MATCH(title, body) AGAINST('database');

• MATCH(...): 검색 대상 컬럼 지정
• AGAINST('검색어'): 찾을 문자열 지정

⚙️ 검색 모드

AGAINST('검색어' IN NATURAL LANGUAGE MODE);
AGAINST('검색어' IN BOOLEAN MODE);
AGAINST('검색어' WITH QUERY EXPANSION);

✅ BOOLEAN MODE 연산자 정리

💡 예제

SELECT * FROM articles
WHERE MATCH(title, body)
AGAINST('+database -"oracle cloud"' IN BOOLEAN MODE);

• database는 반드시 포함
• "oracle cloud"는 제외
• 정교한 검색이 가능해짐

🚧 주의사항

• 단어 길이가 3자 이하이거나 **불용어(stopwords)**는 검색되지 않을 수 있음
• *는 접두사만 지원 (뒤에만 붙일 수 있음)
• 관련성 점수는 MATCH ... AGAINST에만 적용 가능

📚 마무리

FULLTEXT INDEX는 대량의 텍스트 데이터에서 빠르고 정교한 검색이 필요한 서비스(예: 게시판, 문서 검색)에 매우 유용합니다. 특히 BOOLEAN MODE의 조합을 이해하고 잘 활용하면, SQL에서 강력한 검색 기능을 구현할 수 있습니다.

궁금한 점이나 실습 예제가 필요하다면 댓글로 알려주세요 😊 Happy Querying!

필요하시면 이 글에 추가로 실습 예제나 이미지도 만들어드릴 수 있어요. JSON 검색과의 연계도 가능하니 원하시면 알려주세요!

⚙️ InnoDB Fulltext Index 튜닝 및 내부 정보 조회

MySQL의 InnoDB 스토리지 엔진에서 Fulltext 인덱스를 보다 정밀하게 제어하거나 디버깅하려면 아래와 같은 시스템 변수 및 정보 스키마 테이블을 활용할 수 있습니다.

🔧 innodb_ft_aux_table 설정

SET GLOBAL innodb_ft_aux_table = 'testdb/Notice';

• InnoDB의 Fulltext 인덱스를 분석하거나 조사할 때 사용하는 보조 테이블 설정입니다.
• 'DB명/테이블명' 형식으로 지정해야 합니다.
• 단일 테이블만 지정 가능 (복수 설정은 불가능)

이 설정을 통해 다음과 같은 테이블들을 조회할 수 있게 됩니다:

SELECT * FROM information_schema.innodb_ft_index_table;
SELECT * FROM information_schema.innodb_ft_index_cache;

📦 Fulltext Index 테이블 정보 조회

SHOW VARIABLES LIKE 'innodb_ft_aux%';

SELECT * FROM information_schema.innodb_ft_index_table;

이 명령어들을 통해 현재 Fulltext 인덱스에 등록된 단어, 문서 ID, 내부 구조 등을 확인할 수 있습니다.

🧹 Fulltext Index 최적화 (Rebuild)

Fulltext 인덱스를 정리하거나 재구성하려면 다음과 같은 절차를 따릅니다:

-- 1. 최적화 모드 활성화
SET GLOBAL innodb_optimize_fulltext_only = ON;

-- 2. 인덱스 최적화 실행
OPTIMIZE TABLE testdb.Notice;

-- 3. 모드 비활성화
SET GLOBAL innodb_optimize_fulltext_only = OFF;

• OPTIMIZE TABLE 실행 시 innodb_optimize_fulltext_only가 ON이면 Fulltext 인덱스만 최적화합니다.
• 삭제된 단어, 중복된 토큰 등을 제거하여 인덱스 크기 감소 및 성능 향상에 도움됩니다.

📝 요약

이러한 고급 기능들은 검색 품질 개선, 성능 디버깅, 인덱스 재정비에 매우 유용합니다. 대규모 게시판이나 문서 검색 시스템에서는 정기적인 점검 루틴에 포함시키는 것도 좋은 전략입니다.

필요하다면 위 기능들을 포함한 Fulltext Index 점검 스크립트도 만들어드릴 수 있습니다. 원하시나요?

1. ✅ WITH CTE (Common Table Expression)

🔍 개념

CTE는 서브쿼리를 재사용 가능하고 가독성 좋게 만든 문법입니다. 복잡한 쿼리를 계층적으로 구성할 수 있습니다.

🛠 사용법

WITH cte_name AS (
    SELECT ...
)
SELECT ...
FROM cte_name;

📌 예시

WITH HighSalaryEmp AS (
    SELECT *
    FROM Emp
    WHERE salary > 3000
)
SELECT ename, dept
FROM HighSalaryEmp;

2. 🔁 윈도우 함수 (Window Functions)

🔍 개념

윈도우 함수는 집계함수처럼 동작하지만 그룹핑하지 않고도 각 행에 대해 누적합, 순위 등을 계산할 수 있습니다.

🛠 사용법

SELECT ename, salary,
       SUM(salary) OVER (PARTITION BY dept) AS dept_total
FROM Emp;

📌 자주 쓰는 함수

• ROW_NUMBER() : 전체 결과에서 파티션 기준 출력되는 행 번호(순번)
• RANK() : 값의 랭킹(순위), 공동 랭킹은 동일값을 보이며 다음 랭킹은 공동 랭킹을 건너뛰어 표시
• DENSE_RANK() : RANK() 함수와 동일한 기능이지만 공동 랭킹을 건너뛰지 않는다.
• SUM() OVER(...)
• AVG() OVER(...)
• LAG(n) : 현재 행 기준 앞(이전) n 번째 값
• LEAD(n) : 현재 행 기준 뒤(다음) n 번째 값

📌 예시

SELECT ename, dept, salary,
       RANK() OVER (PARTITION BY dept ORDER BY salary DESC) AS dept_rank
FROM Emp;

3. 📈 GROUP BY WITH ROLLUP

🔍 개념

ROLLUP은 그룹핑된 컬럼을 기반으로 소계, 총계를 자동 계산합니다.

🛠 사용법

SELECT dept, job, SUM(salary)
FROM Emp
GROUP BY dept, job WITH ROLLUP;

📌 예시

SELECT p.id pid, d.id did, 
       (CASE WHEN p.id IS NOT NULL THEN MAX(p.dname) ELSE '--총계--' END) AS '상위부서',
       (CASE WHEN d.id IS NOT NULL THEN MAX(d.dname) ELSE '--소계--' END) AS '하위부서',
       FORMAT(SUM(e.salary), 0) AS '급여합'
FROM Dept p
INNER JOIN Dept d ON p.id = d.pid
INNER JOIN Emp e ON e.dept = d.id
GROUP BY p.id, d.id
WITH ROLLUP;

4. 🔄 PIVOT

🔍 개념

행 → 열로 전환해 집계 데이터를 보기 좋게 가공하는 방식입니다. MySQL에는 직접적인 PIVOT 구문은 없지만, CASE WHEN + GROUP BY로 구현합니다.

🛠 사용법

SELECT dept,
       SUM(CASE WHEN job = 'Manager' THEN salary ELSE 0 END) AS Manager,
       SUM(CASE WHEN job = 'Clerk' THEN salary ELSE 0 END) AS Clerk,
       SUM(CASE WHEN job = 'Sales' THEN salary ELSE 0 END) AS Sales
FROM Emp
GROUP BY dept;

🧠 정리 요약

결과 집합(Result Set)을 한 행(row)씩 순차적으로 처리할 수 있게 해주는 도구

• SELECT 결과로 여러 행이 나왔을 때, 이를 하나씩 꺼내어 반복 처리할 수 있도록 하는 반복 포인터라 생각하면 쉽다.

✅ Cursor를 사용하는 이유

일반적으로 SQL은 한 번에 여러 행을 처리하지만 어떤 작업은 "하나씩" 처리해야 할 때가 있다.

Cursor 대표 예시

• 학생 테이블에서 학생들 하나씩 불러와서, 각각의 학점 계산 결과를 다른 테이블에 기록할 때

  
  

• 여러 명에게 개별 알림 메시지를 보낼 때

  
  

• 어떤 조건에 따라 하나씩 다른 UPDATE를 해야 할 때

✅ 커서의 기본 흐름 (4단계)

1. DECLARE CURSOR

   • 사용할 커서를 선언합니다. 어떤 SELECT 결과를 순회할 것인지 지정합니다.

2. OPEN CURSOR

   • 커서를 열어 결과 집합을 준비합니다.

3. FETCH

   • 한 줄씩 데이터를 가져옵니다. 반복문(WHILE 등)과 함께 자주 사용합니다.

4. CLOSE CURSOR

   • 커서를 닫습니다. 메모리 누수를 막기 위해 꼭 해야 합니다.

❗주의 사항

• Cursor는 성능이 느릴 수 있다.

  • 수천, 수만 건 이상 순회하면 오히려 SQL 자체의 집합 처리 방식이 더 빠르다.

    
    

    • 커서는 트랜잭션 안에서 사용되며, 에러나 종료 시 반드시 닫아야 한다.

      
      

    • 커서는 Stored Procedure 안에서만 사용 가능하다.

  
  
  

🔚 언제 사용하나?

• 개별 행을 조건에 따라 다른 로직으로 처리할 때

• SQL로는 한 번에 처리할 수 없는 절차적 로직이 필요할 때

• 루프가 필요한 반복 작업을 데이터에 대해 수행해야 할 때

MySQL에서 Routine은 저장 프로시저(Stored Procedure)와 함수(Function)를 포함하는 프로그램 코드를 말한다. --> MySQL에서 반복적으로 사용되는 쿼리나 작업을 반복 실행할 수 있도록 미리 정의해 놓은 코드

Routine을 사용하는 이유

1. 재사용성: 한 번 정의한 프로시저나 함수를 여러 번 호출하여 사용할 수 있습니다.

2. 효율성: 복잡한 작업을 서버 측에서 처리하므로 클라이언트에서 매번 실행할 필요가 없습니다.

3. 보안성: 중요한 로직을 데이터베이스 내부에 숨길 수 있으며, 사용자에게 필요한 권한만 부여할 수 있습니다.

4. 구성 관리: 여러 SQL 명령을 그룹화하여 관리할 수 있습니다.

Stored Procedure

MySQL 서버에 저장된 SQL 코드로, 특정 작업을 수행하는 데 필요한 여러 SQL 문을 그룹화하여 하나의 이름으로 실행할 수 있도록 만든 프로그램 일반적으로 반복적인 작업이나 복잡한 로직을 처리할 때 사용한다.

DELIMITER $$

CREATE PROCEDURE GetEmployeeDetails(IN emp_id INT)
BEGIN
    SELECT name, department, salary
    FROM employees
    WHERE id = emp_id;
END $$

DELIMITER ;

DELIMITER $$

• 원래는 종료를 나타내는 문자로 ;를 사용하지만, DELIMITER를 선언하면 뒤에 나오는 문자를 종료를 나타내는 문자로 사용하겠다는 의미이다.
  
  

  CREATE PROCEDURE GetEmployeeDetails(IN emp_id INT)

• input으로 Int 타입의 emp_id를 받는다.
  
  

  Stored Procedure 실행하는 법

  CALL GetEmployeeDetails(101);

Function

MySQL에서 함수는 특정 작업을 수행하고 결과를 반환하는 코드 함수는 보통 데이터를 처리하거나 계산한 후, 그 결과를 반환하는 데 사용된다. 함수는 SELECT 문 안에서 호출할 수 있다.

DELIMITER $$

CREATE FUNCTION GetEmployeeSalary(emp_id INT) RETURNS DECIMAL(10, 2)
BEGIN
    DECLARE salary DECIMAL(10, 2);

    SELECT salary INTO salary
    FROM employees
    WHERE id = emp_id;

    RETURN salary;
END $$

DELIMITER ;

CREATE FUNCTION GetEmployeeSalary(emp_id INT) RETURNS DECIMAL(10, 2)

-> input으로 Int 타입의 emp_id를 받고, 전체 자릿수를 10자리로 하되, 그 중 소수점 이하를 2자리로 하는 값을 리턴한다.

❗️Stored Procedure 와 Function 의 차이

🔍 최종정리

절차적인 작업, 데이터 조작, 복잡한 흐름 → Stored Procedure 계산, 값 반환, SELECT문 안에서 사용 → Function

참고

• Mysql Routine

Index 는 원하는 데이터를 빠르게 찾기 위한 도구이다.

• 데이터 조회를 빠르게 하기 위해 사용된다.
• 데이터 INSERT, UPDATE, DELETE 쿼리 사용 시, 오히려 느려진다.
• SQL Server에서 Heap은 다음과 같은 의미를 가진다. :Heap = 클러스터형 인덱스(Clustered Index)가 없는 테이블의 데이터 저장 구조
  
  

Index에 사용하는 자료구조

B-Tree

정렬된 데이터를 효율적으로 저장하고 검색할 수 있도록 설계된 트리 구조 특징

• 일반적으로 데이터베이스 인덱스 OR 파일 시스템에서 사용된다.
• 조회, 삽입, 삭제 연산 -> (O(log n))
• MySQL(InnoDB)에서 사용하는 인덱스 --> B+Tree

Hash

key를 Hash 함수에 넣어 나온 Hash value를 이용하여 배열 인덱스에 데이터를 저장한다. 특징

• 조회, 삽입, 삭제 연산 -> O(1)
• HashMap, Python의 dict, MySQL MEMORY 엔진의 Hash Index

B-Tree를 Index에 사용하는 이유

B-Tree

• 컬럼의 값을 변형하지 않고, 원래의 값을 이용하여 인덱싱한다.

  Hash

• 컬럼의 값으로 해시 값을 계산해서 인덱싱하여 값을 변형하게 된다.
• 특정 문자로 시작하는 값으로 검색을 하는 등 전방 일치와 같이 값의 일부만으로 검색하고자 할 때, Hash index를 사용할 수 없다. (ex - LIKE, IN)

==> SELECT 절의 조건에 부등호 연산(>, <)이 포함될 경우 문제가 발생한다. HashTable은 동등 연산(=)에 특화되어있어 데이터베이스의 자료구조에 적합하지 않다.

Index 종류

Unique key

특징

• 값 중복을 허용하지 않는다.

• primary key와 다르게, null 값을 허용한다.

• primary key와 다르게, 테이블에서 한 개만 생성 가능하다.

• 2개 이상의 컬럼을 Unique index로 생성할 시, 앞 선 컬럼이 항상 더 중복성이 낮은(카디널러티가 높은)것으로 골라야 성능이 좋다.
  
  

  Clustered Index

  Def : 데이터베이스의 테이블의 레코드 순서를 Index의 키 값 순서대로 정렬하는 것을 의미한다. ex ) Primary key (InnoDB 스토리지 엔진 기준)

  특징

  • 한 테이블 당 하나만 존재해야 한다.
  • 가장 빠르게 처리한다.
  • 조회는 빠르나 삽입 시 재정렬이 필요해 성능이 떨어질 수 있다. -> 재정렬이 일어나지 않고 순차적으로 쌓이는 컬럼에 설정해야 한다. (ex - id)
    
    

    Non-Clustered Index

    Def : 테이블에 저장된 물리적 순서에 따라 데이터를 정렬하지 않는다.

  특징

  • leaf node에는 데이터 페이지에 대한 포인터가 있어 이를 통해 데이터 페이지를 조회할 수 있는 형태
  • 한 테이블에 여러 인덱스를 생성할 수 있다.
  • 데이터 조회 시, leaf level에서 data 페이지에 접근하는 추가적인 step이 필요하기 때문에, clustered index 보다는 속도가 느리다.
  • 데이터 입력 시, 약 10% 정도의 별도 공간에 인덱스를 생성해야 하기 때문에 추가 작업이 요구된다.

Bitmap Index

Def : 인덱스 컬럼의 데이터를 Bit 값인 0 또는 1로 변환하여 Index key로 사용하는 방법

특징

• 키 값을 포함하는 행의 주소를 제공한다는 목적을 제공한다.
• B-Tree 인덱스와 달리, 카디널리티(: 중복된 수치)가 낮은 경우(중복된 경우가 많은 경우)에 사용하기 좋다. ex) 성별 테이블...?(이런 테이블을 만들 일이 있나...)
• 효율적인 논리 연산이 가능하고 저장공간이 작다.
• 동일한 값이 반복되는 경우가 많기에 압출 효율이 좋다.

Secondary key

Def : 클러스터드 인덱스와 별개로 따로 만든 인덱스 = 필요한 컬럼만 저장 + Primary Key 값을 같이 저장

특징

• Primary key와 항상 같이 다녀야 한다.
• 인덱스에 테이블 일부 정보만 있다.
• 인덱스를 보고 테이블로 다시 찾아가야 한다.
• 읽는 I/O 수가 많다.
• 쿼리속도가 Clustered Index에 비해 느리다.

  CREATE TABLE employees (
      emp_id INT PRIMARY KEY,
      name VARCHAR(100),
      department_id INT,
      hire_date DATE,
      INDEX idx_name (name)
  );

```

• emp_id는 Primary Key → Clustered Index
• name은 Secondary Index (보조 인덱스)

그 외 : Fulltext Index, Composite Index

참조

Index Bitmap Index Index 종류

코드 평가 시 선언문을 해당 스코프의 상단으로 끌어 올려 메모리 선점/생성 ** **목적: 각 식별자의 메모리 위치를 미리 잡아 stack 영역 세팅 ⇒ 실행이 빠름!

함수 Hoisting

함수 선언 전에 함수 실행 코드가 있어도 정상적으로 작동한다.

test(); // "Hosting" -> 정상 실행
>
function test() {
  document.writeln("Hoisting");
}
>
test(); // "Hoisting"

변수 Hoisting

변수 호이스팅할 때는

• 선언 O
• 초기화 O
• 할당 X

var 변수 호이스팅

: 선언 전에 호출 시 undefined로 접근한다.

console.log(name); // undefined
var name = "Hong GilDong";
console.log(name); // Hong GilDong

const, let 변수 호이스팅

: 선언 전에 호출 시 Error 발생

console.log(name1); // ReferenceError
const name1 = "Hong GilDong";
console.log(name1); // Hong GilDong
>
console.log(name2); // ReferenceError
let name2 = "Hong GilDong";
console.log(name2); // Hong GilDong

TDZ(Temporal Dead Zone)

JS에만 있는 변수가 선언되기 전 코드 영역 - 임시사각지대

• 변수가 선언되었지만 아직 초기화 되지 않는 상태 == '선언만 되고 아직 초기화 되지 않는 변수가 머무는 공간'

참고

• https://ccomccomhan.tistory.com/288
• https://ccomccomhan.tistory.com/290
• https://velog.io/@saemileee/Javascript-%ED%98%B8%EC%9D%B4%EC%8A%A4%ED%8C%85-%ED%81%B4%EB%A1%9C%EC%A0%B8

값이 Stack에 들어간다.

• 메모리의 값은 변경이 안되고, 값이 변경되면 새로운 메모리가 할당됨!

• 숫자(number), 문자열/문자열템플릿, boolean, null, undefined, Symbol

✅ Object Type (Reference)

• Array, Date, RegExp, Map/WeakMap, Set/WeakSet

✚ Constant pool

🔹 Constant Pool이란?

: Constant Pool(상수 풀) 은 자바 클래스 파일(.class 파일) 내에 포함된 리터럴 상수값과 심볼 참조(Symbolic References) 를 저장하는 테이블

• 즉, 자바 컴파일러가 .java 파일을 .class 파일로 변환할 때, 프로그램에서 사용하는 문자열, 정수, 클래스 및 메서드 참조 등을 이 테이블에 저장한다.
• String.intern() 메서드는 문자열을 명시적으로 Constant Pool에 등록하고, 동일한 문자열이 이미 존재한다면 그 참조를 반환합니다.
  • Constant Pool은 메모리 절약에 유리하지만, 크기가 제한되어 있어서 너무 많은 상수를 선언하면 java.lang.ClassFormatError: constant pool full 예외가 발생할 수 있습니다.

🔸 종류별 Constant Pool

1. 클래스 파일의 Constant Pool

.class 파일 내부에는 constant_pool이라는 테이블이 있으며, 여기에 다음과 같은 정보가 저장됩니다.

• 문자열 리터럴 ("hello") / 숫자 리터럴 (10, 3.14) / 클래스/인터페이스 이름/ 필드/메서드 이름 및 타입 정보 / 메서드 참조 (Methodref)/ 필드 참조 (Fieldref) 등 👉 이건 JVM이 클래스를 로드할 때 참고하는 정보입니다.

2. 런타임 Constant Pool

클래스가 JVM에 로드되면 .class 파일의 Constant Pool은 Runtime Constant Pool로 변환되어 메모리에 올라갑니다.

• String literal은 이 런타임 상수 풀에 저장되며, 중복을 방지하고 메모리 효율성을 높이기 위해 사용됩니다.

    String a = "hello";
    String b = "hello";
    System.out.println(a == b); // true

  → "hello"라는 문자열은 Constant Pool에 한 번만 저장되므로, a와 b는 같은 객체를 참조합니다.

Contant Pool VS String Constant Pool

예제

    public class Main {
      public static void main(String[] args) {
          String a = "hello";
          String b = "hello";
          String c = new String("hello");
          String d = c.intern();
>
          System.out.println(a == b); // true (둘 다 String Constant Pool에서 공유)
          System.out.println(a == c); // false (c는 Heap에 새로 생성된 객체)
          System.out.println(a == d); // true (c를 intern해서 풀에서 찾아씀)
      }
}

Git 작업영역

Working Directory : 이력 관리 대상(tracked) 파일들이 위치하는 영역

✓ 지정된 디렉토리에서 .git 폴더를 제외한 공간 ✓ 작업된 파일이나 코드가 저장되는 공간 ✓ add 전 상태

Staging Area : 이력을 기록할, 다시 말해 commit할 대상 파일들이 위치하는 영역

✓ .git 폴더 하위에 파일형태로 존재(index) ✓ add 후 상태

Repository : 이력이 기록된(committed) 파일들이 위치하는 영역

✓ .git 폴더에 이력관리를 위한 모든 정보가 저장, 관리됨 ✓ commit 후 상태

명령어 정리

git checkout

• git checkout <브랜치 명> == git switch : 해당 브랜치로 작업영역 바뀐다.

• ex) git checkout develop -> develop 브랜치로 작업영역 변경

  
  

  • git checkout <'commit id'> : 해당 커밋내역으로 작업영역 바뀐다.

• ex) git checkout 81c183r -> commit id가 81c183r인 작업영역으로 바뀐다.

  • 해당 커밋에서 새로운 작업을 하고, 그 작업영역 그대로 새로운 브랜치로 만들고 싶다면 git branch "새로 만들 브랜치명" "commit id"

    
    

  • git checkout - : 최신 커밋으로 파일을 되돌린다.
  
  

HEAD

: 현재 작업하는 브랜치의 최종 커밋을 가리키는 포인터

git commit

• git commit -m"커밋 메세지"
  

• git commit -am"커밋 메세지" : git add + git commit -m

  
  

• git commit --amend : 커밋 수정하기 ▪ 커밋 메시지를 수정하려면 ‘-m’ 옵션 사용 ▪ 저자 정보 등을 수정하려면 ‘--author’ 옵션 사용 ▪ 커밋 메시지를 수정하지 않으려면 ‘--no-edit’ 옵션 사용

  
  

git restore

• git restore : 작업 디렉토리에서 변경된 파일을 되돌리는 데 사용 → 마지막 커밋 상태로 복원
  

• git restore --staged ▪ staging area(스테이징 영역)에서 파일을 복원하는 데 사용 ▪ 목적: 스테이징된 파일을 언스테이징하여 다시 커밋되지 않도록 설정 ▪ 동작: 파일을 스테이징 영역에서만 복원하고, 작업 디렉토리의 내용은 그대로 유지

  
  

  git rm

  • git rm --cache : 스테이징 영역에서 파일을 제거할 때 사용

  • working directory에서 파일이 삭제되지 않는다.
    
  • git rm : staging area + working directory 둘다 삭제
    
  • 만약 실수로 git rm --cached가 아닌 git rm을 사용하여 파일이 삭제되었다면?

    git restore --staged ttt.txt
    git restore ttt.txt

branch

• git branch "브랜치 명" : 브랜치 만들기

• (main) -> git branch develop -> main에서 develop이라는 브랜치명을 가진 브랜치 만들기
  - git branch -d "브랜치 명" : 브랜치 삭제하기
  - git push -d origin "원격 브랜치 명" : github에 있는 원격브랜치 삭제

stash

• git stash

• 작업하던 중 아직 add하지 않은 상황에서, 다른 것을 먼저 처리하거나 다른 브랜치로 이동할 때, 지금까지 작업하던 것을 임시저장 -> stack 형식
  - git stash save "label 명" : 헷갈리지 않게 라벨을 지정해서 임시저장할 수 있음
  - git stash pop : 임시저장해 놓은 작업물 다시 working directory에 가져오기 - 가장 나중에 저장한 것 먼저 나온다 -> STACK(FILO)
  - git stash apply "stash 번호"
• Ex) git stash pop stash@{2} -> 3번째(index가 2)로 저장한 임시저장본 가져오기
  - git stash list : stash 목록 가져오기
  - git stash drop : 임시저장 본 삭제
• stash pop 같은 경우, 적용하고 바로 해당 stash가 사라지지만, stash apply 같은 경우, 적용만 하고 사라지지 않는다.
  - git stash branch : 현재 작업중인 내역으로 새로운 브랜치 생성

clean

• git clean : untracked 파일 삭제
  

• git clean -n : 삭제할 목록만 확인, 실제로 삭제 X
  • .gitignore에 정의된 파일은 대상이 아님
    
• git clean -d : ignore file외 untracked 파일 삭제(하위폴더포함)
  • git clean -di : 안전하게 interactive하게!
  • git clean -df : 강제로 삭제
    
• git clean -x : ignore file 포함 모든 untracked 삭제
  • git clean -xi : 안전하게 interactive하게!
    • git clean -xf : 강제로 삭제
      
• git clean -X : only ignore file만 삭제

merge

• merge에는 총 3가지 방식이 있다.

1. Merge 1.1 Fast-Forward merge 1.2. 3-Way merge
2. Rebase
3. Squash
   #### 1.1 Fast-Forward merge - 시간의 흐름대로 커밋된 내역을 병합 - 충돌(conflict) 발생 없고 100% Auto-merge - merge 후 모든 commit이 복제  >
   #### 1.2 3-Way merge

• 두 개 이상의 브랜치로 파생된 커밋을 병합
  • 충돌(conflict) 가능성 있음
  • 병합 메시지(merge commit) 존재
    
    #### 2. Rebase
  • 공통조상(base) 병합
  • 3-Way ⇒ Fast-Forward 화
    
    #### Squash
• 많은 커밋의 양이 생기는데 여러 개의 커밋을 하나로 합치는 기능을 말한다.

입력

출력

문제풀이

• 처음에는 노드가 서로 순환하고 있는 것(원 모양)을 찾는 문제인 줄 알고, 방문노드(visited)에 들어 있는 노드는 건너뛰고, 없는 노드는 넣어서 지금 방문하고 있는 노드가 처음 방문한 노드와 일치하는지 확인하는 방식으로 접근하려고 했다.
• 깊이가 4인 그래프를 찾으라는 문제라는 것을 깨닫고 다음과 같은 방식으로 코드를 구현했다.
  
  
  

첫번째 코드 -> 시간초과

# ABCDE
import sys
input = sys.stdin.readline
>
n, m = map(int, input().split())
relations = [[] for _ in range(n)]
answer = False
>
for i in range(m):
    x, y = map(int, input().split())
>    
    relations[x].append(y)
    relations[y].append(x)
>
def dfs(now, cnt):
    global answer
>   
    if cnt == 4:
        answer = True
        return
>    
    visited.append(now)
    for i in relations[now]: 
        if i not in visited:
            dfs(i, cnt + 1)
>
for i in range(n):
    visited = []
    dfs(i,0)
>    
if answer:
    print(1)
else:
    print(0)

시간초과 이유

• 성공한 코드와 비교했을 때, visited를 넣기만 하고 pop을 해주지 않아서 시간초과가 뜬 것 같다.

for i in relations[now]: 
        if i not in visited:
            dfs(i, cnt + 1)

visited를 pop을 해 주지 않으면 최대 1999개의 원소가 든 리스트를 순회하며 원소가 들어있는지 비교해야 하기 때문에 시간초과가 발생한 것 같다.

최종 코드 - 성공

ABCDE

import sys input = sys.stdin.readline

n, m = map(int, input().split()) relations = [[] for _ in range(n)] answer = False

for i in range(m): x, y = map(int, input().split())

relations[x].append(y)
relations[y].append(x)

def dfs(now, cnt): global answer

if cnt == 4:
    answer = True
    return

visited.append(now)
for i in relations[now]: 
    if i not in visited:
        dfs(i, cnt + 1)
visited.pop()

for i in range(n): visited = [] dfs(i,0) if answer: break

if answer: print(1) else: print(0) ```

입력

출력

문제풀이 - DFS : Pypy3로 성공

• 백트래킹으로 하나하나 벽을 세운 후, 그 때의 안전영역 크기를 구해 최댓값을 저장하는 방식으로 접근해야 된다는 생각을 했다.
• 처음에는 값이 '0'인 방들의 index를 조합(collections)을 이용해 벽을 세우는 방식을 떠올렸으나, 이후 풀이가 안 떠올라 포기했다.
• DFS 알고리즘으로 접근하기로 했다.

바이러스를 퍼트리는 함수

def infect(x,y):
    for i in range(4):
        nx = x + dx[i]
        ny = y + dy[i]
>
        if 0 <= nx < n and 0 <= ny < m and tmp[nx][ny] == 0:
            tmp[nx][ny] = 2
            infect(nx, ny)

안전영역 크기 구하는 함수

def count():
    temp = 0
    for i in range(n):
        for j in range(m):
            if tmp[i][j] == 0:
                temp += 1
    return temp

전체 코드

# 연구소
import sys
input = sys.stdin.readline
>
n, m = map(int, input().split())
array = [list(map(int, input().split())) for _ in range(n)]
tmp = [[0]*m for _ in range(n)]
answer = 0
>
dx = [0, 0, -1, 1]
dy = [1, -1, 0, 0]
>
def infect(x,y):
    for i in range(4):
        nx = x + dx[i]
        ny = y + dy[i]
>        
        if 0 <= nx < n and 0 <= ny < m and tmp[nx][ny] == 0:
            tmp[nx][ny] = 2
            infect(nx, ny)
>
def count():
    temp = 0
    for i in range(n):
        for j in range(m):
            if tmp[i][j] == 0:
                temp += 1
    return temp
>                
def dfs(w):
    global answer 
>    
    if w == 3: # 벽을 다 세우면
        for i in range(n):
            for j in range(m):
                tmp[i][j] = array[i][j] # copy
>                
        for i in range(n):
            for j in range(m):
                if array[i][j] == 2:
                    infect(i,j)
        answer = max(answer, count())
        return
    for i in range(n):
        for j in range(m):
            if array[i][j] == 0:
                array[i][j] = 1 # 벽 세우기
                w += 1
                dfs(w)
                array[i][j] = 0 # 세운 벽 거두기
                w -= 1
>
dfs(0)
print(answer)

다른 풀이 - BFS : Python3로 성공

• 처음 생각했던 방법으로, 조합으로 벽을 세울 수 있는 3군데 리스트로 뽑아내기
• 조합 순회하면서 벽을 세우고, 바이러스 퍼트린 뒤, 안전영역 크기 구하기

import sys
from itertools import combinations
from collections import deque
import copy

input = sys.stdin.readline n, m = map(int, input().split()) graph = [list(map(int, input().split())) for _ in range(n)] points = [] virus = [] answer = 0

def three_point(points): # 벽 세울 곳 new_wall = list(combinations(points, 3)) return new_wall

dx = [0, 0, -1, 1] dy = [1, -1, 0, 0]

def bfs(graph, points): for i, j in points: # 벽 세우기 graph[i][j] = 1

queue = deque()
for v in virus:
    queue.append(v)

while queue:
    x, y = queue.popleft()

    for i in range(4): # 바이러스 퍼트리기
        nx = x + dx[i]
        ny = y + dy[i]

        if 0 <= nx < n and 0 <= ny < m and graph[nx][ny] == 0:
            graph[nx][ny] = 2
            queue.append((nx, ny))

count = 0
for k in range(n): # 안전영역 크기 구하기
    count += graph[k].count(0)

return count

for i in range(n): for j in range(m): # 리스트 순회하면서 if graph[i][j] == 0: points.append((i, j)) # 벽 세울 수 있는 곳 elif graph[i][j] == 2: virus.append((i, j)) # 바이러스 있는 곳

new_wall = three_point(points) # 벽 세울 수 있는 곳 조사하기

for p in new_wall: new_graph = copy.deepcopy(graph) answer = max(answer, bfs(new_graph, p))

print(answer) ```

✏️ 1번째 풀이 방법

0 ~ (n+1) 까지 리스트를 생성한 후 명령어가 0이면 index가 a와 b인 리스트를 서로 복사하는 방법으로 풀이를 생각했다.

import sys
input = sys.stdin.readline

n, m = map(int, input().split())

hash = [[i] for i in range(n+1)]

for i in range(m):
    op, a, b = map(int, input().split())

    if op == 0:
        hash[a].extend(hash[b])
        hash[b].extend(hash[a])
    else:
        if b in hash[a] or a in hash[b]:
            print("YES")
        else:
            print("NO")

❌ 1번째 방법 - 실패

리스트가 a, b는 서로 연결이 되지만 합집합으로는 되지 못하기에 이 방법은 틀렸다.

예) 입력값으로 다음과 같을 때,

7, 3
0 1 2
0 1 3
0 2 4

** 저장된 리스트 **

[[0], [1, 2, 3], [2, 1, 2, 4], [3, 1, 2, 3], [4, 2, 1, 2, 4], [5], [6], [7]]

✅ 2번째 방법 - 성공

부모가 누구인지 알 수 있는 함수인 find 함수와 집합을 합쳤을 때, 부모를 같게 만들어주는 union 함수를 따로 정의하여 문제를 풀었다.

import sys
sys.setrecursionlimit(1000000)
input = sys.stdin.readline

n, m = map(int, input().split())

p = [i for i in range(n+1)]

def find(x):
    if p[x] == x:
        return x
    p[x] = find(p[x])
    return p[x]

def union(a, b):
    a = find(a)
    b = find(b)
    if a <= b:
        p[b] = a
    else:
        p[a] = b

for i in range(m):
    op, a, b = map(int, input().split())

    if op == 0:
        union(a, b)
    else:
        if find(a) == find(b):
            print("YES")
        else:
            print("NO")

"스노우타운"에서 호텔을 운영하고 있는 "스카피"는 호텔에 투숙하려는 고객들에게 방을 배정하려 합니다. 처음에는 모든 방이 비어 있으며 "스카피"는 다음과 같은 규칙에 따라 고객에게 방을 배정하려고 합니다.

• 호텔에는 방이 총 k개 있으며, 각각의 방은 1번부터 k번까지 번호로 구분하고 있습니다.
• 한 번에 한 명씩 신청한 순서대로 방을 배정합니다.
• 고객은 투숙하기 원하는 방 번호를 제출합니다.
• 고객이 원하는 방이 비어 있다면 즉시 배정합니다.
• 고객이 원하는 방이 이미 배정되어 있으면 원하는 방보다 번호가 크면서 비어있는 방 중 가장 번호가 작은 방을 배정합니다.

1차 접근 방법

• 처음에 10^12를 보지 못하고 중첩 반복문을 사용하려고 하였다.
• 아래와 같이 배정 여부를 저장하려고 했다.

booked = [0 for in range(k+1)]

1차 접근 실패!

-> 접근성 테스트는 모두 통과 했지만, 10^12이다 보니 효율성 테스트에서 모두 실패했다.

2차 접근 방법

• 시간복잡도를 줄이는 것이 관건이라고 생각했다.
• O(logn)의 시간복잡도를 가지는 알고리즘을 찾기 시작했다.
• Union Find 알고리즘을 발견했고, 이를 사용하기로 결정했다.

제출 코드 (통과)

import sys
sys.setrecursionlimit(100000000)

def check_room(num, rooms):
    if num not in rooms.keys():
        rooms[num] = num + 1
        return num
    empty = check_room(rooms[num], rooms)
    rooms[num] = empty + 1
    return empty

def solution(k, room_number):
    answer = []
    room = {}

    for i in room_number:
        checkIn = check_room(i, room)


    return list(room.keys())

참고 호텔방배정

: 일정한 규칙, 규약을 통해 구조화되어 저장되는 데이터의 모음

DBMS

: 데이터베이스를 제어, 관리하는 통합 시스템

ex) Mysql

4.1.1 엔터티

Entity

: 여러 개의 속성을 지닌 명사

4.1.2 릴레이션

Relation

: 데이터베이스에서 정보를 구분하여 저장하는 기본 단위

• 엔터티에 관한 데이터를 데이터베이스는 릴레이션 하나에 담아 관리한다.
• 관계형 데이터베이스에서는 “Table” / Nosql에서는 “Collection” 이라고 한다.

테이블과 컬렉션

데이터베이스 종류

1. 관계형 데이터베이스
   ex) Mysql
   • mysql 구조는 레코드-테이블-데이터베이스로 이루어져 있다.
   • 레코드가 쌓여 테이블이 되고, 테이블이 쌓여 데이터베이스가 된다.

     
     

2. Nosql 데이터베이스 ex) MongoDB
   • MongoDB 구조는 도큐먼트-컬렉션-데이터베이스

4.1.3 속성

Attribute

: 릴레이션에서 관리하는 구체적이며 고유한 이름을 갖는 정보

4.1.4 도메인

Domain

: 릴레이션에 포함된 각각의 속성들이 가질 수 있는 값의 집합을 말한다.

4.1.5 필드와 레코드

• 행 단위의 데이터 == 레코드

필드 타입

• 필드는 타입을 갖는다.

숫자 타입

날짜 타입

DATE

• 날짜부분만 존재
• 시간 부분은 없음
• 3바이트 용량을 가짐

1000-01-01 ~ 9999-12-31

DATETIME

• 날짜부분 & 시간부분 모두 포함
• 8바이트 용량을 가짐

1000-01-01 00:00:00 ~ 9999-12-31 23:59:59

TIMESTAMP

• 날짜 부분 & 시간 부분 모두 포함
• 4바이트 용량 가짐

1970-01-01 00:00:00 ~ 2038:01-19 03:14:07

문자 타입

CHAR

• CHAR에 경우 최대 30자까지 입력 가능함
• 고정 길이 문자열이고 길이는 0 ~ 255 사이의 값을 가진다.
• 레코드를 저장할 때 무조건 선언한 길이 값으로 고정해서 저장된다.
  • CHAR(100)이라 선언한 경우 10글자이더라도 100바이트로 저장되게 된다.

VARCHAR

• 가변 길이 문자열
• 0 ~ 65535 사이의 값으로 지정할 수 있다.
• 입력된 데이터에 따라 용량을 가변시켜 저장한다.
  • 10글자의 이메일을 저장할 경우 10글자에 해당하는 바이트 + 길이기록용 1바이트로 저장함

TEXT

• 큰 문자열 저장에 쓰며 주로 게시판의 본문을 저장할 때 쓴다.

BLOB

• 이미지, 동영상 등 큰 데이터 저장에 쓴다.
• 하지만 보통은 S3를 사용하여 서버에 파일을 올리고 파일경로를 VARCHAR로 저장한다.

ENUM

• 문자열을 열거한 타입
• ‘x-small’ , ‘small’, ‘medium’, ‘large’, ‘x-large’ 형태로 쓰인다.
• 이 중에서 하나만 선택하는 단일 선택만 가능하고, ENUM 리스트에 없는 잘못된 값을 삽입하면 빈 문자열이 대신 삽입된다.
• 이를 사용하면 ‘x-small’ 등이 0, 1 등으로 매핑되어 메모리를 적게 사용하는 이점을 얻는다.
• 최대 65535개의 요소들을 넣을 수 있다.

SET

• 문자열을 열거한 타입
• 여러 개의 데이터를 선택할 수 있고, 비트 단위의 연산을 할 수 있으며, 최대 64개의 요소를 집어 넣을 수 있다는 점이 ENUM과 다르다.

—> ENUM, SET을 사용할 경우 공간적으로는 이점을 볼 수 있지만, 애플리케이션의 수정에 따라 데이터베이스의

ENUM, SET에서 정의한 목록을 수정해야 한다는 단점이 있다.

4.1.6 관계

• 1대1 관계
• 1대다 관계
• 다대다 관계

4.1.7 키

기본키

: 유일성과 최소성을 만족하는 키

자연키

: 중복된 값들을 제외하며 중복되지 않은 것을 자연스레 뽑다가 나오는 키

• 언젠가는 변하는 속성을 가진다.

ex) 이름, 성별, 주민번호라는 속성이 있을 때, 주민번호가 자연키

인조키

: 인위적으로 생성한 키

• 자연키와는 대조적으로 변하지 않는다.
• 보통 기본키는 인조키로 설정한다.

ex) 사용자가 설정한 ID

외래키

: 다른 테이블의 기본키를 그대로 참조하는 값으로 개체와의 관계를 식별하는 데 사용한다.

• 외래키는 중복되어도 괜찮다.

후보키

: 기본키가 될 수 있는 후보들이며, 유일성과 최소성을 동시에 만족하는 키

대체키

: 후보키가 두 개 이상일 경우, 어느 하나를 기본키로 지정하고 남은 후보키를 의미한다.

슈퍼키

: 각 레코드를 유일하게 식별할 수 있는 유일하게 식별할 수 있는 유일성을 갖춘 키

• DB의 구조와 제약 조건에 관한 전반적인 명세를 기술한 metadata의 집합
• DB를 구성하는 Entity, Attribute, Relationship 및 데이터 조작 시 데이터 값들이 갖는 제약 조건 등에 관해 전반적으로 정의함
• 사용자 관점에 따라 외부 스키마, 개념 스키마, 내부 스키마로 나눠진다.

특징

1. 데이터 사전에 저장되며, 다른 이름으로 메타데이터라고도 함
2. 현실 세계의 특정한 한 부분의 표현으로서 특정 데이터 모델을 이용해서 만들어짐
3. 시간에 따라 불변인 특성을 갖는다.
4. 데이터의 구조적 특성을 의미하며, 인스턴스에 의해 규정됨

• 사용자나 응용 프로그래머가 개인의 입장에서 필요한 DB의 논리적 구조를 정의한다.
• 전체 데이터베이스의 한 논리적인 부분으로 볼 수 있기 때문에 서브 스키마라고도 한다.
• 하나의 데이터베이스 시스템에는 여러 개의 외부 스키마가 존재할 수 있다.
• 하나의 외부 스키마를 여러 개의 응용 프로그램 혹은 사용자가 공유할 수 있다.
• 일반 사용자는 SQL과 같은 질의어를 이용하여 DB를 쉽게 사용할 수 있다.
• 응용 프로그래머는 C나 JAVA 등의 언어를 사용하여 DB에 접근한다.

• 물리적인 저장장치 입장에서 데이터가 저장되는 방법을 기술한 것이다.
• 실제 DB에 저장될 레코드의 물리적인 구조를 정의한다.
• 저장 데이터 항목의 표현방법, 내부 레코드의 물리적 순서, index 유/무 등을 나타낸다.
• 시스템 프로그래머나 시스템 설계자가 관리한다.

• DB의 전체적인 논리적 구조, 모든 응용 프로그램이나 사용자들이 필요로 하는 데이터를 종합한 조직 전체의 DB로 하나만 존재한다.
• 개체 간의 관계와 제약 조건을 나타내고 DB의 접근 권한, 보안 및 무결성 규칙에 관한 명세를 정의한다.
• DB파일에 저장되는 데이터의 형태를 나타내는 것으로, 단순히 스키마라고 하면 개념 스키마를 의미한다.
• 기관이나 조직체의 관점에서 데이터베이스를 정의한 것이다.
• DBA에 의해서 구성된다.

: Relationship DataBase Management System → 관계형 데이터베이스 관리 시스템

• 관계형 모델을 기반으로 하는 DBMS 유형이다.

  : 실제 세계의 데이터를 '관계' 라는 개념을 사용해서 표현한 데이터 모델

• RDBMS의 테이블은 서로 연관되어 있어 일반 DBMS보다 효율적으로 데이터를 저장, 구성 및 관리할 수 있다.

• 정규화를 통해 데이터의 중복성을 최소화하여 트랜잭션을 수행하는 것이 더 쉽다.

• 데이터의 원자성, 일관성, 격리 및 내구성을 유지하며 데이터 무결성을 높인다.

• ex) MSSQL, MySQL, Oracle

• SQL에 의해 저장되고 있으며 정해진 스키마(Schema)에 따라 저장하여야 한다.

DBMS

• 사용자와 DB사이에서 사용자의 요구에 따라 데이터를 생성해주고, DB를 관리해주는 소프트웨어
• 데이터를 계층 또는 탐색 형식으로 저장한다.
• 파일 시스템을 사용해 저장하며, 따라서 테이블 간에는 아무런 관계가 없다.
• 데이터에 대한 많은 보안을 제공하지 않으며 정규화를 수행할 수 없어 데이터는 높은 중복성을 가질 수 있다.

RDB

• 관계형 데이터 모델에 기초를 둔 데이터 베이스이다.
• 모든 데이터를 2차원의 테이블 형태로 표현한다.

RDBMS 장점

• 정해진 스키마에 따라 데이터를 저장해야 하므로 명확한 구조를 보장하고 있다.
• 관계는 각 데이터를 중복없이 한 번만 저장할 수 있다.

RDBMS 단점

• 시스템이 커질 경우 JOIN문이 많은 복잡한 쿼리가 만들어질 수 있다.
• 성능 향상을 위해서는 서버의 성능을 향상시켜야 하는 scale-up만을 지원하고, 이로 인해 비용이 기하급수적으로 늘어날 수 있다.
• 스키마로 인해 데이터가 유연하지 못하다.
• 스키마가 변경될 경우 번거롭고 어렵다.

NoSQL

: Not Only SQL의 약자로 관계형 데이터베이스가 아닌 다른 형태의 데이터 저장 기술을 의미한다.

• 테이블 간 관계를 정의하지 않는다.
• 데이터 테이블은 하나의 테이블이며 테이블 간의 관계를 정의하지 않아 일반적으로 테이블간 join도 불가능하다.
• 수평적 확장성(scale-out)을 쉽게 할 수 있다.

1. Key - value DB
   • 데이터가 key - value의 쌍으로 저장된다.
   • 이미지나 비디오도 가능하다.
   • 간단한 Api를 제공하는 만큼 질의의 속도도 굉장히 빠르다.
   • ex) Redis, Riak, Amazon Dynamo DB
2. Document DB
   • key, document의 형태로 저장된다.
   • key - value와 다르게 value가 계층적인 형태인 document로 저장된다.
   • 객체 지향의 객체와 유사하며 하나의 단위로 취급하여 저장된다.
   • 객체 - 관계 맵핑이 필요하지 않다. → key-value 모델과 동일
   • 사용이 번거롭고 쿼리가 sql과는 다르다.
   • 질의의 결과가 JSON, xml 형태로 출력된다.
   • ex) MongoDB, CouthDB
3. Wide Column DB
   • column-family model 기반의 db이며 키에서 필드를 결정한다.
   • 키는 row(키 값)와 column-family, column-name을 가진다.
   • 연관된 데이터들은 같은 column-family 안에 속해 있으며 각자의 column-name을 가진다.
   • 관계형 모델로 따지면, attribute가 계층적인 구조를 가지고 있는 셈
   • 하나의 커다란 테이블로 표현가능하며, 질의는 Row, column-family, column-name을 통해 수행된다.
   • ex) HBase, Hypertable
4. Graph DB
   • node, edge, property와 함께 그래프 구조를 사용하여 데이터를 표현하고 저장한다.
   • 개체와 관계를 그래프 형태로 표현한 것이므로 관계형 모델이라고 할 수 있다.
   • 데이터 간의 관계가 탐색의 키일 경우에 적합하다.
   • ex) Neo4J

: Strucured Query Language

• 관리 시스템의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어
• 관계형 데이터베이스 관리 시스템에서 자료의 검색과 관리, 데이터베이스 스키마 생성과 수정, 데이터베이스 객체 접근 조정 관리

NoSQL 장점

• 스키마가 없기 때문에 유연하며 자유로운 데이터 구조를 가질 수 있다.
• 언제든 저장된 데이터를 조정하고 새로운 필드를 추가할 수 있습니다.
• 데이터 분산이 용이하며 성능 향상을 위한 Scale-up 뿐만이 아닌 Scale-out 또한 가능합니다.

NoSQL 단점

• 데이터 중복이 발생할 수 있으며 중복된 데이터가 변경 될 경우 수정을 모든 컬렉션에서 수행을 해야 합니다.
• 스키마가 존재하지 않기에 명확한 데이터 구조를 보장하지 않으며 데이터 구조 결정가 어려울 수 있습니다.

결론

RDBMS는

• 데이터 구조가 명확하고, 변경될 여지가 없으며, 명확한 스키마가 중요한 경우 사용하는 것이 좋다.
• 관계를 맺고 있는 데이터가 자주 변경이 이루어지는 시스템에 적합하다.

NoSQL은

• 정확한 데이터 구조를 알 수 없고 데이터가 변경/확장이 될 수 있는 경우에 사용하는 겻이 좋다.
• Update가 많이 이루어지지 않는 시스템이 좋다.
• 막대한 데이터를 저장해야 해서 DB를 Scale-out를 해야 하는 시스템에 적합하다.

RDBMS와 NoSQL의 차이점

RDBMS는 관계형 데이터베이스로 테이블이 서로 연관되어 있어, 효율적으로 데이터를 저장 및 관리를 할 수 있다. 정해진 스키마에 따라 데이터를 저장해야 한다. NoSQL은 테이블 간의 관계를 정의하지 않으며, 데이터 테이블은 보통 하나의 테이블이다. 스키마가 존재하지 않기 때문에 자유로운 데이터 구조를 가질 수 있고, 데이터 분산이 용이하다.

출처

https://velog.io/@sysop/DBMS-와-RDBMS의-개념

DP (Dynamic Programming)

문제

        7
      3   8
    8   1   0
  2   7   4   4
4   5   2   6   5

위 그림은 크기가 5인 정수 삼각형의 한 모습이다.

맨 위층 7부터 시작해서 아래에 있는 수 중 하나를 선택하여 아래층으로 내려올 때, 이제까지 선택된 수의 합이 최대가 되는 경로를 구하는 프로그램을 작성하라. 아래층에 있는 수는 현재 층에서 선택된 수의 대각선 왼쪽 또는 대각선 오른쪽에 있는 것 중에서만 선택할 수 있다.

삼각형의 크기는 1 이상 500 이하이다. 삼각형을 이루고 있는 각 수는 모두 정수이며, 범위는 0 이상 9999 이하이다.

Solution

제출 코드

# 정수 삼각형

import sys
input = sys.stdin.readline

n = int(input())
triangle = []

for i in range(n):
    triangle.append(list(map(int, input().split())))    

for i in range(n-2,-1,-1):
    for j in range(len(triangle[i])):
        triangle[i][j] = max(triangle[i+1][j], triangle[i+1][j+1])+ triangle[i][j]

print(triangle[0][0])

1. build.gradle에 추가하기

    implementation 'org.springframework.cloud:spring-cloud-starter-aws:2.2.6.RELEASE'

2. application.yml에 추가하기

    cloud:
      aws:
        s3:
          bucket: {버킷이름}
        credentials:
          access-key: ???
          secret-key: ???
        region:
          static: ap-northeast-2
          auto: false
        stack:
          auto: false

3. Config

   • AWSS3Config

     package jpabook.jpashop;
     
     import com.amazonaws.auth.AWSStaticCredentialsProvider;
     import com.amazonaws.auth.BasicAWSCredentials;
     import com.amazonaws.services.s3.AmazonS3Client;
     import com.amazonaws.services.s3.AmazonS3ClientBuilder;
     import org.springframework.beans.factory.annotation.Value;
     import org.springframework.context.annotation.Bean;
     import org.springframework.context.annotation.Configuration;
     
     @Configuration
     public class AWSS3Config {
        @Value("${cloud.aws.credentials.access-key}")
        private String accessKey;
     
        @Value("${cloud.aws.credentials.secret-key}")
        private String secretKey;
     
        @Value("${cloud.aws.region.static}")
        private String region;
     
        @Bean
        public AmazonS3Client amazonS3Client() {
            BasicAWSCredentials awsCreds = new BasicAWSCredentials(accessKey, secretKey);
            return (AmazonS3Client) AmazonS3ClientBuilder.standard()
                    .withRegion(region)
                    .withCredentials(new AWSStaticCredentialsProvider(awsCreds))
                    .build();
        }
     }

     4. Controller

   • AmazonS3Controller

     package jpabook.jpashop.controller;
     
     import jpabook.jpashop.Service.AWSS3Service;
     import lombok.RequiredArgsConstructor;
     import org.springframework.http.ResponseEntity;
     import org.springframework.web.bind.annotation.*;
     import org.springframework.web.multipart.MultipartFile;
     
     import java.util.List;
     
     @RestController
     @RequiredArgsConstructor
     @RequestMapping("/s3")
     public class AmazonS3Controller {
     
        private final AWSS3Service awsS3Service;
     
        /**
         * Amazon S3에 파일 업로드
         * @return 성공 시 string Success 반환하게 함
         */
     //    @ApiOperation(value = "Amazon S3에 파일 업로드", notes = "Amazon S3에 파일 업로드 ")
        @PostMapping("/file")
        public String uploadFile(@RequestPart List<MultipartFile> multipartFile) {
            awsS3Service.uploadFile(multipartFile);
            return "success";
        }
     
        /**
         * Amazon S3에 업로드 된 파일을 삭제
         * @return 성공 시 string Success 반환하게 함
         */
     //    @ApiOperation(value = "Amazon S3에 업로드 된 파일을 삭제", notes = "Amazon S3에 업로드된 파일 삭제")
        @DeleteMapping("/file")
        public ResponseEntity<Void> deleteFile(@RequestParam String fileName) {
            awsS3Service.deleteFile(fileName);
            return null;
        }
     }

     5. Service

   • AWSS3Service

     package jpabook.jpashop.Service;
     
     import com.amazonaws.services.s3.AmazonS3;
     import com.amazonaws.services.s3.model.CannedAccessControlList;
     import com.amazonaws.services.s3.model.DeleteObjectRequest;
     import com.amazonaws.services.s3.model.ObjectMetadata;
     import com.amazonaws.services.s3.model.PutObjectRequest;
     import lombok.RequiredArgsConstructor;
     import org.springframework.beans.factory.annotation.Value;
     import org.springframework.http.HttpStatus;
     import org.springframework.stereotype.Service;
     import org.springframework.web.multipart.MultipartFile;
     import org.springframework.web.server.ResponseStatusException;
     
     import java.io.IOException;
     import java.io.InputStream;
     import java.util.ArrayList;
     import java.util.List;
     import java.util.UUID;
     
     @Service
     @RequiredArgsConstructor
     public class AWSS3Service {
     
        @Value("${cloud.aws.s3.bucket}")
        private String bucket;
     
        private final AmazonS3 amazonS3;
     
        public List<String> uploadFile(List<MultipartFile> multipartFile) {
            List<String> fileNameList = new ArrayList<>();
     
            // forEach 구문을 통해 multipartFile로 넘어온 파일들 하나씩 fileNameList에 추가
            multipartFile.forEach(file -> {
                String fileName = createFileName(file.getOriginalFilename());
                ObjectMetadata objectMetadata = new ObjectMetadata();
                objectMetadata.setContentLength(file.getSize());
                objectMetadata.setContentType(file.getContentType());
     
                try(InputStream inputStream = file.getInputStream()) {
                    amazonS3.putObject(new PutObjectRequest(bucket, fileName, inputStream, objectMetadata)
                            .withCannedAcl(CannedAccessControlList.PublicRead));
                    System.out.println("fileName = " + fileName);
                } catch(IOException e) {
                    throw new ResponseStatusException(HttpStatus.INTERNAL_SERVER_ERROR, "파일 업로드에 실패했습니다.");
                }
     
                fileNameList.add(fileName);
            });
     
            return fileNameList;
        }
     
        public void deleteFile(String fileName) {
            amazonS3.deleteObject(new DeleteObjectRequest(bucket, fileName));
        }
     
        private String createFileName(String fileName) { // 먼저 파일 업로드 시, 파일명을 난수화하기 위해 random으로 돌립니다.
            return UUID.randomUUID().toString().concat(getFileExtension(fileName));
        }
     
        private String getFileExtension(String fileName) { // file 형식이 잘못된 경우를 확인하기 위해 만들어진 로직이며, 파일 타입과 상관없이 업로드할 수 있게 하기 위해 .의 존재 유무만 판단하였습니다.
            try {
                return fileName.substring(fileName.lastIndexOf("."));
            } catch (StringIndexOutOfBoundsException e) {
                throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "잘못된 형식의 파일(" + fileName + ") 입니다.");
            }
        }
     }

결과

• 파일 업로드

• 파일 삭제