IT용어 정리

●End to End(E2E Service):

-콘텐츠의 제작에서부터 유통 및 재생까지 전 과정을 지원하는 솔루션을 의미하는 단어입니다. ​한마디로 제작자들의 제작 편의를 위해 탄생한 기술

 

●프로토타입(prototype):

-원래의 형태 또는 전형적인 예, 기초 또는 표준이다.

-시제품이 나오기 전의 제품의 원형으로 개발검증과 양산 검증을 거쳐야 시제품이 될 수 있다.

-프로토타입은 '정보시스템의 미완성 버전 또는 중요한 기능들이 포함되어 있는 시스템의 초기모델'이다.

-이 프로토타입은 사용자의 모든 요구사항이 정확하게 반영할 때까지 계속해서 개선/보완 된다.

-실제로 많은 애플리케이션들이 지속적인 프로토타입의 확장과 보강을 통해 최종 설계가 승인된다.

 

●파싱(parsing):

-parsing은 구문 분석이라고 합니다.

-문장이 이루고 있는 구성 성분을 분해하고 분해된 성분의 위계 관계를 분석하여 구조를 결정하는 것입니다.

-즉 데이터를 분해 분석하여 원하는 형태로 조립하고 다시 빼내는 프로그램을 말합니다.

-웹상에서 주어진 정보를 내가 원하는 형태로 가공하여 서버에서 불러들이는 것입니다.

-이러한 parsing 기법은 XML parsing과 JSON parsing이 있습니다.

 

●리팩토링(refactoring):

-외부 동작을 바꾸지 않으면서 내부 구조를 개선하는 방법입니다.

-코드가 작성된 후에 디자인을 개선하는 작업입니다.

 

●스파게티 코드(spaghetti code):

-컴퓨터 프로그램의 소스코드가 복잡하게 얽힌 모습을 스파게티의 면발에 비유한 표현이다.

-스파게티 코드는 작동은 정상적으로 하지만, 사람이 코드를 읽으면서 그 코드의 작동을 파악하기는 어렵다.

-스파게티 코드는 GOTO문을 지나치게 많이 사용하거나, 프로그램을 구조적으로 만들지 않는 경우에 만들어지기 쉽다.

 

●ETL(Extract, Transform, Load):

-추출,변환,적재 → 저장된 데이터를 변형하여(요구사항에 맞게) 다른 곳으로 이동하는 것.

-추출: SELECT문을 통해 데이터를 가져오는 것.(년,월,일,시,분,초)

-변환: 요구되는 형태로 바꾸는 것.(년월일/시분초 의 형태로바꿈)

-적재: 변경된 데이터를 새로운 테이블에 적재.

 

●샤딩(sharding):

-관계형 데이터베이스에서 대량의 데이터를 처리하기 위해 데이터를 파티셔닝(분할)하는 기술.

-DBMS레벨에서 데이터를 나누는 것이 아니고, 데이터베이스 자체를 분할하는 방식.

1.vertical partitioning(수직적 분할)-테이블별로 서버를 분할하는 방식.

2.range based partitioning(범위 기반 분할)-하나의 테이블이 점점 커질 경우 서버를 분리하는 방식

3.key or hash based partitioning(키,해쉬 기반 분할)-엔티티를 해쉬함수에 넣어서 나오는 값을 이용해서 서버를 정하는 방식

4.directory based partitioning-(디렉토리 기반 분할)-파티셔닝 메카니즘을 제공하는 추상화된 서비를 만듬

 

●HTTP(Hyper Text Transfer Protocol):

-HTTP는 웹상에서 클라이언트와 서버 간에 요청/응답으로 데이터를 주고 받을 수 있는 프로토콜입니다.

-클라이언트가 HTTP 프로토콜을 통해 서버에게 요청을 보내면 서버는 요청에 맞는 응답을 클라이언트에게 전송합니다. -이 때, HTTP 요청에 포함되는 HTTP 메소드는 서버가 요청을 수행하기 위해 해야할 행동을 표시하는 용도로 사용합니다

 

●GET

-서버로부터 정보를 조회하기 위해 설계된 메소드

-GET은 요청을 전송할 때 필요한 데이터를 Body에 담지 않고, 쿼리스트링을 통해 전송합니다. URL의 끝에 ?와 함께 이름과 값으로 쌍을 이루는 요청 파라미터를 쿼리스트링이라고 부릅니다. 만약, 요청 파라미터가 여러 개이면 &로 연결합니다. 쿼리스트링을 사용하게 되면 URL에 조회 조건을 표시하기 때문에 특정 페이지를 링크하거나 북마크할 수 있습니다.

여기서 요청 파라미터명은 name1, name2이고, 각각의 파라미터는 value1, value2라는 값으로 서버에 요청을 보내게 됩니다.

 

●POST

-리소스를 생성/변경하기 위해 설계

-GET과 달리 전송해야될 데이터를 HTTP 메세지의 Body에 담아서 전송

