Mon L'étrange voyage

SOAP(Simple Object Access Protocol)는 그 자체로 프로토콜이며, 보안이나 메시지 전송 등에 있어서 REST보다 더 많은 표준들이 정해져있기 때문에 조금 더 복잡합니다. 이러한 표준들로 인해서 오버헤드가 많기는 하지만, 보안, 트랜잭션, ACID(원자성, 일관성, 고립성, 지속성)을 준수해야 하는 보다 종합적인 기능이 필요한 조직에게는 적합한 방식이 될 수 있습니다. 굳이 비교를 하자면, SOAP는 웹 서비스 시나리오에 적용하기에는 그다지 좋지 않기 때문에, 기업용 애플리케이션 등을 작업하는데 더 이상적이라고 말할 수 있습니다.

SOAP는 보안 수준이 엄격합니다. SOAP에서는 SSL도 지원하고 WS-Security라는 자체 표준의 보안 기능도 가지고 있지요. 따라서 은행용 모바일 앱처럼 보안 수준이 높아야 하거나, 신뢰할 수 있는 메시징 앱, 또는 ACID를 준수해야 하는 경우라면 SOAP 방식이 더욱 선호됩니다.

REST에서는 표준화된 메시징 시스템이 갖춰져 있지 않으며, 통신 장애가 있을 경우 재시도를 통해서만 조치할 수 있습니다. 반면 SOAP 표준에는 성공/반복 실행 로직이 규정되어 있기 때문에, SOAP API를 통해서 통신을 할 때 처음부터 끝까지 신뢰성을 제공합니다.

SOAP 표준에는 ACID 준수에 관한 사항이 있습니다. ACID를 준수하기 때문에 데이터의 변형을 줄여주고, 데이터베이스와의 상호작용에 대해서 사전에 정확하게 정하기 때문에 데이터의 무결성을 지켜주지요. ACID는 데이터 일관성을 위한 다른 방식들보다도 더 보수적이기 때문에, 금융 정보 등의 민감한 데이터를 주고받을 때 일반적으로 많이 사용됩니다.

출처 : http://blog.wishket.com/soap-api-vs-rest-api-%EB%91%90-%EB%B0%A9%EC%8B%9D%EC%9D%98-%EA%B0%80%EC%9E%A5-%ED%81%B0-%EC%B0%A8%EC%9D%B4%EC%A0%90%EC%9D%80/

1. Nested Loop Join

• 2개 이상의 테이블에서 하나의 집합을 기준으로 순차적으로 상대방 Row를 결합하여 원하는 결과를 조합하는 방식
• 먼저 선행 테이블의 처리 범위를 하나씩 액세스하면서 추출된 값으로 연결할 테이블을 조인한다
• 순차적으로 처리된다.
• 바깥 테이블과 일치하는 값을 안쪽 테이블에서 찾아야 하므로 안쪽 테이블의 해당 열에 인덱스가 필요하다.
• 메모리 사용량은 가장 적다.
• 바깥 테이블과 안쪽 테이블의 크기는 성능과 관련이 없다.
• 첫 테이블 필터링 -> 두테이블간의 연결 -> 최종운반 단위 산출가지 반복적, 순차적으로 진행됩니다.
• 선행 테이블의 처리 범위가 전체 일의 양을 결정합니다.
• 후행 테이블의 필터링 조건은 선행 테이블에서 나온 결과를 한번 더 걸러주는 체크 조건 역할을 할 뿐 전체 처리량을 좌우하지 않습니다.
  
  

2. Sort Merge Join

양쪽 테이블의 처리 범위를 각자 액세스하여 정렬한 결과를 차례로 스캔하며, 연결고리 조건으로 Merge하는 방식을 말합니다.
이 방식은 경우에따라 Loop Join 보다 훨씬 빨라지는 경우도 많이 있으며, 랜덤 액세스가 줄어들어 시스템 부하를 감소 시킵니다.
하지만 일반적으로 Loop Join보다는 사용빈도가 적습니다.

장점

• 처리량이 많을때 성능상 이점이 있다.
• 중첩반복(Nested Loops)은 연결고리의 상태가 굉장히 중요하다. 한쪽 연결고리에 이상이 발생하면 중첩반복은 심히 고려해야한다. 이때 연결고리에 영향을 받지않는 Sort Merge를 쓰면 좋다.

단점

• 정렬에 따른 부담 (메모리 사용 증가)정렬은 tempdb를 사용한다. 정렬양이 극도로 많아 tempdb의 임계치를 넘었을때 순간 전체 데이터베이스에 페이지잠금이 발생하는등 DB성능에 심각한 영향을 줄 수 있다.물론 가공없이 Clustered Index를 그대로 사용하게 되면 정렬은 안해도 되니 이때만큼은 정렬의 부담에서 해방된다.

3. Hash Join

Hash Join은 Hash Table을 생성하여 Hash Function에 의한 탐색을 하여 조인합니다. 주로 대용량의 데이터를 사용할 때 사용되며 일반적으로 Nested Loop Join이나 Sorted Merge Join보다 빠르다고합니다. 알고리즘에서 시간 복잡도의 개념으로 봤을 때도 Hash Function을 사용하게 되면 O(1)의 시간 복잡도를 갖게되니까 빠를수 밖에 없는 것 같습니다. 하지만, 해시 충돌을 방지나 해시 체인의 크기가 커지는 것을 막기 위해 중복되는 데이터가 적은 경우에 사용되어하고 Hash Table을 생성하는데 Hash Area에 충분히 담길 정도로 데이터 양이 작아야합니다.

HASH JOIN의 사용처

