Hello backEnd

분산 시스템을 위한 유일 ID 생성기 설계 분산 시스템에서 사용될 유일 ID생성기를 설계할 때 'auto_increment 속성이 설정된 관계형 DB의 PK를 쓰면 되지 않을까?' 할 수도 있는데... 분산 환경에서 이 접근법은 통하지 않는다. DB서버 한 대로는 그 요구를 감당할 수 없을뿐 아니라 여러 DB서버를 쓰는 경우에는 지연시간을 낮추기가 무척 힘들 것이기 때문이다. -> Auto increment는 따로 동기화가 되어있지 않으면 각각의 분산 환경에서 동일한 ID가 나타날 수 있다. -> Auto increment 추가적인 단점은 외부에서 해당 시스템의 id를 예측하기 쉽다는 것이다...이는 트래픽의 파악과 SQL Injection에 취약해지기 쉽다는 단점을 낳는다. 1단계 문제 ..

Spring Data JPA를 통한 CRUD방법에 관하여..(feat 변경감지) Spring Data JPA를 사용한 CRUD방법을 구현하면 어떻게 하나? 조회(Read) find나 get을 사용한다. 이 둘의 차이는 여기서 알아보자 저장(Create) save를 사용한다. 이 save에 관해 조금 후에 다시 서술한다. 삭제(Delete) delete를 사용하거나, 실제로 데이터를 삭제하고 싶지 않으면 soft delete를 하면 된다. 이제 변경(Update)를 한다면? Update방식 위에서 데이터 저장에 사용된 save에 대해 먼저 알아보자 얘 코드를 살펴보면 /* * (non-Javadoc) * @see org.springframework.data.repository.CrudRepository#s..

Java에서 기본 타입과 참조 타입의 차이 기본 타입(Primitive Type)이란? == 원시 타입 우리가 실제로 데이터 값을 저장할 때에 사용하는 값이다. 정수형 int, long, short, byte ... 실수형 float, double 문자형 char 논리형 boolean 참조 타입(Reference Type)이란? 이름에서 알 수 있듯, 객체의 번지를 참조하는 타입이다. 즉 객체의 주소를 저장하고, 이를 참조하여 사용하는 타입이라 할 수 있다. String, Long, Integer ... 배열, Enum, 클래스, 인터페이스 등을 사용해서 선언한 변수는 메모리 값을 가지게 되는데, 이런 애들을 참조 타입이라 한다. 둘 간의 간단한 차이 저장 장소의 차이 기본 타입은 스택 영역에, 참조 타..

Spring Data JPA에서 ID를 통하여 어떤 엔티티를 조회하고 싶을 때, 우리는 getById나 findById를 사용한다. 둘 간에 어떤 차이가 있을까?? getById @Override public T getById(ID id) { Assert.notNull(id, ID_MUST_NOT_BE_NULL); return em.getReference(getDomainClass(), id); } getById의 내부를 살펴보면 이렇게 나온다. 이 getById는 em.getReferecnce를 이용해서 엔티티를 조회..하는데, 사실 이거는 엔티티가 아니라 프록시를 반환한다는 것이다. 즉, getById를 통해 바로 DB에 검색하는게 아니라, 이를 실제로 사용할 때에 DB에 접근한다는 것이다. 한마디로..

문제 설명 1. 3XN 크기의 벽을 2X1, 1X2 타일로 채우는 경우의 수를 구해보자! 2. 문제 길이가 겁나 짧다... 그냥 이게 다임 풀이 과정 1. DP문제이다. 참 이 문제는...고민할 내용은 정말정말정말정말 많지만 코드로 구현하면 뭐가 이렇게 짧지? 하는 기분을 준다. 2. DP를 푸는 방법은 개인적으로 처음부터 무식하게 들이박는 수밖에 없다고 생각이 든다. 3X1의 타일의 경우는 못구한다. 3X2의 타일의 경우는 얘네 셋이 나올 것이다. 3X3의 타일의 경우는 못구한다. 3X4의 타일의 경우는 저 위에있는 3X2 타일에다가 추가로 3X2타일을 붙이면 구할 수 있을 것이다. 그런데... 그 방식 말고도 다른 방식으로 타일을 채울 수도 있을 것이다 예를 들어 이런 애들이 추가로 나타나게 될 것이..

키-값 저장소 설계 key-value 저장소는 noSql중 하나이다. 이 저장소에 저장되는 값은 고유 식별자를 키로 가져야 한다. 키와 값 사이의 이런 연결 관계를 키-값 쌍(pair)이라고 한다. 키-값 쌍에서의 키는 유일해야 하며 해당 키에 매달린 값은 키를 통해서만 접근 가능하다. 키는 텍스트일 수도, 해시 값일수도 있다. 당연히 키는 짧을수록 좋을 것이다(성능상) 값은 무엇이 오든 크게 상관 없다. 키-값 저장소를 한번 설계해 본다. 문제 이해 및 설계 범위 확정 완벽한 설계는 없다. 읽기, 쓰기 그리고 메모리 사용량 사이에 어떤 균형을 찾고, 데이터의 일관성과 가용성 사이에서 타협적 결정을 내린 설계를 만들었다면 쓸만한 답안일 것이다. 다음 특성을 갖는 키-값 저장소를 설계해 보자. 키-값 쌍의..

수평적 규모 확장을 의해 요청 또는 데이터를 서버에 균등하게 나누는 것이 중요하다. 요청 또는 데이터를 균등하기 나누기 위해 보편적으로 사용하는 기술이 안정 해시이다. 이 해시 기술이 풀려고 하는 문제부터 좀 더 자세히 알아본다. 해시 키 재배치(rehash) 문제 N개의 캐시 서버가 있다고 할 때, 이 부하를 균등하게 나누는 보편적 방법이 해시 함수를 사용하는 것이다. serverIndex = hash(key)%N (N은 서버의 개수)예를 들어 4개의 서버를 사용한다고 할 때 주어진 각각의 키에 대해 해시 값과 서버 인덱스를 계산하면 이렇게 나온다. 특정 키가 보관된 서버를 알아내기 위해 나머지연산을 f(key)A%4와 같이 적용했다. 예를 들어 hash(key0)%4=1 이면 클라이언트는 캐시에 보관..

study004 tags: Tag(가상 면접 사례로 배우는 대규모 시스템 설계 기초) 처리율 제한 장치의 설계 처리율 제한 장치 네트워크에서 처리율 제한 장치란 클라이언트 또는 서비스가 보내는 트래픽의 처리율을 제어하기 위한 장치이다. HTTP를 예로 들면 이 장치는 특정 기간 내에 전송되는 클라리언트의 요청 횟수를 제한한다. API요청 횟수가 제한 장치에 정의된 임계치(threshold)를 넘어서면 추가로 도달한 모든 호출은 처리가 중단된다. 예를 들면 사용자는 초당 2회 이상 새 글을 올릴 수 없다. 같은 IP주소로는 하루에 10개 이상의 계정을 생성할 수 없다. 같은 디바이스로는 주당 5회 이상 리워드를 요청할 수 없다. 이런 처리율 제한 장치를 설계하는 방법에 관해 알아본다.. 그리고 그 전에 이..

시스템 설계 면접 공략법 일단 시스템 설계 면접은 면접에서 실제 서버에서 쓰이는 만큼 복잡하고 어려운 설계를 요구하지 않는다. 설계 기술을 시연하고, 그 과정에서 결정들에 대한 방어 능력을 보이고, 면접관의 피드백을 건설적인 방법으로 처리할 자질이 있음을 보이는 자리이다. 따라서 해당 시스템 설계 면접에서 면접관이 찾고자 하는 것은 기술적 측면의 평가 지원자가 협력에 적합한 사람인지 평가 압박이 심한 상황도 잘 헤쳐나갈 자질이 있는지, 모호한 문제를 건설적으로 해결할 능력이 있는지 평가 좋은 질문을 던질 능력이 있는지 평가 이라고 한다. 또 한가지 중요한 것은 설계의 순수성(purity)에 집착한 나머지 타협적 결정(tradeoff)를 도외시하고 과도한 엔지니어링(over-engineering)을 하게 ..

DB의 삭제 구현 방법은 두가지가 있다. Soft Delete 데이터를 실제로 삭제하지 않고, 삭제 flag를 변경하는 방법이다. Hard Delete 실제로 데이터를 삭제하는 방법이다. 실제로 서비스를 구현할 때에는 Soft Delete를 자주 사용한다. 하지만 Spring Data JPA에서 이 Soft Delete를 구현할 때에는 주의해야 할 점이 다수 있다. 만약에 한꺼번에 많은 데이터를 삭제하는 경우가 생긴다면 어떨까?? 이러한 Bulk연산에서 Soft Delete를 사용할 때에 여러 번의 쿼링이 진행되게 될 것이다. 이를 해결하기 위해서 @SQLDelete어노테이션과 JPA에서 제공하는 deleteAllInBatch를 사용할 수 있다. @SQLDelete JPA에서 기본으로 삭제는 Hard D..