본문 바로가기

개발

 (5)
데이터베이스 PK로 auto-increment를 사용하면 안 될까? 데이터베이스 설계에서 기본 키(Primary Key) 선택은 시스템의 성능, 확장성, 그리고 데이터 무결성에 큰 영향을 미치는 중요한 결정입니다. PK를 바꾼다는 것은 꽤나 번거로운 작업이기에 나중에 확장하기 쉽거나 어렵게 만드는 결정을 끊임없이 내리게 됩니다.기존에 프로젝트를 진행하면서 RDB 테이블의 PK의 경우 대부분, 데이터베이스의 auto increment ID 생성 전략에 위임하고 신경 쓰지 않는 경우가 많았습니다. 최근 supabase로 토이 프로젝트를 진행하면서 PostgreSQL의 PK 생성 옵션으로 auto increment와 UUID 중 선택할 수 있었는데, 여기서 UUID를 PK로 사용하는 것의 장점을 살펴보고, 토이 프로젝트에 UUID를 적용하는 것이 적절할지 고민해보겠습니다.먼저..
버퍼(Buffer)에 대한 이해와 활용 컴퓨터 과학에서 버퍼(Buffer)라는 용어는 자주 등장합니다. 버퍼는 데이터를 일시적으로 저장하는 메모리 공간으로, 데이터 전송의 효율성을 높이고 안정성을 보장하는 데 중요한 역할을 합니다. 이번 글에서는 버퍼의 정의와 목적, BufferedReader와 FileReader의 성능 차이, 데이터베이스 대량 데이터 전송에서 버퍼 사용의 중요성을 살펴보겠습니다.버퍼(Buffer)의 정의와 목적버퍼의 사전적 정의버퍼는 데이터를 임시로 저장하는 메모리 공간으로, 데이터 전송 속도 차이를 완화하고 데이터의 일관성을 유지하는 역할을 합니다. 버퍼는 주로 하드웨어와 소프트웨어 간의 데이터 전송을 원활하게 하기 위해 사용됩니다.버퍼의 목적버퍼는 여러 가지 중요한 목적을 가지고 있습니다:데이터 임시 저장 및 속도 차이..
Firestore에서 상위 문서 삭제 후 남아있는 하위 컬렉션 관리 방법 최근 프로덕션 환경에서 Firestore 데이터베이스를 관리하던 중, 특정 문서를 삭제할 때 하위 컬렉션이 자동으로 삭제되지 않고 그대로 남아있는 문제를 발견했습니다. 예를 들어, 다음과 같이 문서를 삭제할 때:await db.collection("users").doc(userId).collection("kid").doc(kidId).delete();해당 문서의 하위 컬렉션은 삭제되지 않았습니다. 이에 대한 원인을 조사해본 결과, Firestore의 데이터 삭제 동작 방식 때문임을 알게 되었습니다.Firestore의 데이터 삭제 동작 이해하기Firestore는 컬렉션과 하위 컬렉션을 독립적인 엔티티로 취급합니다. 상위 문서를 삭제한다고 해서 하위 컬렉션이 자동으로 삭제되지는 않습니다. 이는 데이터 모델링..
Git 커밋 되돌리기: reset, revert, --amend Git을 사용하다 보면 실수를 되돌리거나 특정 커밋을 수정해야 하는 상황이 자주 발생합니다. 이때 유용하게 사용할 수 있는 명령어가 reset, revert, --amend입니다. 이 명령어들의 차이점과 사용 방법을 실제 시나리오와 함께 정리해보겠습니다.reset 명령어reset은 브랜치의 HEAD를 특정 커밋으로 이동시키는 명령어입니다. 이 명령어는 작업 디렉토리, 스테이징 영역, HEAD에 영향을 미치며, 세 가지 모드로 동작합니다: --soft, --mixed, --hard.reset 모드--soft: HEAD만 이동시키고, 스테이징 영역과 작업 디렉토리는 그대로 유지합니다.--mixed(default): HEAD와 스테이징 영역을 이동시키고, 작업 디렉토리는 유지합니다.--hard: HEAD, 스..
Firebase 프로젝트 관리 효율화: codebase로 함수 분리 및 최적화 Firebase Cloud Functions를 사용하다 보면 프로젝트가 커지면서 관리의 복잡성이 증가하게 됩니다. 처음에는 모든 함수를 한 폴더에 넣어 관리했지만, 시간이 지나면서 파일이 많아져 혼란스럽고, 배포 시 코드 용량 문제도 발생했습니다. 특히, 하나의 폴더에 모든 함수를 관리하다 보니 코드 용량이 증가하면서 배포 시간이 점점 늘어났습니다. 또한, monorepo 설정에서 서로 다른 팀이 독립적으로 함수를 관리하거나, 외부 종속 항목이 많고 초기화 시간이 오래 걸리는 함수를 지연 시간에 민감한 함수와 격리하고자 할 때, 더 큰 어려움이 있었습니다. 단일 Firebase 프로젝트 내에서 모든 함수를 관리하여 Firestore의 기본 사용량을 최대한 활용하면서, 위의 문제를 해결 하고 싶었습니다.이..

티스토리툴바