INFJ의 성장하는 습관

모놀리식 아키텍처 vs MSA 시스템의 비교/장단점

감성적인 개발자 — Wed, 12 Jun 2024 13:32:40 +0900

1. 모놀리식 (Monolithic)

모놀리식은 시스템의 모든 비즈니스 로직이 하나의 서버에 의해 처리되는 방식으로 배포가쉽고 시스템을 빠르게 만들 수 있다는 장점이 있어 초기 서비스를 만들 때 유용한 방식이다. 하지만 시스템 규모가 커짐에 따라 다음과 같은 단점이 발생할 수 있다.

단일장애지점 : 하나의 장애가 발생하면 시스템 전체에 영향을 미침
트래픽 대응 : 특정 서비스의 트래픽 증가시 대응하기 위해 모든 서비스(시스템 전체) 리소스 스케일링 필요
기술에 종속적 : 작은 기능을 수정 해도 전체 배포를 하기 때문에 테스트 시간이 많이 필요하고 오류가 자주 발생하여 신기술 도입 어려움

2. MSA (Micro Service Architecture)

모놀리식 아키텍처를 Microservice 단위로 쪼갠 후 독립적으로 구축하는 방식이다. 서비스가 대형화되고 클라우드 서비스가 활성화된 요즘 모놀리식 방식에서 MSA 방식으로 구조 변경을 진행하고있다.

개발인원 증가, 사용자 트래픽 대응을 위해 쿠팡은 2013년, 배달의 민족은 2016년에 기존 모놀리식 시스템을 AWS 를 이용한 MSA로 시스템을 전환하였다. 운영 중인 서비스가 급격하게 성장하고 있다면 MSA 도입을 고려해볼만하다.

https://spring.io/cloud

구성요소

Microservice: 독립적으로 운영되는 Microservice (로그인/결제/배송/리뷰 등)
API Gateway: 요청을 직접 받아 적절한 서비스로 요청을 포워딩
모니터링서버 : 각각의 서비스들의 상태를 관리하기 위한 서버
변수관리서버 : 의존성이 강한 변수(DB정보 등)변경시 각각의 서비스의 환경변수 관리필요

장점 (독립적인 서비스 운영)

트래픽 : 특정 서비스에 트래픽이 증가했을 때, 해당 서비스에 대해서만 resource 스케일링을 해줌으로써 트래픽 대응에 대한 자원낭비 방지
신뢰성 : 특정 서비스에 장애가 발생해도 전체 서비스 실행이 멈추지 않고 운영가능
확장성 : 전체 시스템에 영향을 주지않고도 서비스별로 적절한 라이브러리, 언어, 서버도입 가능

단점

초기 인프라 구성 난이도가 높고 서비스가 커질 수록 복잡도가 늘어날 수 있다.
특정 서비스가 동작안할 경우에도 시스템이 동작함으로서 사용자 혼란 발생 가능 (쇼핑몰에서 로그인 서비스만 다운되고 쇼핑은 여전히 가능할 경우 등)
별개로 동작하는 Microservice 서비스 관리 및 서비스간 API 호출 비용문제를 고려해야한다.

참고

MSA, 마이크로서비스 여행기 정리 (배달의 민족)

마이크로서비스 아키텍처로의 전환 (쿠팡)

AWS 기반 서버리스 마이크로 서비스 구현 사례 (빙글)

넥사크로 시간마다 함수 실행시키기 (onTimer/setTimer/killTimer)

감성적인 개발자 — Mon, 8 Apr 2024 14:35:59 +0900

화면 구성

버튼 구성

Script

//좌측버튼
this.ExecSetTimerButton_onclick = function(obj:nexacro.Button,e:nexacro.ClickEventInfo){
	console.log('>> setTimer function');
	this.setTimer(1, 1000);
};

//우측버튼
this.ExecKillTimerButton_onclick = function(obj:nexacro.Button,e:nexacro.ClickEventInfo){
	console.log('>> killTimer function');
	this.killTimer(1);
};

//ontimer 함수
this.화면ID_ontimer = function(obj:nexacro.Form,e:nexacro.TimerEventInfo){
	console.log('>> ontimer function');
};

