개발일기장

강의29. 엔터프라이즈 vs. 웹서비스 응용범위로 보는 차이(엔터프라이즈[상용 application]) 1. 트래픽의 경우 웹서비스의 경우 특히 글로벌하게 전개되고 있는 서비스에서는 어마어마한 트래픽이 발생할 가능성이 있다. 2. 성장속도도 웹서비스가 압도적이다. 3. 신뢰성에서는 엔터프라이즈는 장애가 발생해서 데이터가 없어지거나 하면 실제로 돈이 사라지기도 하고, 사람의 목숨과도 연관이 있는 경우도 있다. 그런 의미에서 굉장히 높은 신뢰성이 요구되지만, 웹 서비스에서는 신뢰성이 그렇게 높은 레벨이 요구되지 않는다는 특징이 있다. 4. 트랙잭션의 경우(DB) 엔터프라이즈에서는 데이터 간 정합성을 정확히 유지해야한다.(ex 은행 인출, 입금) 트랜잭션 처리를 이용해서 정합성을 명확히 담보하면서 처리해야한다..

강의16. 정수 데이터를 컴팩트하게 가져가기 큰 정수열을 컴팩트하게 만들면 -> 디스크 I/O를 줄일 수 있다. -> 고속처리 가능 -> RDBMS에 저장하면 아무래도 크기가 늘어나는 데이터를 최소한의 크기로 줄여서 다룰 수 있다. 데이터 형의 크기 등에 의식을 갖는다. VB Code(Variable Byte Code, 가변길이 바이트 부호)를 사용한다. 예시) 수치 고정길이 바이너리 부호 VB Code 5 00000000 00000000 00000000 00000101 10000101 130 00000000 00000000 00000000 10000010 00000001 10000010 강의 17~18은 문제 풀어보는 거랑 코드라서 생략 강의20. 하테나 다이어리의 키워드 링크 하테나 다이어리는 블로그..

강의14. 용도특화형 인덱싱 인덱스와 시스템 구성 – RDBMS의 한계 전문 검색이나 유사문서계열 탐색, 데이터 마이닝의 경우에는 RDBMS로는 한계가 있다. 배치처리를 통해 RDBMS에서 데이터를 추출해서 별도의 인덱스 서버와 같은 것을 만들고, 여기서 Remote Procedure Call(API로 불리는 것) 등으로 액세스하는 방법을 사용한다. AP서버에서 직접 관리하지 않는 이유는 커다란 검색 인덱스를 여러 프로세스에서 같이 사용하도록 구성하는 거는 비효율적이기 때문이다.(AP서버는 여러 개 있고 각각의 서버마다 검색 인덱스를 가지고 있을 필요가 없잖아.) 그래서 검색 인덱스를 위한 서버가 있으면 좋다. 용도특화형 인덱싱 – 튜닝한 데이터 구조 사용하기 RDBMS는 범용적인 용도로 만들어져 있다...

강의11. 인덱스를 올바르게 운용하기 - MySQL 분산을 고려한 MySQL 운용, 세가지 포인트 1. OS 캐시 활용(계속 언급됨) 2. 인덱스를 적절하게 설정하기 -> RDBMS에서 사용하는 구조 3. 확장을 전제로 한 설계 OS 캐시 활용 전체 데이터 크기에 주의해서 데이터양이 물리 메모리보다 가능한 적어지도록 유지한다. 메모리가 부족할 경우에는 증설한다. 대량의 데이터를 저장하려는 테이블은 레코드가 가능한 작아지도록 설계해야 한다. 3억 레코드 정도에서 칼럼을 늘리면(8Byte) 3GB만큼 늘어난다. 정규화? 경우에 따라서 정규화를 하게 되면 쿼리가 복잡 해져서 속도가 떨어지는 경우가 있으므로 속도와 데이터 크기 간 상반관계(trade-off)와 같은 부분도 생각해야 한다. DB의 내용이 메모리 ..

강의8. OS의 캐시 구조 OS에서는 디스크 내의 데이터에 빠르게 액세스할 수 있도록 구조가 갖춰져 있고, 메모리를 이용해서 디스크 액세스를 줄여준다. 그래서 이를 전제로 application을 작성할 때 OS에 상당부분을 맡길 수 있는 것이다. Linux에서는 page cache라고 하는데 이 특성을 알아야한다. 일단 가상메모리라는 것을 알아야 하는데 이 책 볼 정도면 기본적인 운영체제에 대해서 알고 있을 것 같다. OS는 가상메모리 구조를 가지고 있고, 이거는 논리적인 선형 주소를 물리적인 주소로 변환해주는 것. 1. 프로세스에서 메모리를 다루기 쉽게 하는 이점을 제공한다. 2. OS가 커널 내에서 메모리를 추상화하고 있다. 3. OS가 물리 메모리를 확보/관리하는 단위는 page. Linux의 페이..

강의4는 별 내용없어서 생략 강의5. 대규모 데이터 처리의 어려운 점 대규모 데이터는 어떤 점이 어려운가? 1. 메모리 내에서 계산할 수 없다는 점 -> 디스크에 있는 데이터를 검색한다. -> 디스크는 느리므로 I/O에 시간이 걸린다. -> 어떻게 해결? 메모리와 디스크는 10~100만배의 속도차이가 난다고 생각하자. (2009년 + HDD사용하는 것, 2021년에 SDD사용하는거랑은 차이가 있지 않을까?) HDD는 기본적으로 헤드의 이동, 원반의 회전이라는 두가지 물리적인 이동이 필요하다. 그리고 전송속도의 차이도 있다. 따라서 현대의 컴퓨터에서는 메모리와 디스크 속도차를 생각하고 애플리케이션을 만들어야 한다. 확장성을 생각할 때 매우 본질적이면서 어려운 부분. 책에서는 디스크와 메모리 전송속도 차이가..

https://jpub.tistory.com/122 웹 개발자를 위한 대규모 서비스를 지탱하는 기술 웹 개발자를 위한 대규모 서비스를 지탱하는 기술 이 책은 현재 절판입니다. 그간 읽어주신 독자들께 감사드립니다. 출판사 제이펍 원출판사 기술평론사(技術評論社) 원서명 [Web開発者の jpub.tistory.com 이 책으로 공부하고 정리한것. 강의1. 문제점 확인. 하테나를 예시로 든다. 2009년 이야기하는 것을 보면 최신 이야기는 아님. 그리고 여기서 이야기하는 것은 대규모 서비스, 구글 같은 초 대규모가 되면 또 다른 어려움이 생길 것. 소규모 서비스와 대규모 서비스의 차이. 1. 확장성 확보, 부하분산 필요 scale-out(서버를 횡으로 전개, 역할을 분담하거나 대수를 늘림으로써 시스템의 전체적인..