선택자(selector)에 추가되지만 특별한 상태를 기술하는 대신, 문서의 특정 부분을 스타일할 수 있습니다. 예를 들어,::first-line가상 요소는 선택자에 의해 지정된 요소의 첫 줄만을 대상으로 합니다.
selector::pseudo-element (선택자) {
property (속성) : value (속성값) ;
}
주의할 점은선택자에 가상 요소를 하나만쓸 수 있으며 문장 내단일 선택자 뒤에 위치해야합니다.
<p class="boring-text">적당히 좋고 오래되고 지루한 글입니다.</p>
<p>지루하지도 흥미진진하지도 않은 적당한 글입니다.</p>
<p class="exciting-text">MDN에 공헌하는 것은 쉽고 재밌습니다.
동작하는 예제를 새로 추가하거나 기존의 흥미진진한 예제를 더 좋게 만들기 위해서 편집 버튼을 눌러보세요.</p>
.exciting-text::after {
content: "<- 바로 이 부분이 흥미진진합니다!";
color: green;
}
.boring-text::after {
content: "<- 지루해요!";
color: red;
}
선택자는 HTML요소를 선택해서 가져옵니다. CSS선택자와 마찬가지로 선택한 요소의 디자인속성을 적용하는 등 사용하고 이 때 HTML에 작성한 스타일은 사용자의 동작에 의해 스타일을 변경할 수 없어 정적이나 제이쿼리/자바스크립트 선택자를 이용하면 동적으로 스타일을 적용할 수 있습니다.
HTML의 문서 객체 구조를 그림으로 표현하면 나무 모양으로 생긴 트리구조로 가장 상위에 위치하는 html은 뿌리(Root)라 부르고, 뿌리부터 가지처럼 뻗어나가는 모양의 요소를 노드(Node)라고 합니다. 노드의 종류는 요소노드, 텍스트노드, 속성노드가 있습니다.
jQuery 선택자(selector) 사용 방법
선택자를 사용하기 위해서는 문서 객체를 불러와야 하기에 1이 아닌 2나 3의 방법으로 불러와야 합니다. 1은 body가 생성되기 이전에 선택자가 먼저 실행되어 선택자로 문서 객체를 선택할 수 없습니다.
내용의 이해를 위해 같은 것을 제이쿼리와 자바스크립트로 짜 보았음. 구현하고자 하는 것은 화면프레임을 동적으로 분할 및 통합 구성하는 것. (이 글은 디바이스 기반 반응형 이야기 아님) 사이드 바를 제외한 센터 패널을 통으로 하나, 가로반반, 세로반반으로 프레임을 나눠보고 프레임을 나눴을 때 각 패널의 위치를 특정 메뉴를 누를 때마다 전환도 하는 것이었음 (1을 2의 위치로 2를 1의 위치로)
var fullShow = $("#fullShow").hide();
var horizonShow = $("#horizonShow").hide();
var mul = $("#horizonShow, #fullShow, #defaultShow").hide();
var submenu = $("#leftPanel").show();
var defaultShow = $("#defaultShow").show();
var count = 0;
//쓰지 않는 다른 요소가 display:none임에도 불구하고 선택되는 문제
function crossClick() {
count++;
var a = document.getElementById("cp1");
var b = document.getElementById("cp2");
if (count % 2 == 1) {
b.parentNode.insertBefore(a, b.nextSibling);
} else {
b.parentNode.insertBefore(a, b);
}
}
원인 > id는 말 그대로 고유값이고 class가 좀 유한 편인데 본 특성과 다르게 겹쳐서 여러 개를 만들다보니 아래 horizonShow의 cp1를 선택하고 싶은데 다른 id 아래의 (순서대로 읽으니까 가장 위의) cp1이 선택됨
해결 > active된 자식...이런 식으로 동적으로 할당하면 될 것 같은데 짬이 안되서 defaultShow를 눌렀을 때는 defaultShow의 cp1 이런식으로 할당함
SDL는 C 프로그래밍 언어로 짜여진 크로스플랫폼 멀티미디어 라이브러리이다. 이 라이브러리는 비디오, 오디오, 사용자 입력 등의 계층을 추상화하여, 리눅스, 마이크로소프트 윈도, 맥 OS X 등 여러 운영 체제에서 실행이 가능하도록 한다. 이 라이브러리는 비디오, 이벤트, 디지털 오디오, CD-ROM, 사운드, 스레드, 공유 객체 불러오기, 네트워킹, 타이머를 관리한다. 이 라이브러리는 내부적으로 C로 작성되어 있으며, 대상 플랫폼에 따라 C++나 오브젝티브-C도 지원하며 C의 API를 제공함으로써 다른 언어와의 결합을 지원한다.
SDL은 다양한 환경하에서 작동할수 있도록 설계되어져 있으며, 모두 같은 소스코드를 사용할 수 있는 구조로 되어져 있습니다. 윈도우에서 작성한 코드를 그대로 리눅스에서 컴파일 하여 실행하도록 할 수 있으며, 심지어 맥이나 BeOS 등에서도 구동을 보장받을 수 있습니다. 공식적으로 Win32 / 리눅스 / MacOS / MacOS X 에서의 작동을 보장하며, Solaris / IRIX / FreeBSD / QNX / OSF/True64 등의 플랫폼에서도 비공식적으로 포팅되어져 있습니다.
1998년 초에 처음 출시된 이 라이브러리는 Sam Lantinga가 로키 소프트웨어용으로 작업하는 동안 만들어냈다. 그는 윈도 응용 프로그램을 매킨토시로 포팅하는 동안 이 개념을 떠올렸다. 그 뒤 SDL을 이용하여 둠을 BeOS로 포팅하였다. 일부 다른 자유 라이브러리들이 SDL에 맞추어 개발되었는데, 이를테면 SMPEG와 OpenAL이 있다. 그는 2008년에 갤럭시 게임웍스를 설립하여 SDL의 상업적인 지원을 돕기도 했으나 이 기업 계획은 시간 제한으로 인해 보류된 상태.
SDL 1.3은 SDL 1.2 코드 기반의 주요 업데이트로 자리잡았다. 1.2 API의 여러 부분을, 다중 입출력 옵션을 위한 더 일반적인 지원으로 대체하고 있다. 추가되는 기능으로는 이를테면 다중 창 지원, 다중 입력 장치 지원 (다중 마우스, 다중 키보드 등), 하드웨어 가속 2차원 그래픽, 더 나은 유니코드 지원이 있다. 그 뒤 1.3/2.0으로 브랜치가 이동됨에 따라[4] SDL 1.3 개발이 끝나면 끝으로 SDL 2.0이 될 예정이다.[5] SDL 1.3은 zlib 라이선스이므로 SDL 1.2와 달리 상용 클로즈드 소스 프로젝트에 정적 링크하여 자유롭게 이용할 수 있다.[6]
구조
라이브러리는 비디오, 오디오, CD-ROM, 조이스틱, 타이머.. 하부 시스템으로 나뉜다. 이러한 낮은 수준의 기본적인 지원뿐 아니라 다음과 같은 기능들도 몇 가지 더 지원한다. 이들은 "표준 라이브러리"를 이루고, 공식 웹사이트에서 제공되며 공식 문서에 포함되어 있다
장점
멀티 플랫폼을 지원하며, 하나의 소스코드로 여러가지 플랫폼에서 컴파일이 가능하다는 것입니다. 즉, 크로스 플랫폼(Cross-Platform) 멀티미디어 라이브러리 인 셈입니다.
SDL은 화면 제어는 물론, 시스템의 몇몇 이벤트 / 사운드 / CD-Rom 제어 / 쓰레드 / 타이머 등의 멀티미디어 관련 라이브러리도 함께 포함하고 있습니다.
SDL은 여러가지 확장을 통해 더 쉽고 강력하게 사용할 수 있도록 되어져 있습니다. jpg, png와 같은 이미지 파일을 불러오고 사용하기 위한 SDL_Image, 네트워크 기능을 활용하기 위한 SDL_Net, mp3, ogg 같은 사운드 파일을 다루기 위한 SDL_Mixer 등등... 여러가지 확장을 통해 더 쉽고 빠르게 게임을 개발 할 수 있습니다.
SDL은 OpenGL을 공식적으로 지원하며, SDL과 OpenGL을 이용하여 3D 게임을 쉽고 빠르게 제작할 수 있습니다. 심지어 OpenGL 학습을 위한 용도로도 SDL을 이용할 수 있습니다.
SDL은 여러 아마추어 개발자들이 사용하고, 충분히 그 성능 입증을 받아왔습니다. 따라서 세계 곳곳에 SDL 관련 정보가 아주 많으며, IGF 같이 굵직한 아마추어 게임 개발 대회에서도 SDL 사용을 인정해 주고 있습니다.
SDL은 어떤 환경하에서도 컴파일하고 실행해 볼 수 있으며, 쉽습니다.
SDL은 OS에 비 종속적인만큼, 라이브러리 간의 호환성이 100% 유지되어지지 않습니다. 몇몇 시스템 상에서는 풀 스크린 전환 함수가 제대로 작동하지 않기도 하며, 리눅스의 OpenGL과 윈도우의 OpenGL 간에도 동기화 옵션이 작동 되고, 작동 되지 않는 등의 호환성 문제는 여전히 남습니다.
철저하게 게임 제작을 위해 개발된 API이기 때문에 여러가지 윈도우 시스템에 종속적인 기능을 사용할 수 없습니다. 윈도우 창에 메뉴바를 단다거나, 트레이에 아이콘을 추가한다거나 하는 등의 옵션은 윈도우 시스템에 맡겨야 합니다.
S1000D는 기획(planning), 관리(management), 생산(production), 교환(exchange), 배포(distribution) 등의 기술 콘텐츠의 라이프 사이클을 관리할 수 있도록 지원합니다. 항공 분야를 시작으로 자동차, 조선, 반도체 등 방대한 양의 기술 문서를 다루는 산업 분야로 그 사용성이 확대되고 있습니다.
S1000D는 데이터 모듈(data module), 퍼블리케이션 모듈(publication module), 공유 가능 콘텐츠 객체 참조 모델(SCORM), Common Source Data Base(CSDB), Business Rules Exchange(BREX) 등으로 구성되어 있습니다.
SDL의 소프트웨어는 번역, 기술 컨텐츠 관리, 향상된 디지털 경험, xml 자동화 퍼블리싱 등이 가능합니다. 자동차산업, 제조, 금융서비스, 정부, 법률, 생명과학, 항공우주, 의료, 하이테크소프트웨어, 관광레저, 소매 등 산업별 솔루션으로도 적응 가능합니다.
SDL Contenta Publishing Suite에 포함된 SDL LiveContent S1000D가대화형 뷰어를 통해 현장의 기술자에게 정확한 정보를 제공해주므로, 기술자가 필요한 컨텐츠에 빠르게 액세스할 수 있습니다. 이 Suite의 IETP(Interactive Electronic Technical Publishing) 기능은거의 실시간으로 컨텐츠를 제공하므로 사용자가 가장 필요할 때 원하는 형식으로 최신 컨텐츠를 얻을 수 있습니다.
S1000D를 사용하려면 문서를 개별 XML 레이블 및 메타 데이터로 표시 할 수 있고 계층 적 XML 구조의 일부인 개별 데이터 항목 (데이터 모듈이라고 함)으로 분류해야합니다.이를 통해 XML 트리 아래로 향하는 경로를 변경하지 않고도 단일 데이터 항목을 업데이트 할 수 있습니다.따라서 분할 및 분류 된 지식은 많은 출판물간에 공유 될 수 있으며 기본 S1000D (XML) 문서에서 항목을 업데이트하면 종속 출판물의 업데이트에 자동으로 영향을 미칩니다.
DM(Data Module) 데이터 모듈 구조 : DM(Data Module)은 기술정보(설명, 절차, 운영 데이터 등)를 저장하기위한 XML 기반의 데이터 로서 구성하는 최소 정보 단위로 DM의 상태 및 식별정보를 나타내는 ‘IDSTATUS’와 기술정보가 저장되는 ‘CONTENT’ 영역으로 구분됩니다. DM 유형은 S1000D 규격에서 정의한 Schema에 의해 구분 되며, S1000D 4.1버전 기준으로 총 22가지로 구성되어 있습니다.
Data Module Code(DMC) : DM을 식별하기 위한 표준화, 구조화된 코드로 DM의 ‘IDSTATUS’ 영역 내 작성되며 DMC를 통하여 CSDB 내 저장된 DM을 관리합니다.
DMC는 최소17자리에서 최대 41자리로 모델정보, SNS, 정보유형 등을 구분할 수 있는 코드로 구성되며 BR 설정 시 해 당 프로젝트 특성을 고려하여 적절한 DMC 구조를 결정해야 합니다. DM 목록은 개발 프로세스를 거쳐 계속적으로 추 가 및 삭제될 것이다. DM 목록 및 이력관리를 위 하여 DM을 생성하기 전에 Data Module Requirements List(DMRL)를 작성해야 한다. DMRL은 DMC를 기준으로 상태 및 식별정보와 간 략한 내용을 포함하여 작성하며, CSDB 내 DM 생산 및 통합 관리를 지원합니다.
S1000D 기반의 문서는 데이터 모듈(data module)이라는 정보 구조 단위로 작성합니다. 각 데이터 모듈은 그 자체만으로 완결성을 갖춘 콘텐츠이며 재사용이 가능합니다. 각 데이터 모듈에 중복되지 않는 형식으로 지정되는 데이터 모듈 코드(DMC)를 이용하면 데이터 식별과 체계적인 관리가 가능합니다. 데이터 모듈은 다음 2개의 섹션으로 구성되어 있습니다.
Identification and Status: 데이터 식별 및 관리에 필요한 정보를 입력하는 영역(일종의 메타 데이터)
Common Source Database(CSDB) CSDB란 DM을 포함한 기술문서 출판을 위해 생성되는 모든 정보객체를 저장하고 관리하는 데이터베이스로 기술정보의 저작, 관리 및 출판 을 포함한 개발 전체 프로세스가 CSDB를 통해 진행됩니다.
S1000D 규격을 적용한 출판 방식은 데이터를 모듈화하여 생성하고, 생성된 정보를 참조하여 출판하는 방식으로 중복 정보가 발생되지 않고, 또한 추후 수정소요 시 하나의 데이터 수정만으로 관련되는 모든 데이터가 수정되는 효과가 있습니다.
개발 절차는 총 5단계로 Business Rule 설정, Informtion Set 설정, DMRL 설정, DM 생성 및 저작, 출판 단계로 분류해볼 수 있습니다.
(1) Business Rule 설정 : S1000D 규격을 어떻게 활용할 것인지 개발자, 사용자 및 유관조직간의 협의를 통하여 설정
(2) Information Set 설정 : Information Set은 요구되는 기술문서의 범위와 깊이로서, 생성할 기술문서 별 적용되는 DM 유형(Schema 및 Information Code)을 의미한다. S1000D 규격에서 체계 특성 별 기본 Information Set을 제안하지만, 필요 시 프로젝트 특성에 맞춰 테일러링하여 적용한다.
(3) DMRL 생성 : 프로젝트에 요구되는 DM을 식 별하고 DMRL를 작성한다.
(4) DM 생성 및 저작 : DMRL 및 BR에 근거하 여 DM 생성 및 기술정보를 저작한다.
(5) 출판 : 기술문서 출판을 위한 CSDB의 정보 객체들(DM, 도해, 멀티미디어 등)을 구성하여 책자형과 전자식 기술교범을 생성한다.
2005년 6월 8일 출시된 3D 및 2D 비디오 게임의 개발 환경을 제공하는 게임 엔진 (라이브러리의 집합) 으로 Multi-Platform의 Mono Framework (Xamarin) 입니다.
많은 Device 업체의 Testbed로 사용 중이며 C# 기반의 AR, VR에 대한 강력한 기능 제공하며 Asset Store 로 유 무료의 스토어 개념으로 퀄리티가 좋은 소스들을 활용 가능합니다. (경우에 따라 Asset Store를 통한 수익이 사업모델이 될 수 있음)
유니티는 Component Based Engine으로 GameObject와 Component의 형태로 기능이 정의되는데 모든 기능은 Component의 형태로 개발되며, GameObject는 Component를 담는 Container의 역할과 Object의 공통 Data만 포함하는 기능이 있습니다.
Entity Component System을 생각
에디터를 이용해 컨텐츠를 제작하게 되는데 각 패널은 하이어락키(Hiarachy), View(Scene View, Game View), Inspector, Project/Console 영역으로 나뉘어집니다.
Hierachy에서 3d object -> plane, sphere를 설치해보며 Scene View에서 마우스 우클릭, wasd를 통해 SceneView의 카메라를 움직여도 보고, .Inpector의 Transform을 통해 Position, Rotation, Scale를 조정해보고 Gizmo를 통해 Transform을 제어해봅니다. 이게 기본적인 기능입니다 alt를 누르고 마우스 왼쪽 버튼을 드래그하면 시야 조정이, 마우스 우버튼을 누르고 asdeq는 시야 조정 및 게임 내부에서처럼 앞뒤좌우 이동이 가능합니다.
유니티의 좌표계는 왼손좌표계 (left handed)를 사용합니다. 다른 3D 프로그램의 좌표계는 각각 다음과 같습니다.
Rendering Coordinate System
Rendering Coordinate System
Transform을 공유하는 Component들
1) Transfrom (1.Local Spalce->Model Matrix)
Local To World
Position, Rotation, Scale
계층구조의 Child에 있다면 부모로부터의 Local 좌표계로 표시
실제 렌더링 될 때는 자신의 Matrix에 부모의 Matrix를 곱해서 적용됨
2) Camera - ViewMatrix (2.World Space->View Matrix)
World To View
Camera의 Forward, Up Vector를 기준으로 생성
이전 Transform Component에서 구해진 World Matrix에 Camera의 ViewMatrix를 곱함
연산이 완료되면 카메라를 기준으로 모든 오브젝트가 정렬됨
3) Camera - Projection Matrix (3.View Space->Projection Matrix)
View To Projection
Ortho(직교), Perspective(원근) 투영
2D기법으로 Ortho를 사용 - left, right, up, bottom, near, far - 단위 : M단위
3D 기법으로 Perspective를 사용 - fov, aspect Ratio, near, far - 단위 : fov(각도), aspect ratio(화면의 가로세로 비율), near, far(M단위)
OnEnable: Component나 GameObject가 Enable(Active:true)되는 시점에 호출
Start: Component나 GameObject가 Enable(Active:true)되는 시점에 한번 호출
FixedUpdate: Edit->Project Setting->Time 에서 Fixed Timestep에 맞춰 호출(주의)
Update: 매 프레임 한번 호출
LateUpdate: 매 프레임 한번 호출
OnDisable: Component나 GameObject가 Disable(Active:false)되는 시점에 호출
OnDestroy: Component가 Destroy되는 시점에 한번 호출
FixedUpdate의 경우 한 프레임이 Fixed Timestep보다 짧으면 해당 프레임에서 무시될 수 있고, Fixed Timestep보다 길면 해당 프레임에서 여러번 호출될 수 있다. FixedUpdate에서는 deltaTime이 아니라 fixedDeltaTime를 사용
Script Excution Order
Unity의 Script는 Message Driven의 방식으로 호출되어짐
각각의 Script에는 어떠한 우선순위도 정의되지 않음
Script에서 다른 Script를 참조하여 사용할 때 Script의 실행 우선순위에 따라 오류가 발생할 수 있음
위 오류를 해결하는 방법이 Script Excution Order
Edit -> Project Setting -> Script Excution Order
Inspector창의 우측하단 ‘+’버튼을 통해 Script의 Excution Order를 제어할 수 있음
// Raycast를 참고하여 mouseInput을 이용한 Raycast를 구현하여보자
Vector3 fwd = transform.TransformDirection(Vector3.forward);
if (Physics.Raycast(transform.position, fwd, 10))
print("There is something in front of the object!");
Coroutine
Update함수는 매 초마다 fps만큼 호출된다.
1초에 한번 혹은 5초에 한번 실행될 기능을 Update에서 처리하는 것은 불합리 - > Coroutine을 제공
// StartCoroutine은 해당하는 함수를 Coroutine에 등록시키는 것
public IEnumerator Function()
// 실제 Coroutine을 Update와 분리시키는 코드
yield return new WaitForFixedUpdate()
// 이 코드는 IEnumerator를 반환하는 함수에서만 활용할 수 있다.
// yield return의 특징은 다시 해당 메소드가 호출될 때 yield코드로 돌아온다는 것
yield return의 다양한 예
yield return null=> 다음 프레임까지 대기
yield return new WaitForSeconds(float)=> 지정된 초 만큼 대기
yield return new WaitForFixedUpdate()=> 다음 물리 프레임까지 대기
yield return new WaitForEndOfFrame()=> 모든 렌더링작업이 끝날 때까지 대기
yield return StartCoRoutine(string)=> 다른 코루틴이 끝날 때까지 대기
yield return new WWW(string)=> 웹 통신 작업이 끝날 때까지 대기
yield return new AsynOperation=> 비동기 작업이 끝날 떄까지 대기
3. Camera, Light, Shader를 통한 Rendering
Camera란?
- 한 화면의 렌더링을 담당하는 Component
주요 항목
Clear
Culling Mask
Projection
Ortho
Perspective
Near, Far
Viewport
Rendering Path
Forward, Deferred
Target Display
Target Texture
예시 : 거울 구현
거울로 사용할 plane의 뒤에 카메라를 위치시킨다
해당 카메라에 Target Texture를 설정하여 Texture에 해당 카메라로 렌더링한다.
KanBan System 이라는 것이 있는데 To do, Doing, Done 등으로 나누어서 분류 (포스트잇을 붙이는 등) 방법이다. 마소 플래너는 버킷 + 카드 방식을 도입하면서 기존 엑셀에서 했던 그대로 가능합니다. 업무 처리 정도를 자동 시각화해서 캘린더와 그래프로도 볼 수 있다. 보고하기도 좋을 듯 합니다. 엑셀로도 추출되며 Outlook 일정에도 추가 가능합니다.
단위 별로 업무 진행이 가능합니다. 상-하 위주의 경직된 커뮤니케이션에서 좌-우 등으로도 직원끼리 활발한 업무 소통이 가능합니다. 1: 다는 공유된 파일, 문서 등은 프라이빗한 OneDrive에 저장된다. 팀 단위 대화는 SharePoint에 업로드되며 팀 라이브러리 채녈명의 폴더에 저장됩니다. Dropbox, Google Drive도 사용가능합니다.일괄복원이라는 기능이 있어서 랜섬웨어에 감염되도 감염 이전으로 돌릴 수 있습니다. (Nas는 파일 공유에는 좋으나 뭘 설정 안하면 자동백업이 없다?)
버전 관리(Version History / 버전 기록) 도 가능합니다. 오피스 문서는 최대 99명까지 동시 편집이 가능하며 온라인으로도 (라이선스가 없어도) 수정 가능 (온라인은 레이아웃 틀어지는 경우가 있던데 보완은 했나?) 윈도우/맥용 원드라이브 동기화되어 팀 별 쉬운 동기화 기능을 제공합니다. 구글온라인문서편집처럼 편집하는 부분과 작업하는 사람이 보입니다.
- 챗봇 : 채팅 로봇의 줄임말로 AI를 기반으로 사람과 자동으로 대화를 나누는 소프트웨어. 카톡 챗봇을 상상하면 이해가 빠르다. 장점은 패턴이 비슷하며 노력이 적게 든다. 약 1주일에서 2틀 안에 만든다.
대화형 AI, Conversational AI의 사례 (MS 프레임웤을 사용해서 만든 회사)
아시아나항공챗봇 아론(Aaron), 맥도날드 드라이브쓰루, 현대차 코나 챗봇 (번역엔진을 이용, 5개국어) 기타 : LG, NCSOFT의 게임 런쳐에 챗봇을 이식. (게임 레벨별 장비추천, 게임 실행 시 오류 직면하면 답을 찾아주는 등, 데이터 쌓이면 프로모션 등), 해법 천재*육의 교육용 안드로이드태블릿 안의 챗봇 (연령별로 대답하는 DB도 있음). L*전자의 연말정산/공제 콜센터 질문 시스템(세무서의 엑셀 파일에서 바뀐 내용을 학습시킨 뒤 이틀만에 제작. 하루 700콜 소화, 정확도 70% (높은 편이라고 한다.), 진에어 챗봇.
MDS : 스타일러 안에 패션스타일링추천, 일기예보 대답 등. 기능은 잘 작동했으나 호출 시(트리거: 시리야, 구글,) 응답을 해야하는데 전시회에 내놓자 언어별로 인식을 못하는 문제 발생.
쓱배송 챗봇 : 정확성을 높이기 위해 인력과 비용 투자를 많이 했다.
Conversation AI 구축 시 필요 기술
1. MicrosoftBot Framework 4.0
이미 오픈소스, 서비스화가 되어 있어서 결국 웹개발이며 환경설정이 반 이상이라고 합니다. 이미 자연어처리기능이나 채팅프레임워크 등 라이브러리로 다 있습니다 C#이나 자바스크립트 (Node.js)로 개발을 추천합니다. 자바나 파이썬은 별 일(?) 다 겪을 수도 있다고 합니다.
Azure 마이크로소프트 기반으로 Web App Bot 서비스가 돌아갑니다. 웹챗은 기본 제공되며 다양한 서비스들이 연결 가능합니다. 스카이프, 그룹, 라임 등도 연결됨 페이스북 연결할 경우 개발자용 서비스키 등이 세팅 시 필요합니다.
* 깃허브에 Bot Builder SDK v4 등 참고.
개발환경 구축
비쥬얼스튜디오 2019 버전 추천. (2017 이상) 설치 후 설정에서 AS.net과 Azure 개발 체크 추가로 Bot Builder v4 SDK Temlate for ... 설치 Bot Emulator 설치 ( 클라우드와 메신저(채널)을 커버해준다 )
단축키 설정은 Windows - Preferences - Java - Editor - Typing - Automatically insert at correct position에서 해 줍니다. sysout이나 syso 처럼 템플릿을 수정하거나 추가하려면 환경설정 - 자바 - 편집기 - 템플릿 에서 할 수 있습니다.
소스 코드 형식 및 공통 주석 설정은 1. 환경설정 - 자바 -> 코드스타일 -> 코드포멧터 -> 가져오기 -> 프로파일.xml을읽음 2. 다수의자바파일에 프로파일을 적용시 패키지 탐색기, 패키지 선택후[소스->형식화]를선택 3. 환경설정->자바->코드스타일->코드템플리트->가져오기->템플리트.xml을사용
단축키
기능
Ctrl + Shift + L
단축키 보기 Hint (단축키 목록)
Ctrl + F6
창간 전환 (소스코드 네비게이션)
Ctrl + F11
바로 전에 실행했던 클래스 실행
Ctrl + Shift + B
브레이크 포인트 설정/해제
F11
디버깅
F8
디버깅 계속
F6
디버깅 한줄씩 실행(step over)
F5
디버깅 한줄씩 실행 함수 내부로 들어감(step into)
F7
현재 함수를 빠져나온다.(Step out / return)
Ctrl + 마우스커서(혹은 F3)
클래스나 메소드 혹은 멤버를 상세하게 검색하고자 할때
Alt + Left, Alt + Right
작업창 이동
Alt + 왼쪽화살표, 오른쪽화살표
현재이전위치,현재이후위치
Ctrl + O
해당 소스의 메소드 리스트를 확인하려 할때
F3
선언된 위치, 변수로 이동, 메소드 정의부로 이동(Open Declaration)
F4 (Open Type Hierarchy)
클래스명을 선택하고 누르면 현재 해당 클래스의 계층구조 상속관계를 볼 수 있다.
Ctrl + F
문자열 찾기
Ctrl + K
찾고자 하는 문자열을 블럭으로 설정한 후 키를 누른다.블럭지정 후 뒤로 찾기
Ctrl + Shift + K
블럭지정 후 앞으로 찾기
Ctrl + J
입력하면서 찾을 수 있음. 한자씩바로찾기,상태표시줄에 Incremental Find라고 표시(next:DownArrow, prev:UpArrow)
Ctrl + Shift + J
입력하면서 거꾸로 찾아갈 수 있음.
Ctrl + Space
입력 보조장치(Content Assistance) 강제 호출
F2
(컴파일 에러) 빨간줄에 커서를 대고 키를 누르면 에러의 원인에 대한 힌트를 제공
Ctrl + L
원하는 소스 라인으로 이동. 로컬 히스토리 기능을 이용하면 이전에 편집했던 내용으로 변환이 가능
Ctrl + Shift + Space
메소드의 가로안에 커서를 놓고 이 키를 누르면 파라미터 타입 힌트를 볼 수 있다.
Ctrl + D
한줄 삭제
Ctrl + Shift + Delete
현재 위치에서 라인 끝까지 삭제(Delete to End of Line)
Ctrl + W
파일 닫기
Ctrl + Shift + F4
모두 닫기.
Ctrl + I
들여쓰기 자동 수정(인덴트 중심의 자동구문정리)
Ctrl + Shift + /
블록 주석(/* */). 선택영역 block comment 설정
Ctrl + Shift + \
블록 주석 제거
Ctrl + /
한꺼번에 여러 줄 주석처리. 해제하려면 반대로.
Alt + Shift + J
Javadoc타입의 주석처리 (Add Javadoc Comment)
Alt + Up(Down)
위(아래)줄과 바꾸기. 줄 위치 서로 바꿈 (Move Lines Up/Down)
Alt + Shift + 방향키
블록 선택하기
Ctrl + Shift + Space
메소드의 파라메터 목록 보기
Ctrl + Shift + O
소스에 필요한 패키지의 자동 import
Ctrl + Shift + M
캐럿이 위치한 대상에 필요한 특정클래스 import
Ctrl + M
현재선택영역 최대화 (전체화면 토글)
Ctrl + Alt + Up(Down)
한 줄 (블럭) 복사(Duplicate Lines)
Ctrl + .
다음 annotation(에러, 워닝, 북마크 가능)으로 점프
Ctrl + ,
이전 오류부분으로 가기
Ctrl + 1
퀵 픽스
Ctrl + T
하이어라키 팝업 창 띄우기(인터페이스 구현 클래스간 이동시 편리) 간단한 클래스 상속관계 보기 (Quick Hierarchy)
Ctrl + O
현재 클래스 메서드, 맴버변수 보기 (Quick Outline) , 메소드나 필드 이동하기
Ctrl + F6
창간 전환, UltraEdit 나 Editplus 의 Ctrl + Tab 과 같은 기능
에디터가 여러 파일을 열어서 작업중일때 Ctrl + F6 키를 누르면 여러파일명이 나오고 F6키를 계속 누르면 아래로Ctrl + Shift + F6 키를 누르면 위로 커서가 움직인다.
옵티마이저(Optimizer)는 사용자가 질의한 SQL문에 대해 최적의 실행 방법을 결정하는 역할을 수행한다. 이러한 최적의 실행 방법을 실행계획(Execution Plan)이라고 한다. 관계형 데이터베이스는 궁극적으로 SQL문을 통해서만 데이터를 처리할 수 있다. JAVA, C등과 같은 프로그램 언어와는 달리 SQL은 사용자의 요구사항만 기술할 뿐 처리과정에 대한 기술은 하지 않는다. 그러므로 사용자의 요구사항을 만족하는 결과를 추출할 수 있는 다양한 실행 방법이 존재할 수 있다. 다양한 실행 방법들 중에서 최적의 실행 방법을 결정하는 것이 바로 옵티마이저의 역할이다. 관계형 데이터베이스는 옵티마이저가 결정한 실행 방법대로 실행 엔진이 데이터를 처리하여 결과 데이터를 사용자에게 전달할 뿐이다. 옵티마이저가 선택한 실행 방법의 적절성 여부는 질의의 수행 속도에 가장 큰 영향 미치게 된다. 이런 의미에서 관계형 데이터베이스에서 진정한 프로그래머는 옵티마이저라고 할 수 있다. 최적의 실행 방법 결정이라는 것은 어떤 방법으로 처리하는 것이 최소 일량으로 동일한 일을 처리할 수 있을지 결정하는 것이다. 그러나 이러한 결정을 옵티마이저는 실제로 SQL문을 처리해보지 않은 상태에서 결정해야 하는 어려움이 있다. 옵티마이저가 최적의 실행 방법을 결정하는 방식에 따라 [그림 Ⅱ-3-1]과 같이 규칙기반 옵티마이저(RBO, Rule Based Optimizer)와 비용기반 옵티마이저(CBO, Cost Based Optimizer)로 구분할 수 있다.
현재 대부분의 관계형 데이터베이스는 비용기반 옵티마이저만을 제공한다. 비록 규칙기반 옵티마이저를 제공하더라도 신규 기능들에 대해서는 더 이상 지원하지 않는다. 다만 하위 버전 호환성을 위해서만 규칙기반 옵티마이저가 남아 있을 뿐이다. 그렇지만 규칙기반 옵티마이저의 규칙은 보편 타당성에 근거한 것들이다. 이러한 규칙을 알고 있는 것은 옵티마이저의 최적화 작업을 이해하는데 도움이 된다.
가. 규칙기반 옵티마이저
규칙기반 옵티마이저는 규칙(우선 순위)을 가지고 실행계획을 생성한다. 실행계획을 생성하는 규칙을 이해하면 누구나 실행계획을 비교적 쉽게 예측할 수 있다. 규칙기반 옵티마이저가 실행계획을 생성할 때 참조하는 정보에는 SQL문을 실행하기 위해서 이용 가능한 인덱스 유무와 (유일, 비유일, 단일, 복합 인덱스)종류, SQL문에서 사용하는 연산자(=, <, <>, LIKE, BETWEEN 등)의 종류 그리고 SQL문에서 참조하는 객체(힙 테이블, 클러스터 테이블 등)의 종류 등이 있다. 이러한 정보에 따라 우선 순위(규칙)가 정해져 있고, 이 우선 순위를 기반으로 실행계획을 생성한다. 결과적으로 규칙기반 옵티마이저는 우선 순위가 높은 규칙이 적은 일량으로 해당 작업을 수행하는 방법이라고 판단하는 것이다. [그림 Ⅱ-3-2]는 Oracle의 규칙기반 옵티마이저의 15가지 규칙이다. 순위의 숫자가 낮을수록 높은 우선 순위이다.
규칙기반 옵티마이저의 우선 순위 규칙 중에서 주요한 규칙에 대해서만 간략히 설명한다.
규칙 1. Single row by rowid : ROWID를 통해서 테이블에서 하나의 행을 액세스하는 방식이다. ROWID는 행이 포함된 데이터 파일, 블록 등의 정보를 가지고 있기 때문에 다른 정보를 참조하지 않고도 바로 원하는 행을 액세스할 수 있다. 하나의 행을 액세스하는 가장 빠른 방법이다.
규칙 4. Single row by unique or primary key : 유일 인덱스(Unique Index)를 통해서 하나의 행을 액세스하는 방식이다. 이 방식은 인덱스를 먼저 액세스하고 인덱스에 존재하는 ROWID를 추출하여 테이블의 행을 액세스한다.
칙 8. Composite index : 복합 인덱스에 동등(‘=’ 연산자) 조건으로 검색하는 경우이다. 예를 들어, 만약 A+B 칼럼으로 복합 인덱스가 생성되어 있고, 조건절에서 WHERE A=10 AND B=1 형태로 검색하는 방식이다. 복합 인덱스 사이의 우선 순위 규칙은 다음과 같다. 인덱스 구성 칼럼의 개수가 더 많고 해당 인덱스의 모든 구성 칼럼에 대해 ‘=’로 값이 주어질 수록 우선순위가 더 높다. 예를 들어, A+B로 구성된 인덱스와 A+B+C로 구성된 인덱스가 각각 존재하고 조건절에서 A, B, C 칼럼 모두에 대해 ‘=’로 값이 주어진다면 A+B+C 인덱스가 우선 순위가 높다. 만약 조건절에서 A, B 칼럼에만 ‘=’로 값이 주어진다면 A+B는 인덱스의 모든 구성 칼럼에 대해 값이 주어지고 A+B+C 인덱스 입장에서는 인덱스의 일부 칼럼에 대해서만 값이 주어졌기 때문에 A+B 인덱스가 우선 순위가 높게 된다.
규칙 9. Single column index : 단일 칼럼 인덱스에 ‘=’ 조건으로 검색하는 경우이다. 만약 A 칼럼에 단일 칼럼 인덱스가 생성되어 있고, 조건절에서 A=10 형태로 검색하는 방식이다.
규칙 10. Bounded range search on indexed columns : 인덱스가 생성되어 있는 칼럼에 양쪽 범위를 한정하는 형태로 검색하는 방식이다. 이러한 연산자에는 BETWEEN, LIKE 등이 있다. 만약 A 칼럼에 인덱스가 생성되어 있고, A BETWEEN ‘10’ AND ‘20’ 또는 A LIKE '1%' 형태로 검색하는 방식이다.
규칙 11. Unbounded range search on indexed columns : 인덱스가 생성되어 있는 칼럼에 한쪽 범위만 한정하는 형태로 검색하는 방식이다. 이러한 연산자에는 >, >=, <, <= 등이 있다. 만약 A 칼럼에 인덱스가 생성되어 있고, A > '10' 또는 A < '20' 형태로 검색하는 방식이다.
규칙 15. Full table scan : 전체 테이블을 액세스하면서 조건절에 주어진 조건을 만족하는 행만을 결과로 추출한다.
규칙기반 옵티마이저는 인덱스를 이용한 액세스 방식이 전체 테이블 액세스 방식보다 우선 순위가 높다. 따라서 규칙기반 옵티마이저는 해당 SQL문에서 이용 가능한 인덱스가 존재한다면 전체 테이블 액세스 방식보다는 항상 인덱스를 사용하는 실행계획을 생성한다. 규칙기반 옵티마이저가 조인 순서를 결정할 때는 조인 칼럼 인덱스의 존재 유무가 중요한 판단의 기준이다. 조인 칼럼에 대한 인덱스가 양쪽 테이블에 모두 존재한다면 앞에서 설명한 규칙에 따라 우선 순위가 높은 테이블을 선행 테이블(Driving Table)로 선택한다. 한쪽 조인 칼럼에만 인덱스가 존재하는 경우에는 인덱스가 없는 테이블을 선행 테이블로 선택해서 조인을 수행한다. 조인 칼럼에 모두 인덱스가 존재하지 않으면 FROM 절의 뒤에 나열된 테이블을 선행 테이블로 선택한다. 만약 조인 테이블의 우선 순위가 동일하다면 FROM 절에 나열된 테이블의 역순으로 선행 테이블을 선택한다. 규칙기반 옵티마이저의 조인 기법의 선택은 다음과 같다. 양쪽 조인 칼럼에 모두 인덱스가 없는 경우에는 Sort Merge Join을 사용하고 둘 중하나라도 조인 칼럼에 인덱스가 존재한다면 일반적으로 NL Join을 사용한다.
다음 SQL문을 이용해서 규칙기반 옵티마이저의 최적화 과정을 알아보자.
SELECT ENAME FROM EMP WHERE JOB = 'SALESMAN' AND SAL BETWEEN 3000 AND 6000 INDEX --------------------------------- EMP_JOB : JOB EMP_SAL : SAL PK_EMP : EMPNO (UNIQUE)
조건절에서 JOB 칼럼의 조건은 ‘=’, SAL 칼럼의 조건은 ‘BETWEEN’으로 값이 주어졌고 각각의 칼럼에 단일 칼럼 인덱스가 존재한다. 우선 순위 규칙에 따라 JOB 조건은 규칙 9의 단일 칼럼 인덱스를 만족하고 SAL 조건은 규칙 10의 인덱스상의 양쪽 한정 검색을 만족한다. 따라서 우선 순위가 높은 EMP_JOB 인덱스를 이용해서 조건을 만족하는 행에 대해 EMP 테이블을 액세스하는 방식을 선택할 것이다. 다음은 규칙기반 옵티마이저가 생성한 실행계획이다.
Execution Plan ------------------------------------------------------------ SELECT STATEMENT Optimizer=CHOOSE TABLE ACCESS (BY INDEX ROWID) OF 'EMP' INDEX (RANGE SCAN) OF 'EMP_JOB' (NON-UNIQUE)
나. 비용기반 옵티마이저
규칙기반 옵티마이저는 조건절에서 ‘=’ 연산자와 'BETWEEN' 연산자가 사용되면 규칙에 따라 ‘=’ 칼럼의 인덱스를 사용하는 것이 보다 적은 일량 즉, 보다 적은 처리 범위로 작업을 할 것이라고 판단한다. 그러나 실제로는 ‘BETWEEN’ 칼럼을 사용한 인덱스가 보다 일량이 적을 수 있다. 단순한 몇 개의 규칙만으로 현실의 모든 사항을 정확히 예측할 수는 없다. 비용기반 옵티마이저는 이러한 규칙기반 옵티마이저의 단점을 극복하기 위해서 출현하였다. 비용기반 옵티마이저는 SQL문을 처리하는데 필요한 비용이 가장 적은 실행계획을 선택하는 방식이다. 여기서 비용이란 SQL문을 처리하기 위해 예상되는 소요시간 또는 자원 사용량을 의미한다. 비용기반 옵티마이저는 비용을 예측하기 위해서 규칙기반 옵티마이저가 사용하지 않는 테이블, 인덱스, 칼럼 등의 다양한 객체 통계정보와 시스템 통계정보 등을 이용한다. 통계정보가 없는 경우 비용기반 옵티마이저는 정확한 비용 예측이 불가능해져서 비효율적인 실행계획을 생성할 수 있다. 그렇기 때문에 정확한 통계정보를 유지하는 것은 비용기반 최적화에서 중요한 요소이다.
[그림 Ⅱ-3-3]과 같이 비용기반 옵티마이저는 질의 변환기, 대안 계획 생성기, 비용 예측기 등의 모듈로 구성되어 있다. 질의 변환기는 사용자가 작성한 SQL문을 처리하기에 보다 용이한 형태로 변환하는 모듈이다. 대안 계획 생성기는 동일한 결과를 생성하는 다양한 대안 계획을 생성하는 모듈이다. 대안 계획은 연산의 적용 순서 변경, 연산 방법 변경, 조인 순서 변경 등을 통해서 생성된다. 동일한 결과를 생성하는 가능한 모든 대안 계획을 생성해야 보다 나은 최적화를 수행할 수 있다. 그러나 대안 계획의 생성이 너무 많아지면 최적화를 수행하는 시간이 그만큼 오래 걸린 수 있다. 그래서 대부분의 상용 옵티마이저들은 대안 계획의 수를 제약하는 다양한 방법을 사용한다. 이러한 현실적인 제약으로 인해 생성된 대안 계획들 중에서 최적의 대안 계획이 포함되지 않을 수도 있다. 비용 예측기는 대안 계획 생성기에 의해서 생성된 대안 계획의 비용을 예측하는 모듈이다. 대안 계획의 정확한 비용을 예측하기 위해서 연산의 중간 집합의 크기 및 결과 집합의 크기, 분포도 등의 예측이 정확해야 한다. 보다 나은 예측을 위해 옵티마이저는 정확한 통계정보를 필요로 한다. 또한 대안 계획을 구성하는 각 연산에 대한 비용 계산식이 정확해야 한다. 앞에서 규칙기반 옵티마이저는 항상 인덱스를 사용할 수 있다면 전체 테이블 스캔 보다는 인덱스를 사용하는 실행계획을 생성한다고 했다. 그렇지만 비용기반 옵티마이저는 인덱스를 사용하는 비용이 전체 테이블 스캔 비용보다 크다고 판단되면 전체 테이블 스캔을 수행하는 방법으로 실행계획을 생성할 수도 있다. 비용기반 옵티마이저는 통계정보, DBMS 버전, DBMS 설정 정보 등의 차이로 인해 동일 SQL문도 서로 다른 실행계획이 생성될 수 있다. 또한 비용기반 옵티마이저의 다양한 한계들로 인해 실행계획의 예측 및 제어가 어렵다는 단점이 있다.
2. 실행계획
실행계획(Execution Plan)이란 SQL에서 요구한 사항을 처리하기 위한 절차와 방법을 의미한다. 실행계획을 생성한다는 것은 SQL을 어떤 순서로 어떻게 실행할 지를 결정하는 작업이다. 동일한 SQL에 대해 결과를 낼 수 있는 다양한 처리 방법(실행계획)이 존재할 수 있지만 각 처리 방법마다 실행 시간(성능)은 서로 다를 수 있다. 옵티마이저는 다양한 처리 방법들 중에서 가장 효율적인 방법을 찾아준다. 즉, 옵티마이저는 최적의 실행계획을 생성해 준다. 생성된 실행계획을 보는 방법은 데이터베이스 벤더마다 서로 다르다. 실행계획에서 표시되는 내용 및 형태도 약간씩 차이는 있지만 실행계획이 SQL 처리를 위한 절차와 방법을 의미한다는 기본적인 사항은 모두 동일하다. 실행계획을 보고 SQL이 어떻게 실행되는지 정확히 이해할 수 있다면 보다 향상된 SQL의 이해 및 활용이 가능하다. Oracle의 실행계획 형태는 [그림 Ⅱ-3-4]와 같다. 실행계획을 구성하는 요소에는 조인 순서(Join Order), 조인 기법(Join Method), 액세스 기법(Access Method), 최적화 정보(Optimization Information), 연산(Operation) 등이 있다
조인 순서는 조인작업을 수행할 때 참조하는 테이블의 순서이다. 예를 들어, FROM 절에 A, B 두 개의 테이블이 존재할 때 조인 작업을 위해 먼저 A 테이블을 읽고 B 테이블을 읽는 작업을 수행한다면 조인 순서는 A → B이다. [그림 Ⅱ-3-4]에서 조인 순서는 EMP → DEPT이다. 논리적으로 가능한 조인 순서는 n! 만큼 존재한다. 여기서는 n은 FROM 절에 존재하는 테이블 수이다. 그러나 현실적으로 옵티마이저가 적용 가능한 조인 순서는 이보다는 적거나 같다. 조인 기법은 두 개의 테이블을 조인할 때 사용할 수 있는 방법으로서 여기에는 NL Join, Hash Join, Sort Merge Join 등이 있다. [그림 Ⅱ-3-4]에서 조인 기법은 NL Join을 사용하고 있다. 액세스 기법은 하나의 테이블을 액세스할 때 사용할 수 있는 방법이다. 여기에는 인덱스를 이용하여 테이블을 액세스하는 인덱스 스캔(Index Scan)과 테이블 전체를 모두 읽으면서 조건을 만족하는 행을 찾는 전체 테이블 스캔(Full Table Scan) 등이 있다. [그림 Ⅱ-3-4]에서 액세스 기법은 인덱스 스캔을 사용하고 있다. 최적화 정보는 옵티마이저가 실행계획의 각 단계마다 예상되는 비용 사항을 표시한 것이다. 실행계획에 비용 사항이 표시된다는 것은 비용기반 최적화 방식으로 실행계획을 생성했다는 것을 의미한다. 최적화 정보에는 Cost, Card, Bytes가 있다. Cost는 상대적인 비용 정보이고 Card는 Cardinality의 약자로서 주어진 조건을 만족한 결과 집합 혹은 조인 조건을 만족한 결과 집합의 건수를 의미한다. Bytes는 결과 집합이 차지하는 메모리 양을 바이트로 표시한 것이다. 이러한 비용 정보는 실제로 SQL을 실행하고 얻은 결과가 아니라 통계 정보를 바탕으로 옵티마이저가 계산한 예상치이다. 만약 이러한 비용 사항이 실행계획에 표시되지 않았다면 이것은 규칙기반 최적화 방식으로 실행계획을 생성한 것이다. [그림 Ⅱ-3-4] 실행계획의 예에서는 비용 정보가 표시되어 있으므로 비용기반 최적화 방식으로 생성된 실행계획이다. 연산(Operation)은 여러 가지 조작을 통해서 원하는 결과를 얻어내는 일련의 작업이다. 연산에는 조인 기법(NL Join, Hash Join, Sort Merge Join 등), 액세스 기법(인덱스 스캔, 전체 테이블 스캔 등), 필터, 정렬, 집계, 뷰 등 다양한 종류가 존재한다. 예를 들어, SQL에서 정렬을 목적으로 ORDER BY를 수행했다면 정렬 연산이 표시되다.
3. SQL 처리 흐름도
SQL 처리 흐름도(Access Flow Diagram)란 SQL의 내부적인 처리 절차를 시각적으로 표현한 도표이다. 이것은 실행계획을 시각화한 것이다. [그림 Ⅱ-3-5]와 같이 액세스 처리 흐름도에는 SQL문의 처리를 위해 어떤 테이블을 먼저 읽었는지(조인 순서), 테이블을 읽기 위해서 인덱스 스캔을 수행했는지 또는 테이블 전체 스캔을 수행했는지(액세스 기법)과 조인 기법 등을 표현할 수 있다. 예를 들어, [그림 Ⅱ-3-5]에서 조인 순서는 TAB1 → TAB2이다. 여기서 TAB1을 Outer Table 또는 Driving Table이라고 하고, TAB2를 Inner Table 또는 Lookup Table이라고 한다. 테이블의 액세스 방법은 TAB1은 테이블 전체 스캔을 의미하고 TAB2는 I01_TAB2 이라는 인덱스를 통한 인덱스 스캔을 했음을 표시한 것이다. 조인 방법은 NL Join을 수행했음을 표시한 것이다. [그림 Ⅱ-3-5]에서 TAB1에 대한 액세스는 스캔(Scan) 방식이고 조인시도 및 I01_TAB2 인덱스를 통한 TAB2 액세스는 랜덤(Random) 방식이다. 대량의 데이터를 랜덤 방식으로 액세스하게 되면 많은 I/O가 발생하여 성능상 좋지 않다.
성능적인 관점을 살펴보기 위해서 SQL 처리 흐름도에 일량을 함께 표시할 수 있다. [그림 Ⅱ-3-5]에서 건수(액세스 건수, 조인 시도 건수, 테이블 액세스 건수, 성공 건수)라고 표시된 곳에 SQL 처리를 위해 작업한 건수 또는 처리 결과 건수 등의 일량을 함께 표시할 수 있다. 이것을 통해 어느 부분에서 비효율이 발생하고 있는지에 대한 힌트를 얻을 수 있다.
다음은 [그림 Ⅱ-3-5]가 다음 SQL문에 대한 SQL 처리 흐름도라는 가정으로 설명한다.
SELECT … FROM TAB1 A, TAB2 B WHERE A.KEY = B.KEY AND A.COL1 = :condition1 AND B.COL2 = :condition2
[그림 Ⅱ-3-5]에서 액세스 건수는 SQL 처리를 위해 TAB1을 액세스한 건수이다. 여기서는 TAB1의 A.COL1 칼럼에 이용 가능한 인덱스가 존재하지 않아 전체 테이블 스캔을 수행했음을 의미한다. 따라서 액세스 건수는 TAB1 테이블의 총 건수와 동일하다. 조인 시도 건수는 TAB1을 액세스한 후 즉, 테이블에서 읽은 해당 건에 대해 A.COL1 = :condition1 조건을 만족한 건만이 TAB2와 조인을 시도한다. 즉, TAB1을 액세스한 후 A.COL1 = :condition1 조건을 만족하지 않는다면 더 이상 조인 작업을 진행할 필요가 없다. 따라서 조인 시도 건수는 TAB1에 주어진 조건인 A.COL1 = :condition1을 만족한 건수가 된다. 테이블 액세스 건수는 B.KEY 칼럼만으로 구성된 인덱스(B.KEY 칼럼만으로 구성된 인덱스라고 가정함)인 I01_TAB2에서 B.KEY = A.KEY (TAB1은 이미 읽혀졌기 때문에 A.KEY 값은 상수임) 조건을 만족한 건만이 TAB2 테이블을 액세스한다. 즉, 조인 시도한 건들 중에서 B.KEY = A.KEY 조건까지 만족한 건과 같다. 성공 건수는 SQL 실행을 통해 사용자에게 답으로서 보여지는 결과 건수이다. TAB2 테이블을 액세스해서 B.COL2 = :condition2 조건까지 만족해야 비로서 사용자에게 보여질 수 있다.
인덱스 기본
1. 인덱스 특징과 종류
인덱스는 원하는 데이터를 쉽게 찾을 수 있도록 돕는 책의 찾아보기와 유사한 개념이다. 인덱스는 테이블을 기반으로 선택적으로 생성할 수 있는 구조이다. 테이블에 인덱스를 생성하지 않아도 되고 여러 개를 생성해도 된다. 인덱스의 기본적인 목적은 검색 성능의 최적화이다. 즉, 검색 조건을 만족하는 데이터를 인덱스를 통해 효과적으로 찾을 수 있도록 돕는다. 그렇지만 Insert, Update, Delete 등과 같은 DML 작업은 테이블과 인덱스를 함께 변경해야 하기 때문에 오히려 느려질 수 있다는 단점이 존재한다.
가. 트리 기반 인덱스
DBMS에서 가장 일반적인 인덱스는 B-트리 인덱스이다.
[그림 Ⅱ-3-6]과 같이 B-트리 인덱스는 브랜치 블록(Branch Block)과 리프 블록(Leaf Block)으로 구성된다. 브랜치 블록 중에서 가장 상위에서 있는 블록을 루트 블록(Root Block)이라고 한다. 브랜치 블록은 분기를 목적으로 하는 블록이다. 브랜치 블록은 다음 단계의 블록을 가리키는 포인터를 가지고 있다. 리프 블록은 트리의 가장 아래 단계에 존재한다. 리프 블록은 인덱스를 구성하는 칼럼의 데이터와 해당 데이터를 가지고 있는 행의 위치를 가리키는 레코드 식별자(RID, Record Identifier/Rowid)로 구성되어 있다. 인덱스 데이터는 인덱스를 구성하는 칼럼의 값으로 정렬된다. 만약 인덱스 데이터의 값이 동일하면 레코드 식별자의 순서로 저장된다. 리프 블록은 양방향 링크(Double Link)를 가지고 있다. 이것을 통해서 오름 차순(Ascending Order)과 내림 차순(Descending Order) 검색을 쉽게 할 수 있다. B-트리 인덱스는 ‘=’로 검색하는 일치(Exact Match) 검색과 ‘BETWEEN’, ‘>’ 등과 같은 연산자로 검색하는 범위(Range) 검색 모두에 적합한 구조이다. [그림 Ⅱ-3-7]은 브랜치 브록이 3개의 포인터로 구성된 B-트리 인덱스의 예이다. 인덱스에서 원하는 값을 찾는 과정은 다음과 같다.
1단계. 브랜치 블록의 가장 왼쪽 값이 찾고자 하는 값보다 작거나 같으면 왼쪽 포인터로 이동 2단계. 찾고자 하는 값이 브랜치 블록의 값 사이에 존재하면 가운데 포인터로 이동 3단계. 오른쪽에 있는 값보다 크면 오른쪽 포인터로 이동
이 과정을 리프 블록을 찾을 때까지 반복한다. 리프 블록에서 찾고자 하는 값이 존재하면 해당 값을 찾은 것이고, 해당 값이 없으면 해당 값은 존재하지 않아 검색에 실패하게 된다.
예를 들어, [그림 Ⅱ-3-7]에서 37을 찾고자 한다면 루트 블록에서 50보다 작으므로 왼쪽 포인터로 이동한다. 37는 왼쪽 브랜치 블록의 11과 40 사이의 값이므로 가운데 포인터로 이동한다. 이동한 결과 해당 블록이 리프 블록이므로 37이 블록 내에 존재하는지 검색한다. 본 예에서는 리프 블록에 37이 존재한다. 검색하고자 하는 값을 찾은 것이다. 만약, SQL문에서 다른 칼럼이 더 필요하면 리프 블록에 존재하는 레코드 식별자를 이용해서 테이블을 액세스한다. 만약, 37과 50사이의 모든 값을 찾고자 한다면(BETWEEN 37 AND 50) 위와 동일한 방법으로 리프 블록에서 37을 찾고 50보다 큰 값을 만날 때까지 오른쪽으로 이동하면서 인덱스를 읽는다. 이것은 인덱스 데이터가 정렬되어 있고 리프 블록이 양방향 링크로 연결되어 있기 때문에 가능하다. 인덱스를 경유해서 반환된 결과 데이터는 인덱스 데이터와 동일한 순서로 갖게 되는 특징을 갖는다. 인덱스를 생성할 때 동일 칼럼으로 구성된 인덱스를 중복해서 생성할 수 없다. 그렇지만 인덱스 구성 칼럼은 동일하지만 칼럼의 순서가 다르면 서로 다른 인덱스로 생성할 수 있다. 예를 들어, JOB+SAL 칼럼 순서의 인덱스와 SAL+JOB 칼럼 순서의 인덱스를 별도의 인덱스를 생성할 수 있다. 인덱스의 칼럼 순서는 질의의 성능에 중요한 영향을 미치는 요소이다. Oracle에서 트리 기반 인덱스에는 B-트리 인덱스 외에도 비트맵 인덱스(Bitmap Index), 리버스 키 인덱스(Reverse Key Index), 함수기반 인덱스(FBI, Function-Based Index) 등이 존재한다.
나. SQL Server의 클러스터형 인덱스
SQL Server의 인덱스 종류는 저장 구조에 따라 클러스터형(clustered) 인덱스와 비클러스터형(nonclustered) 인덱스로 나뉜다. 여기서는 클러스터형 인덱스에 대해서만 설명하기로 한다. 클러스터형 인덱스는 두 가지 중요한 특징이 있다.
첫째, 인덱스의 리프 페이지가 곧 데이터 페이지다. 따라서 테이블 탐색에 필요한 레코드 식별자가 리프 페이지에 없다(인덱스 키 칼럼과 나머지 칼럼을 리프 페이지에 같이 저장하기 때문에 테이블을 랜덤 액세스할 필요가 없다). 클러스터형 인덱스의 리프 페이지를 탐색하면 해당 테이블의 모든 칼럼 값을 곧바로 얻을 수 있다. 흔히 클러스터형 인덱스를 사전에 비유한다. 예를 들어, 영한사전은 알파벳 순으로 정렬되어 있으며 각 단어 바로 옆에 한글 설명이 붙어 있다. 전문서적 끝 부분에 있는 찾아보기(=색인)가 페이지 번호만 알려주는 것과 비교하면 그 차이점을 알 수 있다. 둘째, 리프 페이지의 모든 로우(=데이터)는 인덱스 키 칼럼 순으로 물리적으로 정렬되어 저장된다. 테이블 로우는 물리적으로 한 가지 순서로만 정렬될 수 있다. 그러므로 클러스터형 인덱스는 테이블당 한 개만 생성할 수 있다.(전화번호부 한 권을 상호와 인명으로 동시에 정렬할 수 없는 것과 마찬가지다.)
[그림 Ⅱ-3-8]은 Employee ID, Last Name, First Name, Hire Date로 구성된 Employees 테이블에 대해 Employee ID에 기반한 클러스터형 인덱스를 생성한 모습이다. B-트리 구조를 편의상, 삼각형 모양을 왼쪽으로 90도 돌려서 나타냈다.
[그림 Ⅱ-3-8]에 표시된 것처럼, 리프 블록에 인덱스 키 칼럼 외에도 테이블의 나머지 칼럼이 모두 함께 있다.
2. 전체 테이블 스캔과 인덱스 스캔
가. 전체 테이블 스캔
전체 테이블 스캔 방식으로 데이터를 검색한다는 것은 테이블에 존재하는 모든 데이터를 읽어 가면서 조건에 맞으면 결과로서 추출하고 조건에 맞지 않으면 버리는 방식으로 검색한다.
Oracle의 경우 [그림 Ⅱ-3-9]와 같이 검색 조건에 맞는 데이터를 찾기 위해서 테이블의 고수위 마크(HWM, High Water Mark) 아래의 모든 블록을 읽는다. 고수위 마크는 테이블에 데이터가 쓰여졌던 블록 상의 최상위 위치(현재는 지워져서 데이터가 존재하지 않을 수도 있음)를 의미한다. 전체 테이블 스캔 방식으로 데이터를 검색할 때 고수기 때문에 모든 결과를 찾을 때까지 시간이 오래 걸릴 수 있다. 이와 같이 전체 테이블 스캔 방식은 테이블에 존재하는 모든 블록의 데이터를 읽는다. 그러나 이것은 결과를 찾기 위해 꼭 필요해서 모든 블록을? 모든 블록을 읽은 것이다. 따라서 이렇게 읽은 블록들은 재사용성이 떨어진다. 그래서 전체 테이블 스캔 방식으로 읽은 블록들은 메모리에서 곧 제거될 수 있도록 관리된다.
옵티마이저가 연산으로서 전체 테이블 스캔 방식을 선택하는 이유는 일반적으로 다음과 같다.
1) SQL문에 조건이 존재하지 않는 경우
SQL문에 조건이 존재하지 않는다는 것은 테이블에 존재하는 모든 데이터가 답이 된다는 것이다. 그렇기 때문에 테이블의 모든 블록을 읽으면서 무조건 결과로서 반환하면 된다.
2) SQL문의 주어진 조건에 사용 가능한 인덱스가 존재하는 않는 경우
사용 가능한 인덱스가 존재하지 않는다면 데이터를 액세스할 수 있는 방법은 테이블의 모든 데이터를 읽으면서 주어진 조건을 만족하는지를 검사하는 방법뿐이다. 또한 주어진 조건에 사용 가능한 인덱스는 존재하나 함수를 사용하여 인덱스 칼럼을 변형한 경우에도 인덱스를 사용할 수 없다.
3) 옵티마이저의 취사 선택
조건을 만족하는 데이터가 많은 경우, 결과를 추출하기 위해서 테이블의 대부분의 블록을 액세스해야 한다고 옵티마이저가 판단하면 조건에 사용 가능한 인덱스가 존재해도 전체 테이블 스캔 방식으로 읽을 수 있다.
4) 그 밖의 경우
병렬처리 방식으로 처리하는 경우 또는 전체 테이블 스캔 방식의 힌트를 사용한 경우에 전체 테이블 스캔 방식으로 데이터를 읽을 수 있다.
나. 인덱스 스캔
여기서는 데이터베이스에서 주로 사용되는 트리 기반 인덱스를 중심으로 설명한다. 인덱스 스캔은 인덱스를 구성하는 칼럼의 값을 기반으로 데이터를 추출하는 액세스 기법이다. 인덱스의 리프 블록은 인덱스 구성하는 칼럼과 레코드 식별자로 구성되어 있다. 따라서 검색을 위해 인덱스의 리프 블록을 읽으면 인덱스 구성 칼럼의 값과 테이블의 레코드 식별자를 알 수 있다. 인덱스에 존재하지 않는 칼럼의 값이 필요한 경우에는 현재 읽은 레코드 식별자를 이용하여 테이블을 액세스해야 한다. 그러나 SQL문에서 필요로 하는 모든 칼럼이 인덱스 구성 칼럼에 포함된 경우 테이블에 대한 액세스는 발생하지 않는다. 인덱스는 인덱스 구성 칼럼의 순서로 정렬되어 있다. 인덱스의 구성 칼럼이 A+B라면 먼저 칼럼 A로 정렬되고 칼럼 A의 값이 동일할 경우에는 칼럼 B로 정렬된다. 그리고 칼럼 B까지 모두 동일하면 레코드 식별자로 정렬된다. 인덱스가 구성 칼럼으로 정렬되어 있기 때문에 인덱스를 경유하여 데이터를 읽으면 그 결과 또한 정렬되어 반환된다. 따라서 인덱스의 순서와 동일한 정렬 순서를 사용자가 원하는 경우에는 정렬 작업을 하지 않을 수 있다. 인덱스 스캔 중에서 자주 사용되는 인덱스 유일 스캔(Index Unique Scan), 인덱스 범위 스캔(Index Range Scan), 인덱스 역순 범위 스캔(Index Range Scan Descending)에 대해 간단히 설명하면 다음과 같다. 제공되는 인덱스 스캔 방식은 데이터베이스 벤더마다 다를 수 있다.
1) 인덱스 유일 스캔은 유일 인덱스(Unique Index)를 사용하여 단 하나의 데이터를 추출하는 방식이다. 유일 인덱스는 중복을 허락하지 않는 인덱스이다. 유일 인덱스 구성 칼럼에 모두 '='로 값이 주어지면 결과는 최대 1건이 된다. 인덱스 유일 스캔은 유일 인덱스 구성 칼럼에 대해 모두 ‘=’로 값이 주어진 경우에만 가능한 인덱스 스캔 방식이다.
2) 인덱스 범위 스캔은 인덱스를 이용하여 한 건 이상의 데이터를 추출하는 방식이다. 유일 인덱스의 구성 칼럼 모두에 대해 ‘=’로 값이 주어지지 않은 경우와 비유일 인덱스(Non-Unique Index)를 이용하는 모든 액세스 방식은 인덱스 범위 스캔 방식으로 데이터를 액세스하는 것이다. [그림 Ⅱ-3-10]의 왼쪽 그림과 같은 방식으로 인덱스를 읽는다.
다. 전체 테이블 스캔과 인덱스 스캔 방식의 비교
3) 인덱스 역순 범위 스캔은 [그림 Ⅱ-3-10]의 오른쪽 그림과 같이 인덱스의 리프 블록의 양방향 링크를 이용하여 내림 차순으로 데이터를 읽는 방식이다. 이 방식을 이용하여 최대값(Max Value)을 쉽게 찾을 수 있다. 이 또한 인덱스 범위 스캔의 일종이다.
이외에도 인덱스 전체 스캔(Index Full Scan), 인덱스 고속 전체 스캔(Fast Full Index Scan), 인덱스 스킵 스캔(Index Skip Scan) 등이 존재한다.
가. 규칙기반 옵티마이저
데이터를 액세스하는 방법은 크게 두 가지로 나눠 볼 수 있다. 인덱스를 경유해서 읽는 인덱스 스캔 방식과 테이블의 전체 데이터를 모두 읽으면서 데이터를 추출하는 전체 테이블 스캔 방식이다. 인덱스 스캔 방식은 사용 가능한 적절한 인덱스가 존재할 때만 이용할 수 있는 스캔 방식이지만 전체 테이블 스캔 방식은 인덱스의 존재 유무와 상관없이 항상 이용 가능한 스캔 방식이다. 앞에서 설명한 것처럼 옵티마이저는 인덱스가 존재하더라도 전체 테이블 스캔 방식을 취사 선택할 수 있다. [그림 Ⅱ-3-11]은 전체 테이블 스캔과 인덱스 스캔에 대한 SQL 처리 흐름도 표현의 예이다.
인덱스 스캔은 인덱스에 존재하는 레코드 식별자를 이용해서 검색하는 데이터의 정확한 위치를 알고서 데이터를 읽는다. 그렇기 때문에 인덱스 스캔 방식에서는 불필요하게 다른 블록을 더 읽을 필요가 없다. 따라서 한번의 I/O 요청에 한 블록씩 데이터를 읽는다. 그러나 전체 테이블 스캔은 데이터를 읽을 때 한번의 I/O 요청으로 여러 블록을 한꺼번에 읽는다. 어차피 테이블의 모든 데이터를 읽을 것이라면 한 번 읽기 작업을 할 때 여러 블록을 함께 읽는 것이 효율적이다. 대용량 데이터 중에서 극히 일부의 데이터를 찾을 때, 인덱스 스캔 방식은 인덱스를 이용해 몇 번의 I/O만으로 원하는 데이터를 쉽게 찾을 수 있다. 그러나 전체 테이블 스캔은 테이블의 모든 데이터를 읽으면서 원하는 데이터를 찾아야 하기 때문에 비효율적인 검색을 하게 된다. 그러나 반대로 테이블의 대부분의 데이터를 찾을 때는 한 블록씩 읽는 인덱스 스캔 방식 보다는 어차피 대부분의 데이터를 읽을 거라면 한번에 여러 블록씩 읽는 전체 테이블 스캔 방식이 유리할 수 있다.
조인 수행 원리
조인이란 두 개 이상의 테이블을 하나의 집합으로 만드는 연산이다. SQL문에서 FROM 절에 두 개 이상의 테이블이 나열될 경우 조인이 수행된다. 조인 연산은 두 테이블 사이에서 수행된다. FROM 절에 A, B, C라는 세 개의 테이블이 존재하더라도 세 개의 테이블이 동시에 조인이 수행되는 것은 아니다. 세 개의 테이블 중에서 먼저 두 개의 테이블에 대해 조인이 수행된다. 그리고 먼저 수행된 조인 결과와 나머지 테이블 사이에서 조인이 수행된다. 이러한 작업은 FROM 절에 나열된 모든 테이블을 조인할 때까지 반복 수행한다. 예를 들어, A, B, C 세 개의 테이블을 조인할 때를 가정으로 설명하면 다음과 같다. 먼저 A와 B 두 테이블을 먼저 조인하면 해당 조인 결과와 나머지 C 테이블을 조인한다(A → B → C). 만약, A와 C 테이블을 먼저 조인한다면 해당 조인 결과와 나머지 B 테이블을 조인한다(A → C → B). 테이블 또는 조인 결과를 이용하여 조인을 수행할 때 조인 단계별로 다른 조인 기법을 사용할 수 있다. 예를 들어, A와 B 테이블을 조인할 때는 NL Join 기법을 사용하고 해당 조인 결과와 C 테이블을 조인할 때는 Hash Join 기법을 사용할 수 있다. 조인 기법은 두 개의 테이블을 조인할 때 사용할 수 있는 방법이다. 여기서는 조인 기법 중에서 자주 사용되는 NL Join, Hash Join, Sort Merge Join에 대해서 조인 원리를 간단하게 설명한다.1. NL Join
NL Join은 프로그래밍에서 사용하는 중첩된 반복문과 유사한 방식으로 조인을 수행한다. 반복문의 외부에 있는 테이블을 선행 테이블 또는 외부 테이블(Outer Table)이라고 하고, 반복문의 내부에 있는 테이블을 후행 테이블 또는 내부 테이블(Inner Table)이라고 한다.
FOR 선행 테이블 읽음 → 외부 테이블(Outer Table) FOR 후행 테이블 읽음 → 내부 테이블(Inner Table) (선행 테이블과 후행 테이블 조인)
먼저 선행 테이블의 조건을 만족하는 행을 추출하여 후행 테이블을 읽으면서 조인을 수행한다. 이 작업은 선행 테이블의 조건을 만족하는 모든 행의 수만큼 반복 수행한다. NL Join에서는 선행 테이블의 조건을 만족하는 행의 수가 많으면(처리 주관 범위가 넓으면), 그 만큼 후행 테이블의 조인 작업은 반복 수행된다. 따라서 결과 행의 수가 적은(처리 주관 범위가 좁은) 테이블을 조인 순서상 선행 테이블로 선택하는 것이 전체 일량을 줄일 수 있다. NL Join은 랜덤 방식으로 데이터를 액세스하기 때문에 처리 범위가 좁은 것이 유리하다.
NL Join의 작업 방법은 다음과 같다.
① 선행 테이블에서 주어진 조건을 만족하는 행을 찾음 ② 선행 테이블의 조인 키 값을 가지고 후행 테이블에서 조인 수행 ③ 선행 테이블의 조건을 만족하는 모든 행에 대해 1번 작업 반복 수행
[그림 Ⅱ-3-12]의 예를 이용하여 NL Join의 수행 방식을 알아보도록 하자. [그림 Ⅱ-3-12]에서 인덱스는 B-트리 인덱스의 리프 블록만을 그린 것임을 표현한 것이다.
① 선행 테이블에서 조건을 만족하는 첫 번째 행을 찾음 → 이때 선행 테이블에 주어진 조건을 만족하지 않는 경우 해당 데이터는 필터링 됨 ② 선행 테이블의 조인 키를 가지고 후행 테이블에 조인 키가 존재하는지 찾으러 감 → 조인 시도 ③ 후행 테이블의 인덱스에 선행 테이블의 조인 키가 존재하는지 확인 → 선행 테이블의 조인 값이 후행 테이블에 존재하지 않으면 선행 테이블 데이터는 필터링 됨 (더 이상 조인 작업을 진행할 필요 없음) ④ 인덱스에서 추출한 레코드 식별자를 이용하여 후행 테이블을 액세스 → 인덱스 스캔을 통한 테이블 액세스 후행 테이블에 주어진 조건까지 모두 만족하면 해당 행을 추출버퍼에 넣음 ⑤ ~ ⑪ 앞의 작업을 반복 수행함
추출버퍼는 SQL문의 실행결과를 보관하는 버퍼로서 일정 크기를 설정하여 추출버퍼에 결과가 모두 차거나 더 이상 결과가 없어서 추출버퍼를 채울 것이 없으면 결과를 사용자에게 반환한다. 추출버퍼는 운반단위, Array Size, Prefetch Size라고도 한다. [그림 Ⅱ-3-12]에서 만약 선행 테이블에 사용 가능한 인덱스가 존재한다면 인덱스를 통해 선행 테이블을 액세스할 수 있다. (여기서는 사용할 인덱스가 없음을 가정으로 설명한 것임) NL Join 기법은 조인이 성공하면 바로 조인 결과를 사용자에게 보여 줄 수 있다. 그래서 결과를 가능한 빨리 화면에 보여줘야 하는 온라인 프로그램에 적당한 조인 기법이다.
2. Sort Merge Join
Sort Merge Join은 조인 칼럼을 기준으로 데이터를 정렬하여 조인을 수행한다. NL Join은 주로 랜덤 액세스 방식으로 데이터를 읽는 반면 Sort Merge Join은 주로 스캔 방식으로 데이터를 읽는다. Sort Merge Join은 랜덤 액세스로 NL Join에서 부담이 되던 넓은 범위의 데이터를 처리할 때 이용되던 조인 기법이다. 그러나 Sort Merge Join은 정렬할 데이터가 많아 메모리에서 모든 정렬 작업을 수행하기 어려운 경우에는 임시 영역(디스크)을 사용하기 때문에 성능이 떨어질 수 있다. 일반적으로 대량의 조인 작업에서 정렬 작업을 필요로 하는 Sort Merge Join 보다는 CPU 작업 위주로 처리하는 Hash Join이 성능상 유리하다. 그러나 Sort Merge Join은 Hash Join과는 달리 동등 조인 뿐만 아니라 비동등 조인에 대해서도 조인 작업이 가능하다는 장점이 있다.
Sort Merge Join의 동작은 [그림 Ⅱ-3-13]과 같다.
① 선행 테이블에서 주어진 조건을 만족하는 행을 찾음 ② 선행 테이블의 조인 키를 기준으로 정렬 작업을 수행 ① ~ ②번 작업을 선행 테이블의 조건을 만족하는 모든 행에 대해 반복 수행 ③ 후행 테이블에서 주어진 조건을 만족하는 행을 찾음 ④ 후행 테이블의 조인 키를 기준으로 정렬 작업을 수행 ③ ~ ④번 작업을 후행 테이블의 조건을 만족하는 모든 행에 대해 반복 수행 ⑤ 정렬된 결과를 이용하여 조인을 수행하며 조인에 성공하면 추출버퍼에 넣음
Sort Merge Join은 조인 칼럼의 인덱스를 사용하지 않기 때문에 조인 칼럼의 인덱스가 존재하지 않을 경우에도 사용할 수 있는 조인 기법이다. Sort Merge Join에서 조인 작업을 위해 항상 정렬 작업이 발생하는 것은 아니다. 예를 들어, 조인할 테이블 중에서 이미 앞 단계의 작업을 수행하는 도중에 정렬 작업이 미리 수행되었다면 조인을 위한 정렬 작업은 발생하지 않을 수 있다.
3. Hash Join
Hash Join은 해슁 기법을 이용하여 조인을 수행한다. 조인을 수행할 테이블의 조인 칼럼을 기준으로 해쉬 함수를 수행하여 서로 동일한 해쉬 값을 갖는 것들 사이에서 실제 값이 같은지를 비교하면서 조인을 수행한다. Hash Join은 NL Join의 랜덤 액세스 문제점과 Sort Merge Join의 문제점인 정렬 작업의 부담을 해결 위한 대안으로 등장하였다.
Hash Join의 동작은 [그림 Ⅱ-3-14]와 같다.
① 선행 테이블에서 주어진 조건을 만족하는 행을 찾음 ② 선행 테이블의 조인 키를 기준으로 해쉬 함수를 적용하여 해쉬 테이블을 생성 → 조인 칼럼과 SELECT 절에서 필요로 하는 칼럼도 함께 저장됨 ① ~ ②번 작업을 선행 테이블의 조건을 만족하는 모든 행에 대해 반복 수행 ③ 후행 테이블에서 주어진 조건을 만족하는 행을 찾음 ④ 후행 테이블의 조인 키를 기준으로 해쉬 함수를 적용하여 해당 버킷을 찾음 → 조인 키를 이용해서 실제 조인될 데이터를 찾음 ⑤ 조인에 성공하면 추출버퍼에 넣음 ③ ~ ⑤번 작업을 후행 테이블의 조건을 만족하는 모든 행에 대해서 반복 수행
Hash Join은 조인 칼럼의 인덱스를 사용하지 않기 때문에 조인 칼럼의 인덱스가 존재하지 않을 경우에도 사용할 수 있는 조인 기법이다. Hash Join은 해쉬 함수를 이용하여 조인을 수행하기 때문에 '='로 수행하는 조인 즉, 동등 조인에서만 사용할 수 있다. 해쉬 함수를 적용한 값은 어떤 값으로 해슁될 지 알 수 없다. 해쉬 함수가 적용될 때 동일한 값은 항상 같은 값으로 해슁됨이 보장된다. 그러나 해쉬 함수를 적용할 때 보다 큰 값이 항상 큰 값으로 해슁되고 작은 값이 항상 작은 값으로 해슁된다는 보장은 없다. 그렇기 때문에 Hash Join은 동등 조인에서만 사용할 수 있다. [그림 Ⅱ-3-14]와 같이 Hash Join은 조인 작업을 수행하기 위해 해쉬 테이블을 메모리에 생성해야 한다. 생성된 해쉬 테이블의 크기가 메모리에 적재할 수 있는 크기보다 더 커지면 임시 영역(디스크)에 해쉬 테이블을 저장한다. 그러면 추가적인 작업이 필요해 진다. 그렇기 때문에 Hash Join을 할 때는 결과 행의 수가 적은 테이블을 선행 테이블로 사용하는 것이 좋다. 선행 테이블의 결과를 완전히 메모리에 저장할 수 있다면 임시 영역에 저장하는 작업이 발생하지 않기 때문이다. Hash Join에서는 선행 테이블을 이용하여 먼저 해쉬 테이블을 생성한다고 해서 선행 테이블을 Build Input이라고도 하며, 후행 테이블은 만들어진 해쉬 테이블에 대해 해쉬 값의 존재여부를 검사한다고 해서 Prove Input이라고도 한다.
