세상의 모든 Software 지식을 정리

1. db.serverStatus().mem {  "bits" : 64 //시스템 처리사양(64비트)  "resident" : 42 //Working Set 저장을 위한 메모리크기  "virtual" : 275, //Virtual 메모리 현재크기  "mapped" : 80m //Mapped File 현재크기 } 2. db.serverStatus().extra_info {  "page_faults" : 11722, //현재 메모리 페이지 폴트 수   "ramMB" : 3885 , //현재 시스템 메모리 크기수 }

1. Document-Level Lock 제공으로 다수의 사용자가 트랜잭션 위주의 데이터를 빠르게 처리할 수 있도록 동시성을 제공합니다. 2. 인메모리 구조의 개선으로 몽고 디비 서버의 빠른 처리 성능이 개선되었습니다. 3. Memory Mapping 저장엔진은 단일 CPU 중심의 프로세싱 구조라면 wiredTiger 저장엔진은 Multi-Core 를 활용할 수 있는 시스템 구조이다. 다중쓰레드를 통해 집중화를 최소화 하였으며 동시성을 향상 시켰습니다. 4. CheckSums기능을 통해 시스템 장애 또는 저장 장치 장애로 부터 발생하는 데이터 유실을 최소화 할 수 있습니다. File system의 훼손 상태를 분석할수 있는 기능이 추가되었습니다. 5. 압축(Compression)기능을 통해 저장공간의 최소화가 가능합니다. 기본적으로 Snappy Compression 기능을 제공 

카프카는 고성능, 고가용성 메시징 애플리케이션으로 발전하는데 토픽과 파티션이라는 데이터 모델을 이용한다. 토픽은 메시지를 받을 수 있도록 논리적으로 묶은 개념이고, 파티션은 토픽을 구성하는 데이터 저장소로서 수평 확장이 가능한 단위이다. 1. 토픽의 이해 카프카 클러스터는 토픽이라 불리는 곳에 데이터를 저장한다. 토픽은 메일주소 시스템이라고 생각하면 쉽다. 토픽이름은 249자 미만으로 영문, 숫자, ' . ' , ' _ ', ' - ' 를 조합하여 자유롭게 만들 수 있다. 1개의 메시지를 보내는데 1초가 걸린다면, 4개의 메시지를 각각 보내게 되면 4초가 걸리게 된다. 큐시스템에서 한 가지 제약조건은, 메시지의 순서가 보장되어야 한다. 그렇게 때문에 이전메시지 처리가 완료된 후 다음 메시지를 처리하게 된다. 그래서 토픽안에 4개의 파티션을 만들어서 보낸다면 1초가 걸리게 된다. 무조건 파티션수를 늘려야 할까? 다음과 같은 단점이 있다. 파일 핸들러의 낭비 -> 각 파티션은 브로커의 디렉토리와 매핑 되고, 저장되는 데이터마다 2개의 파일(인덱스와 실제 데이터)이 있습니다. 카프카에서는 모든 디렉토리의 파일들에 대해 파일 핸들을 열게 됩니다. 결국 파티션의 수가 많을 수록 파일 핸들 수 역시 많아지게 되어 리소스를 낭비하게 됩니다. 장애 복구 시간 증가 - >   카프카는 높은 가용성을 위해 리플리케이션을 지원한다. 브로커에는 토픽이 있고, 토픽은 여러 개의 파티션으로 나뉘어지므로 브로커에는 여러 개의 파티션이 존재한다. 또한 각 파티션마다 리플리케이션이 동작하게 되며, 하나는 파티션의 리더이고 나머지는 파티션의 팔로워가 된다. 만약 브로커가 다운되면 해당 브로커에 리더가 있는 파티션은 일시적으로 사용할 수 없게 되므로, 카프카는 리더를 팔로워 중 하나로 이동시켜 클라이언트 요청을 처리할 수 있게된다. 이와같은 장애 처리는 컨트롤러...

 public static class SnakeCaseStrategy extends PropertyNamingStrategyBase     {         @Override         public String translate(String input)         {             if (input == null) return input; // garbage in, garbage out             int length = input.length();             StringBuilder result = new StringBuilder(length * 2);             int resultLength = 0;             boolean wasPrevTranslated = false;             for (int i = 0; i < length; i++)             {                 char c = input.charAt(i);                 if (i > 0 || c != '_') // skip first starting underscore         ...

<페이지 캐시> 리눅스는 파일 I/O의 성능 향상을 위해 페이지캐시라는 메모리 영역을 만들어서 사용합니다. 한 번 읽은 파일의 내용을 메모리 영역에 저장시켜 두었다가 다시 한번 접근하면 디스크에 접근하지 않고 메모리에 접근해 데이터를 불러오는 곳입니다. free 명령어로 확인해봅니다. $ free -k

conf내에 있는 zoo.cfg에 tickTime=2000 dataDir=/Users/james/zookeeper clientPort=2181 이것은 표준 자바 속성 파일이고, 다음 세개의 속성은 주키퍼를 독립모드로 실행할 때 필요한 최소한의 속성이다. tickTime은 주키퍼의 기본시간 단위 dataDir은 주키퍼가 영속적인 데이터를 저장할 로컬파일 시스템의 위치이며, clientPort는 클라이언트의 연결을 기다리는 포트이다. dataDir은 사용사 시스템에 맞게 적적힐 변경해야 한다. 다음과 같이 서버를 시작한다. zkServer.sh start 그후 서버가 시작되었는지 확인한다. echo ruok | nc localhost 2181

1. 트랜잭션이 보장해야 하는 ACID 원자성(Atomicity) : 한 트랜잭션 내에서 실행한 작업들은 모두 하나의 작업으로 간주한다. 모두 성공 또는 모두 실패되어야한다. 일관성(Consistency) : 모든 트랜잭션은 일관성있는 데이터베이스 상태를 유지해야 한다. DB에서 정한 무결성 조건을 항상 만족 격리성(Isolation) : 동시에 실행되는 트랜잭션들이 서로 영향을 미치지 않아야 한다. 지속성 (Durability) : 트랜잭션을 성공적으로 마치면 그 결과가 항상 저장되어야 한다. 격리성에 대한 이슈가 존재한다. 격리성을 완전히 보장하기 위해 모든 트랜잭션을 순차적으로 실행한다면 동시성 처리 이슈가 발생한다. 반대로 동시성을 높이기 위해 여러 트랜잭션을 병렬처리하게 되면 데이터의 무결성이 깨질 수 있다. * Serializable Isolation Level 이란?  - SELECT 수행시 READ LOCK ,즉  sharded lock을 사용 - 트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 sharded lock이 걸리므로 다른 사용자는 그 영역에 해당되는 데이터에 대한 수정 및 입력이 불가능하다. * 몽고DB의 격리성 Read Uncommitted 몽고디비에서는 클라이언트가 끝나지 않는 쓰기 작업(durable) 에 접근할 수 있다. Read Uncommitted는 디폴트 설정으로 mongod인스턴스와 레플리카셋 샤드 클러스터에 적용할 수 있다. Read Uncommitted And Single Document Atomicity single 쓰기 수행작업이 단건이 아닌 여러개의 documents를 수정할 때,  각각의 document에는 원자성(atomic)이 보장된다. 그러나 그 수행작업 전체에는 원자성이 보장되지 않고, 다른 수행작업이 간섭할 수 있다. 그래서 다음과 같은 특징을 ...