MySQL TIP

MySQL은 여러 종류의 RDB 중에서 개발자가 접근성도 높고, 레퍼런스도 많은 DB이다. 글쓴이도 가벼운 게시판류 개발부터 데이터 분석 플랫폼까지 다양한 유형의 소프트웨어 개발에 MySQL을 사용해 왔다. 요즘은 클라우드 플랫폼에서 PAAS 형태로 서비스하고 있어 DB 인프라 지식이 많이 필요하지 않는 시점이지만 혹시나 나중에 글쓴이가 필요할까 싶어 정리 차원에서 이 글을 작성한다.

; 차후 관련 TIP을 생각나는데로 계속 보강해 나갈 예정이다.

Web Proxy(Squid) Server 구축 및 사용 방법(Python Crawler)

우리는 인터넷 환경에서 다양한 경우에 Proxy를 사용한다. 보안상의 이유이거나 성능적 이슈에서나 아니면 약간의 불법적인 이유에서 우리는 Proxy를 사용한다.
오늘 이야기할 부분은 크롤링 과정에서 서버 아이피가 차단되었을 때 Proxy 서버를 구성하여 우회하는 방법을 이야기하고자 한다. 약간 불법적인 면이 있으니 사용 유무는 사용자가 알아서 판단해야 한다. 다만 개인적인 목적으로 자동화 툴을 사용하거나, 약간?의 정보 수집 목적으로 사용하는 경우 개인적 생각에 문제가 없지 않을까 한다.

JPA Multiple DataSource

업무를 하다보면 마이크로 서비스도 구축하게 되고, 다중 데이터베이스도 처리해야하는 경우가 생긴다.

일반적으로 하나의 서비스에서 다중 데이터베이스에 접속하는 일이 없겠지만, 가끔 불가피하게 이런일이 생기게 된다.

그래서 시작된 삽질과 도출된 결과를 공유하고자 한다.

AWS RDS Aurora MySQL 호환은 MySQL이 아니다

AWS RDS에는 Aurora라는 서비스가 있다. 엔진을 MySQL 혹은 PostgresSQL로으로 지정해서 사용할 수 있고, 해당 RDB와 호환된다고 나와있다. 그리고 웹페이지에서 RDB 클러스트를 구성할 수 있는 편리한 부가 기능을 제공한다.

Vert.x 프레임워크(3.x) 이벤트 핸들러 처리(2)

이전 글에서 Vert.x 이벤트 핸들러를 처리를 위해서 제공하는 인터페이스에 사용 예를 간단히 알아보았다. 하지만 해당 인터페이스의 도움이 있다고 해도 순차적으로 처리되어야 하는 비동기 작업은 어쩔 수 없이 “Callback Hell”은 벗어 날 수 없다.
이번 글에서는 “Callback Hell”의 예를 살펴보고 Vert.x 프레임워크에서 제시하는 해결책을 알아보고자 한다.

  • Vert.x Reactive Programming을 제외한 글이다.

JPA SPECIFICATION

jpa CrudRepository 사용 시 조건 검색으로 인해 난감한 상황이 생겼다.
예를 들어 사용자 이름, 사용자 이름과 주소, 사용자 이름과 주소와 이메일과 같은 조건으로 검색이 필요 시 조건에 따라 method를 생성해 주어야 한다는 것이었다.

Vert.x 프레임워크(3.X) 이벤트 핸들러 처리(1),

Vert.x는 Java 진영에 고성능 서버 프레임워크 중 하나이다. 그리고 Vert.x 프레임워크는 Event Driven 프로그래밍 모델을 사용하고 non blocking인 것을 강조한다. 이는 개발자가 특정 이벤트가 발생했을때 호출될 이벤트 핸들러를 수 없의 정의하고 이것들이 블럭킹 없이 비동기로 동작한다는 예상할 수 있다. 이렇게 Vert.x는 Event Driven/Non blocking 아키텍처 위에서 고성능 비동기 서버 프로그래밍을 할 수 있다.
Vert.x는 비동기 프로그래밍을 Call-Back 패턴으로 구현한다. Vert.x에서 이 Call-Back 패턴을 어떤 식으로 구현해서 사용하는지 알아보자.(Vert.x는 Reactive Programming도 지원함)

JPA CRITERIA QUERY

jpa 사용 시 join 및 동적 쿼리에 따른 문제에 대한 해결 내용을 공유하고자 한다.
시작은 hibernate namig 전략을 이용해 entity와 repository를 맵핑하여 쿼리를 생성하는 방식을 사용하였다.
이는 적응하면 굉장히 편한 쿼리 방식이다. 다만 많은 join과 세밀한 조회가 필요 시 원하는 결과를 도출하기 어려울 수 있다.
일반적으로 알려진 문게가 n+1 쿼리 동작이다.
Lazy Loding으로 인해 join 테이블의 쿼리가 n번 요청되는 문제이다.
위 문제의 경우 검색해 보면 많은 해결 방식이 나와있다.

ORM. 깊이 없이 알아보기.

초기 JAVA JDBC에서 DB CRUD 작업이나 기타 DB CRUD 작업을 해본 개발자라는 그 번 거로 웁과 지루한 작업에 대한 경험이 한 번씩은 있을 것이다. 쿼리에 대입할 값을 한 칸씩 밀어 써서 전혀 다른 값이 들어갔다던가, 쿼리 결과를 객체에 잘못 넣어 다른 결과가 출력된다던지 등등 단순 실수로 디버깅 시간이 길어지는 경우가 많았다. 이런 번거로움과 실수를 해결을 위해서 나온 것이 ORM이다. ORM에 대해서 간단히 알아보자.