경주장

강의 11 - 인덱스를 올바르게 운용하기 세가지 포인트 OS 캐시 활용 인덱스를 적절하게 설정하기 확장을 전제로 한 설계 OS캐시 활용 . 전체 데이터 크기에 주의하라 -> 데이터량 메모리가 부족할 경우 증설 . 스키마 설계가 데이터 크기에 미치는 영향을 고려한다. -> 최대한 낭비되는 Byte 가 없도록 설계 ->설계의 복잡도와 속도의 TradeOff를 근거로 정규화 고려 인덱스의 중요성 - B트리 인덱스 = 색인 MySQL의 인덱스는 기본적으로 B+트리라는 데이터 구조다. 트리의 높이는 데이터 건수 n에 대해 반드시 log(n)이 되므로 검색의 계산량은 O(log(n))이다. 이분트리 vs B트리 이분트리는 디스크가 읽는 Block의 단위에 관계없이 데..

강의 8 OS캐시 구조 OS 캐시를 이용해 디스크 액세스를 줄이자. . 가상 메모리 프로세스에서 메모리를 다루기 쉽게 하는 이점을 제공한다. OS가 커널 내에서 메모리를 추상화하고 있다. 페이지: OS가 물리 메모리를 확보/관리하는 단위 . 페이지 캐시 - 커널이 한 번 할당한 메모리를 해제하지 않고 남겨두는 것 . 페이지 - 가상 메모리의 최소단위 . 메모리가 비어 있으면 캐싱 - sar 명령어로 캐싱 용량을 확인 할 수 있다. 강의 9 I/O부하를 줄이는 방법 . 데이터 규모를 물리 메모리보다 적게 유지하도록 노력하자 => 전부 캐싱 가능 하지만.. 단순히 대수만 늘려서는 확장성을 확보 할 수 없다. => 강의 10 - 국소성을 살리는 분산 단순히 대수만 늘린 분산 국소성(locality)을 고려한 ..

규모조정, 확장성 Scale-up vs Scale-out Scale-out은 하드웨어를 나열해서 성능을 높이는, 즉 하드웨어를 횡으로 전개해서 확장성을 확보해가게 된다. 이때 CPU부하의 확장성을 확보하기는 쉽다. 예를 들어 웹 어플리케이션에서 계산을 수행하고 있을 때, 즉 HTTP요청을 받아 DB에 질의 하고 DB부터 응답받은 데이터를 가공해서 HTML로 클라이언트에 반환할 때는 기본적으로 CPU부하만 소요되는 부분이다. 이것은 서버 구성 중 프록시나 AP서버가 담당할 일이다. 한편 DB서버 측면에서는 I/O부하가 걸린다. 웹 어플리케이션과 부하의 관계 AP서버는 CPU부하만 걸리므로 분산이 간단하다. 데이터를 분산하여 갖고 있는 것이 아니므로 동일한 호스트가 동일하게 작업을 처리하기만 하면 분산할 수..

강의 5 - 대규모 데이터 처리의 어려운점 대규모 데이터의 어려운 점 - '메모리 내에서 계산 할 수 없다' 메모리 내에서 계산할 수 없게 되면 디스크에 있는 데이터를 검색할 필요가 있다. 하지만 디스크는 느리므로 I/O에 시간이 걸린다. 어떻게 대처할 것인가가 연구 대상 메모리와 디스크의 속도차 - 메모리는 디스크에 비해 10^5~10^6배 이상 빠르다. 디스크는 왜 늦을까? 메모리는 전기적인 부품이므로 물리적 구조는 탐색속도와 그다지 관계없다. 마이크로초(10^-6초)단위의 포인터 이동으로 탐색이 수행된다. 한편 디스크는 헤드의 이동, 원반(디스크)의 회전 이라는 물리적인 동작을 수반한다. 각각 수 밀리초(10^-3초)가 걸리는 동작이다. 다음으로 탐색에 사용되는 것이 CPU 의 캐시에 올리기 쉬운 ..