1. JOIN 이란?
데이터를 검색하다 보면 테이블 하나만을 이용해서는 원하는 정보를 다 가져오지 못하는 경우가 많습니다. 예를 들어 사원의 급여 정보를 검색하는 경우에 [급여] 테이블에는 사원 번호와 급여 정보만 있는 경우 사원 이름을 같이 검색하고자 한다면 사원 이름을 가지고 있는 [사원] 테이블을 참조해야 합니다. 이렇게 테이블을 서로 연결하여 검색을 할 때 사용되는 것이 JOIN 문 입니다.
JOIN의 종류는 다음과 같이 나눌 수 있습니다.
INNER JOIN
OUTER JOIN
FULL JOIN
CROSS JOIN
이 중에서 가장 많이 사용되는 것이 INNER JOIN 입니다. 다음 [그림 1]을 기준으로 해서 이들 조인의 기능을 살펴보도록 하겠습니다.

[그림 1]
[그림 1]과 같이 [사원] 테이블과 [급여] 테이블이 있습니다. 실제 업무와 다를 수 있지만 조인의 기능을 확인하기 위하여 가정을 하도록 하겠습니다. [사원] 테이블에는 사원 정보가, [대출] 테이블에는 대출 정보가 기록되어 있습니다.
2. INNER JOIN
INNER JOIN은 양쪽의 행들 중에서 서로 연관된 내용만 검색하는 조인 방법입니다. INNER JOIN을 위해서는 우선 [그림 2]처럼 두 테이블에서 공통되지 못한 부분은 JOIN의 대상에서 제외가 됩니다.

[그림 2]
그리고 남아 있는 양쪽의 행들이 다음 [그림 3]과 같이 서로 연관된 행들끼리 결합을 하게 됩니다.

[그림 3]
결국 다음 [그림 4]와 같은 결과를 얻을 수 있게 됩니다.

[그림 4]
위 내용을 INNER JOIN을 이용한 쿼리문으로 표현한다면 다음과 같습니다.
SELECT A.사번, A.이름, B.도서
FROM 사원 A INNER JOIN 대출 B ON A.사번 = B.사번


o 이 쿼리문에서 A와 B 는 [사원] 테이블과 [대출] 테이블을 가리키는 Alias 입니다. 
o ON 부분을 보면 두 테이블을 '사번' 을 이용하여 연결하고 있습니다.

위 쿼리문은 다음과 같이 표현 할 수도 있습니다.
SELECT A.사번, A.이름, B.도서
FROM 사원 A JOIN 대출 B ON A.사번 = B.사번
즉 'INNER' 를 생략하고 단순히 'JOIN' 만 사용해도 'INNER JOIN'으로 인식됩니다. 이것은 대부분의 JOIN 이 INNER JOIN 이기 때문에 사용자의 편의를 위한 것입니다.
3. OUTER JOIN
OUTER JOIN은 한쪽 테이블을 기준으로 해서 조인을 형성합니다. 그래서 기준이 되는 테이블은 조인되는 테이블과 연관성이 없다 하여도 검색의 대상이 됩니다. 이러한 이유로 OUTER JOIN에는 다음과 같이 두가지의 방법이 존재하게 됩니다.
LEFT OUTER JOIN (기본값)
RIGHT OUTER JOIN
만일 [사원] 테이블과 [대출] 테이블을 OUTER JOIN 시킬 때 [사원] 테이블을 기준으로 한다면 다음 [그림 5] 와 같은 결과를 얻게 됩니다.

[그림 5]
위 내용을 쿼리문으로 표현한다면 다음과 같습니다.
SELECT A.사번, A.이름, B.도서
FROM 사원 A LEFT OUTER JOIN 대출 B ON A.사번 = B.사번
하지만 [대출] 테이블을 기준으로 한다면 다음 [그림 6] 과 같은 결과를 얻게 됩니다.