콘솔창

구글메일(gmail)에서 Base64 형태의 이미지 안보이는 경우 (Java SMTP, HTML 전송)

감성적인 개발자 — Thu, 15 Feb 2024 13:53:08 +0900

메일전송 과정

화면의 HTML(스트링)을 gmail로 전송했을 때 텍스트는 보이지만 이미지는 보이지 않는 현상이 발생했다.

Java의 SMTP를 이용해 전송했으며, 콘솔창을 통해 <img> 태그의 내용(메일의 body )이 정상적으로 생성된걸 확인했지만, 정작 메일을 수신했을 때 이미지만 보이지 않았다.

개발자 도구를 통해 메일을 확인해보니 이미지 영역의 태그는 존재하지만 <img alt="">로 비어있는 상태였다.

알고보니 gmail 뿐만 아니라 대부분의 메일 서비스에서는 Base64를 통한 이미지 표시를 지원하지 않는다고 한다.

Base64 이미지를 담은 html 파일을 첨부파일로 보내도 브라우저에서는 확인 불가능하며 사용자의 PC에 해당 html 파일을 직접 다운로드 해야만 확인할 수 있었다.

Gmail doesn't support adding images as Base64 strings inside HTML img tags.

Send GMail message with attachment

learn.torq.io

SQL 쿼리 실행순서 정리

감성적인 개발자 — Wed, 17 Jan 2024 23:11:17 +0900

1. FROM

테이블이 존재하는지 USER가 해당 테이블에 대한 SELECT 권한이 있는지 먼저 체크한다. 만약 JOIN절이 존재한다면, JOIN을 먼저 수행한다음 FROM절을 수행한다.

2. WHERE

JOIN 혹은 FROM 절에서 가져온 테이블에서 조건에 맞는 ROW 만을 가져온다.

3. GROUP BY

명시한 컬럼들을 그룹화하며, 집계함수를 이용할 때 주로 사용한다.

4. HAVING

GROUP BY 절이 존재한다면 다음으로 HAVING 절을 수행한다. WHERE 절과 마찬가지로 조건에 맞는 ROW를 가져온다.

WHERE절은 테이블 상의 모든 필드에 조건에 두지만, HAVING은 GROUP BY에 의해 그룹화된 결과에 대해 조건을 준다.

--WHERE 절 사용
SELECT department, salary
FROM   employees
WHERE  salary> 2000;

--HAVING절 사용 
SELECT department, AVG(salary) as avg_salary
FROM   employees
GROUP  BY department
HAVING AVG(salary) > 50000;

5. SELECT

가져온 데이터에서 어떤 행을 출력할지 선택한다.

6. DISTINCT

중복행을 필터링해서 고유한 행만을 반환한다.

7. ORDER BY

특정 열을 기준으로 오름차순 또는 내림차순 정렬한다.

* 거의 마지막에 실행되므로 SELECT 절에서 ALIAS를 준 컬럼이 있다면 ORDER BY 절에서 사용 가능하다.

8. LIMIT

LIMIT 내에 속하는 행만 표시하도록 제한한다. 이전에 평가된 많은 행 중 특정 행만 LIMIT하는 것은 효율적이지 않으므로 권장되지 않는다.

참조

https://www.geeksforgeeks.org/order-of-execution-of-sql-queries/

[넥사크로] 그리드 Head클릭시 체크박스 전체선택 이벤트 추가

감성적인 개발자 — Thu, 19 Oct 2023 11:06:07 +0900

1. 그리드 headclick 이벤트 추가

2. 이벤트 작성

head의 체크박스 인덱스는 0번째라고 가정한다.

this.Grid00_onheadclick = function(obj:nexacro.Grid,e:nexacro.GridClickEventInfo){
    try {
        if (e.col == 0) { /*체크박스 인덱스 : 0*/ 
        var checkValue;

        if (obj.getCellProperty("Head", 0, "text") == "1") {
            obj.setCellProperty("Head", 0, "text", "0");  //체크해제 
            checkValue = "0";
        } else {
            obj.setCellProperty("Head", 0, "text", "1");  //체크
            checkValue = "1";
        }

        this.Dataset00.set_enableevent(false);
        for(var i = 0; i < this.Dataset00.rowcount; i++){
            this.Dataset00.setColumn(i, "CHK" /*체크박스 컬럼*/ , checkValue);
        }
        this.Dataset00.set_enableevent(true);	
        }
    } catch (err) {
    //exception 처리
    }
};

