homebrew computer club

엘라스틱서치 조인 가이드 문서 링크 https://www.elastic.co/guide/en/elasticsearch/reference/current/parent-join.html#parent-join 엘라스틱서치는 Parent-join이라는 것을 제공함. The join data type is a special field that creates parent/child relation within documents of the same index. The relations section defines a set of possible relations within the documents, each relation being a parent name and a child name. `join` 타입은 동일..

애널라이저는 9개 이상의 캐릭터 필터, 1개의 토크나이저, 0개 이상의 토큰 필터로 구성된다. 동작 역시 캐릭터 필터 -> 토크나이저 -> 토큰 필터 순서로 수행된다. 애널라이저는 입력한 텍스트에 캐릭터 필터를 적용하여 문자열을 변형시킨 뒤 토크나이저를 적용하여 여러 토큰으로 쪼갠다. 쪼개진 토큰의 스트림에 토큰 필터를 적용해서 토큰에 특정한 변형을 가한 결과가 최종적으로 분석 완료된 텀이다. 엘라스틱서치는 애널라이저의 동작을 테스트할 수 있는 API를 제공한다. example GET _analyze { "analyzer": "standard", "text": ["Hello, HELLO, World!"] } //result { "tokens": [ { "token": "hello", "start_offs..

object와 nested 모두 필드 하위에 다른 필드가 들어가는 계층 구조의 데이터를 담는 타입이다. 이 둘은 유사하지만 배열을 처리할 때 동작하는 방식이 다르다. object vs. nested object 용도: 일반적인 계층 구조에 사용 성능: 상대적으로 가벼움 검색: 일반적인 쿼리를 사용한다. nested 용도: 배열 내 각 객체를 독립적으로 취급해야 하는 특수한 상황에서 사용 성능: 상대적으로 무거움. 내부적으로 숨겨진 문서를 생성 검색: 전용 nested 쿼리로 감싸서 사용해야 한다. object type JSON 문서는 필드의 하위에 다른 필드를 여럿 포함하는 객체 데이터를 담는다. object가 객체 데이터의 기본 타입이다. object와 nested의 차이는 객체 배열에 대해 쿼리할 때..

프로듀서 기본 동작 프로듀서는 카프카의 토픽으로 메시지를 전송하는 역할을 담당한다. 프로듀서의 디자인은 아래 다이어그램과 같다. ProducerRecord는 카프카로 전송하기 위한 실제 데이터 topic, partition, key, value로 구성 카프카는 특정 토픽으로 값(메시지)을 전달하기 때문에 topic/value는 필수값. 특정 파티션을 지정하기 위한 레코드의 파티션과 정렬을 위한 키는 선택사항 레코드는 프로듀서의 send() 메서드를 통해 serializer -> partitioner를 거친다. 프로듀서 레코드가 파티셔너를 지정했다면 파티셔너는 아무 동작도 하지 않고 지정된 파티셔너로 레코드를 전달함. 파티션을 지정하지 않은 경우 키를 가지고 파티션을 선택해 레코드를 전달한다. 이때 기본적..

kafka 카프카 또는 카프카 클러스터. 아파치 프로젝트 애플리케이션 이름. 여러 대의 브로커를 구성한 클러스터를 의미한다. broker 카프카 애플리케이션이 설치된 서버 또는 노드 producer 카프카로 메시지를 보내는 역할을 하는 클라이언트를 총칭한다. consumer 카프카 애플리케이션이 설치된 서버 또는 노드 message 프로듀서가 브로커로 전송하거나 컨슈머가 읽어가는데이터 조각 topic 카프카는 메시지 피드를 토픽으로 구분하고, 각 토픽의 이름은 카프카 내에서 고유하다. partition 하나의 토픽이 한 번에 처리할 수 있는 한계를 높이기 위해 토픽 하나를 여러 개로 나눠 병렬 처리가 가능하게 만든 것 토픽은 논리적 개념이고 물리적으로 저장되는 곳은 파티션임. 토픽은 최소 하나의 파티션을..

