<ABAP> CDS VIEW, AMDP 쓰기전 고민이 필요한 이유..

간단하게 아래 cds view를 사용해서 데이터를 조회하는 프로그램 DB 트리를 보자..

이 부분은 제일 밑단의 사진이다..

AMDP 안에 CDS VIEW를 호출해서 퍼포먼스를 올렸다 라고 생각했는데 막상 해당 부분을 까보니 최악의 퍼포먼스를 만들어놓고 그게 느리니 AMDP로 감싼 것이었다...

해당 AMDP 안에서 호출하는 CDS VIEW 는 그 안에서 총 7단계 레벨의 CDS VIEW 를 호출하고 있었고 가장 밑단까지 와서 CDS VIEW  3개 보니 위 사진처럼 AUAS db를 그냥 다른 조건으로 불러서 union all로 합치고 있었다.

즉, 최악에 최악에 최악의 방향으로 개발해두고 자재들이 많이 느리니까 amdp.....

cds view 가 결국 저지경이 되는 이유는

아래 내용중에 하나가 있을 것이다.

1. 모 대기업 처럼.. 우리는 이제 db 뷰는 전부 cds view 로 만든다!! => 1년 지나 통테할 때 ecc보다 hana가 느려서 cds view를 다 뜯었다.

2. 대형 플젝에 co에 A , B, C ,D , E 컨이 있다..
A 가 aa + bb db를 조회하는  1번 cds view를 만들었다.
B가 보니 1번 CDS뷰 조회 정보 + cc db를 합쳐서 2번 CDS 뷰를 만들었다.

C가 보니 2번 CDS 뷰에다 + DD + EE db를 합쳐서 3번 CDS 뷰를 만들었다.

D가 보니 3번 CDS 뷰에다 + aa DB를 넣어 다른 조건을 추가해서 합치면 될 것 같아 4번 CDS 뷰를 만들었다.

E컨이 보고 4번 CDS 뷰에다 + ff db를 붙여서 5번 CDS 뷰를 만들었다.

그런데 또 다른 모듈에서 CO 정보를 보기위해 뷰를 보니 5번까지 있는데 5번을 가지고 + gg DB를 붙여서 레포트에서 볼 수 있게 6번 CDS 뷰를 만들었다.
.........(그렇게 통테까지 8개월이 지났다 ..)

그렇게 CDS VIEW가 꼬이고 꼬이고 나중에 뜯을 수도 없게 되어버려 다시 이걸 분석하느라 몇개월이 걸려 뜯게 된다..

과거 ECC 보다 느리다..

AMDP 의 경우도 정말 자재관련된 CO나 MM 특별한 경우가 아니라면 그냥 쿼리를 쓰는게 낫다..
이 이야기는 AMDP를 1년동안 몇천라인씩 몇개를 만들어오신 플젝 고수님이 오늘도 이야기하셨다..

즉, 정말 필요하고 특별한 경우가 아니라면 AMDP를 쓸 필요가 없다.. 하나 처리하고 가져오는데 10시간 넘게 걸리고 하는것만 병렬과 AMDP를 고민해야 하고 그전에 위에처럼 CDS VIEW 부터 정리해야 한다.

위 상황에 추가로 발생한 문제는 CPU가 피크쳐서 다른 모듈의 업무가 중단되거나 최악의 경우는 타 대기업에서 DB가 뻗어 그냥 서버리는 경우도 있었다 한다.

쓰기전에 제대로 분석해서 문제가 되는 부분을 분석하자...

위에 저 사진은 247개 DB를 읽고 계산해서 처리하려 하면서 CPU가 피크가까이 올라간다..

우선 제일 하단에 AUAS를 읽는 CDS VIEW 3개를 1개의 CDS VIEW 로 합하면서 그 안에서 CASE 별로 분기해서 처리하게 만들면 우선 UNION ALL 이 없어지기에 빨라진다..

내말은 안믿을 수 있으니 나보다 똑똑한 제미나이 프로의 이야기를 들어보자..