이벤트 처리 전후 비교

onheadclick 이벤트를 지정해주지 않아도 해당기능을 구현하는데는 문제가 없지만 그리드의 데이터 건수가 많아진다면 이벤트 처리에 많은 자원이 사용된다. setColumn()으로 데이터셋의 컬럼이 변경되면 기본적으로 다음과 같은 이벤트가 call된다.

- cancolumnchange

- oncolumnchanged

- onvaluechanged

값을 지정하는 과정에서 해당 이벤트가 필요하지 않다면, 반복문에 진입하기 전 enableevent를 false로 변경해 처리속도 향상을 기대해볼 수 있다.

브라우저에 URL을 입력하면 일어나는 일

감성적인 개발자 — Tue, 29 Aug 2023 22:38:57 +0900

1. 브라우저 주소창에 www.naver.com을 입력

2. 캐시탐색

DNS를 이용해 호스트네임(naver.com)의 서버로 접근하기 위한 IP주소를 얻을 수 있다. 그 전에 클라이언트 측에 저장된 캐시를 탐색한다. 만약 캐시에 IP 정보가 있다면 DNS로 요청을 하지 않아도 되므로 로딩속도 향상을 기대할 수 있다.

캐시 탐색은 (브라우저 캐시 → OS 캐시 → 라우터캐시 → ISP캐시) 순으로 순차적으로 이루어진다.

브라우저 캐시: 이미 방문한 웹 페이지의 데이터를 저장한 캐시이다. 캐시가 존재하면 서버로부터 데이터를 다운로드하지 않고 바로 표시할 수 있다.
OS 캐시: 운영체제 수준에서 캐시가 구성되어 있는 캐시이다.
라우터 캐시: 라우터(공유기)에 저장된 캐시로 DNS 정보 및 웹 페이지 데이터의 일부가 캐시될 수 있다.
ISP 캐시: 사용자의 인터넷 서비스 제공업체(ISP)에서도 DNS 정보 및 웹 페이지 데이터를 캐시로 저장할 수 있다.

- 캐시와 조건부 요청에 관한 글

3. DNS에 IP 주소 요청

(캐시를 이용할 수 없다면) 로컬 DNS 서버로 요청을 보낸다. 로컬 DNS서버는 루트, TLD, 책임 DNS 서버 등을 거쳐 클라이언트에게 서버의 IP주소를 응답해준다.

- DNS(Domain Name System)의 구조와 동작 원리 참조

4. TCP/IP 연결 (3-way handshaking)

데이터 전송 전 클라이언트-서버 간의 연결이 이루어진다.

5. Request(요청)

클라이언트와 서버간 연결이 완료되면 클라이언트는 서버로 요청을 보낸다. 클라이언트는 요청이 손실, 변조 되거나 누군가 보는 것을 방지하기 위해 HTTPS/TLS를 이용해 요청을 암호화 한다.

6. 로드밸런싱

대규모 시스템의 경우 다수의 서버를 두고 운영할 수 있다. 현재 서버들의 트래픽, 클라이언트의 위치(서울, 부산, 도쿄 등) 등을 고려하여 운영 중인 서버 중 클라이언트의 요청을 처리하기 가장 적합한 서버를 찾아 요청을 전달한다.

7. Response(응답)

클라이언트의 요청을 분석하여 필요한 파일, DB정보를 응답 메세지에 담아 HTTP 상태 코드와 함께 Response해준다.

- HTTP 상태코드에 관한 글

8. 브라우저 렌더링

브라우저는 서버로 부터 받은 HTML을 이용해 렌더링을한다. 브라우저는 빠르게 응답하기 위해 서버로부터 데이터를 모두 받기 전에도 렌더링을 시작하며 필요한 이미지나 파일이 있을 경우 추가로 요청을 할 수 있다.

