맵리듀스는 2004년 Google의 Jeffrey Dean이 발표한 기술이다.GFS와 같은 분산 파일시스템에서, 사용자가 작성한 맵 함수와 리듀스 함수를 실행하여 결과를 생산해낸다.디스크에 있는 파일을 읽어 사용자 함수 Map을 실행한다. 중간 결과(인메모리)에서 셔플링을 통해 사용자 함수 Reducer는 매퍼의 결과를 복사한다.맵리듀스는 다음과 같은 그림으로 도식화 할 수 있다. 사용자 프로그램 워커는 Map Phase와 Reduce Phase가 있고 Master 프로그램이 워커에게 알맞은 작업을 부여한다.여러 스레드나 프로세스에서 동일한 워커에 접근하여 작업을 지시하면 안되므로 Master 프로그램은 강한 격리성을 유지해야하한다. 즉, 병렬 등의 동시성 처리에 취약하면 안된다.워커들은 일반적으로 2-..
다시, 맨처음 이야기를 시작한 원래 코드로 돌아가자.최초 작성한 코드는 다음과 같다. @Transactional(propagation=Propagation.REQUIRES_NEW)public void sendRegistered(Long scheduleId){ // 스케쥴된 아이템을 찾는다 Schedule sending = scheduleRepository.findById(alimtalkScheduleId). orElseThrow(() -> new GeneralException(Type.NO_STORED_SCHEDULED_BY_ID)); List items = sending.getItems(); boolean hasError = false; // 해당 아이템의 하위 아이템..
목차 - 트랜잭션 격리- 스냅샷 격리- 직렬성 - 진짜 순서대로 실행하기 - 2PL - 직렬성 스냅숏 격리 - 오래된 MVCC 읽기 감지하기 - 과거의 읽기에 영향을 미치는 쓰기 감지하기- 참고문헌 트랜잭션 격리이제까지 트랜잭션 격리와 그 수준에 대해서 충분히 이야기한 듯 하다. 하지만 격리는 어떻게 구현되는 걸까? read committed, repeatable read는 다른 트랜잭션이 변화를 주어도 본 트랜잭션에 영향이 없다. read committed인 경우 상대 트랜잭션이 커밋한 순간 값이 업데이트 되며 repeatable read는 본인의 트랜잭션이 커밋 또는 롤백되기 전까지 다른 트랜잭션이 변경하거나 커밋한 사항을 확인할 수 없다. 트랜잭션은 undo log에 위치한 ..
목차 - ACID- 동시성 문제 - Dirty Read, Non-Repeatable Read, Phantom Read - 더티 쓰기 (dirty write) - 갱신 손실 (lost update) - 쓰기 스큐 (write skew)- 참고문헌 ACID동시성의 이야기를 진행하기 전에 먼저 ACID를 다루고자 한다. Atomicity 원자성, Consistency 일관성, Isolation 격리성, Durability 지속성이 있다. 원자성과 격리성은 동시성을 다루기전에 한번 짚고 넘어갈 만한 이야기다.원자성은 쪼갤 수 없는 어떤 것을 말한다. 데이터베이스는 어떤 작업들의 절차들을 하나의 쪼갤 수 없는, 트랜잭션을 정의할 수 있다. 그리고 일련의 작업 중 어떤 것이 실패하였을 때 전부 되돌릴 수 있..
목차 - 문제 정의- 트랜잭션 격리레벨 - SERIALIZABLE - READ UNCOMMITTED - READ COMMITTED - REPEATABLE READ- 참고문헌 문제 정의이 글은 Spring Boot 및 JPA기준으로 작성되어 있습니다.send 함수의 수행 시간은 1회마다 1.x초 정도 소요된다. 목표치는 2600회 정도 이고 소요시간은 40분으로 측정된다.안타깝게도, 해당 함수 호출을 하는 snedRegistered 함수가 여러 쓰레드에서 호출이 되었다. (sendRegistered 는 send함수를 여러회 호출한다. 목표치가 2600회이므로 2600번 호출된다.)함수는 다음과 같이 작성되어있다.@Transactional(propagation=Propagation.REQUIRES_..
유난히 스트레스 받는 하루.하나를 마무리 하면 하나가 오고, 또 끝내면 또 하나가 오고.쉽지 않네. 케이스별로 테스트도 해야하는데, 업무는 몰리고삽들고 삽질 중.근데 뭔가... 받는거에 비해 많이 일하는데 많이 받고 작게 받는거고 자시고,가치는 뒤따라 오는 거니까무엇보다 이게 의미가 있는 일인가도움이 되는 방향으로 성장하고 있나 생각하면그렇지 않다라고 생각이 든다Implementation의 향연이미 머릿속엔 red flag가 떴는데, 이걸 팀의 방향을 설정해야하는데 적어도 팀이 다른 조직에 가서도 의미가 있는 일을 하려면 힘과 방법을 길러놔야하는데이 걸 업무와 같이 갈 수 있게끔 어떻게 해야할까 팀원들이 두려운 것 처럼 나도 두려운 것이 많다.그렇다고 회피할 순 없다.무서워서 도망치면 죽는다무서울수록 더..
3. 운동을 하라 개발자들은 건강에 취약하다. 정말, 컴퓨터 앞에서 10시간 넘게 앉아 있는 일이 너무 흔하기 때문이다. 심지어 회사일이 끝나고 난 뒤에도 사내 스터디나 자기계발로 책상앞에 앉아있을 일이 있기때문이다. 자기계발은 심지어 대부분 사이드 프로젝트다. 또, 코딩을 하다니 허리는 괜찮으신가. 나도 예외는 아니다!정상적인 범주에서, 젊을 때는 괜찮다. 그런데 나이가 30 이상이 되면 어느 순간 버겁기 시작한다. 적어도 경력이 3~5년 되었을때 여러분은 한 발 더 경쟁이란 시스템에 발을 올리게 된다. 그리고 더 많은 스트레스를 받는다. 스트레스 관리는 생활습관에 달려있다고 생각한다. 스트레스를 풀기위해선 자기만의 방법들이 있다. 여행가기, 봉사하기, 기도하기, 명상하기, 게임하기 등.나는 스트레스 ..
2. 책을 읽어라 나는 책을 자주 읽는 타입이 아니라, 아직 책을 자주 읽어야하는 이유를 잘 모른다. 하지만, 분명한 것은 인생은 혼돈으로 가득하다. 차가 움직일 때 고속도로라는 큰 길로 와서 복잡한 골목길을 찾아가듯이 또는, 망망대해에 떨어져 나룻배를 운전하 듯 네비게이션이나 나침반이 없이 움직이는 물체와 어쩌면 인생은 같다. 그리고 책은 목적지를 가르키는 마법도구가 되진 못 하더라도, 큰 흐름을 잡아주는 길 잡이가 되어준다.어느 분야의 사람들도 책을 자주 읽어야하지만, 특히 개발자가 책을 읽어야 한다고 생각한다. 대개, 개발자들은 사회생활이 결여되어있다. 그럴것이 하루의 적어도 10시간은 컴퓨터 앞에 앉아있으니까 말이다. 사람보다 컴퓨터를 대하는 시간이 더 많다. 이야기를 하는 것보다 코드를 보는게 ..
개발자를 하면서 느낀것 10가지를 나눠서 쓰겠습니다. 1. 계속 공부해야한다. 개발은 영역이 너무 넓다. 대부분의 큰 틀의 업무가 비슷하겠지만, 조금만 자리를 옮겨보면 하는 일이 확확 바뀐다.공부할 거리가 너무 많고, 내가 공부한다고 해서 이해할 수 있는 것과는 다른 외우거나 도움이 필요한 영역도 있다.공부해야하는 것들에 대한 분류는 3가지로 나눌 수 있다.A. 공개되어있고 충분한 시간을 들이면 이해할 수 있는 영역 이 것은 내가 시간만 들이면 알 수 있는 것이다. 이런 영역은 평소에도 꾸준히 공부해야하는 부분이다. 주니어에서 벗어날수록, 새로운 주니어에게 이런 기술도 있어요 라고 하며 난감한 경우도 느낄수 있을것이다. "어, 내가 개발할 때엔 이런게 없었는데..." 아마 나 때에 git을 가지고 ..
이 글은 나의 개인 견해이다.실무에서 Spring REST Docs와 Swagger를 쓰면서 드는 생각을 정리해본다.필요성API 문서는 시스템을 드러내는 문이라고 생각한다. 누군가가 사용해야하기에 반드시 정의해야한다. 잘 정의된 API와 문서는 동료 개발자들이 개발을 하는데 매우 큰 도움을 주고, 또한 개발자 스스로에게도 이 API 역할이 무엇인지 명확히 알 수 있는데 도움을 준다. 그렇기에 모두에게 필요한 문서이다. 아이러니하게도, 나를 포함하여, 문서를 왠만큼 잘 읽는 개발자들도 필요할 때가 아니면 잘 안읽는 사람들 많지만 필요할 땐 반드시 찾게된다.API 문서가 없는 개발 환경은 팀으로 일하지 않는 경우를 제외하고는, 아주 초창기에나 가능할 듯 하다.가독성가독성에 대해서 이야기하기 위해선, 먼저 레..
- Total
- Today
- Yesterday
- 대규모 시스템 설계 기초
- 가상 면접 사례로 배우는 대규모 시스템 설계 기초
- 그라파나
- 아레나 시뮬레이션
- 엄청난 인내심과 시뮬레이션을 위한 아레나 툴
- 아레나시뮬레이션
- 아레나
- Arena
- Discrete Mathematics
- javascript
- 자바스크립트 예제
- beginning javascript
- 백준
- 로젠
- 항해99
- paul wilton
- 트랜잭션
- 데이터 중심 애플리케이션 설계
- Simulation
- 이산 수학
- 시뮬레이션
- 명제논리
- 이산수학
- rosen
- Propositional and Predicate Logic
- 최단경로 알고리즘
- grafana cloud
- 자바스크립트
- 동시성
- arena simulation
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |