따봉 구걸남's 블로그

AWS 환경에서 S3 통한 덤프파일 전달 받아 데이터펌프 사용하기 

# 외부 Oracle 환경에서 expdp 로 덤프 파일 생성

expdp username/password@database_link \
DIRECTORY=data_pump_dir \
DUMPFILE=export_dump.dmp \
SCHEMAS=schema_name \
LOGFILE=export_dump.log

case 1. ec2 oracle  환경에서 impdp 

1) 생성된 덤프 파일 S3 버킷에 업로드

 - AWS CLI를 사용하여 덤프 파일을 S3 버킷에 업로드합니다:

aws s3 cp export_dump.dmp s3://your-bucket-name/export_dump.dmp

2) EC2 인스턴스 접속,  S3 버킷으로부터 덤프 파일 다운로드

 - EC2 인스턴스에 접속합니다:

ssh -i "your-key.pem" ec2-user@your-ec2-instance-public-dns

 - S3 버킷에서 덤프 파일 다운로드

aws s3 cp s3://your-bucket-name/export_dump.dmp /tmp/export_dump.dmp

3) ec2 Oracle 에 impdp 로 데이터 로드

impdp username/password@database \
DIRECTORY=data_pump_dir \
DUMPFILE=export_dump.dmp \
SCHEMAS=schema_name \
LOGFILE=import_dump.log \
TABLE_EXISTS_ACTION=REPLACE

- 작업 후 파일 삭제

aws s3 rm s3://your-bucket-name/export_dump.dmp

case 2. rds oracle  환경에서 impdp 

1) 생성된 덤프 파일 S3 버킷에 업로드

aws s3 cp export_dump.dmp s3://your-bucket-name/export_dump.dmp

2) S3에서 덤프 파일을 다운로드

BEGIN
  rdsadmin.rdsadmin_s3_tasks.download_from_s3(
    p_bucket_name    => 'your-bucket-name',
    p_s3_prefix      => 'export_dump.dmp',
    p_directory_name => 'DATA_PUMP_DIR'
  );
END;
/

3) rds Oracle 에 impdp 로 데이터 로드

DECLARE
  v_hdnl NUMBER;
BEGIN
  v_hdnl := DBMS_DATAPUMP.OPEN(
    operation => 'IMPORT',
    job_mode  => 'SCHEMA',
    job_name  => 'IMPORT_JOB'
  );
  
  DBMS_DATAPUMP.ADD_FILE(
    handle    => v_hdnl,
    filename  => 'export_dump.dmp',
    directory => 'DATA_PUMP_DIR'
  );
  
  DBMS_DATAPUMP.METADATA_FILTER(
    handle => v_hdnl,
    name   => 'SCHEMA_EXPR',
    value  => 'IN (''schema_name'')'
  );
  
  DBMS_DATAPUMP.START_JOB(v_hdnl);
END;
/

# impdp 작업 모니터링

SELECT *
  FROM DBA_DATAPUMP_JOBS 
 WHERE JOB_NAME = 'IMPORT_JOB';
  

커피를 하루 1잔 정도 꾸준히 마시게 된지는 몇 년 되었는데 주로 아묻따 아아로 마시곤 했다. 

그러다 최근에 커피오일이라는게 심장에 안좋다는 영상을 보았는데, 대신에 드립커피를 마시면 괜찮다는 것을 알게됨.

또 다른 추출 방식으로 콜드브루 라는 것도 있는데 커피추출 방식에 따라 성분, 맛도 달라지는 것을 알게되어 한번 정리해봄.

이것을 보구 나에게는 어떤 스타일의 커피가 적당한지 판단해보면 좋을 듯함. 

위의 3가지 말고도 다른 방식의 추출(ex. 모카포트) 도 있는데 보통 언급한 3가지가 가장 많이 카페에서 접할수 있는 것이라 3개만 정리 해봄.

1. 추출 별 종류

 - 아메리카노

