네, 답변드립니다. 먼저 인덱스 추가할지 말지 결정할 때 제일 먼저 보는 지표는 buffers입니다. 선택도나 dml 빈도도 참고하긴 하지만, 결국 그 쿼리가 실제로 블록을 얼마나 읽어들이는지가 체감 성능을 가장 직접적으로 보여주기 때문에 buffers를 1순위로 봅니다. 인덱스 갯수 상한선은 사실 딱 몇 개다라고 정해놓기는 어렵습니다. 그 테이블이 조회 위주인지 dml 위주인지에 따라 달라지기 때문입니다. 조회가 압도적으로 많은 테이블이라면 인덱스를 좀 더 여유 있게 두는 편이고, insert나 update가 빈번한 테이블이라면 인덱스 하나 늘어날 때마다 dml 비용이 같이 늘어나니까 훨씬 보수적으로 접근합니다. 그래서 절대적인 개수보다는 그 테이블의 트래픽 패턴을 먼저 보고 판단하시는 게 맞습니다. 운영 중인 큰 테이블에 인덱스를 새로 만들 때는 생성 속도를 위해 parallel 옵션이랑 nologging 옵션을 같이 사용합니다. parallel로 여러 프로세스가 동시에 인덱스를 만들게 해서 시간을 줄이고, nologging으로 리두 로그 생성을 최소화해서 부하를 줄이는 방식입니다. 인덱스 생성후에는 반드시 alter index 명령어로 다시 parallel 을 1로 되돌리고 로깅도 nologging 에서 logging으로 변경을 해둡니다.
네 ~ 답변드립니다. DBMS 의 작동원리는 비슷비슷해서 튜닝의 큰 원리는 거의 같습니다. 다만 DBMS 마다 추구하는 튜닝철학이 달라서 차이가 조금 있습니다. 예를 들어 오라클은 힌트가 많은데 상대적으로 PostgreSQL은 힌트가 거의 없습니다. 혹시 오라클 말고 쓰고 계시는 디비가 어떤건지 알려주시면 더 자세히 답변드릴 수 있습니다.
안녕하세요! 답변드립니다. 구름 IDE 환경 자체는 Linux + UTF-8 기반이라 한글 변수명이 기술적으로 동작합니다. 체험 환경에서 직접 테스트해보시면 실제로 돌아가는 걸 확인하실 수 있을 거예요. https://dataq.goorm.io/exam/3/%EC%B2%B4%ED%97%98%ED%95%98%EA%B8%B0/quiz/1 그런데 저는 그래도 쓰지 말라고 말씀드리고 싶습니다. 이유가 있습니다. 체험 환경과 실제 시험 당일 환경은 같지 않습니다. 공지사항에도 "패키지 및 라이브러리는 시험 회차별로 다를 수 있다"고 명시되어 있고, 시험장 PC의 언어 설정이나 Python 실행 환경 세부 설정까지 동일하다는 보장이 없습니다. 변수명은 아래처럼 짧은 영문으로 습관화하시면 전혀 불편하지 않습니다. df # 데이터프레임 X, y # 피처, 타겟 result # 최종 결과 cnt # 개수 tmp # 임시 변수 이 다섯 개만 몸에 익혀두시면 시험장에서 변수명 고민할 일이 거의 없습니다. 합격하세요!
넵! 좋은 질문이에요 -1을 쓰는 이유 정확히 파악하셨어요! df.loc는 끝값을 포함하기 때문에 -1 안 하면 151개가 맞아요. 다만 더 안전한 방법을 알려드릴게요. 시험 중에 이런 코드가 앞에 있으면 어떻게 될까요? df = df[df['나이'] > 20] # 필터링 필터링 후에는 인덱스가 0, 1, 2, 3… 이 아니라 5, 7, 11… 처럼 뒤섞여요. 이 상태에서 df.loc[:149] 하면 150개가 아닌 엉뚱한 개수가 나와요. 이럴 때 쓰는 게 바로 iloc예요. df_75 = df.iloc[:int(len(df) * 0.75)] iloc는 인덱스 번호가 아니라 순서로 찾아요. “앞에서 150번째까지 주세요” 라고 하는 거라서 인덱스가 뒤섞여도 항상 정확하게 150개를 가져와요. 그리고 -1도 필요 없어요. iloc는 끝값을 포함하지 않거든요! 앞으로 iloc 쓰는 습관 들이시면 시험에서 훨씬 안전해요
좋은 질문 주셔서 정말 감사합니다. 꼼꼼하게 확인하셨네요. 사실 두 방법 모두 등분산 검정에 사용할 수 있는데, 이 문제에서는 '모델은 정규분포를 포함한다'는 조건이 있어서 F검정 공식으로 직접 계산하는 게 더 문제 의도에 맞습니다. var1 = np.var(normal, ddof=1) var2 = np.var(patient, ddof=1) F = max(var1, var2) / min(var1, var2) print(round(F, 3)) 강의에서 levene을 사용한 건 실무에서 자주 쓰이는 방법을 보여드린 것인데, 이 문제처럼 정규분포 가정이 명시된 경우에는 위 공식으로 푸시는 게 정확합니다. 헷갈리셨을 텐데 좋은 포인트를 짚어주셔서 감사합니다.
안녕하세요, 꼼꼼하게 확인해 주셔서 진심으로 감사드립니다! ^^ 말씀하신 내용이 맞습니다. sklearn 공식 문서 기준으로 accuracy_score(y_true, y_pred) — 실제값이 먼저, 예측값이 나중이 올바른 순서입니다. 강의에서 제가 순서를 반대로 사용했는데, accuracy_score는 대칭 함수라 결과값 자체는 동일하게 나오지만, sklearn 컨벤션에 맞지 않는 코드였습니다. precision_score, recall_score, f1_score 등 다른 평가 지표에서는 순서가 바뀌면 결과도 달라지므로, 처음부터 올바른 순서로 익히는 것이 중요합니다. 정확하게 주셔서 감사합니다!
안녕하세요. 질문 정말 감사드립니다. 제 생각으로 답변드리면 다음과 같습닏나. 함수기반 인덱스는 실무에서 무조건 피해야 하는 대상이라기보다는, 마지막에 꺼내는 실무 카드에 가깝다고 봅니다. 결론부터 말하면, 함수기반 인덱스를 피해야 한다기보다는 먼저 SQL을 고칠 수 있는지부터 확인하는 게 맞습니다. 예를 들어 WHERE 절에서 컬럼에 함수를 씌우고 있다면, 먼저 조건식을 함수 없이 바꿀 수 있는지, 데이터 저장 방식을 정리할 수 있는지, 일반 인덱스로 해결할 수 있는지부터 봐야 합니다. 그런데 현실적으로 SQL을 고칠 수 없는 경우도 많습니다. 대표적으로는 첫째, 레거시 코드라서 애플리케이션 SQL을 수정하기 어려운 경우입니다. 이미 여러 시스템에서 같은 SQL을 사용하고 있거나, 배포 리스크가 커서 WHERE 절을 바꾸기 어려운 상황이라면 함수기반 인덱스가 현실적인 해결책이 될 수 있습니다. 둘째, 배치성 레포트나 조회 전용에 가까운 테이블입니다. INSERT, UPDATE, DELETE가 거의 없고, 특정 조건으로 반복 조회되는 테이블이라면 함수기반 인덱스를 만들어 검색 성능을 개선하는 것이 충분히 합리적입니다. 다만 함수기반 인덱스를 만들면 DML 비용과 인덱스 관리 비용이 늘어납니다. 그래서 OLTP처럼 데이터 변경이 많은 테이블에 습관적으로 만드는 것은 조심해야 합니다. 정리하면, 함수기반 인덱스는 나쁜 인덱스가 아닙니다. 다만 먼저 SQL 수정 가능성, 데이터 정합성, 일반 인덱스 활용 가능성, DML 비용을 검토한 뒤에 사용하는 것이 좋습니다. 즉, SQL을 고칠 수 있다면 SQL부터 고치고, SQL을 고칠 수 없고 조회 성능 문제가 명확하다면 함수기반 인덱스를 만드는 것이 맞습니다. ^^
안녕하세요, 파타곤이야님! 질문 주신 7회 작업형 1의 1번 문제는 '데이터를 50:50으로 분할한 후 각 그룹의 결측치를 중앙값과 최댓값으로 채우고 표준편차의 합을 구하는 문제'였습니다. 따라서 이 문제에서는 정규화 과정이 포함되지 않는 것이 맞습니다. 여러 문제를 풀다 보면 다른 회차의 기출문제와 기억이 조금 섞이실 수 있으니 걱정하지 않으셔도 됩니다! 정규화 여부는 문제에 나와 있나요? 라는 핵심 질문에 답을 드리자면, 네, 무조건 문제에 명시됩니다. 빅데이터분석기사 실기 시험은 채점 플러그인을 통해 최종 제출한 '단 하나의 숫자(값)'가 정답과 일치하는지 자동 채점하는 방식입니다. 정규화(Min-Max Scaling)나 표준화(Standard Scaling) 처리를 해야만 하는 문제라면, 발문이나 조건에 반드시 명확한 문구로 제시됩니다. 따라서 시험장에서는 임의로 '이 데이터는 정규화를 해야 할까?' 고민하실 필요가 전혀 없습니다. 문제에 '정규화' 혹은 '변환'이라는 단어가 직접적으로 언급되어 있지 않다면, 정규화를 진행하지 않고 주어진 요구사항(결측치 처리, 통계량 추출 등)만 순서대로 구현하시면 됩니다. 남은 기간 차분하게 준비하셔서 좋은 결과 있으시길 바랍니다.