-HTTP 메세지의 Body는 길이의 제한없이 데이터를 전송할 수 있습니다. 그래서 POST 요청은 GET과 달리 대용량 데이터를 전송할 수 있습니다. 이처럼 POST는 데이터가 Body로 전송되고 내용이 눈에 보이지 않아 GET보다 보안적인 면에서 안전하다고 생각할 수 있지만, POST 요청도 크롬 개발자 도구, Fiddler와 같은 툴로 요청 내용을 확인할 수 있기 때문에 민감한 데이터의 경우에는 반드시 암호화해 전송해야 합니다.

그리고 POST로 요청을 보낼 때는 요청 헤더의 Content-Type에 요청 데이터의 타입을 표시해야 합니다. 데이터 타입을 표시하지 않으면 서버는 내용이나 URL에 포함된 리소스의 확장자명 등으로 데이터 타입을 유추합니다. 만약, 알 수 없는 경우에는 application/octet-stream로 요청을 처리합니다.

 

●GET 과 POST의 차이

-GET은 Idempotent, POST는 Non-idempotent하게 설계되었습니다.
-Idempotent(멱등)은 수학적 개념으로 다음과 같이 나타낼 수 있습니다.

수학이나 전산학에서 연산의 한 성질을 나타내는 것으로, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질

즉, 멱등이라는 것은 동일한 연산을 여러 번 수행하더라도 동일한 결과가 나타나야 합니다.
여기서 GET이 Idempotent하도록 설계되었다는 것은 GET으로 서버에게 동일한 요청을 여러 번 전송하더라도 동일한 응답이 돌아와야 한다는 것을 의미합니다. 이에 따라 GET은 설계원칙에 따라 서버의 데이터나 상태를 변경시키지 않아야 Idempotent하기 때문에 주로 조회를 할 때에 사용해야합니다. 예를 들어, 브라우저에서 웹페이지를 열어보거나 게시글을 읽는 등 조회를 하는 행위는 GET으로 요청하게 됩니다.

반대로 POST는 Non-idempotent하기 때문에 서버에게 동일한 요청을 여러 번 전송해도 응답은 항상 다를 수 있습니다. 이에 따라 POST는 서버의 상태나 데이터를 변경시킬 때 사용됩니다. 게시글을 쓰면 서버에 게시글이 저장이 되고, 게시글을 삭제하면 해당 데이터가 없어지는 등 POST로 요청을 하게 되면 서버의 무언가는 변경되도록 사용됩니다. 이처럼 POST는 생성, 수정, 삭제에 사용할 수 있지만, 생성에는 POST, 수정은 PUT 또는 PATCH, 삭제는 DELETE가 더 용도에 맞는 메소드라고 할 수 있습니다.

마지막으로 웹페이지를 조회할 때, 링크를 통해 특정 페이지로 바로 이동하려면 해당 링크와 관련된 정보가 필요한데 POST는 요청 데이터가 Body에 담겨 있기 때문에 링크 정보를 가져올 수 없습니다. 반면, GET은 URL에 요청 파라미터를 가지고 있기 때문에 링크를 걸 때, URL에 파라미터를 사용해 더 디테일하게 페이지를 링크할 수 있습니다.

출처- https://hongsii.github.io/2017/08/02/what-is-the-difference-get-and-post/

 

●preparedstatement(pstmt 객체)

-statement를 상속받는 인터페이스로 SQL구문을 실행시키는 기능을 갖는 객체

-PreCompiled된 SQL문을 표현 즉, statement객체는 실행시 SQL명령어를 지정하여 여러 SQL구문을 하나의 statement 객체로 수행이 가능하다.(재사용 가능)

 

-preparedStatement는 객체 생성시에 지정된 SQL명령만을 실행할 수 있다.(다른 SQL문은 실행 못함)(재사용못함)

-동일한 SQL구문을 반복 실행한다면 preparedStatement가 성능면에서 빠름

-SQL문에서 변수가 들어갈 자리는 '?'로 표시한다. 실행시에 ?에 대응되는 값을 지정할 때 setString(int parameterIndex,String X)이나
setInt(int parameterIndex,int x)와 같이 setXXX메소드를 통해 설정한다.

-그리고 SQL문에서 Like키워드를 사용할 때에는 PreparedStatement를 사용할 수 없다.

-connection 객체의 prepareStatement(String query)를 통해 생성된다.

-preparedStatement객체를 생성할 때 SQL문이 인자로 주어진다.

-SQL문에 매개변수를 사용하고, 실행전에 값을 지정할 수 있다.

-SQL문을 실행할 때 execute(), executeQuery()또는 executeupdate()를 사용한다.

-preparedStatement가 제공하는 메소드는 Statement가 제공하는 메소드와 거의 같다.

 

●데이터 파이프라인(data pipeline):

데이터 파이프라인 : 효율을 위한 작업

