지난 주에 이어서 상태 관리에 관한 코드를 작성했다. 오늘은 테이블을 분리했는데, OneToOne으로 작업했다. 처음에는 식별관계로 만들고 싶었지만, 굳이 복잡성을 높일 이유가 없다고 판단했다.
JPA책에 조인 대상 테이블이 아닌 주인 테이블에 fk를 넣어주는게 개발자 입장에서는 편하다고 했는데, 이해를 못 하다가 저장 한 번 해보고 바로 깨달았다. 주종관계라는 것이 결국 참조를 가져올 수 있느냐에 관한 것이라 한 번에 업데이트나 조회 등이 되는지와 연관이 있는 것 같다. JPA 너무 어렵다 ..ㅋㅋ
지난주와 같이 상태를 관리하는 이유는 원하는 동작을 할 수 있는 상태를 제한하고, 또 해당 상태로 갈 수 있는 방법을 제한하는데 있는데, 단순히 속성만 가지고 생각하려면 너무 머리아프다. 일관성이 깨질 가능성도 높다. 코드 작성자마다 상태에 대한 이해가 다를 수도 있기 때문이다. 자연스럽게 테이블 조회도 줄어든다.
단점은. 객체지향적이지 않은 것 같다는 느낌이 얼핏 얼핏 든다. 왜 그런걸까? 객체 자체의 상태에 따라 행동하는 것이 아니라 특정 상태를 별도로 잡아놓고 상태에 따라 동작하도록 해서 그런 것 같은 느낌인데, 정확한 근거를 대기 힘들다. 생소해서 그럴 수도 있으니 좀 더 생각을 해봐야겠다.
시간이 없는 날짜를 관리하는데도 타임존이 필요할까?
UTC든 KST든 날짜로만 표현한다면 그 날짜 자체가 올 것이다. DB에 DATETIME으로 저장하지 않으니 필요 없지 않을까? 하는 결론을 내렸다.
전략 패턴이랑 상태 패턴 - 상태 패턴은 계속 변화하고, 전략 패턴은 한 번 정해지면 거의 변화가 없는 경우라고 한다. 그래서 상태 패턴은 스스로 상태변화를 계속해서 하기 때문에 주인은 현재 상태가 어떤지 신경쓰지 않아도 된다. 그냥 명령만 하면 다형성으로 알아서 처리하고 바꾼다.
반면 전략 패턴은 주인이 직접 전략을 바꿔줘야 한다. 보통은 객체 생성 시 넣어주고 안 바꾸는 식으로 하는 것 같다.
내가 했던 것은 상태 패턴인데, 복잡해져서 레이어를 하나 추가한 느낌이다.
DSP를 만드려고 하면서 비슷하지만 다른 경우가 생겼는데, 이번에는 특정 매개변수에 따라 동작이 달라져야 한다.
그런데 조회 방법까지 달라져 서비스 이후에 나누기 애매해졌다. 그래서 서비스를 여러개 만들어 선택하도록 하는 방법을 택하려고 한다. 이거는 전략패턴에 가까운 방법인듯 하다.
다시 읽고 있다. 읽은 부분과 메모하는 부분을 따로 표시해가며 넘어가기로 했다. 읽을때는 끄덕끄덕 하지만, 잊고 있었던 부분들이 많다.
중간점검을 받고 질문을 했다.
가장 궁금했던 최소값과 최대값에 대한 질문이 주 였는데, 결론적으로 서버에서 처리하고 있다고 한다. 현재는 데이터가 만건정도라고 한다. 그리고 DB 스케일 아웃도 자동으로 리플리케이션을 만드는 방식으로 진행되고 있다고 한다.
만약 풀에 엄청 데이터가 많으면 긁어와서 서버에서 처리하기에 버거울 것이다. 그래서 쿼리로 처리하고 DB에서 해결을 하는 방안도 생각을 해봤지만, 원하는 방향이 아니었다고 한다. 지난번에도 쿼리로 구현해와서 직접 구현하라 피드백 하셨다고 한다. 방향은 잘 맞춘 것 같아 다행이다 ㅋㅋ.
그래도 만약 데이터가 너무 많으면 해당 값만 긁어오도록 수직 파티셔닝을 고려해볼 수 있을 것 같다.
서버에서 감당 못할 양인데, 서버에서만 처리한다면 경매 전용 서버를 두고 잘게 자른 여러개를 경매 붙인 뒤에 승자끼리 왕중왕전을 하는 것도 생각해봤다. 어떤게 베스트일까. 라는 생각을 하면서 실버불렛이 생각났다. 그때 그때 최적의 선택을 하는게 가장 좋은 것이니 최적의 선택 후보 공부를 많이 해두자? 가 결론이 되는 것 같다.
요즘 계속 궁금했던 점인데 코어에 감싸서 배포해라 혹은 코어에 새롭게 요청해서 가져와라 등 여러 가지 방법론을 들어본 것 같은데, 실제로 어떻게 하고 있는지 궁금했다.
결론적으로 그냥 중복 구현을 한다고 한다. 도메인을 잘 나눠두면 결국에는 중복이 아니게 되는 경우가 많았다고 한다. 김영한님의 MSA 여행기도 한 번 봐야겠다. 메세지와 이벤트만 공부하면 이제는 이해가 될 것 같다.
경매 부분은 생각보다 부드럽게 넘어갔다. 내가 버그를 잡는 동안 다른 구현을 잘 해주셔서 나는 바로 엘라스틱 서치 공부로 넘어갔다.
관계형 테이블처럼 생각하면 안 되는 것 같다. 조회를 빠르게 하기 위해 도큐먼트를 사용하는데 도큐먼트끼리 참조를 시키면 오버헤드가 발생해 안티패턴이라 한다.
물론 사용이 잘 안돼서 나눠놓은 것은 OK. 그런데 사용이 많이 되면서 나눠놓은 것은 좋지 않다고 한다. RDB도 비슷한 이유로 최대한 한 테이블에 많이 모아뒀던 것 같다.
현재 문제점 중 하나가 계속 조회해야 하는 데이터가 쪼개져있다는 것인데, 이걸 합치는 디자인 패턴이 있다고 한다.
이걸 적용해보려 하니 테이블 하나가 의미가 없어지는 것 같아 일단 생략해보고 진행하기로 했다. 만들어보고 질문 해봐야겠다.
두루뭉술하게 알고 있었는데, 이번에 짚어봤다.
파티셔닝은 수직과 수평으로 나뉜다. 말 그대로 각각 로우와 컬럼을 기준으로 나누는 것이다.
샤딩은 DB를 조각으로 나누어 분산시키는 것이다. 샤딩도 수직과 수평으로 진행할 수 있고, 파티셔닝의 방법론 중 하나다.
dsp까지 마무리가 됐다. 어제부터 애를 먹었던 부분은 날짜 관련된 것이었는데, Spring data를 사용하는 엘라스틱 서치에서 LocalDateTime이 사용되지 않았던 문제다.
물어봐서 해결했는데, 컨버팅 과정에서 맨 뒤에 Z가 붙어있는게 제대로 변환되지 않는 것 같았다. 왜 이런지 모르겠지만...
그래서 계속 시도했던 타임존 없는 데이트 포멧은 정상적으로 작동한다. 아마 어제 안 됐던 것은 스키마 초기화가 제대로 되지 않아 그랬던 것 같다.
겉핥기만 하고 넘어가는 것 같아 조금 아쉽다. 엘라스틱서치는 아쉽지만 어쩔 수 없고, 적어도 몽고디비는 제대로 공부를 한 번 해봐야겠다.
이제 배치가 남았는데, 간만에 하니까 잘되지 않는다. 이번에는 예습을 조금 해와야겠다.
이번 주 스터디는 금요일로 밀리게 됐다. 파이로가 엄청난 발표를 해주셨는데, 얻어갈만한게 있었다.
함수형으로 가져가려면 플럭스 아키텍쳐를 사용하는 것이 좋다고 한다. 들었을때 말이 된다. 간단하게는 이벤트를 쏘고 이벤트는 큐에서 관리하도록 하면 로직은 상태를 직접 관리할 필요가 없다는 것인데, 어떤 컨셉인지 알 것 같다. 프런트에서 말하는 상태관리 같은 것도 이런 맥락인건지 알아봐야겠다.
정작 코틀린 람다는 문법적으로 특이한 점이 없었던 것 같았는데, 내부적으로는 익명객체를 사용하도록 되어 있다는 점이 자바와 다른 점이다. 자바8이 나오기 전에 안드로이드 등을 지원하려고 먼저 나와 그랬다고 한다. 시퀀스도 같은 맥락이라 한다.
여담으로 파이로는 회사 내부에 개발 문화를 이식 시키기 위해 노력중이라고 한다. 나였으면 다른 회사를 찾아봤을 것 같은데... 조금 반성하게 된다.
Powered with by Gatsby 2.0