[Oracle] Spring, Mybatis에서 대량 데이터 INSERT 수행. multirow, 다건 삽입 수행하기

감성적인 개발자 — Wed, 12 Jul 2023 22:01:36 +0900

대량 데이터 삽입 로직

데이터 입력시 보통 단건 또는 10건 미만으로 입력이 들어오기 때문에 입력되는 ROW수 만큼 INSERT쿼리 호출이 이루어진다. 그러나 1만 8천 건 정도 되는 데이터를 한 번에 INSERT 하니, 수행 시간이 5분 이상 소요되었고 이대로는 사용할 수 없다고 판단했다.(오류는 나지 않더라도 예외 메세지가 뜨면서 통신이 끊어진것 처럼 보였다.)

일반적으로 사용했던 INSERT 로직 (대용량 INSERT에 부적합)

사용자가 이용할 수 없는 속도를 보여줬기 때문에 삽입하는 ROW 수만큼 쿼리를 호출해 수행하는 기존 INSERT 로직을 이용할 순 없었다. ~~나중에 들어보니 AS-IS(기존 시스템)에선 10분넘게 걸렸었다고한다...~~

//paramList : 화면단에서 넘겨받은 Data
for (Map<String, Object> paramMap : paramList) { 
    dao.insert();
    //쿼리호출 : INSERT INTO TABLE (...) VALUES (...) x row 수 만큼 수행
}

UNION ALL을 이용한 INSERT

INSERT INTO [TABLE] (
    COL1, COL2, COL3
)
SELECT 'VALUE1', 'VALUE2', 'VALUE3' FROM DUAL UNION ALL
SELECT 'VALUE1', 'VALUE2', 'VALUE3' FROM DUAL UNION ALL
SELECT 'VALUE1', 'VALUE2', 'VALUE3' FROM DUAL UNION ALL
...
SELECT 'VALUE1', 'VALUE2', 'VALUE3' FROM DUAL

SELECT문과 UNION ALL을 활용하면 INSERT 쿼리 한 번에 다건의 ROW를 삽입하면서 속도 향상을 기대해 볼 수 있었기에 해당 쿼리를 사용해 하나의 요청마다 200건씩 INSERT를 수행하기로 헀다. 여기에 사용될 SELECT문은 Service단에서 만들어서 dao 쿼리 호출 시에 인자로 전달한다.

*INSERT ALL 쿼리도 있었지만 UNION ALL을 사용하는 방법이 속도면에서 더 빠르다기에 이 방법을 선택했다.

Mybatis xml

 <insert id="insertQueryId" parameterType="java.util.HashMap">
    INSERT INTO [TABLE] (
        COL1, COL2, COL3
    )
    ${QUERY}
</insert>

SELECT 문에 작은 따옴표('VALUE')를 사용해야 했기 때문에 파라미터 사용 시 #{} 대신 ${}을 선택했다. ${}을 사용하면 SQL Injection 공격에 취약해질 수 있지만, 이 경우 데이터가 다수의 사용자에 의해 입력/수정/삭제되지 않으며, 한정된 사용자(1~2명)의 파일 업로드를 통해 생성되므로 보안적인 측면에서는 상대적으로 낮은 위험성을 가진다고 판단했다.

Java - Service단

// Save 로직 일부

List<Map<String, Object>> dataListSlice = new ArrayList<>();

for (int i = 0; i < paramList.size(); i++) {
    Map<String, Object> element = paramList.get(i);
    dataListSlice.add(element);
    
    // 200개씩 끊어서 입력
    if ((i + 1) % 200 == 0 || i == paramList.size() - 1) {
        Map<String, Object> insertParams = new HashMap<>();
        String insertQuery = generateInsertQuery(dataListSlice);
        insertParams.put("QUERY", insertQuery);
        dao.insert("namespace.insertQueryId", insertParams);
        dataListSlice.clear();
    }
}