데이터 파이프라인의 시작은 왜, 어디에서, 어떻게 데이터를 수집할 것인가에서 부터 시작한다.

데이터 파이프라인을 구축하기 위해서는 여러 소프트웨어적인 수동 작업들을 제거해야하며 Data가 각 지점을 순조롭게 흐르도록(flow) 만들어야 한다. Data의 추출(extracting), 변경(transforming), 결합(combining), 검증(validating) 그리고 적재(loading)하는 과정들을 자동화 하는 것이다. 또한 여러 데이터 스트림을 한번에 처리해야 한다. 이 모든 과정은 오늘날 data-driven enterprise에서 필수적이다.

 

데이터파이프라인은 모든 종류의 스키마의 데이터를 수용해야한다. 입수하고자 하는 파일이 static source든 real time source이든 데이터파이프라인에서는 해당 파일의 데이터는 작은 단위(chnk)로 들어와서 병렬로 처리된다.

 

데이터 파이프라인과 ETL의 차이는?

아마 이 글을 보는 독자는 ETL이라는 단어를 들어봤을 것이다. ETL은 추출(Extract), 변환(Transform), 적재(Load)의 줄임이다. ETL시스템은 하나의 시스템에서 data를 추출하고, data를 변환하여 database나 data warehouse에 적재한다. 레거시 ETL 파이프라인은 보통 배치로 작동하고 큰 덩어리의 data를 특정 시간에 한 공간에 저장하는 작업을 한다. 예를 새벽 12:30에 시스템 트래픽이 낮아질 때 배치가 돌아서 데이터를 모아 적재하는 작업이 있을 수 있다.

 

반면에, 데이터 파이프라인은 ETL을 서브셋으로 포함하는 광범위한 용어다. 데이터를 한 시스템에서 또다른 시스템으로 옮기는 작업을 뜻한다. 해당 데이터는 transform되는 경우도 있고 안하는 경우도 있다. 또한 실시간성으로 처리하는 것도 있고 배치성으로 처리할수도 있다. 데이터가 지속적으로 흘러서 업데이트되는 경우가 있는데 traffic 센서 모니터링과 같은 경우를 예로 들 수 있다. 데이터 파이프라인을 통해 가져온 데이터는 database나 data warehouse에 쌓지 않는 경우도 있고 혹은 다중으로 데이터를 쌓는 경우도 있다.

 

●대시보드(dash board):

-다양한 데이터를 동시에 비교할 수 있게 해 주는 여러 뷰의 모음입니다.

-매일 검토하는 일련의 뷰가 있는 경우, 워크시트를 개별적으로 탐색하는 대신 모든 뷰를 동시에 표시하는 대시보드를 만들 수 있습니다.

-워크시트와 마찬가지로 대시보드는 통합 문서 맨 아래에 있는 탭에서 액세스합니다.

- 시트와 대시보드의 데이터는 연결되어 있습니다.

- 시트를 수정하면 해당 시트가 포함된 모든 대시보드가 변경되며, 반대의 경우도 마찬가지입니다.

- 시트와 대시보드는 모두 데이터 원본에서 사용할 수 있는 최신 데이터로 업데이트됩니다

 

●전자정부표준프레임워크:

개발프레임워크는 정보시스템 개발을 위해 필요한 기능 및 아키텍처를 미리 만들어 제공함으로써 효율적인 어플리케이션 구축을 지원합니다.
“전자정부 표준프레임워크”는 공공사업에 적용되는 개발프레임워크의 표준 정립으로 응용 SW 표준화, 품질 및 재 사용성 향상을 목표로 합니다.
이를 통해“전자정부 서비스의 품질향상” 및 “정보화 투자 효율성 향상”을 달성하고, 대ㆍ중소기업이 동일한 개발기반 위에서 공정 경쟁이 가능하게 됩니다.

※ 표준프레임워크는 기존 다양한 플랫폼(.NET, php 등) 환경을 대체하기 위한 표준은 아니며, java 기반의 정보시스템 구축에 활용하실 수 있는 개발·운영 표준 환경을 제공하기 위한 것입니다.

 

특징

 

 

●프레임워크(framework):

frame+work =틀 을 가지고 일을한다.

 

'특정 프로그램을 개발하기 위한 여러 요소들과 메뉴얼인 룰을 제공하는 프로그램'

 

1.spring(java framework)

2.Django(python framework)

3.ruby on rails(ruby framework)

4.Express(node.js framework)

 

●라이브러리(librarary):

 

-라이브러리는 도구의 모음입니다.

 

-소프트웨어를 개발하기 쉽게 어떤 기능을 제공하는 도구들

 

-특정 기능을 하는 코드 뭉치이다

 

-라이브러리(library)는 다른 프로그램들과 링크되기 위하여 존재하는, 하나 이상의 서브루틴이나 함수들의 집합 파일을 말하는데 함께 링크될 수 있도록 보통 컴파일된 형태인 목적코드 형태로 존재한다.