[그림 6]
위 내용을 쿼리문으로 표현한다면 다음과 같습니다.
SELECT A.사번, A.이름, B.도서
FROM 사원 A RIGHT OUTER JOIN 대출 B ON A.사번 = B.사번
4. FULL JOIN
FULL JOIN은 [그림 5]와 [그림 6]의 결합이라고 생각하시면 됩니다. 결합이 되는 양쪽 테이블에서 연관성이 없는 행도 조인의 결과에 포함되기 때문입니다. [사원] 테이블과 [대출] 테이블의 FULL JOIN의 결과는 다음 [그림 7]과 같습니다.

[그림 7]
위 내용을 쿼리문으로 표현한다면 다음과 같습니다.
SELECT A.사번, A.이름, B.도서
FROM 사원 A FULL JOIN 대출 B ON A.사번 = B.사번
5. CROSS JOIN
CROSS JOIN은 한쪽 테이블의 모든 행들에 대하여 다른 쪽 행들이 전부 대입이 되는 형태의 조인입니다. 만일 [사원] 테이블과 [대출] 테이블을 CROSS JOIN 시킨다면 [그림 8] 과 같은 각각 대입되어 [그림 9]와 같은 결과를 얻게 됩니다. 단, [그림 8]은 첫번째 행에 대한 대입만을 보여주고 있는데 이러한 대입이 [사원] 테이블의 모든 행에 대하여 이루어지게 됩니다.

[그림 8]

[그림 9]
결국 [사원] 테이블의 행의 갯수 X [대출] 테이블의 행의 갯수 만큼의 행이 CROSS JOIN의 결과를 얻어지게 됩니다.
위 내용을 쿼리문으로 표현한다면 다음과 같습니다.
SELECT A.사번, A.이름, B.도서
FROM 사원 A CROSS JOIN 대출 B
즉, 두 테이블의 연관성이 전혀 필요없게 되므로 ON 절이 포함되지 않습니다.
6. 정리
SELECT 문을 사용 할 때 가장 이해하기 힘든 부분이 JOIN 이 아닌가 싶습니다. JOIN 기능을 잘 익혀 두면 좀더 효율적인 검색을 할 수 있습니다. OUTER JOIN이나 FULL JOIN, CROSS JOIN은 잘 사용이 되지 않습니다. 그 이유는 많은 사람들이 INNER JOIN 까지만 배우고 더이상은 JOIN에 대하여 배우지 않고 무작정 SELECT 문을 사용하기 때문이 아닌가 싶습니다.
다음 강좌에서는 실제로 JOIN을 사용하는 예제를 보면서 다시한번 JOIN에 대하여 살펴볼 예정입니다. 온라인 설명서(Books Online)을 보시면 JOIN에 대한 방대한 량의 설명이 있습니다. 그 내용을 꼭 참고하여 주시기 바랍니다.


'Major > Database' 카테고리의 다른 글

데이터베이스 - MySql  (0) 2015.11.26
데이터베이스 - 데이터 타입  (0) 2015.11.26
데이터베이스 - 트랜잭션  (0) 2015.11.26
데이터베이스 - SQL  (0) 2015.11.25
데이터베이스 - 관계 대수  (0) 2015.11.25

출처: http://sejoong.github.io/dev/2015/02/15/dev/HTTP 2.0 : The New Web Standard and Issue(허태성, saturn.twinfish@gmail.com)

HTTP 1.1 이후로 처음 등장한 새로운 버전인 HTTP/2.0을 알아보기 전에 HTTP가 무엇인지 알아보고 HTTP/2.0에서는 어떤 변화가 있는지 알아보자.

HTTP