기본 분산 시스템 분산 시스템은 네트워크상에서 연결된 컴퓨터들의 그룹. 단일 시스템이 갖지 못한 높은 성능이 목표 성능 뿐 아니라 하나의 서버 또는 노드 등에 장애가 발생할 때 다른 서버/노드가 대신 처리하므로 장애 대응 면에서도 탁월 부하가 높은 경우 확장도 용이하다. 카프카 역시 마찬가지. 최초 구성한 클러스터 리소스가 한계치에 도달했을 때, 브로커를 추가하는 방식으로 확장 가능하다. (이미 메시지가 들어오는 상태에서 줄이는 것도 쉽게 가능한가?) 페이지 캐시 다른 메시징 시스템은 메시지를 전송하고 나면 메시지를 삭제함. 아직도 그런지 모르겠음. 2018에 나온 카프카, 데이터 플랫폼의 최강자는 그렇게 설명했음. 카프카는 디스크에 세그먼트 형식으로 메시지를 저장함. 디스크에 저장하기 때문에 어떤 이유..

이 글은 제 주관이 많이 들어있고 팩트와 다를 수 있습니다. 지적해주시면 고치겠습니다. 회사에서 신규 프로젝트에 포트 앤 어댑터 패턴을 도입하기로 했다. 헥사고날 아키텍처보다 포트 앤 어댑터 패턴이라는 말이 더 명료하게 이 패턴을 설명하는 것 같다. 어쨌든 공부할 시간이 많지는 않았고 짧게 공부한 기록을 남겨본다. 포트 앤 어댑터 패턴에 대해 이야기하기 전에 전통적(?)인 레이어드 아키텍처를 먼저 짚고 넘어가야 할 것 같다. 레이어드 아키텍처는 프레젠테이션, 도메인, 영속 세 개의 계층으로 이루어진 아키텍처다. 프레젠테이션 계층은 HTTP 요청을 처리한다. 도메인 계층은 비즈니스 로직을 담당하는 가장 핵심 레이어다. 마지막으로 영속 계층은 데이터 영속화를 담당한다. 레이어드 아키텍처의 규칙은 간단하다. ..

연습용 주문 서버 만들기 git repository 01 Kotlin/Spring 멀티모듈 프로젝트 구성 02 멤버십 발급 API 작성하기 03 메뉴 목록 조회 API 등록 API는 따로 만들지 않고, 메뉴가 고정되어 있다고 가정하겠습니다. 메뉴 조회는 누구나 가능하다. 프로젝트 실행 시 기본 메뉴 생성 역시 매우 간단한 기능이므로 딱히 부연 설명할 게 없습니다. 메뉴 조회 API Controller @RestController @RequestMapping(V1_API_PREFIX) class MenuViewApiController( private val menuService: MenuService ) { @GetMapping("/menu") fun getAllMenu(): ResponseEntity {..

연습용 주문 서버 만들기 git repository 01 Kotlin/Spring 멀티모듈 프로젝트 구성 02 멤버십 발급 API 작성하기 03 메뉴 목록 조회 API 가장 간단한 아이디 발급 API부터 만들겠습니다. 지난 번 글에도 말했듯이 편의상 회원가입없이 아이디 발급 요청하면 임의의 UUID를 발급하겠습니다. 이 아이디를 membership이라고 하겠습니다. 사용자는 나중에 발급받은 membership를 가지고 포인트를 충전하거나 결제할 수 있습니다. 구현할 요구사항은 아래와 같습니다. 사용자는 누구나 membership 발급 API를 통해 멤버십 번호를 발급받을 수 있다. 따로 무엇을 검증하지 않을 것이므로 매우 간단한 구현이 되겠습니다. 아이디 발급은 실패하는 케이스가 없다고 가정하겠습니다. ..

연습용 주문 서버 만들기 git repository 01 Kotlin/Spring 멀티모듈 프로젝트 구성 02 멤버십 발급 API 작성하기 03 메뉴 목록 조회 API Kotlin + Springboot로 주문 서버를 만드는 연습을 해보겠습니다. 최대한 간략하게 구성하기 위해 아래 네 개의 API만 만들겠습니다. 아이디 발급 API 편의상 회원가입 없이 아이디 발급 요청하면 임의의 아이디 발급 메뉴 조회 API 포인트 충전 API 결제 API 이번주 인기 메뉴 API 요구 사항 누구나 고유한 아이디를 발급 받을 수 있습니다. 누구나 메뉴를 조회할 수 있다. (메뉴 등록은 안 만들겠습니다.) 고유한 아이디에 포인트를 충전할 수 있다. 한 아이디를 여러 명이서 쓸 수도 있기 때문에 동시성을 고려해보겠습니다...