라이브러리는 코드 재사용을 위해 조직화된 오래된 기법 중의 하나이며, 많은 다른 프로그램들에서 사용할 수 있도록,

운영체계나 소프트웨어 개발 환경 제공자들에 의해 제공되는 경우가 많다.

 

라이브러리라는 기술이 생긴 이유:

-코드의 재사용 및 부품화 실현

-소스를 제공하지 않음으로서 중요기술의 유출 방지

-사용하는 개발자들로서는 대형 어플리케이션 개발 시간을 단축시킬 수 있다는 장점을 줌

 

-라이브러리 내에 있는 루틴들은 두루 쓸 수 있는 범용일 수도 있지만, 3차원 애니메이션 그래픽 등과 같이 특별한 용도의 함수로 설계될 수도 있다.

 

-라이브러리들은 사용자의 프로그램과 링크되어, 실행이 가능한 완전한 프로그램을 이룬다.

이러한 링크는 대개 정적으로 연결되지만, 시스템에 따라 동적으로 연결될 수도 있다.

 

정적 라이브러리:

-라이브러리에 포함된 목적코드가 실행 프로그램 컴파일 시에 실행 파일에 복사되어 배포되는 방식.

-기본적으로 필요한 기능이 실행 파일과 동일한 위치에 존재하기 때문에 프로그램 실행파일이 커지는 단점이 있지만,

배포해야 하는 파일이 실행파일 하나 만으로 충분하다는 장점을 가지고 있다.

-일반적으로 Unix,Linux,DOS등 소개된지 오래된 OS에서는 정적 라이브러리 확장자로 lib,l 등을 사용한다.

최근에 소개되는 자바,C#등에서는 동적 라이브러리를 적극 도입하는 추세이다.

 

동적 라이브러리:

-정적 라이브러리의 단점은 실행 프로그램의 크기가 커지는 문제뿐만 아니라, 동일한 라이브러리를 포함한 유사한 프로그램들이 동시에 실행될 경우, 똑같은 코드들이 불필요하게 많은 메모리 자원을 중복해서 사용하는 문제가 발생한다.

-게다가, 점차 복잡해지는 소프트웨어의 구조 상 실행 파일 크기가 기하급수적으로 커지는 단점도 있다.

-따라서, 어플리케이션들에서 사용되는 공통되는 모듈을 메모리에 단 한 차례만 적재하고 사용할 수 있는 방안을 강구하게 되었다.

-이 방식은 실행 프로그램에 항상 라이브러리를 포함하는 것이 아니라 필요할 때만 라이브러리를 메모리로 불러 들이기 때문에 동적 라이브러리라고 이름 붙였다.

 

-동적 라이브러리의 장점은 앞서 설명한 바와 같이 실행 파일의 크기를 줄어주며, 사용이 끝나면 메모리에서 삭제되기 때문에 메모리를 보다 효율적으로 사용할 수 있다.

 

-그러나, 프로그램 배포시에 exe 파일과 함께 dll파일이 추가로 배포해야 한다는 단점이 있다.

dll 파일이 없으면 컴파일 시에는 에러가 나지 않지만 실행 시에는 라이브러리를 찾을 수 없다는 오류가 발생,

라이브러리의 이름은 정확하지만 만일 버전이 적절하지 않다면, 역시 문제가 발생할 우려가 있다.

 

●Spring Framework:

-스프링 프레임워크(Spring Framework)는 자바 플랫폼을 위한 오픈소스 애플리케이션 프레임워크로서 간단히 스프링(Spring)이라고도 불린다. 동적인 웹 사이트를 개발하기 위한 여러 가지 서비스를 제공하고 있다. 대한민국 공공기관의 웹 서비스 개발 시 사용을 권장하고 있는 전자정부 표준프레임워크의 기반 기술로서 쓰이고 있다.

 

-스프링 사이트에서는 스프링 프레임워크가 인프라와 관련된 내용을 애플리케이션 레벨에서 설정하도록 해줌으로써 개발자가 코드로 대부분을 컨트롤 할 수 있게끔 지원한다고 설명한다. 즉, 개발자가 코드 안에 애플리케이션 동작에 대한 내용을 기술하면 스프링 프레임워크가 이를 해석해서 동작하는 것이다. 스프링을 사용하는 가장 일반적인 예로는 Servlet API 가 있다. 개발자는 API를 처리할 클래스를 정의하고 이것이 Servlet API 를 위한 클래스임을 표시(어노테이션 활용)한다. 그 이후 프로그램을 실행하면 스프링은 API 요청이 들어오면 해당 클래스를 이용해서 처리한다. 개발자가 Servlet에 관련된 것을 개발하지 않아도 되며, 데이터 바인딩, 객체 생성 등 왠만한 것들은 스프링이 알아서 해준다. 이런 편한 점 때문에 많은 개발자들이 스프링 프레임워크를 사용하고 있다.

 

