즐기자, 꾸준히, 오래오래
최근 이야기
-
JSON_CONTAINS(), IN 절의 검색 대상을 여러 개로 확장하는 전략
JSON_CONTAINS(), IN 절의 검색 대상을 여러 개로 확장하는 전략
2024.04.140. 글을 시작하며현재 진행하는 프로젝트에는 해시태그 개념이 존재하고, 이 해시태그를 이용한 검색 기능을 제공하고 있었습니다. 기존에는 하나의 post는 하나의 해시태그만을 가질 수 있다는 정책을 설정하고 사용하고 있어서 데이터를 다음과 같은 형태로 저장하고 있었습니다.post_idpost_namepost_content...hash_tag1석촌호수 벚꽃석촌호수 벚꽃이 정말......벚꽃2따뜻한 날씨요즘 날씨가 많이 따뜻......일상......104날씨 좋은 날 나들이이렇게 날씨 좋은 날 ......나들이105Querydsl 도입기기존 프로젝트에서는......기술 그래서 사용자가 "벚꽃" 또는 "나들이" 라는 해시태그가 포함된 글을 보고 싶다면 다음과 같은 쿼리를 사용해서 해당 태그를 포함한 포스트들을 .. -
동적 쿼리와의 전쟁... Querydsl을 도입할 수 없었던 이유
동적 쿼리와의 전쟁... Querydsl을 도입할 수 없었던 이유
2024.03.170. 글을 시작하며2024년 회사에서 새로운 프로젝트를 시작한 것도 어느덧 2달이 넘어가고 있습니다. 이미 오랜 기간 개발이 되어오던 프로젝트라 복잡한 DB 구조 및 비즈니스 로직, 새로운 요구사항을 반영할수록 높아지는 클래스간 결합도 등 저를 괴롭히는 문제들이 많지만, 그 중에서 단연 가장 큰 문제는 바로 "동적쿼리" 처리 방식이었습니다. 해당 프로젝트는 현재 Spring Boot에 JPA를 주요 기술스택으로 사용하고 있습니다. JPA에서 동적쿼리 문제를 가장 이상적으로 해결할 수 있는 기술이 querydsl 이라는 것은 많은 분들이 이미 알고 계실겁니다. 하지만 이번 글에서는 제가 자신있게 querydsl을 도입해서 현재 프로젝트의 동적쿼리 문제를 더 깔끔하게 풀어낼 수 없었는 지, native qu.. -
프로젝트 인수인계 시 꼭 기억할 5가지
프로젝트 인수인계 시 꼭 기억할 5가지
2024.02.040. 글을 시작하며 2024년을 시작하면서 입사 후 한 해동안 진행하던 프로젝트를 마무리하고 새로운 프로젝트를 인수인계 받아 진행하게 되었습니다. 이전 프로젝트는 처음부터 프로젝트를 세팅하고 코드를 직접 작성하며 진행한 프로젝트였지만 이번 프로젝트는 지난 1년부터 지금까지 개발과 유지보수 병행하며 실제 운영 중인 서비스를 유지보수하고 추가 개발하는 내용이었습니다. 이전에는 머릿속으로 정리한 논리를 코드로만 잘 작성하면 되었지만 이제는 기존 전임자의 코드를 통해서 핵심 로직을 이해하고, 전체 시스템에 대해 이해하여 서비스에 대한 유지보수와 함께 신규 기능 추가 개발을 통해 서비스를 향상시켜야할 필요가 있었습니다. 즉, 이전에는 나의 방식대로 로직만 잘 작성하여 요구사항을 충족하는 능력만 있으면 되었다면,.. -
유클리드 호제법 (Euclidean-algorithm)
유클리드 호제법 (Euclidean-algorithm)
2023.06.070. 글을 시작하며우리가 문제해결을 하다보면 최대 공약수를 구해야하는 경우가 있습니다. 우선 가장 쉽게 생각해볼 수 있는 것은 초등학교 때 배우는 두 수를 모두 소인수 분해 후 공약수를 찾아 모두 곱하는 방식입니다. 예를 들어 우리가 27과 45의 최대공약수를 구한다고 할 때 보통 이런 그림을 그려서 최대 공약수를 구하곤 합니다.그래서 우리가 두 자연수의 최대 공약수를 구해야하는 문제를 코드로 작성해서 해결해야할 때 가장 먼저 쉽게 떠올리고 접근하게 되는 방식이 바로 위의 방식일 것 입니다. 이를 코드로 다음과 같이 옮겨서 문제해결을 할 수 있지만 이 방식에는 한 가지 문제점이 있습니다 (여기서는 numberA가 numberB보다 크거나 같은 수임을 전제로 합니다).private static int ge.. -
[Google BigQuery] WITH문, 성능에 문제없을까?
[Google BigQuery] WITH문, 성능에 문제없을까?
2023.04.040. 배경통계쿼리를 작성할 때 가독성을 고려하지 않고 작성하다보면 주요 지표들을 계산하는 복잡한 로직과 Table 간의 JOIN, 많은 서브쿼리들이 복잡하게 얽혀 매우 복잡한, 가독성을 사실상 거의 포기한 Query가 나오게 됩니다. 하지만 보통 데이터 분석에서 다루는 로그 성격의 정보를 저장하는 테이블들은 아무리 적절히 정제과정을 거처더라도 row수가 매우 많습니다 (1억건도 많지는 않은 편...). 그렇기 때문에 이렇게 거대한 Table들을 모두 JOIN해서 사용하는 것은 아무리 ON 조건을 적절히 잘 건다고 하더라도 상상 이상의 비용이 발생합니다. Google BigQuery 같이 수천대의 분산환경 컴퓨팅 성능을 활용할 수 있는 막강한 성능을 가진 플렛폼을 사용하더라도 분명 결과를 받기까지 상당히 .. -
[Google BigQuery] 1라인 쿼리에서 변수를 사용하고 싶을 때
[Google BigQuery] 1라인 쿼리에서 변수를 사용하고 싶을 때
2023.04.030. 배경 (문제 상황)데이터 분석 프로젝트를 진행하면서 Google BigQuery로 구성된 DW에 저장된 전체 서비스 로그와 사용자 정보가 저장된 Table로부터 Mart Table을 생성하는 CTAS Query를 작성해야할 일이 있었습니다. 전체 서비스 로그가 하나의 Table로 모여 저장되고 있었기 때문에 내부적으로 이를 저장할 때에는 해당 로그가 어떤 서비스에 대한 로그인지를 식별하기 위한 식별자가 들어갔고, 이 식별자를 알고 있으면 특정 서비스에 대한 로그만을 필터링하여 이를 데이터 분석에 활용할 수 있었습니다. 하지만 통계쿼리의 특성 상 쿼리 길이가 굉장히 길고(수백라인...) 각 서비스들이 가지는 자신 만의 히스토리가 데이터에 스며있기 때문에 이 모든 맥락을 이해하며 데이터 분석에 활용할 ..