String generateInsertQuery(List<Map<String, Object>> data) {
    StringBuilder queryBuilder = new StringBuilder();
    String insertValueList;
    
    for (int i = 0; i < data.size(); i++) {
        Map<String, Object> dataMap = data.get(i);
        insertValueList = "'" + dataMap.get("COL1") + "'" +
                          ", '" + dataMap.get("COL2") + "'" +
                          ", '" + dataMap.get("COL3") + "'";

        if (i == data.size() - 1) {
            queryBuilder.append("SELECT " + insertValueList + " FROM DUAL");
        } else {
            queryBuilder.append("SELECT " + insertValueList + " FROM DUAL UNION ALL\n");
        }
    }
    return queryBuilder.toString();
}

${QUERY} 파라미터에 전달할 값(SELECT ... FROM DAUL UNION ALL)을 Java단에서 만들어주는 로직이다.

입력된 데이터를 200개씩 끊어서 INSERT 쿼리를 호출하니 18000건 정도의 데이터를 입력하는데 5분 → 30초 정도로 시간이 단축됐다.

대량 데이터를 INSERT 하는 방법2

INSERT 처리속도를 의미있게 향상시켰지만 ${} 태그를 사용하여 개발한 것이 만족스럽진 않았다. 그러나 Dao단을 추가하여 작업할 정도로 많은 시간을 투자할만한 화면이 아니었고 ${} 태그를 사용하는 데 있어 상대적으로 덜 위험한 환경이라 판단했기 때문에 ${} 태그를 이용했다.

[추가] Java단에서 #{COL1_1} ~ #{COL1_200} 까지 인자만 생성해주고 xml에 200개의 SELECT UNION ALL을 작성해주면 ${} 태그를 사용하지 않아도 된다.

조금 더 정석적인 방법으로는 다음과 같다.

1. Map을 대체할 객체 생성 : Map의 KEY 항목에 해당하는 필드를 가지는 객체 생성

public class Data {
    private String COL1;
    private String COL2;
    private String COL3;
    
    // getter and setter 
    
    // 생성자
}

2. 데이터 처리 : Data 항목에 컬럼들을 할당하고 List<Data>에 해당 Data를 add

List<Data> dataList = new ArrayList<>();

for (Map<String, Object> paramMap : paramList) {
    Data data = new Data();
    data.setCOL1((String) paramMap.get("COL1"));
    // ... 다른 필드들 설정
    
    dataList.add(data);
}

3. DAO 매서드 수정 : DAO 메서드의 파라미터를 List<Data> 형태로 수정하여 전달

public int insert_NEW(List<Data> dataList) {
    // ...
}

4. Mybatis XML 수정 : Mybatis XML 상에선 foreach 태그를 이용해 다중 INSERT

<insert id="insertQueryId" parameterType="java.util.List">
    INSERT INTO [테이블] (
        COL1, COL2, COL3
    )
    VALUES
    <foreach collection="list" item="item" separator=",">
        (
            #{item.COL1}, #{item.COL2}, #{item.COL3}
        )
    </foreach>
</insert>

대용량 데이터 이관시 안정성 확보하기 (데이터분리, 인덱싱)

감성적인 개발자 — Sun, 18 Jun 2023 16:04:18 +0900

차세대 프로젝트에서 데이터 이관작업을 위해 AS-IS 테이블을 ①우리 개발 DBMS로 그대로 밀어 넣은 다음, ②프로시저를 돌려 개발에 사용되는 테이블에 데이터를 밀어 넣는 작업을 하는 중 DB가 뻗어버렸다.

데이터가 1000만건이 넘어가고 다른 프로시저들이 함께 돌아가다 보니 프로시저를 한 번에 실행하기 어려웠던 것으로 보인다.

프로시저 분리 및 인덱스 추가

그래서 테이블 데이터를 조건별로 데이터를 끊어서 밀어넣기로 했다. 그렇다 해도 최대 70만 건의 row를 조회하기 때문에 속도개선을 위해 SELECT 문에 조인 조건으로 사용 중인 컬럼들에 인덱스를 추가했다. (기간에 해당하는 컬럼은 기존에 조인조건에도 포함되었기 때문에 인덱스로 같이 잡혔다.)

결과