●Spring boot:

스프링 프레임워크는 기능이 많은만큼 환경설정이 복잡한 편이다. 이에 어려움을 느끼는 사용자들을 위해 나온 것이 바로 스프링 부트다. 스프링 부트는 스프링 프레임워크를 사용하기 위한 설정의 많은 부분을 자동화하여 사용자가 정말 편하게 스프링을 활용할 수 있도록 돕는다. 스프링 부트 starter 디펜던시만 추가해주면 바로 API를 정의하고, 내장된 탐캣이나 제티로 웹 애플리케이션 서버를 실행할 수 있다. 심지어 스프링 홈페이지의 이니셜라이저를 사용하면 바로 실행 가능한 코드를 만들어준다. 실행환경이나 의존성 관리 등의 인프라 관련 등은 신경쓸 필요 없이 바로 코딩을 시작하면 된다. 그리고 바로 그것이 스프링의 키 포인트이다.

 

●파싱(parsing):

-컴퓨터에서 컴파일러 또는 번역기가 원시 부호를 기계어로 번역하는 과정의 한 단계로, 각 문장의 문법적인 구성 또는 구문을 분석하는 과정. 즉 원시 프로그램에서 나타난 토큰(token)의 열을 받아들여 이를 그 언어의 문법에 맞게 구문 분석 트리로 구성해 내는 일

-파싱은 크게 하향식 파싱과 상향식 파싱으로 나뉜다.

 

●메이븐(maven):

-Maven은 자바 프로젝트의 빌드(build)를 자동화 해주는 빌드 툴(build tool)이다.

즉, 자바 소스를 compile하고 package해서 deploy하는 일을 자동화 해주는 것이다.

 

●마이바티스(MyBatis):

-MyBatis란?

 

객체 지향 언어인 자바의 관계형 데이터베이스 프로그래밍을 좀 더 쉽게 할 수 있게 도와 주는 개발 프레임 워크로서 JDBC를 통해 데이터베이스에 엑세스하는 작업을 캡슐화하고 일반 SQL 쿼리, 저장 프로 시저 및 고급 매핑을 지원하며 모든 JDBC 코드 및 매개 변수의 중복작업을 제거 합니다. Mybatis에서는 프로그램에 있는 SQL쿼리들을 한 구성파일에 구성하여 프로그램 코드와 SQL을 분리할 수 있는 장점을 가지고 있습니다.

 

-MyBatis 특징

 

복잡한 쿼리나 다이나믹한 쿼리에 강하다 - 반대로 비슷한 쿼리는 남발하게 되는 단점이 있다.

프로그램 코드와 SQL 쿼리의 분리로 코드의 간결성 및 유지보수성 향상

resultType, resultClass등 Vo를 사용하지 않고 조회결과를 사용자 정의 DTO, MAP 등으로 맵핑하여 사용 할 수 있다.

빠른 개발이 가능하여 생산성이 향상된다.

 

●아이바티스(IBatis):

-

더 빠른 JDBC 코딩을 위한 일반화된 프레임워크

- SQL 매퍼 + DAO 프레임워크

iBatis는 데이터베이스에 있는 자원들을 보다 편리하게 가져오기 위한 프레임워크이다.

XML서술자를 사용해서 간단하게 자바빈즈를 PreparedStatement의 바인드 변수인 파라미터와

ResultSet으로 맵핑시켜주는 기능으로 SQL Maps 또한 ORM이라고도 한다.

iBATIS 데이터 매퍼 프레임워크는 관계형 데이터베이스에 접근할 때 가독성, 유지보수성, 생산성 등을 향상시켜준다.

특징

간결함과 쉬운 접근성

-다른 프레임워크와 객체관계맵핑툴에 비해 가장 간단한 퍼시스턴스 프레임워크

iBATIS 데이터 매퍼를 사용하기 위해서 자바빈즈와 XML 그리고 SQL만 알면 추가적으로 배워야 할것이 거의 없고

테이블을 조인하거나 복잡한 쿼리문을 수행하기 위해 필요한 복잡한 스키마도 없다.

데이터 매퍼를 사용하면 실제 SQL문의 모든 기능을 그대로 사용할수 있으며,

XML 형태로 서술된 JDBC 코드라고 생각해도 될 만큼 JDBC에 적용되는 거의 모든 기능은 iBATIS에서도 잘 적용된다

데이터베이스 관리자와 SQL 프로그래머 양 쪽 모두 이해하기 용이하다

 

성의 향상

-JDBC와 SQL을 유지하면서도 훨씬 더 적은 코드로도 JDBC처럼 작동

자바코드의 20%를 사용하여 JDBC기능의 80%를 제공하는 간단한 프레임워크

작성할 필요가 없는 JDBC 코드로 인한 분량 문제는 현저하게 줄어듬 (JDBC에 비해 62%정도)

