이 글은 책 내용을 토대로 작성하였습니다.
스트림은 무한하다.
그러므로 스트림의 시작과 끝을 정하여 작은 블록으로 쪼갠 후
각 블록을 일괄 처리하듯이 다루는 방법을
마이크로 일괄 처리(Microbatching)라 한다.
ex) 스파크 스트리밍
마이크로 일괄 처리의 크기는 일반적으로 약 1초 정도로 설정한다.
사이즈가 작으면 스케줄링 + 코디네이션 비용이 커진다.
사이즈가 커지면 처리 결과를 보기까지 지연시간이 발생한다.
만약 설정한 크기에서 한 번에 처리를 못 할 땐
작업 수행 후 상태를 명시적으로 다음 작업으로 넘긴다. (= 체크포인트)
Given an array nums of n integers, return an array of all the unique quadruplets [nums[a], nums[b], nums[c], nums[d]] such that:
0 <= a, b, c, d < n
a, b, c, and d are distinct.
nums[a] + nums[b] + nums[c] + nums[d] == target
You may return the answer in any order.
이 글은 책 내용을 토대로 작성하였습니다.
하나 이상의 입력 스트림을 처리해 하나 이상의 출력 스트림을 생산할 수 있다.
스트림을 처리하는 코드 조각을 연산자 혹은 작업이라 부른다.
스트림은 끊임없이 이벤트가 발생하므로
스트림 상에서 수행하는 조인은
일괄 처리 작업에서 수행하는 조인보다 훨씬 어렵다.
이 글은 책 내용을 토대로 작성하였습니다.
이벤트 소싱은 도메인 주도 설계에서 개발한 기법이다.
CDC와 비슷하게 어플리케이션 상태 변화를 모두 변경 이벤트 로그로 저장한다.
다만 CDC와 추상화 레벨이 다르다.
- CDC에서 어플리케이션은 DB에 있는 데이터에 대해 자유롭게 "추가/수정/삭제" 작업이 가능하다.
- 변경 로그의 순서는 DB에서 추출한 쓰기 순서와 실제로 데이터를 기록한 순서와 일치하다.
- 이벤트 소싱에서 어플리케이션 로직은 이벤트 로그에 기록된 불변 이벤트를 기반으로 명시적으로 구축한다.
- 이때 이벤트 저장은 단지 "추가"만 가능하고 "수정/삭제" 작업은 권장하지 않거나 금지한다.
이 글은 책 내용을 토대로 작성하였습니다.
앞선 글에서 이야기했듯이
이벤트란 특정 시점에 발생한 사건을 기록한 레코드다.
그러면 DB에 어떤 데이터를 저장한다는 것을 상세히 쪼개어 보면
DB에 뭔가를 기록한다는 것은
저장할 데이터를 캡처해서 저장하고 처리할 수 있는 하나의 이벤트라고 볼 수 있다.
이 글은 책 내용을 토대로 작성하였습니다.
n분 주기로 동작을 하거나 특정일에 동작을 하는 고정된 시간 개념을 버리고
이벤트가 발생할 때마다 처리를 한다는게 스트림 처리의 정의이다.