Smart Tiger's blog

이전 포스트에 이어서 세 번째 포스트입니다. 이전 포스트에서는 SS테이블과 LSM 트리에 관해 알아보았습니다. 이번 포스트에서는 데이터베이스에서 가장 많이 사용하고 일반적인 색인 유형인 B 트리에 대해서 살펴보겠습니다. B 트리 B 트리는 거의 대부분의 관계형 데이터베이스에서 표준 색인 구현으로 사용할 뿐만 아니라 비관계형 데이터에서도 사용합니다. B트리는 SS테이블과 같이 키로 정렬된 key-value 쌍을 유지하지 때문에 key-value 검색과 range query에 효율적입니다. 이와 같이 LSM 트리와는 유사한 점은 이게 다이고 B 트리의 설계 철학은 매우 다릅니다. LSM 트리는 일반적으로 수 메가바이트 이상의 가변크기를 가진 세그먼트를 나누고 순차적으로 세그먼트를 기록합니다. 반면 B 트리는..

이전 포스트에 이어서 저장소와 검색을 계속 살펴보겠습니다. 이전 포스트 마지막 부분에 대한 설명은 해시 테이블을 통한 색인이 가진 제한사항에 대해 살펴보았습니다. 이러한 제한이 없는 색인 구조를 이어서 살펴보도록 하겠습니다. SS 테이블과 LSM 트리 위 그림과 같이 log-structured 저장소 세그먼트는 key-value 쌍의 시퀀스입니다. key-value 쌍은 쓰여진 순서대로 저장되며 로그에서 같은 키를 갖는 값 중 나중 값이 최신 값이 됩니다. 여기에 간단한 변경사항을 적용해 봅시다. 세그먼트를 key를 기준으로 정렬하는 것입니다. 일단 이러한 변경은 순차적으로 쓰는 것을 못하게 할 것 같습니다. 그러나 이러한 문제는 조금 더 뒤에 살펴보도록 하겠습니다. 먼저 세그먼트를 정렬하는거에 집중해봅..

이전 포스트에서는 데이터 모델과 질의 언어에 대해 알아보았습니다. 예를 들어 애플리케이션 개발자 관점에서 데이터베이스에 저장하는 데이터 포맷과 데이터를 다시 요청하는 메커니즘과 같은 것들을 살펴보았습니다. 이번 장에서는 데이터베이스 관점에서 데이터를 저장하는 방법과 데이터를 요청했을 때 다시 찾을 수 있는 방법에 대해서 살펴볼 예정입니다. 일반적으로 애플리케이션 개발자는 처음부터 자신의 저장소 엔진을 구현하기 보다는 사용가능한 저장소 엔진중에 애플리케이션 요구사항에 적합한 데이터 모델을 처리할 수 있는 저장소 엔진을 선택합니다. 특정 작업부하(workload) 유형에서 좋은 성능을 내도록 저장소 엔진을 조정하려면 어느 정도 저장소 엔진의 내부적인 이해가 필요합니다. 일반적으로 트랜잭션 작업 부하에 최적화..

이번 포스트는 이전 포스트에 이어서 데이터 모델과 질의 언어에 대한 포스트입니다. 이전 포스트를 보지 않은 분들은 먼저 이전 포스트를 보고 오시는 것을 추천드립니다. 데이터를 위한 질의 언어 데이터베이스에 데이터를 질의하는 방법은 각각의 데이터 모델마다 조금씩 다릅니다. 일반적으로 알고 있는 관계형 모델의 경우는 SQL을 이용합니다. SQL은 선언형 질의 언어입니다. 그리고 선언형(declarative) 질의와 대조되는 질의 방식은 명령형(imperative) 질의 방식이 있습니다. 그러면 선언형과 명령형을 사용하여 데이터를 조회하는 방법을 한번 살펴보겠습니다. 동물의 종 목록이 있을 때 목록에서 상어만 반환하는 질의를 비교해보겠습니다. 먼저 명령형 질의 방식으로 상어를 반환하는 방식은 아래와 같습니다...

데이터 모델은 소프트웨어 개발에 있어서 가장 중요한 부분 중에 하나입니다. 다양한 종류의 데이터 모델에 대해 이해를 하고 있고, 애플리케이션 요구사항에 가장 적합한 모델을 찾아서 개발을 해야 합니다. 데이터 모델에 따라 어떤 종류의 사용법은 쉽고 어떤 동작은 지원하지 않습니다. 또한 어떤 연산은 빠르지만 어떤 연산은 매우 느리게 동작할 수 있습니다. 그렇기 때문에 애플리케이션에 맞는 데이터 모델을 사용하는 것이 중요합니다. 이번 장에서는 다양한 데이터 모델과 질의 언어에 대해 살펴볼 예정입니다. 관계형 모델(Relational Model) vs 문서 모델(Document Model) 관계형 모델을 다음과 같이 정의됩니다. 데이터는 관계(relation)(SQL에서 테이블이라고 불리는)로 구성되고 각 관계..