일반적으로 프레임워크는 장황한 코드를 제거하고 복잡한 구조적인 문제를 해결하면서 공통적인 작업을 수행하기 위해 존재

성능

구조적 강점 - 데이터 접근 속도 높여주는 JOIN매핑

-여러가지 방식의 데이터 가져오기 전략

불필요한 수천 개의 행을 한꺼번에 데이터베이스로부터 가져오는 것 X

가져오기 미루기, SQL 줄이기 기법

=> 애플리케이션의 성능을 명백히 향상

SQL 문장과 프로그래밍 코드의 분리

작업의 분배 - 팀을 세분화하는 것을 도움

-SQL문과 Java코드와의 분리만으로도 Java개발자는 Query문을 신경쓰지 않아도 된다.

SQL문이 변경되더라도 파라미터 값만 변경되지 않는다면 Java소스에서 수정할 부분이 없기 때문이다.

성

-어떤 프로그래밍 언어로도 구현가능하다

예) 자바, C#(iBATIS.NET), Ruby(RBATIS)

 

이터베이스 접근 클래스와 비즈니스 로직을 담은 클래스의 분리

-이른바 DAO(Data Access Object) 패턴이 이러한 일을 담당한다.

-ibatis는 DAO 계층 구현을 위한 유틸리티 성격이면서 동시에 best practice 역할도 수행한다.

자주 쓰이는 데이터를 변경되지 않는 동안에 임시 보관(Cache)

-ibatis 에선 XML 설정만으로 캐시를 할 수 있다.

랜젝션과 쓰레드 관리

-트랜젝션 처리 역시 용이하다.

 

●스파크(Spark):

아파치 스파크는 오픈소스 분산 쿼리 및 처리 엔진입니다. 스파크는 유연성과 맵리듀스에 대한 확장성을 훨씬 빠른 속도로 제공합니다. 데이터가 메모리에 저장돼 있을 때는 아파치 하둡보다 100배 빠르며, 디스크에 저장돼 있을 때는 10배 빠릅니다.

 

스파크는 데이터를 읽고, 변형하고, 합계를 낼 수 있으며, 복잡한 통계 모델들을 쉽게 학습하고 배포할 수 있습니다. 스파크 API는 자바, 스칼라, 파이썬, R, SQL을 이용해 접근할 수 있습니다. 애플리케이션을 빌드하는데 씅리 수 있고, 여러 애플리케이션을 라이브러리로 묶어서 클러스터에 배포할 수도 있으며 파이썬 노트북을 통해(예를 들어 주피터, Spark-Notebook, Apache Zepplin) 대화식으로 빠른 분석을 수행할 수 있습니다.

 

스파크는 파이썬 pandas 라이브러리와 R의 data.frames 또는 data.tables를 이용하는 데이터 분석가, 데이터 과학자 또는 연구우너들에게 적합한 여러 라이브러리를 제공합니다. 스파크의 데이터프레임은 pandas나 data.frames/data.tables와 유사하지만, 몇 가지 다른 부분도 있으므로 너무 큰 기대는 하지 않는게 좋습니다. SQL에 더 익숙한 사용자들은 데이터를 다지기 위해 쿼리를 사용할 수 있습니다. 또한 몇몇 선구현된, 튜닝된 알고리즘, 통계 모델과 프레임워크를 아파치 스파크로 사용 가능합니다. 머신러닝을 위한 MLib과 ML 라이브러리, 그래프 처리를 위한 GraphX와 그래프프레임, 스파크 스트리밍(DStream 스트림과 구조적 스트림)이 해당합니다. 스파크로 이러한 라이브러리들을 한 애플리케이션에서 균일하게 사용할 수 있습니다.

 

아파치 스파크는 개인 PC에서도 쉽게 동작하며, YARN과 아파치 메소스(또는 로컬 클러스터나 클라우드)에서 Standalone모드로 쉽게 사용할 수 있습니다. 스파크는 데이터를 HDFS, 아파치 카산드라, 아파치 HBase, S3와 같은 다양한 소스로부터 읽고 쓸 수 있습니다.

 

●카프카(kafka):

-Apache Kafka(아파치 카프카)는 LinkedIn에서 개발된 분산 메시징 시스템으로써 2011년에 오픈소스로 공개되었다. 대용량의 실시간 로그처리에 특화된 아키텍처 설계를 통하여 기존 메시징 시스템보다 우수한 TPS를 보여주고 있다.

 

●하둡(hadoop):

-

하둡이란?

분산 환경에서 빅 데이터를 저장하고 처리할 수 있는 자바 기반의 오픈 소스 프레임 워크.

 

구성요소

1. 하둡 분산형 파일시스템(Hadoop Distributed FileSystem, HDFS)

하둡 네트워크에 연결된 기기에 데이터를 저장하는 분산형 파일시스템

 

특징 :

1. HDFS는 데이터를 저장하면, 다수의 노드에 복제 데이터도 함께 저장해서 데이터 유실을 방지

