Quartz 4

2.26.26 -4th day

8 min read

  • greeting api key 발급받기
    • 피플팀에게 문의해보기
  • 공고 리스트, 지원자 리스트에 대한 페이지네이션 고려
    • 공고 리스트 페이지네이션
  • 파일 업로드에 대해서 생각해볼 것
    • 민감정보니까 저장하면 안됨, 로컬에서 저장하는걸로
  • 설치
    • rectangle 환경
    • runcat

Learn (배운거)

  • resources choice

    • sqlite
      • MySQL이나 PostgreSQL처럼 무서운 데이터베이스 서버를 따로 띄우는 방식이 아님; 컴터나 서버 폴더 안에 .sqlite, .db 처럼 단 하나의 파일로 모든 데이터를 저장함
      • 핸드폰 앱 등에 굉장히 많이 쓰임 → 엄청 가벼움
      • OLTP → 대규모 말고 소규모/개인용 트랜섹션 처리에 특화되어 있음
      • concurrent write가 안됨
      • sqlite를 사용하면 deploy할때마다 새로 해야함
    • s3
      • 굉장히 튼튼
      • file based. update가 없고 무조건 overwrite
      • s3 + 람다를 사용해서, 데이터를 가져오소 합쳐서 s3를 db처럼 사용할 수 있음 (해모님 예시)
    • dynamodb
      • previous notes (aws) on dynamodb
      • key value로 되어있는 documentation db → 기본적으로 key value형태이면서 json 문서를 지원하는 NoSQL 데이터베이스임
      • 굉장히 빠름!!!!! (aws 논문도 있음), 대신 잘 써야함
      • partition key, sort key → unique key
        • partition key만 쓰거나, partition key + sort key를 조합해서 unique를 만듬
        • table db, character db
      • dba (관리사람) 필요없음
        • 원래는 디비 인스턴스를 수시로확인해야하는데 다이나모디비는 필요없음
      • billing
        • 스토리지 용량 + 읽기/쓰기 용량(RCU/WCU)에 따라 과금
        • storage + read/write time computation
      • 400KB 제한 & Gzip 바이너리 팁
        • DynamoDB의 아이템 크기 제한은 정확히 400KB → JSON을 .gz로 압축해서 Binary(B) 타입으로 넣으면 스토리지 비용과 읽기/쓰기 유닛(RCU/WCU)을 아낄 수 있음
        • .gz를 사용하면 바이너리로 압축됨 → .gz면 1/4 사이즈로 줄어듦
        • 하지만 아직도 크다고 하면, 바이너리를 더 쪼개서 (이런식 v_1, v_2) 저장하고 나중에 액세스 할때 다 가져와서 합치는 방식 사용가능
      • 최신 날짜?
        • 유저 정보에 대표값 (-1처럼) 사용할 수 있음
        • TTL 달수있음
    • mysql
      • 한달에 ~6만원 (비쌈). 그래서 정말 필요할때만 사용 (개인 정보를 저장해야할 때 mysql만 법적으로 사용가능함)
      • schemaless
    • 20+ other dbs
      • postgresql, oracle, cassandra, mongodb
      • clickhouse
        • columnar log db → column기반의 분석용(olap) db. update할 수 있지만 성능 떨어짐, 원래 overwrite 위주였음.
        • 데이터를 저장할 때 (schema)
          • id int → int는 32bit
          • varchar vs char
            • char(2)는 2개의 32bit 사용
            • varchar→ “안녕”을 넣으면 딱 2글자만큼, “안녕하세요”를 넣으면 5글자만큼만 용량 차지 (저장소 절약), 하지만 컴퓨터 입장에서는 이 데이터가 어디서 끝나는지 길이나 ‘포인터’ 정보를 같이 읽고 계산해야 해서 속도가 미세하게 느림 (계속 찾아줘야 함)
            • char → 무조건 정해진 칸 수(예: 10칸)를 차지. “안녕” 2글자만 넣어도 나머지 8칸은 빈 공간으로 남겨둠 → 용량은 낭비되지만, 컴퓨터가 데이터를 찾을 때 “무조건 10칸씩 끊어 읽으면 되네!” 하고 기계적으로 빠르게 읽어낼 수 있음 (고정되어 있음)
      • realm
        • 모바일 특화된 디비, sql의 강점 보완
      • h2 → sqlite의 자바 버젼

  • NoSQL

    • sql이 아닌 → No는 no 가 아니라 not only의 약자임 →rdb아닌 모든 것들!
    • redis, memcached

  • csv VS tsv

    • csv
      • , 가 들어간 데이터가 포함되는 순간 골치아픔!
    • tsv
      • 장점 → plaintext, 잘보인다
      • 단점 → 쉼표/delimiter 개수가 틀린 데이터가 발생

  • xml, json, jsonl

    • xml → -JSON이 나오기 전에 천하를 호령하던 포맷 → <name>데이터</name> 처럼 여는 태그와 닫는 태그가 한 세트
      • 단점: 태그 이름이 계속 중복되어서 데이터 크기가 엄청나게 크고 파싱하기도 무거움. 요즘은 특수한 환경(설정 파일 등)이 아니면 JSON으로 다 넘어왔습니다.
    • json
      • 장점 → structure
      • 당점
        • 무거워짐
        • parsing CPU가 많이 발생
        • 꺽쇄 → 언제 닫힐지 모르니까 모든 버퍼를 열어두어야하는데 굉장히 부담 - 재귀로 올라가야함..타입 추론도 계속 끝까지 함
    • jsonl
      • object끼리 디리미터사용 → 겉을 감싸는 큰 리스트 [] 나 쉼표 , 를 없애버리고, 한 줄(Line)에 완벽한 JSON 객체 하나씩만 쓰고 엔터(Newline, \n)로 구분(Delimiter)
      • json보다 parse 훨씬 성능 좋음

  • rdb VS cdb

    • rdb → row니까 oltp 발생
      • 사용자들이 분석 (select 계열, 복잡한 조인 등 olat) → 항상 풀스탠
    • cdb
      • 컬럼 형식으로 저장 → 하나의 타입
      • 압축이 가능해짐
      • rdb 를 미러링하는 cdb를 만들어서 분석팀은 이거만 보게할수있음
      • 하지만 압축을 풀면 다 메모리에 풀어야함 → clickhouse, spark등장
        • parquet

  • 압축 알고리즘

    • tar.gz
    • gzip
      • pigz (parallel)
    • zip
    • br
    • google’s brotl (브로틀)
      • html이 도착할때 브로틀로 도착
      • 속도는 zstd
    • zstd
      • lg 어쩌고, 메타
      • 병령압축이 된다

  • html

    • server는 html을 압축한 형태로 나옴

  • 자주 사용하는 aws

    • S3, synamodb → state를 저장할 때
    • 목적에 맞춘 리소스 선택과 이유 생각

  • 되기만 하면 된다

  • 3월에는 맥 미니로 deploy하는 방법 알아보기

  • 자동화 하는 도중 생길 수 있는 문제점

    • 공고가 플랫폼마다 다를 수 있음
    • 그리팅 api로 리스트를 받아올 수 있는데, 매칭되지 않으면 alert되는 장치도 필요해보임
      • 피플팀한테 알람 보내기 필요 → 슬랙
      • 도구를 만들고 사용하면 좋음… 휴먼 에러가 많이 나올 수 있을 것을 대비
  • 개발 할때 file format은 상황에 맞추어서 고름

Graph View

Backlinks