이 글은 데이터 중심 애플리케이션 설계 서적(마틴 클레프만 저)를 읽고 정리한 내용입니다. 데이터 중심 애플리케이션 설계 : 네이버 도서 네이버 도서 상세정보를 제공합니다. search.shopping.naver.com 데이터 복제는 다음과 같은 이유로 필요하다. 1. 지리적으로 가깝게 복제본을 위치시켜 네트워크 지연시간을 줄인다. 2. 장애에 대처한다. 3. 읽기 질의를 제공하는 장비수를 확장해 처리량을 늘린다. 데이터 량이 작거나 복제 대상의 데이터가 앞으로도 변경되지 않는다면, 복제는 너무나 쉽다. 하지만 거대한 데이터이고 변경이 일어난다면? 최근은 데이터 량이 급증하면서 단일 노드로 구성된 데이터베이스에서 분산 데이터베이스로 넘어가고 있다. 노드 간 변경을 복제하기 위한 분산 데이터베이스의 세 가..

이 글은 데이터 중심 애플리케이션 설계 서적(마틴 클레프만 저)를 읽고 정리한 내용입니다. 데이터 중심 애플리케이션 설계 : 네이버 도서 네이버 도서 상세정보를 제공합니다. search.shopping.naver.com 데이터베이스의 트레이드오프 데이터베이스가 하는 일을 단순히 하면 데이터 저장과 그 데이터를 요청 시 반환하는 일이다. 특정 workload 유형에 좋은 성능이 나게끔 조정하려면 저장소 엔진의 대략적인 이해가 필요하다. 특히 트랜잭션 workload 최적화와 분석 workload최적화 엔진은 차이가 크다. 예를 들어 동영상 데이터에서의 재생 횟수와 같이, 키당 쓰기 수가 많다면 쓰기에 느린 설계는 좋지 않을 것이다. 일반적으로 파일 추가 작업은 매우 효율적이라서, 데이터베이스들의 log들은..