2. HDFS에 파일을 저장하거나, 저장된 파일을 조회하려면 스트리밍 방식으로 데이터에 접근해야 함.

3. 한번 저장한 데이터는 수정할 수 없고, 읽기만 가능하게 해서 데이터 무결성을 유지.

(2.0 알파버전부터는 저장된 파일에 append가 가능하게 됨)

4. 데이터 수정은 불가능 하지만 파일이동, 삭제, 복사할 수 있는 인터페이스를 제공함.

 

●모듈화(mudularity):

-모듈이란 애플리케이션을 구성하는 개별적 요소를 말한다.

 

-일반적으로 파일 단위로 분리되어 있으며 필요에 따라 애플리케이션은 명시적으로 모듈을 로드한다.

 

-모듈은 애플리케이션에 분리되어 개별적으로 존재하다가 애플리케이션의 로드에 의해 비로소 애플리케이션의 일원이 된다.

 

- 모듈은 기능별로 분리되어 작성되므로 개발효율성과 유지보수성의 향상을 기대할 수 있다.

 

●도커(docker):

도커는 컨테이너 기반의 오픈소스 가상화 플랫폼입니다.

컨테이너라 하면 배에 실는 네모난 화물 수송용 박스를 생각할 수 있는데 각각의 컨테이너 안에는 옷, 신발, 전자제품, 술, 과일등 다양한 화물을 넣을 수 있고 규격화되어 컨테이너선이나 트레일러등 다양한 운송수단으로 쉽게 옮길 수 있습니다.

서버에서 이야기하는 컨테이너도 이와 비슷한데 다양한 프로그램, 실행환경을 컨테이너로 추상화하고 동일한 인터페이스를 제공하여 프로그램의 배포 및 관리를 단순하게 해줍니다. 백엔드 프로그램, 데이터베이스 서버, 메시지 큐등 어떤 프로그램도 컨테이너로 추상화할 수 있고 조립PC, AWS, Azure, Google cloud등 어디에서든 실행할 수 있습니다.

 

●REST API(REpresentational State Transfer API):

-소프트웨어 프로그램 아키텍처의 한 형식입니다

 

-REST 의 구성

• 자원 (Resource) - URL
• 행위 (Verb) - Http method
• 표현 (Representations)

-REST의 특징

1) 클라이언트/서버 구조

클라이언트는 유저와 관련된 처리를, 서버는 REST api를 제공함으로써 각각의 역활이 확실하게 구분되고 일관적인 인터페이스로 분리되어 작동할 수 있게 한다.

2) 무상태성 (Stateless)

REST는 HTTP의 특성을 이용하기 때문에 무상태성을 갖는다. 즉 서버에서 어떤 작업을 하기 위해 상태정보를 기억할 필요가 없고 들어온 요청에 대해 처리만 해주면 되기 때문에 구현이 쉽고 단순해진다.

3) 캐시 처리 가능(Cacheable)

HTTP라는 기존 웹표준을 사용하는 REST의 특징 덕분에 기본 웹에서 사용하는 인프라를 그대로 사용 가능하다.

4) 자체 표현 구조(Self-descriptiveness)

Json을 이용한 메세지 포멧을 이용하여 직관적으로 이해할 수 있고 REST api 메세지만으로 그 요청이 어떤 행위를 하는지 알 수 있다.

5) 계층화(Layered System)

클라이언트와 서버가 분리되어 있기 때문에 중간에 프록시 서버, 암호화 계층등 중간매체를 사용할 수 있어 자유도가 높다.

6) 유니폼 인터페이스(Uniform)

Uniform Interface는 Http 표준에만 따른다면 모든 플랫폼에서 사용이 가능하며, URI로 지정한 리소스에 대한 조작을 가능하게 하는 아키텍처 스타일을 말한다.

 

-REST API설계법

URL는 정보의 자원을 표현한다.

제목 대로 URL는 정보의 자원을 표현해야하기 때문에 설계 할때 몇 가지 지켜야 할 것들이 있습니다.

1) 소문자를 사용한다.

• 대소문자에 차이를 두기 떄문에(foo.com과 FOo.com은 서로 다르다) 혼란을 줄 수 있기 때문에 지양하는 것이 좋다.

2) 하이픈( - )을 사용한다.

3) 확장자를 사용하지 않는다.

http://foo.com/world.txt http://foo.com/world.png

위와 같이 했을 때, 확장자에 때른 url을 만들어야 하기 떄문에 비효울적일 수 있다.

4) 밑줄( __ )은 사용하지 않는다.

자원에 대한 행위는 HTTP Method로 표현한다

아래가 대표적으로 사용하는 4가지 Mehtod이다.

HTTP Method역할

GET	GET을 동해 해당 리소스를 조회합니다.
POST	POST를 통해 해당 URL를 요청하면 리소스를 생성합니다.
PUT	PUT을 통해 해당 리소스를 수정합니다.
DELETE	DELETE를 통해 해당 리소스를 삭제합니다.

