변경 이력을 남겨야 하는 요구사항이 있었습니다.CDC(Change Data Capture)를 활용해 처리할 수도 있었지만, 인력과 기술적인 제약으로 도입이 어려운 상황이었습니다. 이미 JPA를 기반으로 개발 중이었기 때문에, Hibernate가 제공하는 변경 감지 기능을 활용해 변경 이력을 남기는 방법을 고민하게 되었습니다. Hibernate에 DefaultFlushEntityEventListener를 통해 엔티티의 변경감지 로직을 손쉽게 확장할 수 있습니다. FlushEntityEvent 객체에는 영속성으로 관리되어 있는 Entity 정보와 propertyNames, propertyValues를 제공하며, 어떤 프로퍼티가 변경되었는지 dirtyProperties를 포함합니다. JPA의 구현체인 하이버네..
MySQL을 사용해서 개발을 하다보면 PK를 Auto-Increment로 잡는 경우가 많습니다. 그 이유는 MySQL에서 PK는 Clustered Index로 데이터를 저장하는 물리적인 순서를 PK의 순서로 정렬이 일어나기 때문에 Insert시 이득을 얻을 수 있으며, 대량의 데이터를 offset, limit를 사용해서 쿼리했을 때 범위 검색에 이득 또한 얻을 수 있습니다. Clustered Index 와 Non-Clustered IndexDatabase에서 index의 종류는 다양하지만 크게 Clustered Index와 Non-Clustered Index로 나뉜다.Cluster 사전적 의미군집화, 집속체, 무리, 밀접해있는 다수의 무언가를 총칭한다.Clustered Index: 실제 데이터uhan..
Kafka Streams DSL은 레코드의 흐름을 추상화한 개념으로 KStream, KTable, GlobalKTable이 존재합니다.이 개념들은 컨슈머, 프로듀서, 프로세서 API에서 사용되지 않고, 스트림즈 DSL 에서만 사용되는 개념입니다. KStream레코드의 흐름을 표현한 것으로 메시지 키와 메시지 값으로 구성되어 있습니다.카프카 컨슈머로 토픽을 구독하는 것처럼 KStream에 존재하는 모든 레코드가 출력됩니다. KTableKStream은 모든 레코드를 조회할 수 있지만 KTable은 유니크한 메시지 키를 기준으로 가장 최신 레코드를 사용합니다.Java Collection의 Map 자료구조처럼 토픽에 있는 데이터를 key-value store 처럼 사용하는 것 이라고 생각하면 된다.사용자 마지막..
데이터 스트림(이벤트 스트림, 스트리밍 데이터)데이터 스트림이란 ‘무한’히 늘어나는 데이터세트(unbounded dataset)를 추상화한 것이다.시간이 흐름에 따라 새로운 레코드가 계속해서 추가되기 때문에 데이터 세트가 무한해지는것을 의미한다.이벤트 스트림이라는 단순한 모델을 통해서 우리가 분석하고자 하는 모든 비즈니스 활동을 나타낼 수 있다. ‘무한’ 이라는 특성 외 이벤트 스트림 모델의 추가적인 속성들✅ 이벤트 스트림에는 순서가 있다.이벤트는 그 자체로 다른 이벤트 전에 혹은 후에 발생했다는 의미를 가진다.금융 이벤트에서 입금/출금 이벤트 순서에 따라서 처리가 달라져야 한다.계좌에 입금한 뒤 나중에 출금하는 것과 출금을 먼저하고 부채 상환을 위해 나중에 입금하는 것은 완전히 다르다.후자의 경우 초과..
아래 블로그에 대한 내용을 정리한 글입니다.https://dol9.tistory.com/281https://dol9.tistory.com/282https://www.youtube.com/watch?v=tU2pHxLh4ZU 카프카에서 Purgatory가 사용될 때컨슈머컨슈머에서 메시지를 가져올 때 성능 개선을 위해서 메시지를 배치로 묶일 때 까지 대기를 하게 된다.컨슈머가 브로커로부터 레코드를 읽어올 때 데이터의 최소량(byte 단위)이 되지 않았을 때카프카가 컨슈머에게 응답하기 전 충분한 데이터가 모일 때까지 기다릴 수 있는데 시간을 만족하지 않았을 때이 때 컨슈머가 보낸 요청이 머무는 것을 Purgatory라고 하며, Purgatory에서 벗어나는 방법은 요청 조건에 만족하거나, 지정한 시간이 흘러 t..