제조방식 : 제일 기본인 아메리카노는 고온, 고압의 머신으로 빠르게 추출한 에스프레소에 물을 희석하여 제조. 
맛 : 쓴맛과 진한 풍미.
성분 : 항산화 물질, 카페스톨, 카페인 ( 평균 125mg)

 - 콜드브루(더치커피)

제조방식 :  분쇄된 원두를 차가운 물 또는 상온의 물에 12-24시간 동안 천천히 우려냄. 원액에 물을 희석하여 마심
맛 : 차가운 물로 추출하여 쓴맛과 신맛이 덜하고 부드러운 풍미
성분 : 항산화 물질, 카페스톨, 카페인 ( 평균 212mg => 추출시간이 길고 더 많은 원두 사용) 


 - 드립커피 

제조방식 : 분쇄된 원두에 물을 부어 필터(종이 또는 섬유) 로 걸러 추출 
맛 : 아메리카노와 콜드브루의 중간 정도 순한 맛. 
성분 : 카페스톨 95% 걸러짐. 카페인은 아메리카노와 비슷 혹은 조금 높음. (물에 잘녹는 특성으로 필터로 걸러지지않음)

2. 체질별 추천 

- 커피 마시고 속이 쓰린적이 있다 => 산도가 덜한 콜드브루
- 심혈관 질환이 우려되거나 콜레스테롤 관리가 필요하다 => 필터로 기름성분 걸러진 드립커피
- 카페인에 민감 하다 => 콜드브루 절대 no, 커피를 안마시는게 좋다. 

 저가커피 매장에서는 드립커피 메뉴가 없는 경우가 많은데, 이는 바리스타에 따라서 맛이 많이 바뀌기에 일관된 품질을 제공하기 어려움에 있다.  또한 추출시간이 상대적으로 길어(5분 이상) 박리다매의 저가커피 매장에는 어울리지 않다. 

반면 콜드브루는 대량으로 만들어놓고 주문시 희석해서 내어주기만 하면 되서 대부분 저가커피 매장도 콜드브루는 구비하고 있다. 

반대로 생각하면 커피맛에 자신있는 개인 매장은 드립커피로 차별화를 할수 있으니 개인 매장에서는 드립커피를 마시는게 좋은 선택일듯 하다. 

겨울철에 자동차 배터리가 방전될까봐 공회전 시키러 갔다가 스마트키 배터리가 나가버렸다. 

시동은 켜는것까지는 성공했는데, 충분히 예열하고 시동을 꺼야 할때가 되니 스마트키 배터리가 나간것이다. 
시동이 꺼질때도 차가 스마트키를 감지해야 문을 닫을수 있는데, 감지를 못하니 차 문을 못닫는 상황이 발생. 

사실 스마트키 배터리가 방전되어도 키를 지정된 위치에 놓으면 자동차가 이를 감지할수 있다. 
근데 그 지정된 위치를 몰라서 헤맸다. (한번도 이런 경험이 없었기에...)

차량마다 그 위치는 다른거 같은데 트레일블레이저의 경우는 기어봉과 컵홀더 뒤의 공간이다. 

스마트키 코인전지 교체 하기

스마트키 배터리 교체하는 방법은 이름과 달리 스마트 하지 않다.
배터리 부분만 탈착식이 아니고 전체 케이스를 까야 한다.
이게 맞나 싶은 생각이 들 정도로 클래식하다. 
 - 차키 옆의 튀어나온 금속부분을 눌러 차키를 뽑은뒤에 

 - 구멍에 차키를 살짝 넣고 회전시켜 케이스가 벌어지는 순간 케이스를 분리한다.

주의할점은 코인전지의 규격이 하나가 아니라서 맞는 규격을 사서 껴야 한다. 

나의 경우는 cr2032 였다. (첨에 모르고 cr2025를 사서 왜 안될까 한참 고민했다 ㅠ)
앞의 '20'은 지름이고 '32'/'25' 가 높이 이다. 그러니 2025를 사면 7mmr가 뜨게되어 동작이 안된다. 그 숫자가 뭘 의미하는지 몰라서 올해가 2025년이니까 올해나온 신상품인가 보다 하고 산 것이다. 코인전지에 여러 규격이 있는걸 처음 알았다. 