이 글은 데이터 중심 애플리케이션 설계 서적(마틴 클레프만 저)를 읽고 정리한 내용입니다. 데이터 웨어하우스 대기업에서는 왜 데이터 웨어하우스를 운영할까? 그 질문에 답하기 위해서는 OLTP와 OLAP 데이터 베이스 모델의 설계 차이를 알아야 한다. 기본적으로 commercial transacation 처리에는 RDBS가 적합하다. 클라이언트가 낮은 지연시간으로 빠르고 읽고 쓰기를 가능하게 해야 한다. 이러한 온라인 트랜잭션 처리를 OLTP(Online Transcation Processing)라고 한다. 하지만 최근에 많이 거론되는 데이터 분석에는 OLTP는 적합하지 않다. 데이터 분석은 커머셜 트랜잭션과는 다르게, 수많은 데이터를 읽어 통계를 제공하는 방식이다. 이러한 사용 패턴은 온라인 OLAP(O..

내 언어의 한계는 내 세계의 한계를 의미한다. -루티비히 비트겐슈타인- 데이터 모델은 해결하려는 문제를 어떻게 생각하는 지에 대해 영향을 미친다. 관계형 데이터 베이스 (SQL)모델과 문서형 데이터베이스 (NOSQL)모델 중에 어떤 것이 자신의 애플리케이션과 적합할까? 또는 더 적합한 모델이 있을까? 이번 게시글에선는 데이터 중심 애플리케이션 설계 서적(마틴 클레프만 저)을 읽으면서 알게된 모델 선택방법에 대해 정리해보려한다. 관계형 (SQL)모델 관계형 모델은 테이블간에 관계를 가진다. 이는 1960~70년대에 비즈니스 데이터 처리와 함께 발전했다. 관계형 데이터 베이스는 항공 예약이나 재고 처리, 은행 거래와 같은 트랜젝션 처리처럼 일상적으로 수행되는 일들에 적합했고, 현재는 관계형 데이터베이스는 비..

*본 게시물은 [클린 코드] 와 [실용주의 프로그래머] 서적에서 배운 것 들을 잘 활용하기 위해 정리한 글입니다. *문제시 삭제하겠습니다. 자료 추상화 조회(get)와 설정(set) 함수를 제공한다면 클래스의 구현은 전혀 감춰지지 않는다. 인터페이스나 조회, 설정 함수만으로는 추상화가 이뤄지지 않는다. 자료와 객체의 비대칭 자료 구조는 자료를 그대로 공개하며 별다른 함수를 제공하지 않는다. 반면에 객체는 추상화로 자료를 숨기고, 자료를 다루는 함수만 공개한다. 물론 객체만이 장점을 가지는 건 아니다. 서로는 상반되는 장점과 단점을 가진다. 절차 지향 코드 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 public class Square{ public Po..

*본 게시물은 [클린 코드] 서적에서 배운 것 들을 잘 활용하기 위해 해당 서적을 정리한 글입니다. *문제시 삭제하겠습니다. 클래스의 체계 변수 목록이 가장 먼저 나오며, 추상화 단계의 순서대로 작성한다. static과 public 상수 다음으로 정적 비공개 변수, 마지막으로 비공개 변수 순서를 지키자. (공개 변수는 사용할 일이 거의 없어야 한다.) 비공개(private) 함수는 자신을 호출하는 공개(public)의 직후에 작성하자. 캡슐화 캡슐화를 해제하는 결정은 언제나 최후의 수단이어야 한다. 함수를 만드는 규칙은 첫번째도 작게, 두 번째는 더 작게이다. 이는 클래스에서도 동일하다. 함수는 실질적인 라인수로 측정을 할 수 있었다면, 클래스에는 다음과 같은 측도가 있다. 단일 책임 원칙 (Single..

*본 게시물은 [클린 코드] 서적에서 배운 것 들을 잘 활용하기 위해 해당 서적을 정리한 글입니다. *문제시 삭제하겠습니다. 소프트웨어에서 이름은 어디에나 쓰인다. 우리가 코드를 짤때는 대부분의 것들을 직접 이름을 붙인다. 전에 소개했듯이 우리는 코드를 작성할 때 대부분의 시간을 작성된 코드를 다시 읽느라 시간을 보낸다고 했다. 따라서 알맞은 이름을 지어주어야 코드를 읽는 자신과 독자의 시간을 아껴줄 수 있다. 물론 좋은 이름을 짓기에는 오랜 시간이 걸리지만, 책에서는 오히려 알기 쉬운 이름으로 절약할 수 있는 시간이 더 많다고 한다. 좋은 이름을 짓는 규칙을 아래에 소개한다. 의도를 분명히 밝혀라 주석이 필요하다면 의도를 분명히 들어내지 못한 것 의도가 분명한 이름은 코드의 이해와 변경에 용이한다. 단..

클린 코드를 읽게 된 계기 알고리즘 문제 풀이를 공부하면서 느끼게 된 점이 있다. 혼자 코드를 짜고 문제를 맞히게 되면 자신의 코드를 다시 되새기며 개선점을 찾으려는 노력을 기울이기 힘들다는 것이다. 어려운 문제를 풀어보아도 결국 다시 자신이 푼 방법을 복습하지 않으면 얼마 지나지 않아 까먹게 되는 것 같다. 알고리즘 문제 풀이에서 실력 향상에 가장 중요한 것은 스스로 문제를 끝까지 잡고 늘어지는 것이 아니라, 다른 사람의 코드를 참고하더라도 자신의 것으로 흡수하는 것이라고 많이 들었다. 즉, 문제를 맞혔든 틀렸든 간에 자신의 코드를 리뷰하는 습관을 들여야 하는 것이다. 이러한 습관을 들이는 데에는 자신의 블로그에 꾸준히 문제 풀이를 올리는 것만큼 좋은 것은 없다고 생각해 블로그를 시작하게 되었다. 블로..