---
최신 SAP 개발 가이드가 "Code-to-Data(데이터베이스에서 처리해라)"를 강조하지만, 지금처럼 잘못 설계된 SQL은 오히려 DB 서버에 과부하를 주고 성능을 갉아먹는 독이 됩니다. 왜 그런지 이유를 3가지로 정리해 드릴게요.
1. 데이터베이스의 'Materialization(실체화)' 부하
WITH 절이나 UNION ALL이 중첩된 CDS 뷰를 호출할 때, DB 옵티마이저(Optimizer)는 내부적으로 **임시 결과물(Intermediate Result Set)**을 메모리에 만듭니다.

SQL 방식: COSPA, COSSA, COSBA 각 마디마다 수천만 건의 데이터를 읽고, SUBSTRING으로 자른 뒤 메모리에 임시 테이블을 생성합니다. 그 후 이들을 다시 합치는 과정을 거칩니다. 이 과정에서 CPU와 메모리를 엄청나게 사용합니다.

과거 ABAP 방식: 필요한 최소한의 데이터만 각 테이블에서 쏙쏙 뽑아(Select) 인터널 테이블에 담고, ABAP 레이어에서 루프를 돌며 합칩니다. 이 방식은 DB 서버의 자원을 거의 쓰지 않고 Application 서버의 메모리만 사용하므로 DB Peak 현상이 발생하지 않습니다.

2. 'Filter Push-down'의 실패 (가장 큰 원인)
DB 성능의 핵심은 **"필요 없는 데이터를 처음부터 안 읽는 것"**입니다.
인터널 테이블 방식: 상위 로직에서 특정 오더 번호(OBJNR)만 필요하다는 것을 알면, SELECT 문에 곧바로 WHERE 조건을 걸어 인덱스를 태울 수 있습니다.
복잡한 UNION ALL 방식: 만약 UNION ALL 내부에서 SUBSTRING으로 필드를 가공했다면, 상위 쿼리에서 WHERE objnr = '...'라고 조건을 걸어도 DB 엔진이 하위 쿼리까지 이 조건을 전달(Push-down)하지 못하는 경우가 많습니다. 결국 DB는 수억 건을 다 읽어서 합친 다음에야 마지막에 필터링을 하게 됩니다.

3. SARGability (Search Argumentable) 문제
인덱스가 걸려 있는 KEY01 필드를 SUBSTRING(KEY01, 3, 22) 처럼 함수로 감싸는 순간, 해당 인덱스는 죽어버립니다.

SQL: DB 엔진이 모든 레코드를 하나하나 꺼내서 3번째 자리부터 잘라보고 조건에 맞는지 확인해야 합니다. (Full Table Scan)

ABAP: 차라리 KEY01 전체를 가져와서 ABAP의 OFFSET(ls_tab-key01+2(22)) 기능을 쓰면, 적어도 데이터 추출 단계에서는 인덱스를 활용할 가능성이 열려 있습니다.


----------
추가로 CTE 구문인
with +it_tab( select........
union all..
select ..)
select ....from it_tab....


도 마찬가지로 느릴 수 있다..
전에도 디버깅 어렵고 업무 정보를 제대로 디버깅 할 수 없다는 단점으로 글을 썼었는데 이 로직도 느려질 수 있다는 것을 알고 써야 한다.

물론 신구문을 알아두는건 매우 중요하다.
OOP 개념은 대충이라도 잘 깨우쳐 놔야 갖다쓰기라도 하고 만들수도 있다.
(이건 컴공출신으로 JAVA 하시는 분들은 날아다니신다. +CTE구문들도 훨씬 잘 쓰신다.)

그러나..... 신구문을 모르더라도 구아밥이라도 퍼포먼스를 잘 활용한다면 충분히 좋은 결과를 얻을 수 있다.

그러면 신기술 몰라도 되나? 한다면 그건 또 아니다... 최신기술들인 AMDP, CDS VIEW, NEW ABAP 구문들은 꼭 활용법을 익혀는 두고 적재적소에 잘 활용 될 수 있도록 하여..
자격증에 적힌것 처럼 찐 ABAP Consultant가 되어보자...ㅎㅎㅎ

오늘도 잡담끝..