이번에 느낀건데 (예상은 한거지만) 다이소 건전지가 수명이 1년이 안되는 것 같다. 작년에도 다이소에서 교체했던것 같은데 벌써 방전이 되었다니... 보통 2,3 년 정도까지가 일반적인 (스마트키 배터리용도의) 수명으로 알고 있는데..

뭐 저렴하니까 산건데 은근 건전지 교체가 스트레스 받는 일이라 웬만하면 에너자이저 같은 거 쓰는게 나을듯 하다. 
그리고 내가 잘못 한 것 중 하나가 스페어 키가 하나더 있는데 그 두개 다 건전지를 껴놓은 상태라 두개가 다 방전이 되었다.  안쓰면 수명이 다르지 않을까 생각했는데 전혀 아니었다. 
 
# 추가 꿀팁
예전에 스마트키 를 바지에 넣고 세탁기에 돌린적이 있는데, 당연히 고장나서 사용 불가 일거라 예상했는데,
혹시나 하는 심정으로 부품을 하나씩 뜯어서(그래봤자 케이스 + 기판 + 실리콘 + 건전지 이게 전부) 잘 말리고 다시 조립하면 사용이 가능하더란..

하나에 십만원도 넘는 귀한 몸인데, 굉장히 섬세하게 다뤄줘야 할 놈 같지만 의외로 막굴려도 멀쩡하다. 

OTT 구독은 안해도 따릉이는 구독을 하고 있습니다. 

가격도 저렴하고 활용도도 높아서 만족하고 있는데요, 한정거장만 가면 되는데 환승을 해야하거나 축구나 야구경기가 있어 지하철이 매우 혼잡할때 활용하면 매우 좋습니다. 

여러 달 사용하고 느낀 점과 개선하면 좋겠다 싶은 것들을 끄적여 봅니다.

- 요금

 일회용 요금은 1시간 1000 원입니다.  

 1시간 6개월은 15000 원, 1년은 30000 원이라 할인이 없어 굳이 1년을 할 필요는 없습니다. 

 여기서 주의점은 6개월 동안 하루에 1시간만 사용하는 것은 아니라는 것인데요.  

 1시간내에 반납하면 하루에 몇번이라도 계속 이용할수 있다.

그래서 반납만 가능하다면 굳이 2시간 권을 살 필요도 없습니다.

아무데나 반납가능 한것은 아니고 반드시 지정된 대여소에 반납해야 반납이 가능합니다. 

가끔 민간이 운영하는 공유 vehicle 중에 아무데나 반납하는 것들도 있는데요. 

사용자는 편하겠지만 다른 시민이나 거주민에게는 매우 보기도 않좋고 민폐인데 따릉이는 그렇지 않아 좋습니다.

- 주의점 

 오랜동안 사용하면서 몸소 겪은 꿀체험기

 자전거의 정비상태가 제 각각 이라 대여하기 전에 몇가지 체크하고 대여하면 좋습니다. 

 제일 기본적으로는 벨, 브레이크 입니다. 브레이크는 매우 중요해서 보통 정비상태는 좋습니다.

 벨은 가끔 이상한 위치에 달려있거나 해서 불편한 경우도 있으니 잘 확인이 필요합니다. 

 두번째는 잠금장치 인데요. 

  앱으로 잠금해제를 하면 블루투스로 신호가 전달되서 자전거 잠금장치가 열려야 되는데 

 가끔 안되는 경우가 있습니다. 시간내에 반납해야 되고 고장시 바로 도움을 받을 직원이 있는 것도 아니라 

 굉장히 난처한 상황에 처할수도 있어요. 그럴때는 차분히 앱이나 핸드폰을 재부팅 해 봅니다. 

 또는 수동으로 열리는지 시도해봅니다. 처음부터 잠금해제가 시원찮게 동작하면 바로 반납하게 다른 기기를 선택하는게 젤 좋아요.  