Compute-intensive(계산 중심) vs Data-intensive(데이터 중심) 과거에는 CPU 성능이 애플리케이션을 제한하는 요소였지만 오늘날에는 그렇지 않습니다. 최근에는 데이터의 양, 데이터의 복잡도, 데이터의 변화 속도가 애플리케이션을 제한하는 요소가 되었습니다. 이렇게 애플리케이션에서 사용하는 데이터의 특징에 맞춰서 설계를 해야 합니다. 그래서 이러한 애플리케이션을 Data-intensive application(데이터 중심 애플리케이션)이라고 합니다. 일반적으로 데이터 중심 애플리케이션은 다음과 같은 구성 요소를 가집니다. 꼭 데이터 중심 애플리케이션이 아니더라도 애플리케이션의 요구 사항에 따라 필요한 것들이 달라질 것입니다. Database Cache Search index Str..

예제로 알아보는 Oozie Coordinator - 2 이번 포스트에서는 예제를 통해서 data availability 기반의 스케줄링이 가능한 우지 코디네이터 사용법에 대해 알아보겠습니다. time interval 기반의 우지 코디네이터의 사용법이 궁금하신분들은 이전 포스트를 참고하시기 바랍니다. Oozie를 통하여 workflow를 동작시킬 때의 조건으로 특정 데이터 셋의 준비가 되는 경우에 워크플로우가 실행되도록 하고 싶은 경우가 있습니다. 이때 사용할 수 있는 방법이 바로 data availability 혹은 data trigger 기반의 코디네이터입니다. 동작 원리는 간단합니다. 코디네이터에서 frequency 마다 지정된 위치의 데이터 셋이 존재하는지 확인합니다. 확인 후 데이터가 없으면 지정..

예제로 알아보는 Oozie Coordinator - 1 이전 포스트에서 우리는 다양한 workflow 패턴에 대해 알아보았습니다. workflow는 여러 액션들을 정의하고 액션들에 실행 관계를 포함해서 실행할 수 있습니다. 그러나 우리는 workflow가 특정 시간에 주기적으로 혹은 데이터가 존재하면 실행하길 원합니다. 이러한 요구사항을 수용해서 Oozie에서는 workflow를 스케줄할 수 있는 Coordinator 기능을 제공합니다. 이러한 스케줄링 기능을 통해 강력한 Orchestration 기능을 제공합니다. Oozie는 기본적으로 time interval 기반의 스케줄링과 data availability 기반의 스케줄링을 제공합니다. 또한 외부 이벤트에 의해서도 실행될 수 있습니다.Oozie에서..

Oozie classpath 사용법 oozie 액션은 일반적으로 우지가 실행하는 작은 자바 어플리케이션들입니다. 그러면 액션을 실행할 때 액션에서 의존성이 있는 클래스들을 classpath를 통해 이용가능한 상태여야 합니다. 우지에서는 sharelib이라는 액션들이 사용하는 라이브러리의 공유 위치를 정의할 수 있습니다. 이를 통해 액션의 디펜던시를 관리를 할 수 있습니다. 또한 다양한 방법으로 라이브러리를 classpath에 추가할 수 있습니다. sharelib directory 사용하기 sharelib를 사용하기 위해서는 oozie.use.system.libpath=true로 설정해주면 사용할 수 있습니다. 그리고 sharelib directory는 다음 oozie-setup 명령어를 통해 생성해줄 수..

Oozie Parameterization of Workflows Oozie에서 workflow 또는 coordinator에서 파라미터를 변수로 설정한 뒤, 워크플로우나 코디네이터를 실행할 때 이 파라미터를 직접 사용할 수 있습니다. 즉, workflow.xml 파일이나 coordinator.xml 파일을 편집하지 않고서도 값을 변경하여 실행할 수 있으며, 다시 배포하지 않아도 파라미터를 통해 다른 형태의 워크플로우나 코디네이터를 실행할 수 있는 것이죠. 그러면 파라미터를 설정하는 방법에 대해 알아보도록 하겠습니다. Parameter 설정 방법 config-defaults.xml에 설정하기 config-defaults.xml 파일을 생성하여 속성 값(property values)를 설정하여 파라미터를 설정..