HyperText Transfer Protocol의 약자로 WWW(World Wide Web)에서 하이퍼텍스트(hypertext) 문서를 교환하기 위하여 사용되는 통신규약이다.
1.0(1996s)m 1.1(1999s)두가지 버전이 있다.

  • Status code:
    http 통신중 요청의 상태 정보를 제공한다. 공식 적인 상태코드 목록은 IANA에서 확인할 수 있다.
    상태코드의 첫 숫자는 응답의 종류를 나타낸다. 아래는 응답의 종류와 내가 개발중 많이 접했던 몇가지 상태 코드 이다.
  1. 1xx - Informational - 정보교환
  2. 2xx - Success - 성공
    200 - OK - 요청이 성공적으로 전송됨
  3. 3xx - Redirection - 방향 지정
    301 - Moved Permanently - 요청 페이지의 영구적인 위치 변화
    302 - Found - 요청 페이지이 일시적인 위치 변화
  4. 4xx - Client Error - 클라이언트 오류
    404 - Not Found - 요청받은 자원을 서버에서 찾을 수 없을때 나타나는 상태 
    405 - Method Not Allowed - 서버에서 사용자가 요청한 주소의 메소드를 지원하지 않을때 나타남
  5. 5xx - server Error - 서버 오류
  • Request methods:
    요청이 수행될 작업의 방법을 나타낸다.

    1. OPTIONS: 요청한 URL에 어떠한 메소드 요청이 가능한지 묻는다.
    2. GET: 다른 작업없이 데이터의 검색에 이용.
    3. HEAD: 데이터의 검색에 이용하나 GET과는 다르게 응답 HEADER만 받는다.
    4. POST: URL에 새로운 데이터를 보낼때 사용.
    5. PUT: URL에 저장될 정보를 보낸다.
    6. DELETE: URL의 리소스를 삭제한다.
    7. TRACE: 보낸 메세지를 다시 돌려받는다.
    8. CONNECT: 프록시에서 사용되는 예약 메소드.
  • 요청/응답 스펙

Request-Line
*(( general-header | request-header | entity-header ) CRLF)
CRLF
[ message-body ]

  1. Request-line: method, request url, http버전
  2. Request-header: general-header, request-header, entity-header가 존재하며 필요에 따라 사용

Status-Line

*(( general-header | response-header | entity-header ) CRLF)
CRLF
[ message-body ]

  1. status-line: http 버전, 상태 코드, 상태 메세지
  2. Request-header: general-header, response-header, entity-header

HTTP/2.0의 등장 배경 및 특징

latency를 줄여 웹의 속도를 개선하기 위해 등장.
1. HTTP Header 데이터 압축
2. Server Push(서버에서 부터 시작되는 전송)
3. HTTP 1에서 존재하던 head-of-line blocking 문제 개선
4. 싱글 TCP connection내에서 병렬 페이지 로딩 구현
2.0은 기존 버전인 1.1과의 높은 호환성(method, status codes 등)은 보장하고 클라이언트 서버 간 전송 및 프레임의 개선에 초점을 맞췄다.
head-of-line blocking: 동일한 송신 포트 자원에 대한 처리량 경쟁으로 인해 처리량 지연 및 프레임 손실 발생 유발 작업대기 중인 2개의 패킷이 존재할 경우 첫번째 패킷이 대기중이면 그 뒤 패킷들은 무조건 대기할때 발생












HTTP 2.0의 개선 사항

  1. 효율적인 페이지 로딩을 위해 URL의 이미지, 스크립트등의 자원을 압축해 페이지 렌더링을 위한 요청횟수를 감소시켰다.
  2. 뿐만 아니라 server가 push가 가능해 웹페이지의 렌더링이 필요하단 사실을 알게되면 추가 요청없이 서버가 리소스를 제공한다.
  3. 그 외에도 성능 개선을 위한 요청 다중화, 헤더 압축, HOL Blocking해결을 위한 요청 우선순위 결정등이 있다.

HTTP/2.0과 SPDY와의 관계

  • SPDY:
    Google이 ‘speedy’라는 단어를 기반으로 제안한 새로운 프로토콜이다. HTTP의 단점들을 보완하여, 인터넷 환경을 보다 효율적으로 이용하기 위한 프로토콜이다. HTTP/2.0에서는 스펙에 SPDY를 반영할 예정이다.

  • 특징:

    1. TLS 위에서 동작한다.

      • https에서만 적용가능
    2. HTTP 헤더를 압축한다.

      • 요청마다 반복되는 내용을 압축해 성능 향상 효과가 나타남
    3. 바이너리로 프레임을 구성한다.

      • 파싱 속도가 향상되고 오류확률은 낮아진다.
    4. 다중 연결을 지원한다.

      • 다수의 요청, 응답 을 동시에 처리 할 수 있어 속도 향상
    5. 인터리빙을 허용한다.

      • 우선순위가 높은 데이터가 더 빨리 전송 될 수있다.
    6. 서버 푸시가 가능하다.