확실히 데이터 건수가 작아지다 보니 실행 시간이 단축된 게 느껴졌다. 또한 일부 데이터는 PK중복 등 오류로 인해 전송되지 않기도 했는데 만약 프로시저를 한 번에 돌렸다가 오류가 났다면 모든 데이터를 처음부터 다시 이관해야 했을 것이다.

데이터 이관시 건수가 많거나 용량이 클 경우, 테이블 구조를 파악하는데 시간을 쓰더라도 대용량 데이터를 한 번에 이관하는 방식은 지양하는 것이 바람직해 보인다.

넥사크로 그리드 포커스 해제, row 선택 해제하기

감성적인 개발자 — Wed, 26 Apr 2023 15:23:50 +0900

한 화면에 그리드가 몰려있는 경우, 모든 그리드의 BODY 영역의 row가 선택된 상태로 있기 때문에 보기 안좋을 때가 있다. Grid.selectRow() 메서드를 이용해 N개 의 그리드가 있을 때도 하나의 그리드의 row만 선택할 수 있도록 구현해보았다.

* selectRow()메서드는 그리드의 selecttype 속성값이 "row" 또는 "multirow" 인 경우만 동작한다.

초기 포커스 해제하기

조회직후 콜백단에서 그리드 row를 선택하지 않도록 해준다. selectRow에 rowIndex 인자로 전달되는 -1 인덱스는 존재하지 않아 row가 선택되지 않지만 기존에 선택되어있는 row를 선택해제 시켜준다.

this.init_GridFocus = function(objGrid){
    if(typeof(objGrid) == "object") {
        objGrid.selectRow(-1);
    }
};

onkillfocus 이벤트 지정해주기

그리드 포커스가 나갈 때 발생되는 onkillfocus 이벤트에 selectRow를 수행하도록 하면, 기존에 선택되어있던 그리드의 row 선택이 해제된다.

this.gridFocusOut = function(obj:nexacro.Grid,e:nexacro.KillFocusEventInfo){
        if(typeof(obj) == "object") {
            obj.selectRow(-1);
    }
}

[Oracle]DB 인덱스 정의, 특징, 주의사항

감성적인 개발자 — Sat, 25 Feb 2023 15:43:07 +0900

인덱스

테이블에 저장되어있는 데이터를 스캔할 때 table full scan을 수행하면 O(n)만큼의 시간복잡도를 가진다. 저장된 데이터가 많아질 수록 검색속도가 느려지게 되는데, 이 때 인덱스를 이용하면 검색속도를 향상시킬 수 있다.

인덱스 생성

인덱스는 자동으로 생성되는 인덱스와 사용자가 수동으로 생성하는 인덱스가 있다. 대부분의 RDBMS에서는 테이블 정의에서 PRIMARY KEY 또는 UNIQUE 제약 조건을 정의하면 인덱스가 자동으로 생성되는데 이를 고유 인덱스라고 하며, 사용자가 직접 생성한 인덱스를 비고유 인덱스라고한다.

생성쿼리

CREATE [UNIQUE][BITMAP]INDEX 인덱스이름 ON 테이블 (column[, column]...)

인덱스가 기반으로 하는 열의 값이 고유해야 함을 나타내려면 UNIQUE를 지정하면된다.

각 행을 별도로 인덱스화하지 않고 각 구분 키에 대한 비트맵을 사용하여 인덱스가 생성되도록 하려면 BITMAP을 지정하면 된다.

한 번 생성된 인덱스는 수정할 수 없으므로 인덱스를 변경하려면 삭제 후 다시 생성해야한다.

단일 인덱스만으로 처리하기 힘든 대용량 데이터베이스 에서는 두 개 이상의 컬럼을 하나의 인덱스에 지정해서 생성하기도 하는데 이를 결합인덱스라고 한다. (결합인덱스 지정 순서에 관한 글 참조)

*이해를 돕기위한 예시이며 실제 인덱스는 행열 형태가 아닌 B-Tree 또는 B+Tree 형태로 저장되어있다.

