CS

DB

• NoSQL, RDB 차이점과 특징
  • RDB

[회원 Table]

회원 번호 (Primary Key)	회원 이름	휴대폰 번호
1111111	김희진	010-xxxx-xxxx
2222222	김또깡	010-yyyy-yyyy

[주문 Table]

주문 번호 (Primary Key)	주문 회원 번호 (foreign key)	주문 상품
20200207xxxxxxxx	1111111	컴퓨터
20200207yyyyyyy	2222222	키보드
20200207zzzzzzz	2222222	마우스

1. 테이블은 row(record, tuple)과 column(field, item)으로 이루어진 기본 데이터 저장 단위
2. 확장에 용이 ER모델에 따라 데이터 베이스가 생성됨
3. ER(Entity Relationship) : Entity(개체), Attribute(애트리뷰트), Relation(관계)로서 개체에는 Student 네모로 표현된 부분, 애트리뷰트에는 student가 가지는 속성 원으로 표현된 부분, 관계는 개체간의 연관관계를 뜻하며 Takes라는 수강의 속성을 가지며 마름모이다.

https://victorydntmd.tistory.com/126

• NoSQL 
  1.  데이터 테이블은 그냥 하나의 테이블이며 테이블 간의 관계를 정의하지 않아 일반적으로 테이블 간 Join이 불가능하다.
  2. 데이터의 일관성을 포기하고 비용적인 측면에서 이점인 여러 대의 데이터에 분산하여 저장하는 Scale-Out(서버를 추가 적으로 연결하여 기존 서버의 부하를 분담시키는 것 Auto Scaling이 여기에 해당한다.)을 목표로 등장
  3. Key-Value Database : 어떠한 형태의 데이터라도 값을 담을 수 있으며 이미지나 비디오도 가능하며 속도가 상당히 빠른 편이다. 대표적인 NoSQL Key-Value Model로는 Redis, Riak, Amazon Dynamo DB 등이 있다.
  4. Document Database : Value가 계층적인 형태인 도큐먼트로 저장되며 검색에 최적화되어 있다. 질의의 결과는 JSON이나 xml의 형태로 출력이 되며 다중 트랜잭션이 요구되거나 Update가 빈번할 경우 사용하기에 적합하지 않다. 대표적인 NoSQL Document Model로는 MongoDB, CouthDB 등이 있다.
• RDB 와 NoSQL의 차이 점
  1. RDB의 경우 데이터 구조가 명확하여 변경 될 여지가 없을시 유용하지만 NoSQL의 경우 변경 확장에 용이하다.
  2. RDB의 경우 중복되는 데이터가 없지만 NoSQL의 경우 데이터 중복이 발생할 수 있다.

• 트랜잭션과 LOCK , Acid, solation Level
  1. 트랜잭션
     1. DB의 데이터를 조작하는 작업의 단위이며 A가 B에게 1000원을 송금시 A의 계좌에서 1000원을 차감하고 B의 계좌에서 1000원을 추가 할 때 B의 은행에서의 오류로 추가 되지 않는다면 A의 돈만 차감되는 오류가 발생하기에 이를 보장하기 위해 작업들을 트랜잭션 단위로 묶어서 처리를 함
  2. LOCK
     1. 트랜잭션의 ACID 원칙과 동시성을 최대한 보장하기 위한 기술이다.
     2. row-level lock : 테이블의 row마다 걸리는 lock, read에 대한 S lock : 조회시 각 row에 S lock을 걸며 S lock이 걸려 있는 쿼리끼리는 다른 row에 접근 가능하다, write에 대한 X lock : X lock이 걸린 row는 다른 어떠한 쿼리도 접근 불가능하다.
     3. Record lock : DB의 index record에 걸리는 lock, 이미 존재하는 row가 변경되지 않도록 보호하는 것
     4. Gap lock : DE index record의 gap(index 중 DB에 실제 record가 없는 부분)에 걸리는 lock, 조건에 해당하는 새로운 row가 추가되는 것을 방지하는 것
     5. lock은 모두 transaction이 commit 되거나 rollback 될 때 함께 unlock 된다.
  3. ACID
     1. Atomicity (원자성) : 하나의 트랜잭션에 대해서 전체 성공 혹은 실패만을 보장하며 일부분만 작업하여 반영하지 않음
     2. Consistency (일관성) : 트랜잭션의 작업이 완료하더라도 작업 이전과 같은 상태를 유지하는 것을 말하며 정수 타입의 컬럼에 문자열 값이 들어가지 않는것을 보장
     3. Isolation (격리성) : 트랜잭션 작업시 다른 작업이 끼어들지 못하도록 보장해주는 것, 트랜잭션끼리 서로 간섭할 수 없지만 유연하게 설정이 가능한 제약조건
     4. Durability (지속성) : 작업이 완료되어 커밋까지 된 작업은 시스템 문제나 일관성 체크를 하여도 유지 되어야 하며 시스템 장애 발생 전 상태로 돌릴수 있다.
  4. isolation level : ACID의 원칙을 너무 타이트하게 지킬시 동시성에 대한 퍼포먼스가 떨어지기에 차등을 두어 이점을 가질 수 있게 하지만 문제가 발생할 가능성이 커짐.
     1. READ UNCOMMITTED : SELECT 쿼리 실행시에 다른 트랜잭션에서 COMMIT 되지 않은 데이터를 읽어올 수 있다.
     2. READ COMMITTED : 트랜잭션내에서 커밋된 데이터만 다른 트랜잭션이 읽는 것을 허용
     3. REPEATABLE READ : 트랜잭션 내에서 한 번 조회한 데이터를 반복해서 조회해도 결과는 동일
     4. SERIALIZABLE : 가장 엄격한 격리 수준으로 완벽한 읽기 일관성 모드 제공