1. JOIN 컬럼에 적당한 인덱스가 없어 NL JOIN이 비효율적일 때

2. JOIN Access량이 많아 Random Access 부하가 심하여 NL JOIN이 비효율적일 때

3. Sort Merge Join을 하기에는 두 테이블이 너무 커 Sort 부하가 심할 때

4. 수행빈도가 낮고 쿼리 수행 시간이 오래 걸리는 대용량 테이블을 JOIN 할 때

1. 둘 중 작은 집합(Build Input)을 읽어 Hash Area에 해시 테이블을 생성한다. (해시 함수에서 리턴 받은 버킷 주소로 찾아가 해시 체인에 엔트리를 연결)

2. 반대쪽 큰 집합(Probe Input)을 읽어 해시 테이블을 탐색하면서 JOIN 한다.

3. 해시 함수에서 리턴 받은 버킷 주소로 찾아가 해시 체인을 스캔하면서 데이터를 찾는다.

출처: https://coding-factory.tistory.com/758

출처: https://needjarvis.tistory.com/162 [자비스가 필요해]

출처: https://blog.sonim1.com/108

RESTful API란?

자원을 URI로 표현하고, 자원에 대한 행위를 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

PUT : 리소스의 모든 것을 업데이트 한다.
PATCH : 리소스의 일부를 업데이트 한다.

가령 한 사용자에 대해 여러 정보를 객체로 수집하여 서버로 보내는 경우, PUT은 보내지지 않은 정보에 대해서는 null값으로 업데이트하지만, PATCH는 기존 데이터를 유지하는 방식으로 대응한다.

HTTP Method는 크게 GET, POST, PUT, DELETE가 대표적이며,

보통 CRUD에서 조회는 GET, 등록은 POST, 수정은 PUT, 삭제는 DELETE를 이용한다.

GET과 DELETE는 비교적 그 행위가 명확하지만, POST와 PUT을 구분하기 위해서는 멱등성의 개념을 알아야 한다.

PUT

반면 리소스의 위치가 명확히 지정된 다음의 요청을 고려해 보자.

PUT /dogs/3 HTTP/1.1 { "name": "blue", "age": 5 }

/dogs 의 프로퍼티가 name 과 age 뿐이라면, 이건 몇 번을 수행하더라도, 같은 결과를 보장한다. 다시 말해 idempotent 하다.

그리고 위에 예에서 알 수 있듯이 PUT 은 리소스의 위치가 지정되었을때 생성 또는 업데이트 를 위해 사용할 수 있다.

PATCH

PUT 이 리소스의 모든 프로퍼티를 업데이트 하기 위해 사용된다면, PATCH 는 부분만을 업데이트하기 위해 사용한다. PUT 과 마찬가지로 리소스의 위치를 클라이언트가 알고 있을 때 사용한다.

(1) POST to a URL creates a child resouce at a server defiend URL
(2) PUT to a URL create/replaces the resource in is entirely at the client defined URL
(3) PATCH to a URL updates part of the resource at that client defined URL

멱등성(Idempotence)이란?

멱등성이란 여러번 수행해도 결과가 같음을 의미한다.

HTTP 메소드를 예를 들자면, GET, PUT, DELETE는 같은 경로로 여러 번 호출해도 결과가 같다.

그러나 POST는 매 호출마다 새로운 데이터가 추가된다. 

따라서, POST 연산은 결과가 Idempotent하지 않지만, PUT은 반복 수행해도 그 결과가 Idempotent 하다. 

출처: https://devuna.tistory.com/77 [튜나 개발일기]

1. MVC (Model-View-Controller) 

# 구성요소

모델-뷰-컨트롤러는 응용 프로그램을 세 가지의 구성요소로 나눈다. 각각의 구성요소들 사이에는 다음과 같은 관계가 있다.

• 개발 할 때, 3가지 형태로 역할을 나누어 개발하는 방법론입니다.Model은 어플리케이션이 “무엇”을 할 것인지를 정의 합니다. 내부 비지니스 로직을 처리하기 위한 역할을 할 것입니다.
  • 처리되는 알고리즘, DB 와 상호작용(CRUD Create Read Update Delete), 데이터 등등..
  Controller는 모델이 “어떻게” 처리할 지를 알려주는 역할을 할 것이고, 모바일에서는 화면의 로직처리 부분입니다. 화면에서 사용자의 요청을 받아서 처리되는 부분을 구현되게 되며, 요청 내용을 분석해서 Model과 View에 업데이트 요청을 하게 됩니다.
  • 사용자로 부터의 입력 을 받고 Model 또는 View중개인 역할
  View는 화면에 “무엇” 인가를 “보여주기 위한 역할”을 합니다. 컨트롤러 하위에 종속되어, 모델이나 컨트롤러가 보여주려고 하는 모든 필요한 것들을 보여줄 것입니다.
  • 최종 사용자에게 “무엇”을 화면(UI)으로 보여줌
  그리고 Controller는 Model과 View가 각각 무엇을 해야 할 지를 알고 있고, 통제합니다. 비지니스 로직을 처리하는 Model과 완전히 UI에 의존적인 View가 서로 직접 이야기 할 수 없게 합니다.
• 비지니스 처리 로직과 사용자 인터페이스 요소들을 분리시켜 서로 영향없이 개발 하기 수월하다는 장점이 있습니다.

출처 : https://medium.com/@jang.wangsu/%EB%94%94%EC%9E%90%EC%9D%B8%ED%8C%A8%ED%84%B4-mvc-%ED%8C%A8%ED%84%B4%EC%9D%B4%EB%9E%80-1d74fac6e256