오래간만에 Java로 프로젝트를 할 일이 생겨서 하다보니 기본적인 것을 헤매고 있다. (무려 3시간이나 삽질하다 금요일 저녁 포기하고 퇴근했다.)

문제는 mybatis에서 foreach를 사용하는데, in sql의 조건으로 list를 넘기는 부분이 생각했던 것이 아니었는데. (결국 1cm 빗나간것이 영 엉뚱한 짓을 하고 있었던 것이다.)

curl

• 결국 보내는 List변수명과 받는 List변수명이 일치해야 하는 것이다.

curl -X 'POST' \
  'http://localhost:8080/test01/select01' \
  -H 'accept: */*' \
  -H 'Content-Type: application/json' \
  -d '{
  "listTest01InVO": [
    {
      "id": "ID2"
    },
    {
      "id": "ID3"
    }
  ]
}'

Java

List의 변수명을 잘 기억하자

# EML 파일명을 Maildir 규칙에 맞게 변경 (예: 타임스탬프 활용)
for eml in *.eml; do
    new_name=$(date +%s%N).$(hostname).eml
    cp "$eml" "/tmp/maildir/new/$new_name"
done

어쩌다 보니 이메일을 파싱해서 특정 보험건에 대한 요율을 추출해야 하는 상황이되어 제반 준비를 하다 발견했다.

위 shell에서 “date +%s%N"의 의미를 몰라 찾아보니.

date 명령의 형식을 지정하는 파라미터였다. 음. 위 방식을 unix 나노초를 반환하는 것이다.

그런데 뒤쪽의 hostname은 왜 필요한 것일까? (그냥 식별하는 용으로 보인다.)

SpikeArrest works

apigee의 traffic management를 보다가 생각한다.

그 짧은 순간에 이전과 이후의 요청을 어떻게 구분한 것인지 말이다.

구글의 엔지니어들은 양동이 개념을 도입해서 요청이 들어오면 평가하는 것이 아니라, 각 요청들을 하나의 양동이에 담고, 그 양동이 시간이 되면 퍼내는 식으로 구현을 했다.

참고할 만하다.

apigee debug

GCP apigee 세션을 진행하다보니 각 호출에 대해 디버깅 할 수 있는 Step이 있어 기록으로 남겨본다.

rest 응답에 메타정보를 포함하는 방식

REST API 설계의 기본이라는 동영상을 보다보니, 데이터 이외에 메타정보를 포함하는 내용이 나온다.

REST를 구성하면서 한 번도 생각해 본적이 없는 것이라 살짝 당혹스럽다.

물론 차세대라고 불리는 SI 할 때는 응답전문에 복수의 배열이 포함될수 있음으로 배열명과 동일한 _변수를 반드시 선언하는 식으로 많이들 하긴 했었다만.

이것을 좀더 나이스한 메타정보로 어찌해 볼 생각은 왜 못했을까 싶다.

GET, POST의 용법에 대해서도 다시 생각한다

물론 기본은 기본이지만 나는 대부분 GET과 POST로 모든것을 다 처리하고 있었는데 말이다.

700만개의 postgres table이라는 좀 자극적인 발표를 보고.

Dung Beetle을 찾아서 테스트 해본다.

• 생각보다 설정이 간단하다. toml파일 하나로 된다.
• SQL폴더에 복수의 SQL File이 있어도 된다.
• 결과 테이블은 매 요청마다 새로 생성 될 수 있다.
• 700만명의 정보라기 보다는 700만번의 request가 아니었을까 싶다.
• table name에 대해서 고민을 좀 잘하면 될 거 같다.

Prefect 인증화면

Prefect를 살펴보기 위해서 Cloud에 sigin in 한 다음 따라하고 있었는데 말이다.

local cli에서 prefect module을 설치하고 cloud + login 파라메터로 실행을 하니, 진행중인 웹브라우저로 인증을 한다.

당연히 web을 통한 인터페이스만 제공되는 줄 알았는데, local 환경을 제공하는 것은 어떤의미일런지.