- 개선점 및 느낀점

따릉이는 민간사업자가 영리 목적으로 운영하는 것은 아닙니다. (겨울에는 위험하니 사용을 자제해 달라고 권고까지 합니다. )그래서 상대적으로 저렴한 비용으로 운영을 하고 있는데요.. 아무래도 정비에 들어가는 비용이 발생할텐데 사용자들로부터 피드백을 받을수 있는 시스템이 있다면 그 노력을 조금은 줄일수 있지 않을까 하는 생각을 해봤습니다. 직접 타지 않고서는 잘 모르는 상태들이 있으니까요.

많이 탈수록 탄소배출량이 절감되서 더 좋은 환경을 만들고자 하는 취지로 다들 많이 이용했으면 좋겠네요. 

요즘 러우 전쟁 영향도 있지만 러시아 밈도 그렇고 러시아에 대한 관심이 많아지고 있다. 

러시아는 알면알수록 꽤나 독특한 나라이다. 

어릴적 초등학교 다닐때 보면 저학년 때는 키도 작고 맞고 다니다가 고학년 되면서 덩치도 커지고 힘도 세지면서 
반에서 짱까지 먹게되는 그런 아이가 있는데 러시아 역사가 그렇다. 

지금의 이미지만 보면 오래 전부터 동네 터줏대감으로 방구 꽤나 꼈을거 같지만 오랫동안 변방이었고 타민족에게 우리의 우두머리가 되어달라고 찾아가기도 하고, 몽골에 직접 지배당한 굴욕의 기간도 길다. 

- 간단하게 정리한 러시아 역사 

 9세기 동슬라브 족의 키예프 루스를 현대 러시아의 뿌리라고 본다면 이때를 시작으로(9세기 전까지는 존재감이 없다)  
 13세기 몽골제국의 지배, 15세기 모스크바 대공국으로 이어지게 된다. 

이후 러시아제국 -> 소비에트 연방(소련) -> 현재의 러시아 연방으로 이어지게 된다.
1991년 고르바쵸프 시절 구소련이 붕괴되고, 러시아 연방의 초대 대통령으로 옐친이 취임.

이후 푸틴, (헌법상 제약으로) 매드베데프 잠깐 걸치고 다시 푸틴이 현재까지 재임 중.
 2000년에 취임한 푸틴이 아직까지 해먹는 중이라는 사실.
 
- 러시아는 유럽인가 

우리의 시선으로 보면 러시아는 유럽이지만 유렵의 시선으로는 그들을 좀 다르게 본다. 
 1) 종교적 측면 : 유럽 중 가장 늦게 기독교를 받아들였다(988년). 기독교의 탄생을 1세기, 로마가 국교로 받아들인것이 380년 임을 감안하면 상당히 뒤늦게 받아들임.  
 2) 정치 체제 : 유럽은 대부분 자유 민주주의, 러시아는 사실상 1인 독재 국가이다.
 3) 역사적 측면 : 유럽 역사의 뿌리는 로마, 러시아와는 별개의 역사 
유럽도 처음엔 중아집권적 왕정 국가에서 출발했지만 그 권력이 점점 귀족, 여러사람, 대중까지 내려오는 과정을 거침.
러시아는 헌법상 3권은 분리지만 이것이 지켜지지는 않음.  
 
유럽은 유럽공동체 출범이후 EU 국가 간에 사실상 국경이 없어지고 평화의 시대가 길어지게 되었다. 
때문에 사람들은 먹고사는 문제가 가장 큰 관심사 이고, 국방비에 대한 지출이 점점 줄어들게 됨. 

 

오징어게임2 에 타노스 역할의 빌런에 TOP 가 나오는데, 이에 대한 사람들의 반감이 꽤나 크다. 

연기에 대한 호불호를 말할수는 있다. 어차피 주관적인 평가이니까. 근데 좀 사람들의 말을 들어보면 그정도까지는 아닌거 같은데 미운털이 많이 박혔구나.. 싶은 생각이 든다. 

