Real MySQL 8장

[KIM-KYOUNG-OH]

Real MySQL 8장

• n-gram 사용하지 않는 이유 -> 캐싱 오버플로우
• 클러스터링 인덱스는 별도의 저장 공간을 사용하지 않는다?
  • pk순으로 정렬된 테이블 자체가 클러스터링 인덱스이다(그렇기 때문에 클러스터링 인덱스는 테이블당 하나만 존재한다)
• 커버링 인덱스는 클러스터링 인덱스가 아닌 세컨더리 인덱스에만 해당하는 용어이다.
• 프라이머리 키 인덱스 == 클러스터링 인덱스?
  • 스토리지 엔진별, DBMS별로 차이가 있어보임
  • https://mozi.tistory.com/319#
• 정순 인덱스가 역순 인덱스보다 빠른 이유
• 인덱스 관련 참고 영상
  • https://www.youtube.com/watch?v=IMDH4iAQ6zM&t=508s

etc

• 이벤트 소싱
  • https://martinfowler.com/eaaDev/EventSourcing.html
• 회사에 시니어가 있어야 하는 이유 -> 많은 인사이트를 얻을 수 있다
  • 각종 기술의 원리는 로우 레벨의 기술을 비즈니스 코드 레벨로 가져온 것
  • webflux?
    • 'event loop' vs 'thread per request'
  • docker
    • Linux LXC, cgroups
  • 부동소수점 문제
    • 엡실론
  • 코드 품질
    • final을 어차피 다 붙일거면 코틀린을 사용해야하나?
    • 불변성을 보장하는 이유는 멀티스레딩 환경에서 race condition 방지, 디버깅 용이성
  • aws 키바나
  • awt tree
• 스프링 캠프
• 카카오 아이디어 도용 의혹
• goldilocks
• graalvm

[HYK97]

n-gram 사용하지 않는 이유 -> 캐싱 오버플로우
대용량 검색에 적합하지 않은 이유는 사견이긴 하지만 buffering 방식의 limit 때문이 아닐까 싶습니다!
물론 이 부분은 inverted index의 생성 방법, 리소스 상태에 따라 결과가 상이 할 수 있다는 점 참고해주세요 ㅎㅎ

------ 추가 ------
"옵티마이저는 index를 통해 읽어야 할 레코드 수가 전체 테이블 레코드의 20~25%를 넘으면 모든 데이터를 순차 탐색하는 방법으로 필터링한다."

이렇게 동작하는 이유가 pk를 이용하면 순차 io로 탐색이 가능하지만 secondary index인 경우 랜덤 io를 하기 때문에 그렇지 않을까 생각해봅니다.