회계사는 기록을 수정해야 하면 이미 입력된 값을 지우지 않고 새로운 값을 다시 씁니다. 최종 결과를 구하려면 모든 항목을 재검토하고 합계액을 계산해야 합니다. 이러한 방식은 바로 오늘 포스트에서 살펴볼 로그 구조 스토리지(Log-Structured Storage)와 유사합니다. 또 다른 예로는 불변 스토리지(immutable storage)가 있습니다.

데이터베이스 시스템의 선택은 중요합니다. 성능, 일관성 문제, 운영의 어려움과 같은 이유로 데이터베이스를 변경하게 되는 경우가 발생할 수 있습니다. 데이터베이스를 변경할 때 마이그레이션이 쉽지 않을 수도 있기 때문에 초기 설계 단계에서 애플리케이션의 특성에 알맞는 데이터베이스를 선택해야 합니다.

이전 포스트에서는 데이터를 Bounded data와 Unbounded 데이터 구별하고, 그것을 처리하는 방법에 관해 살펴보았습니다. Unbounded data를 처리할 때 이벤트 시간과 처리 시간의 차이점에 대해서 다뤘습니다. 또한 윈도우 개념도 함께 알아보았습니다. 이번 포스트에서는 워터마크, 트리거, 어큐뮬레이션에 관해 자세히 살펴보겠습니다.

스트리밍 처리의 중요성이 점점 중요해지고 있습니다. Apache Spark Streaming부터 새로운 스트림 처리의 강자인 Apache Flink와 같은 스트리밍 처리 엔진 등의 사용 사례가 많아지고 있습니다. 그래서 이번 기회에 스트리밍 처리에 대한 기본 개념들에 대해 정리해보고자 합니다.

HBase는 데이터베이스 시스템에서의 커서와 유사한 스캔 기능을 제공합니다. 스캔은 HBase에서 순차적이고 정렬된 저장 구조를 활용하는 방식입니다. 스캔을 사용하면 로우 키를 기반으로 하여 여러 데이터를 가져올 수 있습니다. 스캔은 로우 키가 정확히 일치하지 않아도 사용이 가능합니다.

스트림 처리에서 바라보는 시간적 측면 중에 이벤트 시간(Event time) 기반으로 처리하는 방식에 대해 살펴보겠습니다. 최근에 데이터 처리 분야에서 스트리밍 애플리케이션 개발의 중요성이 더욱 커지고 있습니다. 만약 스트리밍 애플리케이션을 개발하게 되는 경우 애플리케이션의 목적에 따라 이벤트 시간(Event time)을 기준으로 처리할 것인지 처리 시간(Processing time) 기준으로 처리할 것인지 선택을 해야 할 것입니다.

우리 프로그래머들은 항상 공부해야 합니다. 우리는 지식을 중요하게 여깁니다. 하지만 지식에 대한 지식, 즉 내가 그 지식을 얻은 과정이나 방법 같은 것은 소홀히 여기기 쉽습니다. 따라서 지식의 축적과 공유는 있어도 방법론의 축적과 공유는 매우 드문 편입니다.

HBase에 접근하기 위한 주요 인터페이스는 org.apache.hadoop.hbase.client의 HTable 클래스입니다. HTable 클래스를 통해서 HBase에 데이터를 저장하고 삭제하는 등 사용자 작업에 필요한 기능을 제공합니다. HBase에서 데이터를 변경하는 로우 단위의 모든 작업은 원자성(Atomic)이 보장됩니다. 원자성이 보장된다는 말은 무슨 의미일까요? 하나의 로우에 읽기나 쓰기 작업이 수행되는 동일 다른 클라이언트나 스레드에서 동일한 로우에 읽기나 쓰기를 시도해도 아무런 문제가 발생하지 않는다는 의미입니다.

이번 포스트에서는 애플리케이션을 개발할 때 관계형 데이터베이스가 아닌 NoSQL 데이터베이스를 선택할 때 참고할 수 있는 기준들을 살펴보면 도움이 될 것입니다. RDBMS와 NoSQL 데이터베이스의 대표적인 차이점은 스키마와 트랜잭션 속성이나 실제로 데이터를 저장하는 구조에서 살펴볼 수 있습니다. 애플리케이션을 개발할 때 애플리케이션이 가진 특징을 명확히 이해하고 있으면 다양한 데이터베이스 중에 알맞는 데이터베이스를 선택할 수 있을 것입니다.

이전 포스트에 이어서 파티셔닝에서 사용하는 리밸런싱 기법에 관해 살펴보고, 클라이언트에서 질의 요청을 어떻게 처리할 것인지에 관해 알아보겠습니다. 파티션 리밸런싱 리밸런싱이란 클러스터에서 한 노드가 담당하던 부하를 다른 노드를 옮기는 과정입니다. 이러한 리밸런싱이 필요한 경우는 시간이 지나면서 데이터베이스에 변화가 생기기 때문입니다.