stack — 최근 글

개념적 모델링 : 추상화 과정을 통해 중요한 데이터를 추출해 나열한다. 논리적 모델링 : 나열한 데이터의 구조를 결정하고 표시한다. 이 과정을 굳이 분리하지 않고 데이터 모델링으로 이야기한다. 데이터 모델은 데이터 모델리의 결과물을 표현하는 도구. 개념적 데이터 모델 : 사람이 이해할 수 있는 모델링을 통해 개념적 구조로 표현 논리적 데이터 모델 : 데이터베이스의 논리적 구조로 표현 entity 개념 = 테이블의 record 개세는 사람과 사물처럼 물리적으로 존재하는 것만을 의미하지 않는다. 개체는 다른 개체와 구별되는 이름을 가지

문제를 쪼개서 각각 따로 처리한 다음 결과를 합쳐나가는 방법. 배열의 길이가 1이면 정렬이 끝난 것이다. 아니라면 배열을 반으로 나눠서 왼쪽과 오른쪽을 따로 정렬한다. 둘 다 정렬이 끝나면 merge라는 작업을 통해 배열을 합쳐준다. 이미 sorted인 2개의 서브 배열 이 2개의 서브 배열의 merge된, 병합된 하나의 결과를 담을 배열 와 같이 3개의 배열로 이루어져 있다. 위의 배열과 아래의 배열이 합쳐지는데 sorted를 읽지 않도록 합치는 것이다. 배열이 3개인만큼 포인터 역시 3개다. 윗쪽 배열을 A 아래쪽 배열을 B라고

sorted된 배열에 원소를 추가할때 sorted가 깨지지 않게 원소의 위치를 찾아서 넣는 알고리즘이 insertion sort다. 각 숫자를 적절한 위치에 삽입하는 정렬 기법이다. 들어갈 위치를 선택하는데 N번, 선택하는 횟수로 N번이지만 선택정렬보다 약간 빠르다. 선택정렬과 똑같이 O(N^2) 의 시간 복잡도를 가진다. 가장 앞 인덱스의 원소가 정렬되어있다고 가정했을때 바로 뒷부분의 인덱스부터 올바른 위치로 insertion하는 알고리즘이다. temp변수를 두고 원소를 하나씩 swap하는 방법은 비용이 크다. 그래서 temp변수

RDB는 오랜시간 대표적인 DBMS의 자리를 지켜왔다. 그러나 소셜서비스의 규모가 커짐에 따라 비정형 데이터를 이용하고자 하는 빅데이터 개념과 인프라 에코시스템도 클라우드 컴퓨팅의 바람이 불어오면서 기존의 RDB가 가진 단점들이 부각되기 시작했다. RDB를 유지하면서 스케일업 하는것은 한계가 있기 때문이다. 시대적 흐름이 NoSQL의 등장을 이끌었다. RDB의 특징인 ACID 일부를 포기 하고 스키마를 없앴다. 이로인해 비정형 데이터를 신속하게 저장하고 처리하는데 적합했다. 정합성을 포기하며 분산 처리로 인해 뛰어난 확장성 또한 장

Vertex를 연결하는 edge에 순서가 없는 pair로 표현되는 edge들로 이루어져있다. {v1,v2}를 edge라고 표현한다. 예를 들어 v1,v2,v3,v4,v5,v6,v7,v8,v9의 vertex가 있을 때 {v1,v2},{v3,v5},{v4,v7},{v4,v7}의 edge가 있으면 4개의 edge가 있다고 표현한다. 방향이 없기 때문에 v1에서 v2로 가는 edge, v2에서 v1로 가는 edge모두 있다고 본다. 자기 자신에서 자기 자신으로 가는 edge는 없다. V개의 vertext가 있는 방향이 없는 그래프에서 최대

자작 스토리지를 만들어 2016년부터 지금까지 사고 없이 잘 사용하고 있다. 2010년 초반에 집집마다 NAS를 들여야 한다는 광풍이 한차례 지나가고 뒤늦게 스토리지를 장만한 것이다. 땡놀로땡이나 땡냅 같은 벤더들이 개인 및 소규모 업장을 위한 NAS 박스를 많이 만들고 있다. 그러나 RAID나 데이터 저장의 이해 부족으로 적지 않은 고통을 유저들이 떠안고 있다고 생각한다. 용량을 위해 RAID0 (스프라이팅) 볼륨을 서슴없이 만든다던가, 아무생각없이 캐시를 걸었다가 박살이 나는 사례를 여럿 봤기 때문이다. 왜 벤더 박스를 쓰지 않

구현체 없이 인터페이스만으로 리포지토리에 커밋이 가능한 코드를 만들 수 있다. 반복적으로 개발한 CRUD 기능도 스프링 데이터 JPA가 모두 제공한다. RDB에서 스프링 데이터 JPA는 아주 좋은 기능이다. 이외의 인터페이스 선언이나 구현체는 필요없다. 인터페이스 이름에 규칙이 있다. (JPQL) 예를들어 findByNameAndId 라고 하면 & 연산자를 넣을 수 있다. 간단한 요구사항은 인터페이스 이름만으로 개발이 끝난다. 페이징 기능을 자체적으로 제공한다. 의존주입도 Repository 의존만 받아오면 된다. 스프링 데이터 J

JPA → 인터페이스 (자바 표준) hibernate → 구현체 (여러 벤더들이 있음) 쿼리도 JPA가 직접 만들어서 실행해준다. 객체를 메모리에 넣듯 DB에 넣을 수 있게 해준다. SQL과 데이터 중심의 설계에서 객체 중심의 설계로 패러다임을 전환할 수 있다. build.gradle application.properties spring.jpa.show-sql: JPA가 날리는 쿼리를 볼 수 있다. spring.jpa.hibernate.ddl-auto: 테이블을 자동으로 만들어주는 기능이다. (none/create) @Id : 인식