황동혁 감독은 top 을 캐스팅했을때 충분히 시간이 지난 사건이기에 괜찮을거라고 생각했다고 한다. 

물론 대중의 반응도 살펴봐야 겠지만 자기가 데려온 사람에 대해서는 끝까지 포용하는 태도를 보이지 못한것은 아쉬워보인다.

- 캔슬 컬쳐

캔슬 컬처(Cancel Culture, 취소 문화)란 나와 다른 생각이나 이념을 가진 사람(주로 유명인)의 SNS 팔로우를 취소하는 문화로 받아들여진다. 2010년대 이후 X(당시 트위터) 등 SNS 플랫폼에서 비롯된 이 온라인 문화 현상은, 소수자 혐오 등 부적절한 말을 한 사람들에게 ‘#Canceled’ 등의 말과 함께 해시태그를 다는 형태로 지적하며 생겨났다.

출처 : 경북대학교 신문방송사(http://www.knupresscenter.com)

예전에 가나출신 방송인 샘 오취리가 한국의 캔슬컬쳐가 유독 심하다고 말한적이 있다. 

샘 오취리 또한 한국말 잘하면서 한국을 사랑하는 모습들로 대중의 호감을 쌓다가 sns 에서 관짝소년단 학생들의 흑인 분장에 대해 한마디 한 것을 계기로 탈탈 털려서 그 이후로 (한국의) 방송에는 나오지 못하고 있다.  

누구나 잘못은 할수 있다. 이를 비난 할수도 있다. 그러나 한편에는 또 포용적인 문화도 있어야 하지 않나 싶다. 
삼국지에서 유비,관우,장비의 이야기를 사람들이 좋아하는 것은 그들의 의리, 의협심 등의 가치 때문일 것이다. 
한편 조조는 잔혹한 측면은 있었지만 삼국 중 제일 세력이 컸던 나라이다. (결국 사마의에게 먹히긴 했지만.)
그 조조가 제일 잘한 것은 사람을 뽑을때 유연한 것이었다. 능력이 있다면 받아주는 것에 있다. 그래서 능력이 있는 인재들이 조조에게 스스로 먼저 찾아가게 된 것이다. 

한번의 실수로 나락이 가게되면 다시는 기회를 얻지 못하는 사회보다는, 포용적이고 능력이 있다면 기회가 주어질수 있는 사회가 조금더 사회 전반적으로 활기찬 사회가 되지 않을까.. 혼자 생각해 봅니다. 

데이터베이스 모델링에서 관계는 결국 컬럼으로 표현이 되는데 이 컬럼이 참조하는 테이블이 자기자신일 때가 있다. 

이를 자기 참조 모델 또는 순환 관계 모델이라고도 부르는데, 어떻게 사용하는지 알아보자.

-- 테이블 생성
CREATE TABLE EMPLOYEES (
    EMPLOYEE_ID NUMBER PRIMARY KEY,
    FIRST_NAME VARCHAR2(50),
    LAST_NAME VARCHAR2(50),
    EMAIL VARCHAR2(100),
    PHONE_NUMBER VARCHAR2(20),
    HIRE_DATE DATE,
    JOB_ID VARCHAR2(10),
    SALARY NUMBER(8,2),
    MANAGER_ID NUMBER,
    DEPARTMENT_ID NUMBER
);

-- 샘플 데이터 삽입
INSERT INTO EMPLOYEES VALUES (100, 'Steven', 'King', 'SKING', '515.123.4567', TO_DATE('17-JUN-2003', 'DD-MON-YYYY'), 'AD_PRES', 24000, NULL, 90);
INSERT INTO EMPLOYEES VALUES (101, 'Neena', 'Kochhar', 'NKOCHHAR', '515.123.4568', TO_DATE('21-SEP-2005', 'DD-MON-YYYY'), 'AD_VP', 17000, 100, 90);
INSERT INTO EMPLOYEES VALUES (102, 'Lex', 'De Haan', 'LDEHAAN', '515.123.4569', TO_DATE('13-JAN-2001', 'DD-MON-YYYY'), 'AD_VP', 17000, 100, 90);
INSERT INTO EMPLOYEES VALUES (103, 'Alexander', 'Hunold', 'AHUNOLD', '590.423.4567', TO_DATE('03-JAN-2006', 'DD-MON-YYYY'), 'IT_PROG', 9000, 102, 60);
INSERT INTO EMPLOYEES VALUES (104, 'Bruce', 'Ernst', 'BERNST', '590.423.4568', TO_DATE('21-MAY-2007', 'DD-MON-YYYY'), 'IT_PROG', 6000, 103, 60);
INSERT INTO EMPLOYEES VALUES (105, 'David', 'Austin', 'DAUSTIN', '590.423.4569', TO_DATE('25-JUN-2005', 'DD-MON-YYYY'), 'IT_PROG', 4800, 103, 60);
INSERT INTO EMPLOYEES VALUES (106, 'Valli', 'Pataballa', 'VPATABAL', '590.423.4560', TO_DATE('05-FEB-2006', 'DD-MON-YYYY'), 'IT_PROG', 4800, 103, 60);

SELECT LEVEL, 
       LPAD(' ', 4*(LEVEL-1)) || e.FIRST_NAME || ' ' || e.LAST_NAME AS "Employee",
       e.EMPLOYEE_ID,
       e.MANAGER_ID,
       e.JOB_ID,
       e.SALARY,
       e.DEPARTMENT_ID
FROM EMPLOYEES e
START WITH e.MANAGER_ID = 0
CONNECT BY PRIOR e.EMPLOYEE_ID = e.MANAGER_ID
WHERE e.DEPARTMENT_ID = 60
ORDER SIBLINGS BY e.SALARY DESC;

- WHERE 절은 계층 구조가 만들어진 후에 적용. => 상위 관리자가 다른 부서에 속해 있어도(ex. 90) 결과에 포함
- ORDER SIBLINGS BY : 이 구문은 같은 레벨의 형제 노드들을 정렬.
  여기서는 각 레벨에서 급여(SALARY)를 기준으로 내림차순 정렬합니다. 예를 들어, LEVEL 4의 Bruce, David, Valli는 모두 같은 상사(Alexander)를 가지고 있으며, 이들은 급여 순으로 정렬됨.
- 최상위노드의 manager_id 는 보통 null 이 된다. 그러나 검색 편의를 위해 특정 값을 넣거나 편의상 컬럼을 추가하기도한다. (ex. IS_ROOT )

- prior 에 명시된 컬럼이 상수로 바뀌고 이를 반대편 컬럼(manager_id) 에 넣고 찾아가게 되므로 해당 컬럼에 인덱스를 생성하는 것이 좋다. 역전개의 가능성이 있기에 반대쪽 컬럼에도 인덱스를 생성하는 것이 좋다. 

mysql 은 복제 기능을 이용하여 master-slave 의 아키텍쳐를 많이 사용하는데,

multi master 란 master 가 하나가 아닌 여러개를 두고 서비스를 하는 형태를 말한다. 

구성하기

 1. master-master 복제 

 2. 한쪽을 read_only=1 (passive-master)

  * split brain issue

3. event_scheduler 

   on (active) / off (passive)

4. monitor, vip failover

mmm (multi master replication manager )

양방향으로 write 가능하지만 데이터 불일치 가능성 때문에 실제로 그렇게 쓰지는 않고 

한쪽에만 write 를 허용하고, 다른쪽에서는 read_only=1 로 설정하여 한곳에서만 dml 이 이루어진다.

이때 write 가 허용된 쪽을 active(혹은 primary)-master 라 부르고, 다른 한쪽을 passive-master 라고 부른다. 

write 가 이루어지는 노드가 down 되면 manager 서버에서 이를 감지하여, 다른 한쪽으로 서비스를 넘기게 된다. 

그래서 이론적으로는 down time 이 수 분 내로 이루어지게 된다. 하지만 manager 서버는 이중화가 되어있지 않으므로 

이것이 down 될 경우는 관리자가 먼저 인지 해야 함

mysql 의 innodb 엔진에서는 테이블 생성시 참조제약조건만 걸고 해당 컬럼에 인덱스를 생성하지 않아도 자동으로 인덱스가 생성이 된다. 

constraint 만 걸고 테이블을 생성하는 것과 명시적으로 키를 생성하는 것의 차이를 알아보자. 

drop table parent;
drop table child_no_idx;
drop table child_idx;


-- parent 테이블 생성 (일반 컬럼 추가)
CREATE TABLE parent (
    id INT NOT NULL PRIMARY KEY,
    name VARCHAR(50),
    email VARCHAR(100),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB;

-- child 테이블 생성 (제약조건만 명시)
CREATE TABLE child_no_idx (
    id INT NOT NULL PRIMARY KEY,
    parent_id INT,
    name VARCHAR(50),
    email VARCHAR(100),
    description TEXT,
    CONSTRAINT `fk_no_idx_parent_id` FOREIGN KEY (`parent_id`) REFERENCES parent(id)
) ENGINE=InnoDB;

-- child 테이블 생성 (제약조건 + key를 명시)
CREATE TABLE child_idx (
    id INT NOT NULL PRIMARY KEY,
    parent_id INT,
    name VARCHAR(50),
    email VARCHAR(100),
    description TEXT,
    KEY `ix04_child` (`parent_id`),
    CONSTRAINT `fk_idx_parent_id` FOREIGN KEY (`parent_id`) REFERENCES parent(id)
) ENGINE=InnoDB;


-- 인덱스 확인을 위한 쿼리
SHOW INDEX FROM child_no_idx;

SHOW INDEX FROM child_idx;

참조제약조건이 걸려있으면 인덱스를 생성하지 않아도 자동으로 인덱스가 (제약조건 이름으로) 생성이 되었다. 

이제 세컨더리 인덱스를 아래와 같이 추가해보자. 

create index ix01_child on child_no_idx(name, parent_id);
create index ix02_child on child_no_idx(parent_id, name);

제약조건 이름으로 자동 생성되었던 인덱스가 사라졌다. 

참조 제약조건 컬럼(parent_id) 을 선두로 하는 인덱스가 명시적으로 생기면 자동 생성된 인덱스가 사라진다.  

두번째 명시적으로 key 를 만들었던 경우를 비교해보자. 

세컨더리 인덱스를 동일하게 추가해보자. 

create index ix01_child on child_idx(name, parent_id);
create index ix02_child on child_idx(parent_id, name);

사라지지 않고 남아있다.  

물론 ix02_child 인덱스가 parent_id 컬럼을 포함하므로 ix04_parent_id 인덱스는 삭제가 되어도 상관이 없다. 

다만 (제약조건으로 인해) 자동 생성된 인덱스는 자동 삭제가 될수도 있다는 것을 유의해야하고, 이를 인지 하지 않은 상태에서 인덱스를 추가할 경우 의도치 않게 삭제될수 있으니 무조건 명시적으로 key 를 만드는 것이 좋다. 

IOPS와 throughput은 데이터베이스 및 스토리지 시스템의 성능을 측정하는 중요한 지표이다.

IOPS (Input/Output Operations Per Second)

초당 처리할 수 있는 읽기/쓰기 작업의 수를 나타냄
작은 파일들에 대한 빈번한 접근이 필요한 경우에 중요한 지표
데이터에 대한 빠른 접근 및 처리가 필요한 환경에서 중요

Throughput (처리량)

초당 처리할 수 있는 데이터의 크기를 측정. 주로 메가바이트 단위로 표현
큰 파일들을 주로 다루고 데이터 처리 작업이 많지 않은 경우에 중요한 지표
한 번에 큰 용량의 파일을 읽어야 할 때 중요

계산식

IOPS x I/O size = Throughput
예: 16,000 IOPS × 64 KiB = 1,024 MiB/s (Throughput)