들어가기 전 Materialized View는 현재 시점을 기준으로 가장 최신화 된 데이터를 의미한다. 그런데 RDBMS에서는 최신화 된 데이터를 가져오기 위해서 모든 행에 쿼리를 날려서 필요한 통계치를 내서 작성을 했었다. 이런 경우 데이터가 많아지면 속도에 문제가 있다. 그렇지만 ksqlDB는 이런 부분을 RocksDB를 이용해 최적화해서 실시간으로 집계된 데이터(Materialized View)를 바로바로 보여줄 수 있다. 가장 쉬운 예로는 톨게이트 직원이 징수한 요금 합계를 보여주는 것이다. 차가 지나갈 때 마다(메세지) 전체를 모두 다시 계산하는 것은 느릴 수 있다. ksqlDB에서는 징수한 요금 합계를 보여주기 위해 '누적합'과 같은 비슷한 형태로 업데이트를 해서 빠르게 Materialized..
들어가기 전 Stream이라는 것은 이벤트가 도착했을 때, 이벤트를 계산하기 위한 프로그래밍 패러다임이다. 대전제는 아래와 같다. Kafka는 Kafka Broker에 Topic에 이벤트를 저장한다. ksqlDB는 Stream에 이벤트를 저장한다. 이 때 Stream이라는 것은 Persistence Query에 의해서 정의된 schema가 존재하는 Topic이다. 이 Topic 역시 Kafka Broker에 저장된다. CREATE STREAM readings ( sensor VARCHAR KEY, location VARCHAR, reading INT ) WITH ( kafka_topic = 'readings', partitions = 3, value_format = 'json' ); 이 명령어를 ksql..
들어가기 전 ksqlDB는 스트림을 이용해서 특정 기간(Window)의 이벤트를 집계해서 보내주는 형태의 Window 쿼리를 제공한다. 특정 기간을 Duration으로 나타내고, Duration은 WINDOWSTART / WINDOWEND로 표현할 수 있다. WINDOWSTART / WINDOWEND는 Window 쿼리를 생성하면 SELECT 절에 선언해서 사용할 수 있다. Tumbling Window Hopping Window Session Window 이 Window 쿼리는 총 세 가지 모드가 존재한다. 또한 Window에는 Grace Period라는 부가 기능이 있어서 Window를 보조해주는 역할을 한다. Windowing의 의의 Window는 한번 더 그룹화를 한다는 의미가 있다. Window는..
들어가기 전 ksqlDB는 RDBMS에서 사용하는 Join과 마찬가지로 Join 기능을 제공한다. 스트림 - 스트림 / 스트림 - 테이블 / 테이블 - 테이블을 Join해서 새로운 스트림과 테이블을 만들어 낼 수 있다. 기본적으로 Join을 할 때는 파티션을 기준으로 한다. 파티션을 기준으로 한다는 말은 Key를 기준으로 한다는 의미가 될 수 있다. 이것을 미루어 보건데 Join의 대상이 되는 녀석들의 파티션이 중요하다는 것을 암시한다. Join과 Key Table은 항상 PK를 가지고, PK를 기준으로 파티셔닝 된다. 그리고 ksqlDB에서 Table은 리파티셔닝이 되지 않는다. 따라서 Table을 Join 하는 경우 반드시 PK값을 사용해야만 한다. Stream은 Key를 가지는 경우도 있고, Key..
들어가기 전 Stream / Table은 Key에 따라서 파티셔닝된다. 그런데 기존에 생성된 스트림을 그냥 읽기만 하는 경우에는 큰 문제가 없다. 왜냐하면 ksqlDB 내부에서 데이터를 처리할 필요가 없기 때문이다. 그렇지만 Join 같은 작업들을 하게 되면 파티션의 갯수는 문제가 된다. 왜냐하면 Join의 제약 조건 중 하나는 동일한 파티션 갯수를 가지는 것이기 때문이다. 동일한 파티션 갯수를 가지지 않는 스트림/테이블을 Join 하기 위해서는 파티션의 갯수를 맞춰줘야한다. 이렇게 파티션의 갯수를 맞춰주는 방법으로 Repartition이 존재한다. 여기서는 Repartition에 대해서 간략히 정리하고자 한다. 리파티션 하기 파티션 1개만 가지는 토픽을 만들고, 스트림을 생성한다. 생성한 스트림에서 파..