정렬하려는 레코드 수가 메모리보다 크다면 / JWT / resolver vs proxy vs handler

계획

문서 템플릿 작성은 매우 중요한 일인데도 자꾸 미루게 되는 것 같다. 내일은 다른 걸 제쳐두고 이것부터 먼저 처리하도록 하자.

배운 일

정렬하려는 레코드 수가 메모리보다 크다면

최근 오픈 카톡방에서 이런 주제의 톡이 나왔다.

 

해당 부분은 RealMySQl 9.2.3.1 소트 버퍼에서 나온다. 메모리의 소트 버퍼에서 정렬을 수행하고, 그 결과를 임시로 디스크에 기록한다. 그리고 레코드를 가져와서 다시 정렬해서 반복적으로 디스크에 임시 저장한다. 이 병합 정렬을 멀티 머지(Multi-merge)라고 표현한다.

 

여기서 sort_buffer 크기만큼 레코드를 쪼개기 때문에 suffer_buffer를 무작정 크게 잡는다고 해서 성능에 이점을 얻을 수 있는 건 아니다. MySQL에서는 sort_buffer가 세션 메모리 영역에 할당되기 때문에 스레드 당 할당되기 때문이다. 따라서 sort_buffer를 크게 잡으면 성능이 오히려 떨어지게 된다. 데이터가 많거나 I/O 성능이 낮은 디스크라면 sort_buffer_size를 크게 잡았을 때 도움이 될 수 있다.

위 내용은 내 대답과 저 질문이 있었다고 말씀해 주신 분, 그리고 성욱님(Real MySQL 저자분)의 대답이다. Disk I/O를 추가적으로 언급한 이유는, RDBMS에서 성능에 대해서 크게 늘리는 방법이 데이터를 Sequential하게 저장해서 I/O에 대한 시간을 줄이는 것이라고 알고 있었기 때문이다. 따라서 시간 복잡도를 계산할 때 이 부분이 필수라고 생각해서 추가로 고려했는데, 정작 CPU cycle 또한 영향을 미칠 것이라고는 생각해보지 못했다.

 

이번 질문을 하면서 부족한 부분이라고 느껴진 건 다음과 같다.

 

1. 정렬 알고리즘들이 대강 어떻게 돌아가는지만 알지, 시간 복잡도 / 공간 복잡도 / 어떤 데이터에 효과적인지에 대한 건 제대로 알고 있지 못하다는 점
2. Disk I/O가 DB에 미치는 영향 (추가적으로 인덱스 / JOIN문과 Disk I/O의 상관관계도 공부하면 좋을 듯), Lookup과 여러 데이터 꺼내기, DB 데이터가 저장되는 형태

 

조만간 각 잡고 하나씩 공부해야겠다

 

JWT

용례 - 회원인증

1. 유저 로그인시 서버는 유저 정보 기반 토큰을 발급해 유저에게 전달한다
2. 유저가 서버에 요청할 때마다 JWT를 포함해 전달한다
3. 서버가 클라이언트에게서 요청 받을때마다 토큰이 유효하고 인증 됐는지 검증하고, 유저가 요청한 작업에 권한이 있는지 확인해 작업을 처리한다

 

특징 : 서버가 세션을 관리할 필요가 없고 요청시 토큰만 확인하면 된다

 

형태
header.payload.signature
header / payload / signature로 나뉜다

• header : 토큰 타입 / 알고리즘을 지정한다
• payload : 토큰에 담을 정보를 claim이라는 name : value 쌍의 데이터로 저장한다. claim은 크게 registered / public / private claim으로 나눌 수 있다
  • registered claim : 토큰 발급자 / 토큰 제목 / 만료시간 / 발급 날짜 / 고유 식별자가 들어갈 수 있다. 선택적으로 포함된다
  • public claim : 클레임 공개용 url을 전달한다
  • private claim : 클라이언트와 서버 간 협의하에 사용되는 클레임. 이름이 중복되어 충돌될 수 있다
  • 예제 payload 
  • { "iss": "velopert.com", "exp": "1485270000000", "https://velopert.com/jwt_claims/is_admin": true, "userId": "11028373727102", "username": "velopert" }
• signature : hash(encode(header) + encode(payload), 비밀키)로 생성한 값을 base64 형태로 나타낸다

참조 : velopert.com/2389

 

Bearer 헤더
Authorization 헤더에는 다음과 같이 값이 들어간다
Authorization: <type> <credentials>
bearer는 이때 JWT 혹은 OAuth를 사용하겠다고 type에 명시하는 것이다

 

resolver vs proxy vs handler

• resolver : 한 형태를 다른 형태로 해석해 변환 / 연결하거나 복잡한 문제를 해결하는 작업을 한다
  • DNS resolver, (spring) argument resolver, ...
• proxy : 중재자 역할을 해, 요청과 응답 중간에서 부가적인 처리에 집중한다
  • 필터링 / 보안 / 성능향상 / 추가기능, ...
• handler : 특정 이벤트에 대해 처리를 담당한다
  • 키보드 / 네트워크 등의 이벤트 핸들러

뭔가 추상적으로만 알고 있었던 개념들인데 이런 식으로 문화적인(?) 컨텍스트를 이해하게 되니까 해당 기능들이 무슨 일을 하는지 훨씬 알아보기 편해질 것 같다.

 

이 기술들을 만든건 서양인들이기 때문에 이 개념들을 이해하려면 영어의 느낌도 알아야 한다는 사실이 슬프다. (대체 영어권 사람들은 왜 고유명사라는 걸 안 쓸까???? domain 이런 범용적인 단어들 때문에 맨날 헷갈린다)

일기

게임은 재밌어

요 근래 게임을 시작했다. XCOM이라는 게임인데 사실 전부터 쭉 하고싶었던 게임이다. PC로 게임을 하지 않은지는 한 2년 정도 된 것 같다. 그냥 내 형편이 취준생이기 때문에 게임이란 사치라고 생각해서 하지 않았던 것인데, 최근에 여유를 가지고 천천히 나아가자는 생각에서 시작해 보았다.

 

그런데 여태 왜 안 했지란 생각이 많이 들었다. 일단 삶의 질에 있어서 많이 만족스러워 진다. 잊고 살았지만 나는 게임을 정말 좋아한다. 그리고 적절히 내가 ~이러이러한 일을 했으니 보상으로 1시간 정도는 게임을 해! 하고 보상을 주게 되니까 뭔가 오히려 더 자극이 된다.

 

무의미하게 유튜브를 보는 것보다 이런 식으로 나 스스로 보상을 주는 체계를 만드는 것도 좋다는 생각이 든다.