예를 들어 글을 수정하기 위해선 아래와 같이 할 수 있다.

POST /posts/put/:id (X) POST /posts/update/:id (X) PUT /posts/:id (O)

 

 

●on-premise(온프레미스):

-on-premise란 소프트웨어 등 솔루션을 클라우드 같이 원격 환경이 아닌 자체적으로 보유한 전산실 서버에 직접 설치해 운영하는 방식을 말합니다.

-온프레미스는 클라우드 컴퓨팅 기술이 나오기 전까지 기업 인프라 구축의 일반적인 방식이었기 때문에 이전 또는 전통적인 이라는 단어와 함께 사용됩니다.

-일반적으로 온프레미스 시스템을 구축하는데 시간이 수개월 이상 걸렸고 비용 또한 많이 들어, 퍼블릭 클라우드가 나올 당시만 해도 온프레미스 환경이 금방이라도 모두 사라질 것 같았습니다.

-하지만 보안 적인 이유로 비즈니스에 중요하고 보안이 필요한 서비스와 데이터는 온프레미스 환경에서, 덜 중요한 것은 퍼블릭 클라우드 환경을 사용하는 하이브리드 IT 인프라가 대세를 이루고 있습니다.

 

●web-crawling(웹 크롤링):

1. 크롤링이란?

-크롤링(Crawling)이란 사전적으로 기어다니는 것을 뜻하는데, 전산쪽에서는 Web상을 돌아다니면서 정보를 수집하는 행위를 뜻한다.

 

-아마 web에서 그 의미가 파생된 듯 하다. 아무튼 크롤링, 스크래핑(Scraping) 또는 데이터 긁기등 다양한 단어로 불린다.

 

2.

-크롤링 대상앞서 언급된 크롤링에 정의에 따라, 크롤링의 대상은 웹 상의 자원들이다.

 

-이 자원은 정적인 문서가 될 수도 있고, API와 같은 서비스가 될 수도 있다.

 

-다만 어느쪽이던 다수의 데이터를 수집하고, 여기서 필요한 정보만 추출해서 처리하는 것을 우리는 크롤링이라고 부를뿐이다.

 

-예를 들어 구글과 같은 검색엔진에서는 웹 사이트의 정적인 데이터를 긁어다가 필요한 정보를 추출해서 검색 인덱스를 생성하고, 가격 정보 비교 사이트는 상품과 가격정보등을 긁어다가 서로 다른 쇼핑몰의 가격을 알려주기도 한다.

 

- 크롤러는 사실 그렇게 엄청난 것이 아니며, 필요에 따라 누구든지 제작할 수 있다.

 

-물론 정보 수집 대상이 웹이 아닌 경우가 있지만, 이 경우에는 다른 이름으로 불리우는 경우가 많고 크롤러 정의상 범주 밖에 있으니 넘어가도록 하자.

 

3.

-크롤링 툴, 라이브러리사실 어떤 툴이든 라이브러리를 사용하든 정보를 수집한다는 것은 변함이 없다.

 

-다만 자신의 필요에 맞게 사용하면 된다. 가장 일반적으로 호스트 프로그램을 통해서 데이터를 수집할 수 있는 라이브러리에는 Beautiful soup, 자바 버전인 JSoup, 브라우저를 이용한 Selenium 등이 있다.

4.

크롤링 메커니즘크롤링 매커니즘은 대략적으로 아래의 단계를 통해서 진행된다. (1) 대상 선정 -> (2) 데이터 로드 -> (3) 데이터 분석 -> (4) 데이터 수집

(1) 크롤링 대상 선정 (API 또는 웹 문서)

-웹 상의 데이터는 고유한 ID를 가진다.

 

- URI라고 부르며, 이는 우리가 잘 하는 웹 사이트 주소인 URL과 URN이 있다.

 

-간단하게 과일에 대한 네이버 검색 결과를 크롤링하려면 "https://search.naver.com/search.naver?query=사과", "https://search.naver.com/search.naver?query=배"의 URL을 선정하는 과정이다.

 

(2) 데이터 로드

-데이터 로드는 웹 사이트를 켜는것과 같다. 만약 API라면 XML, JSON 문서가 될 것이고, 웹 페이지라면 HTML 문서를 다운로드 받는 것이다.

 

(3) 데이터 분석

-로드된 데이터에서 필요한 부분을 뽑아내는 것을 뜻한다. 당연하게도 웹 사이트상에는 내가 필요로하지 않는 부분이 많다.

 

-어떠한 부분을 수집할지, 어떤 부분을 수집하지 않을지 선정하는 과정이다.

 

(4) 수집

데이터 분석 과정을 통해서 수집할 내용을 선정했다면, 이를 추출하여 파일 또는 데이터를 메모리상에 저장하는 과정이다.