경주장

강의 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 의 캐시에 올리기 쉬운 ..

상속의 관점에서 다형성이 구현되는 기술적인 메커니즘을 살펴보자. 다형성이 런타임에 메시지를 처리하기에 적합한 메서드를 동적으로 탐색하는 과정을 통해 구현되며, 상속은 이런 메서드를 찾기 위한 일종의 탐색 경로를 클래스 계층의 형태로 구현하기 위한 방법이다. 내용은 기술적이지만 문체가 상당히 담백하게 느껴져서 크게 와닿는다. 이전 장에서 부주의한 상속의 문제점을 꾸준히 언급한것에 이어서 계속해서 같은 목소리를 다형성의 측면에서 재조명한다. 01 다형성 a. 오버로딩 다형성 클래스 내에서 하나의 메시지(메서드 명)가 여러 메서드를 가지는 경우를 일컫는다. b. 강제 다형성 동일한 연산자를 다양한 타입에 사용할 수 있는 방식을 가리킨다. c. 매개변수 다형성 - 제네릭 프로그래밍에서 클래스의 인스턴스 변수나 ..

상속 관계는 is-a 관계라고 부르고 합성 관계는 has-a 관계라고 부른다. 처음 해당 용어를 들었을 때에는 헷갈리고 와닿지 않았는데 책을 읽다보니 조금 정리가 되는 듯 하다. 상속 관계는 1대1로 발생하며 부모와 자식의 관계가 strict하게 딱 정해지는 효과가 있어 "is-a"와 같은 단정적인 표현이 어울리고 합성 관계는 1대 다로 발생하며 표현 자체도 딱 composite하게 인자로서 "has a"하는 느낌이 나는 듯 하다. 그리고 "has a" 는 "is a"보다는 아무래도 더 유연한 느낌이 든다. 상속 - 클래스 사이의 정적인 관계 합성 - 객체 사이의 동적인 관계 - 즉, 런타임에 동적으로 변경 할 수 있다. 상속을 합성으로 바꾸면 상속이 초래하는 세 가지 문제점을 해결 할 수 있다. 상속에..

DRY 원칙 = Don't Repeat Yourself = Once and Only Once 원칙 = 모든 지식은 시스템 내에서 단일하고, 애매하지 않고 정말로 믿을 만한 표현 양식을 가져야 한다. 중복 코드는 코드 수정에 필요한 노력을 몇 배로 증가시킨다. 중복과 변경 Call에는 통화의 시작시간, 끝 시간을 저장하는 LocalDateTime 변수가 두개 있고 Phone은 List calls를 가지며 전화요금을 계산해야 하는 상황을 고려해보자. 가장 간단한 구현 방법은 위와 같은 Class 구조이다. 1. 밤 10시 이후의 통화에 대해 요금을 할인 해주는 방식을 추가해야 한다는 요구사항이 접수됐다. a. 클래스 도입 이를 위와 같은 방식으로 구현하는 것은 옳지 않다. Phone과 NightlyDisco..

개방-폐쇄 원칙 (Open-Closed Principle, OCP) 소프트웨어 개체는 확장에 대해 열려있고, 수정에 대해서는 닫혀 있어야 한다. 컴파일타임 의존성을 고정시키고 런타임 의존성을 변경하라. OCP의 핵심 = 추상화에 의존하는 것 변하지 않는 것이 무엇인지를 이해하고 옳바른 추상화를 신중히 결정하자 생성 사용 분리 의존관계를 외부에 명시적으로 드러내라 Factory 추가 생성만을 전문으로 하는 Factory에게 구체 Class 선택의 결정권을 주고 생성을 담당하게 하라 생성된 객체를 사용하는 Client는 Factory에의해 생성된 객체를 이용해 Method를 실행한다. 의존성 주입 (Dependency Injection) 외부의 독립적인 객체가 인스턴스를 생성한 후 이를 전달해서 의존성을 해..

의존성과 결합도 의존성 자체는 객체사이의 협력을 위해 필수적이다. 하지만 너무 높은 의존성은 유연함을 막아 재사용 할 수 없는 클래스설계로 이어진다. 바람직한 의존성 (= 약한 결합도 )은 재사용성과 관련이 있다. 바람직한 의존성 (= 약한 결합도 )은 컨텍스트에 독립적인 의존성을 의미한다. 지식이 결합을 낳는다. : 하위 클래스에 대한 정보를 알변 알수록 강하게 결합된다. => 추상화에 의존하라! 아래 쪽으로 갈 수록(객체가 추상화 될 수록) 클라이언트가 알아야 하는 지식의 양이 적어지고 결합도가 느슨해진다. 구체 클래스 의존성(concrete class dependency) 추상 클래스 의존성(abstract class dependency) 인터페이스 의존성(interface dependency) 의..

.잘 설계된 객체지향 애플리케이션은 작고 응집도 높은 객체들로 구성된다. .작은 객체들은 단독으로 수행 할 수 있는 작업은 제한적이며 서로 협력해야 한다. .다른 객체들이 존재한다는 것, 자신이 다른 객체에게 어떤 메시지를 보낼 수 있는가를 미리 알고 있어야 하고 이런 지식이 객체 사이의 의존성을 낳는다. 의존성은 단뱡향성을 가진다. 의존성은 변경에 의한 영향의 전파 가능성을 암시한다. 실행 시점/구현 시점 의존성의 차이 - 실행 시점 : foward한 의존성을 의미한다. - 구현 시점 : backward한 영향을 의미한다. -> 둘 모두 foward한 의존성의 존재 아래 필연적으로 발생하는 상황이다 (의존성 자체는 단방향) 예를 들어 위와 같은 의존 관계에서 실행 시점에 MemberService객체는 ..