Prefect local deploy 화면

한참을 뒤지다가 local에서 server를 띄우고 deploy를 실행 해 본다.

이런 CLI에서 본격적으로 select하는 녀석은 오래간만이다.

dbt를 보다가 보니 이런 저런 내용이 나오는데, 누군가 star schema에 대한 언근이 있어 찾다가 MS의 Understand star schema라는 페이지를 찾았다.

좀더 구체적인 비교를 찾아 질의 해 본다.

1. 구조 (Structure)

Star Schema

• 중앙에 하나의 팩트 테이블이 있고, 이를 둘러싼 다수의 디멘션 테이블로 구성됩니다.
• 디멘션 테이블은 비정규화된(flat) 형태로 설계되며, 각 디멘션이 별도의 테이블로 저장됩니다.
• 단순한 구조를 가지며 별 모양을 띱니다.

Snowflake Schema

• 팩트 테이블은 동일하지만, 디멘션 테이블이 정규화된(normalized) 형태로 설계됩니다.
• 디멘션 테이블이 하위 디멘션으로 분할되어 복잡한 트리 구조를 형성합니다.
• 눈송이(snowflake) 모양을 닮은 구조입니다.

2. 정규화 수준 (Normalization)

Star Schema

• 디멘션 테이블이 비정규화(denormalized) 되어 있습니다.
• 하나의 디멘션 테이블에 모든 속성이 포함되며, 중복 데이터가 있을 수 있습니다.

Snowflake Schema

• 디멘션 테이블이 정규화(normalized) 되어 있습니다.
• 중복 데이터를 제거하고 디멘션 속성을 여러 테이블로 나눕니다.

3. 복잡도 (Complexity)

Star Schema

• 구조가 단순하여 이해 및 유지 관리가 용이합니다.
• 쿼리가 간단하고 빠르게 실행됩니다.
• 데이터 웨어하우스 설계 초보자나 소규모 프로젝트에 적합합니다.

Snowflake Schema

• 구조가 복잡하며, 이해 및 유지 관리가 어려울 수 있습니다.
• 정규화로 인해 테이블 간 조인(join)이 많아 쿼리 성능이 떨어질 수 - 있습니다.
• 대규모 데이터 웨어하우스나 복잡한 데이터 관계를 다룰 때 유리합니다.

4. 성능 (Performance)

Star Schema

• 조인이 적어 쿼리 성능이 일반적으로 더 우수합니다.
• 디스크 공간 사용량은 더 많을 수 있습니다(중복 데이터 때문).

Snowflake Schema

• 정규화로 인해 조인(join) 작업이 많아 쿼리 성능이 저하될 수 있습니다.
• 디스크 공간 사용은 더 적습니다(중복 데이터가 제거됨).

5. 사용 사례 (Use Cases)

Star Schema

• 단순한 데이터 분석과 빠른 응답 시간이 필요한 경우.
• BI 도구나 OLAP(Online Analytical Processing)에서 자주 사용됨.

Snowflake Schema

• 데이터 중복을 최소화하고 정규화를 통해 데이터 무결성을 유지하려는 경우.
• 복잡한 데이터 관계를 명확히 표현해야 하는 경우.

비교 요약

Rust에서 문자를 파라미터로 넘기는 모습을 봐라

새해들어서 어떻게든 호기심을 유지하려고 한 해 동안 모아두었던 링크들을 정리하고, 하나씩 해 보고 있다.

Rust의 경우. 첫 번쩨 빌드하기 위한 소스의 구조를 toml에 기술해줘야 한다는 것은.. 뭔 그럴수 있다고 치자.

그 다음 파라미터를 좀 보면서 문자열을 넘기는 부분을 보다 아연실색한다.

그리고 좋다고 생각한다.

형식은 언제나 익숙해지기 마련이다. 생각을 잘 하면 매우 유용 할 것이고, 가변적인 상황을 전부 상정해서 어떻게 하려면.. 아마 방법이든 패턴이든 라이브러리든 있을 것으로 생각된다.