https://velog.io/@lsb156/Transaction-Isolation-Level#acid%EB%9E%80

https://suhwan.dev/2019/06/09/transaction-isolation-level-and-lock/

• 인덱스
  1. 인덱스란 추가적인 쓰기 작업과 저장 공간을 활용하여 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조
  2. 장점
     1. 테이블을 조회하는 속도와 성능을 향상시킬 수 있다.
     2. 시스템의 부하를 줄일 수 있다.
  3. 단점
     1. 인텍스 관리를 위해 DB의 약 10%에 해당하는 저장공간이 필요하다.
     2. cud가 빈번한 속성에 잘못 사용시 성능이 저하될 수도 있다.
• ORM이란
  1. 객체와 관계형 DB의 데이터를 자동으로 매핑해주는 것
  2. 객체 간의 관계를 바탕으로 SQL을 자동 생성하여 불일치를 해결해준다.
  3. 비즈니스 로직에 더 집중할 수 있게 도와준다.
• N+1 문제 (LAZY, EAGER)
  • 발생 이유
    • JPQL은 findAll()이란 메소드를 수행하였을 때 해당 엔티티를 조회하는 select * from Owner 쿼리만 실행하게 되는것이다. JPQL 입장에서는 연관관계 데이터를 무시하고 해당 엔티티 기준으로 쿼리를 조회하기 때문이다. 그렇기 때문에 연관된 엔티티 데이터가 필요한 경우, FetchType으로 지정한 시점에 조회를 별도로 호출하게 된다.
  • LAZY
    • 초기 데이터 로드 시점에 N+1 발생
  • EAGER
    • 연관관계 데이터를 사용하는 시점에 N+1 발생
  • 해결 방안
    1. Fetch Join @Quert 어노테이션으로 "join fetch 엔티티.연관관계_엔티티"사용
       1. @Query("select t from Team t join fetch t.users")
       2. List<Team> findAllFetchJoin():
    2. Batch Size : 지연 로딩을 사용하고 성능 최적화가 필요한 부분에서 Fetch 조인을 사용한다.

https://incheol-jung.gitbook.io/docs/q-and-a/spring/n+1

• 트랙잭션 readonly
  • 트랜잭션 커밋시 플러시가 일어나지 않게 되어 엔티티의 등록 수정 삭제가 동작하지 않으며 스냅샷을 보관하지 않고 Hibernate가 Entity에 flush를 호출하지 않게 되기에 변경은 무시되며  Entity와 Snapshot을 비교하는 Dirty Checking을 하지 않기에 성능이 향상된다.

• OSIV(Open Session In View)
  • 영속성 컨텍스트를 뷰까지 열어두는 기능으로 영속성 컨텍스트가 유지되면 엔티티도 영속 상태로 유지된다.

스프일 OSIV - 비즈니스 계층 트랜잭션

• 동작 원리
  1. 클라이언트의 요청시 서블릿 필터나, 스프링 인터셉터에서 영속성 컨텍스트 생성
  2. 서비스 계층에서 트랜잭션을 시작시에 1번의 영속성 컨텍스트를 찾아와 트랜잭션 시작
  3. 서비스 계층이 끝나면 트랜잭션을 커밋하고 영속성 플러시, 이 시점에서 트랜잭션은 끝나지만 영속성 컨텍스트 종료되지 않는다.
  4. 컨트롤러와 뷰까지 영속성 컨텍스트가 유지되며 조회한 엔티티는 영속 상태를 유지한다.
  5. 서블릿 필터나, 스프링 인터셉터로 요청이 오면 영속성 컨텍스트 종료. 플러시 호출을 하지 않고 바로 종료한다.