인덱스를 생성하면 테이블과 매핑된 또 다른 테이블(=오브젝트)이 하나 생성된다고 볼 수 있다. 인덱스가 동작할 때는 기존 테이블과 매핑된 ①인덱스에서 데이터를 찾은 다음 → ②테이블에 접근해서 데이터를 가져온다.

인덱스는 기본적으로 정렬되어 있기 때문에 B-tree 혹은 B+tree와 같은 탐색기법으로 O(logN)의 속도로 탐색 가능하며, 인덱스에 저장된 물리적주소를 이용해 테이블에 접근하므로 table full scan이 이루어지지 않는다.

인덱스 선정기준

인덱스를 많이 생성한다고 반드시 좋은 것(쿼리속도 향상)은 아니다. DML 작업이 커밋되면 변경사항을 인덱스에도 반영해야하는데, 테이블과 연관된 인덱스가 많을 수록 관련 인덱스를 모두 갱신해야 함으로 서버의 부담이 증가한다. 따라서 다음과 같은 경우에만 인덱스를 생성해야한다.

1) 열(Column)에 많은 NULL 값이 포함된 경우

- NULL 값을 제외하고 검색해야하는 경우 인덱스를 사용하면 검색 속도를 향상시킬 수 있다.

2) 열(Column)에 광범위한 값이 포함된 경우

- 인덱스 컬럼에 다양한 값이 있는 경우 인덱스를 사용하면 검색 속도를 향상시킬 수 있다.

3) WHERE절 혹은 JOIN 조건에 자주 사용되는 경우

4) 테이블이 크고 대부분의 쿼리가 테이블에서 2~4% 미만의 행을 검색할 것으로 예상되는경우

- Index range scan이 table full scan 보다 느려지는 조회 건수 지점을 인덱스 손익분기점 이라 하는데, 테이블 전체 데이터양의 10 ~ 15% 이상을 출력하게 되면 오히려 table full scan이 효율적일 수 있다.

5) ORDER BY 절에 자주 사용되는 경우

- 인덱스는 기본적으로 정렬되어있어서 order by를 수행할 필요가 없다.

* 손익분기점 2~4%는 공식문서상의 수치이며 디스크 I/O, 메모리 I/O 비용 간의 비용 차이를 고려하여 결정되므로 환경에 따라 다르다.

또한, 다음과같은 경우에는 인덱스를 생성 또는 지정하지 말아야한다.

1) 열(Column)이 조건절에서 자주 사용되지 않는 경우

2) 테이블이 작거나 대부분의 query가 테이블에서 2%~4% 이상의 행을 검색할 것으로 예상되는 경우

3) 테이블이 자주 갱신되는 경우

- SELECT는 빨라질 수 있지만 인덱스를 INSERT하는 경우 위치탐색이 필요하며 UPDATE되는 경우에도 변경사항을 인덱스에 반영해주어야한다.

4) 인덱스화된 열이 표현식의 일부로 참조되는 경우

주의사항

쿼리상에서 다음과 같이 인덱스를 이용하면 인덱스를 활용했음에도 속도가 느릴 수 있다.

1) 인덱스 컬럼 가공

- 인덱스의 기본 원리는 키 값(Key Value)을 사용하여 레코드를 신속하게 찾는 것이므로 WHERE 절에 사용된 열과 인덱스의 첫 번째 열이 일치해야 효과적인 인덱스 스캔(Index Scan)이 이루어진다.
SUBSTR(인덱스, 1, 4) = ‘2023’
▶ LIKE 인덱스||’%’

2) 묵시적 형 변환 이용 (인덱스가 DATE형 일 경우 예시)
인덱스 = '20230331’
▶ 인덱스 = TO_DATE('20230301', 'YYYYMMDD’)

3) 인덱스 컬럼 부정형 비교

- 부정형 비교는 인덱스를 탐색하는 데 필요한 키를 정의하지 못하기 때문에 인덱스를 사용할 수 없게 된다.
인덱스 != '10’
▶ 인덱스 IN ('20', '30’)

4) LIKE %가 앞에 위치할 경우
- full scan이 수행됨

5) OR 조건 사용

참조

Oracle Database 11g: SQL Fundamentals

인덱스를 타면 왜 빨라지는지 아니? - SQL전문가 정미나