Ctrl+Enter는 오류가 발생한다.

pqrl을 테스트 해 보기 위해서 QStudio를 설치하고 따라 해 보고 있었다.

• 처음 duckdb 파일을 여는 와중에 접속 port가 보여서 duckdb가 server mode로 접속해야 하나 싶었으나. (잘못된 생각이었다.)
• Query를 기록한 파일의 확장자가 prql이어야 동작(인지)하는 것은 쉽게 따라 갔으나. 아무리 실행(하던 버릇데로 Ctrl+Enter)해 봐야 위와 같은 오류만 나온다.
• 그런데 단순 from table-name 하는 것은 잘 나온다.
• 알고봤더니 Ctrl+E 혹은 실행 아이콘으로 해야 정상적으로 파싱하고 인지한다.
• 그렇다면 Ctrl+Enter는 어떤 기능일까?

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

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

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

KRX: 한국거래소
KDS: 한국예탁결제원

RMB: 인민폐의 음차
RQFII: RMB Qualified Foreign Institutional Investor

SWIFT: Society for Worldwide Interbank Financial Telecommunication

1973년 설립, 본사는 벨기에 브뤼셀

CIPS: China Cross-border Interbank Payment System
CCF: CIPS Clearing Framework

즉, SWIFT의 중국버전

예탁결제원 차세대시스템 RFP를 보다가 보니. 중국 위안화 관련 처리를 위한 기능이 많다는 생각이 들었다.

%와 %+의 차이

goLang을 살펴보며 느끼는 불안감이랄까?

저 표현식은 뭘까?

이런 생각이 든 대부분의 것은 출력형식인 경우에 사용되는 옵션이었다.

그리고 느끼는 감정은 좀더 현대적인 언어겠구나. 잘 살펴보면 꾸미기 위해 삽질했던 많은 것 들을 해결 할 수 있겠구나. 하는 것이다.

10분 뒤에 다시 하세요

Web에서 인증하는 경우가 아니라 Local에서 패키지설치 인증을 하는 동안 비밀번호를 틀리자 보이는 UI.

나름 신선하다. 꼭 필요했을까? 필요 한 거 같다.

goLang Tour의 slice를 해보고 있었다.

slice라는 것은 python에서도 자연스러운 것이었으나, goLang에서 가장 크게 혼동되는 것은 cap이라는 개념이 있는 것 + 기존 slice에 append하는 경우에, cap이 모자라면 +1이 아니라 +2 해서 생성이 되는 것을 발견한다.

이거 생각 잘 하고. 그 특성을 이해 하고 써야겠는걸?

package main

import "fmt"

func main() {
	var s []int
	printSlice(s)

	// append wprks on nil slices
	s = append(s, 0)
	printSlice(s)
	// append를 하면 len==1이 되는 것은 당연해 보이는데, cap==2가 되는 이유는 무엇일까?

	// len을 강제로 2로 변경 해 보면 늘어나는 것을 볼 수 있다.
	// s = s[:2]
	// printSlice(s)

	// The slice grows as needed
	// 위에서는  nil에서 append하면 cap==2가 되었는데. cap==2인 상태에서 append하면 여전히 2이다.
	// 뭔가 규칙이 있나?
	s = append(s, 1)
	printSlice(s)

	// We can add more than one element at a time
	// cap이 apped결과보다 작을 경우에, cap+1이 되어 생성되는 것으로 보인다.
	s = append(s, 2, 3, 4)
	printSlice(s)

	// 강제로 len을 설정하면. 마지막은 0으로 되어 있는 것을 볼 수 있다. nil이 아니다.
	s = s[:cap(s)]
	printSlice(s)

}

func printSlice(s []int) {
	fmt.Printf("len=%d cap=%d %v\n", len(s), cap(s), s)
}

1e9에 대한 설명

A Tour of Go를 살펴보다 보니. 변수에 1e9을 대입한다.

응?

처음에는 뭔가 저정돤 메모리주소의 sample인가 싶었지만.

구글링 해 보니, 숫자를 선언하는 형식인것을 알게된다.

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

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

비교 요약

SSH로 연결 할 때 IP는 local host이다.

Oracle Cloud에서 메모리 부족 사태를 겪은 후 DEMO용 DBMS에 대해서 가급적이면 sqlite를 사용하려고 노력하고 있었다.

그런데, wiki.js라던지 FastAPI 공식 Template을 사용 해 보면서, 결국 DB는 postgresql로 넘어갔구나 하는 생각을 하고, 메모리를 얼마나 점유하는지 확인 해 보니, 그리 걱정 할 수준은 아니라고 판단해서 올려 놓기로 한다.

막상 container를 올려놓고 보니, 관리하는 것이 영 불편할것 같아, remote db에는 직접 접속하지 않겠다는 기존 생각을 고쳐먹고, ssh tunneling을 시도 해 보는데.