• 주의 사항
  1. OSIV 전략은 트랜잭션 시작처럼 최초 DB커넥션 시점부터 API 응답이 끝날때까지 영속성 컨텍스트와 DB 커넥션을 유지한다.
  2. 단점 으로는 커넥션을 영속성 컨텍스트가 종료될 때까지 1:1로 물고 있기 때문에 커넥션이 모자랄 수도 있다.

https://ykh6242.tistory.com/entry/JPA-OSIVOpen-Session-In-View%EC%99%80-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94

WEB

• 세션
  •  웹 브라우저을 통해 서버에 접속한 경우 브라우저가 종료할 때까지 유지되는 상태
  • 저장 위치
    • 쿠키 : 클라이언트
    • 세션 : 서버
  • 보안
    • 쿠키 : 클라이언트에 저장되므로 보안에 취약
    • 세션 : 쿠키를 이용해 ID만 저장하고 이 값으로 구분해 서버에서 처리 보안성이 좋다.
• 쿠키
  • 로컬에 저장되는 키와 값이 들어있는 파일이며 이름, 값, 유효 시간등을 포함하고 있다.
  • 구성 요소
    • 쿠키의 이름(name)
    • 쿠키의 값(value)
    • 쿠키의 만료시간(Expires)
    • 쿠키를 전송할 도메인 이름(Domain)
    • 쿠키를 전송할 경로(Path)
    • 보안 연결 여부(Secure)
    • HttpOnly 여부(HttpOnly)
  • 사용 예시
    • 아이디, 비밀번호 저장
    • 쇼핑몰 장바구니
• Stateful
  • 세션이 종료될 떄까지 클라이언트의 세션 정보를 저장하는 프로토콜(TCP)
  • 장점
    • 클라이언트의 세션 정보를 저장하므로, 통신 중단시 중단 된 곳에서부터 시작할 수 있다.
  • 단점
    • 확장성이 좋지 않으며 세션 정보가 Scale-out된 서버에 저장되지 않는다.
• Stateless
  • 서버가 세션 상태 및 정보를 저장하지 않는 프로토콜(UDP)
    • 요청에 대한 응답만 처리
  • 장점
    • 서버가 정보를 저장하지 않기에 확장성이 좋다.
  • 단점
    • 서버가 저장하지 않기에 클라이언트가 송신할 데이터 양이 많아진다.
• JWT, Refresh Token
• RESTful API

NETWORK

• HTTP 프로토콜
  
  • 개념
    • 웹 상에서 클라이언트와 서버 간에 요청/응답(Request/Response)으로 정보를 주고 받을 수 있는 프로토콜
  • 특징
    • 주로 HTML 문서를 주고 받는데 사용
    • TCP와 UDP를 사용, 80번 포트 사용
    • 비연결(Connectionless)
      • 클라이언트가 요청을 서버에 보내고 서버가 적절한 응답을 클라이언트에 보내면 바로 연결이 끊긴다.
    • 무상태(Stateless)
      • 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나며 상태 정보를 유지하지 않는다. ex) 화면 이동 시 다시 로그인을 하여야 됨(쿠키에 저장하기 전)

  동작 과정 ex)웹브라우저에 google.com 치면 일어나는 과정
    1. 사용자가 웹 브라우저에 URL 주소 입력
    2. DNS 서버에 웹 서버의 호스트 이름을 IP 주소로 변경 요청
    3. 웹 서버와 TCP 연결 시도(3-way handshake)
    4. 클라이언트가 서버에 요청(Request)
    5. 서버가 클라이언트에게 응답(Response)
    6. 서버 클라이언트간 연결 종료(4-way handshake)
    7. 웹 브라우저가 웹 문서 출력

•  HTTP, HTTPS 차이
  • 공개 키 방식은 두 개의 키를 가지게 되며 A키로 암호화 시 B키로 복호화가 가능하다. 두 개의 키 중 하나는 공개 키이며 다른 하나는 비공개 키가 되며 비공개 키는 private한 사용자가 가지게 된다.
  • HTTP는 따로 암호화 과정을 거치지 않기에 패킷을 가로채거나 수정을 할 수 있으며 보안이 취약할 수 있기 때문에 나온 것이 HTTPS이며 HTTPS는 중간에 암호화 계층을 거쳐서 패킷을 암호화 합니다.
  • HTTPS는 HTTP에 SSL/TLS계층을 더한 것이다
  • HTTPS의 경우 암호화 하는 과정에서 웹 서버에 부하를 주며 HTTP에 비해 느리다

 

• 웹 브라우저에서 요청했을 때, 서버에 도달하기까지의 과정 (OSI 7계층, 라우터 + 스위치, DNS)