결론

HTTP 1.1 이 사용하는 전송방식(RFC7230)에는 몇가지 문제점이 존재했다.
HTTP/1.0은 TCP connection에서 한번에 하나의 요청 만이 가능했고 HTTP/1.1에서는 그보다 발전하여 request pipelining을 사용했지만 여전히 HOL Blocking 문제가 존재했다.
HTTP/2.0은 오랫동안 변화하지 않았던 HTTP를 현 웹 환경에 맞게 발전시켜 속도의 향상을 도모 한다는데 크 의의가 있다.

참고: http://http2.github.io/http2-spec/#intro 참고: http://helloworld.naver.com/helloworld/140351


'Major > Network' 카테고리의 다른 글

http vs https  (0) 2016.03.23
네트워크 - 총 정리  (0) 2015.12.18
네트워크 - Link Layer  (0) 2015.12.17
네트워크 - Network Layer  (0) 2015.12.10
네트워크 - Transport Layer  (0) 2015.12.09

※요약

인라인 함수는 프로그램의 실행 속도를 높이기 위해 추가된 기능이며 C언어의 매크로 함수와 비교된다.


(개발자 입장에서)일반 함수와 인라인 함수의 가장 큰 차이점은 함수의 호출 방식이다.

일반 함수의 호출 방법은 프로그램 실행 중 함수를 실행해야하면 해당 함수의 주소로 점프시켰다가, 함수의 처리가 종결되면 다시 원래의 자리로 돌아오는 것이다.

이렇게 앞뒤로 점프를 수행하고, 점프할 위치를 기억하려면 함수를 사용하는데 시간이 많이 걸린다.


인라인 함수는 컴파일된 함수 코드가 프로그램의 코드 안에 직접 삽입되어진다.

이 말은 컴파일러가 함수를 호출하는 대신, 그에 대응하는 함수 코드로 대체한다는 것을 의미하며 함수 호출없이 삽입된 함수 코드를 그 자리에서 처리하므로 해당 함수를 수행하기 위해 프로그램이 다른 주소로 점프했다가 되돌아 올 필요가 없어 속도면에서 유리하다.



일반 함수 어셈블리어


인라인 함수 어셈블리어



※특징

 - 인라인 함수를 사용하려면 함수 선언 앞에 inline이라는 키워드를 붙이거나 함수 정의 앞에 inline이라는 키워드를 붙인다.

 - 클래스 멤버 함수가 inline을 사용하려면, 함수 정의의 위치가 *.h에 있어야 한다. 안 그러면 확인할 수 없는 외부 참조라고 뜬다.

 - 프로그래머가 inline 선언을 해도 컴파일러가 인라인화를 거부할 수 있다.

 - 프로그래머가 inline 선언을 안 해도 컴파일러가 인라인화를 할 수 있다.

 - 함수의 덩치가 크거나 재귀호출이면 inline 요구를 거절하는 컴파일러도 있다.

 - 함수 코드의 수행 시간이 짧고 빈번하게 호출되는 함수가 아니라면, 인라인 함수로 인한 절대적인 시간 절약은 그다지 크지 않다.



※장점

 - 함수가 인라인화 되어 성능의 향상으로 이어질 수 있다.



※단점

 - 메모리 사용 측면에서는 인라인 함수가 일반 함수보다 불리하다.

   이유는 어떤 프로그램에서 인라인 함수를 열 번 호출한다면, 

   프로그램은 그 함수의 사본을 프로그램의 코드 안에 열 번이나 삽입해야 하기 때문이다.

 - 매크로 함수와 달리 자료형에 독립적이지 못 하다. 단, 템플릿을 이용하면 자료형에 독립적으로 사용할 수 있다.



※예제

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#include <iostream>
 
using namespace std;
 
inline void Test( int nNum1 );
 
int main( )
{
    Test( 2 );
 
    return 0;
}
 
void Test( int nNum1 )
{
    int nResult = nNum1;
}


+ Recent posts