분류 전체보기 (73) 썸네일형 리스트형 chapter 4. 아키텍처 (1) 4.1.1 MySQL Engine Architecutre MySQL 서버는 크게 MySQL 엔진가 스토리지 엔진으로 구분할 수 있다 MySQL 엔진은 클라이언트로부터의 접속 및 쿼리 요청을 처리하는 커넥션 핸들러 SQL 파서 및 전처리기, 쿼리의 최적화된 실행을 위한 옵티마이저가 중심을이룬다 4.1.1.1 MySQL 엔진 또한 MySQL은 표준 SQL(ANSI SQL) 문법을 지원하기 때문에 표준 문법에 따라 작성된 쿼리는 다른 DB에도 호환되어 실행될 수 있음 다만 자체 문법을 가지고 있는 DB(Oracle, Postgre) 같은 경우 다를 수 있음 다만 큰틀에서는 같은 의미로 말할 수 있음 4.1.1.2 Stroage 엔진 MySQL 엔진은 요청된 SQL 문장을 분석하거나 최적화 하는 등 DBMS의 .. 거래소별 API 분석 각 거래소 별 캔들 데이터는 무사한가 API 분석 및 보고서 1. Coin API architecture 우리나라 기준에서 캔들 API를 지원하는 거래소 3곳(upbit, bithum, coinone)의 API를 확인해 본 결과 가장 날짜별로 데이터를 획인할 수 있는 부분이 하루 기준으로 데이터를 뽑아 시각화를 하는게 가장 다채롭게 볼 수 있는 부분이었습니다 이 부분에서 거래소마다 차이점을 발견할 수 있었습니다 각 거래소 API 의 코인마다의 하루(1 day) 기준으로 데이터 분석을 진행했으며 데이터 분석을 한 결과 다음과 같은 결과를 내포할 수 있었습니다 candle API는 해당 차트데이터를 API 형식으로 제공해 주는 API입니다 전처리 기준 각 거래소 마다 지원하는 칼럼 이 서로 다르고 API 형식별로 들어오는 값을 보장할 수 없었기.. 코인 모듈 그 첫번째 각 거래소 API 정형화 하기 (1) 거래소 선택 API를 정립을 하기 위해서 현 우리나라에서 제공하는 대한민국 4대 거래소를 선택했다 업비트 빗썸 코빗 코인원 REST와 좀 더 정확하게 실시간 데이터를 받을 수 있는 Websocket를 가져가기로 했다 REST로 받을 수 있는데 이미 응답을 받고 데이터를 넘겨받는 순간 몇 초 뒤 일 수도 있어 좀 더 명확하게 실시간 데이터를 받으려면 끊기지 않는 웹소켓을 얻는 것이 가장 좋다 하지만 나는 혹시 몰라 둘 다 하기로 했다 4대 거래소 정형화의 시작 일단 나는 거래소의 일관된 형태의 코드를 만들어 관리하기 편하게 하고 싶은 욕망이 매우 컸기 때문에 다음과 같은 상속 관계를 만들어 시도하였다 관리하기 편하도록 팩토리 패턴을 사용하였고 market을 생성자를 주어 util에 따로 만들어놓은 매칭 패.. 핀테크 프로젝트를 시작하며 요구사항과 Architecture 정리하기 하게된 계기 나는 개발도 좋아하지만 특히 부동산과 핀테크에 관심이 많다 그 이유는 다음 4가지라고 볼 수 있다 결국 핀테크라는 건 돈의 흐름이 무조건적으로 생기는 필연 조건인데 이 돈의 흐름에서 사람의 심리를 볼 수 있어서 매우 흥미롭다 결국 이 돈이라는것이 현 사회(자본주의)와 강하게 연결고리가 있는 상태에서 자기의 자본을 투자한다는 것부터 사람들은 큰 예민을 느낄 수 있다 (자기가 발전하기 위해 나가는 순간 예민해진다는 것과 동일) 모든 사람은 바보가 아닌 이상 자기가 내 이익을 포기하면서 까지 다른 사람의 이익을 챙겨주지 않는다 그런 사람이 있다면 그건 두 부류의 사람이다 호구 구지 내가 필요 없어서 (이건 착한 사람의 부류이지 않나 싶다) 결국 누군가 돈을 얻으면 누군가는 잃게 된다는 것 이 싸움.. 계약에 의한 디자인 소프트웨어는 사용자가 만들어서 직접 사용하기도 하지만 다른 레이어 나 컴포넌트 에서 호출하는 경우도 있다 이런 경우 이들 간 교류를 어떻게 해야하는지 고민해보자 컴포넌트는 기능을 숨겨 캡슐화 하고 함수를 사용할 클라이언트에게는 API 를 노출해야한다 컴포넌트의 함수, 클래스. 메서드는 특별한 유의사항에 따라 동작해야 하며, 그렇지 않을 경우 코드가 깨지게 된다 반대로 코드를 호출하는 클라이언트는 특정 형태의 응답이나 실패를 기대하고 해당 형태와 다른 응답을 받는 경우 함수 호출에 실패하게 되고 부가적인 결함을 생기는 경우도 있음 물론 API를 디자인할 때 예상되는 입출력과 부작용을 문서화해야함 그러나 문서화가 런타임 시의 소프트웨어의 동작까지 강제할 수는 없다 이렇게 코드가 정상적으로 동작하기 위해 필요.. 객체지향 [전체적으로] 객체지향이란? 웹서비스도 결국 객체로 만들어 졌다. 객체 지향의 특성인 [추상화, 상속, 은닉, 재사용, 인터페이스] 함수도 좋은 프로그래밍이 가능했으나 새로운 시각으로 바라 보기 시작함 결국 이 객체 지향이라는게 현실에 존재하는 사물을 있는 그대로 모델링 하면서 행위와 속성을 정의하고 객체가 중심이 되서 실제 사물이 동작하는 방식임 ---- 속성 (Variable) | 사물 = 객체 (Object) (class로 생성한 객체) | -------- 행위(Method) 이런식으로 해서 좀 더 간단하진 설계가 가능함 세상이 절차지향이였으면 지금 삼국시대도 못왔음 결국 객체라는게 3가자의 요소로 이루어진다는건데 이 3가지는 다음과 같다 객체의 3가지 요소 객체를 만들때는 3가지 요소로 응답이 된다 (만약 그렇.. Part 1 - [Chapter 2] . 데이터 엔지니어링 수명 주기 (2) 2.1.3 데이터 저장 데이터를 저장할 공간이 필요하다, 스토리지 설루션을 선택하는 것은 나머지 데이터 수명주기에서 성공을 거두기 위한 열쇠이면서, 다음과 같은 다양한 이유로 데이터 수명 주기에서 가장 복잡한 단계의 하나다 첫째, 클라우드의 데이터 아키텍처는 종종 여러 스토리지 설루션을 활용함 둘째, 복잡한 변환 쿼리를 지원하는 데이터 스토리지 설류션은 순수하게 스토리지로만 작동하는 경우가 거의 없으며 많은 설루션이 복잡한 쿼리를 지원한다 심지어 객체 스토리지 설루션도 Amazon S3 Select와 같은 강력한 쿼리 기능을 지원할 수 있다 셋째, 저장은 데이터 엔지니어링 수명 주기의 한 단계이지만 변환 및 서비스 제공과 같은 다른 단계에서도 자주 관여한다 둘쨰가 참 흥미로운데 이게 보면 대표적으로 S3.. Chapter 2. 클라이언트에서 데이터 가져오기: 데이터 수집 우리가 다루는 첫 번째 단계인 수집 단계(Collection tier)는 우리의 스트리밍 시스템으로 데이터를 입수하는 지점이다. 수집 단계를 강조한 스트리밍 데이터 아키텍처는 다음 과 같다. 2.1 일반적인 통신 패턴 오늘날, 클라이언트에서 생성되는 데이터를 시스템에 입수하기 위해(또는 수집 단계에서 서버가 직접 데이터를 Pulling 하기 위해) 몇 안되는 프로토콜을 사용한다 만물 인터넷의 등장으로 다양한 통신 패턴들이 존재하겠지만. 다음과 같은 몇 가지 통신 패턴 중 한 가지 패턴을 선택하여 통신하는 것이 일반적이다. 요청/응답 패턴 (Request/response pattern) 발행/구독 패턴 (Publish/subscribe pattern) 단방향 패턴 (One-way pattern) 요청/확인.. 이전 1 2 3 4 5 6 ··· 10 다음
