728x90
반응형
SMALL

데이터베이스의 교통 신호등

데이터베이스의 목적중에 가장 큰 것은 데이터의 공유라고 할 수 있다.
따라서 데이터베이스는 여러 사용자가 동시에 접근해서 데이터를 Insert , update , delete
할 수밖에 없다.  사거리 교통신호등이 없다고 생각해보자.. 아마 사방에서 차들이
제각기 주행하면서 아마도 충돌사고가 날 것이다. 데이터베이스도 마찬가지다. 여러 사용자가
동시에 데이터에 접근을 하기 때문에 사거리 교통신호등 처럼 교통정리를 안해주면 데이터는
정합성이 깨지면서 엉망이 될 것이다.
그래서 데이터베이스에서는 이러한 데이터에 대한 접근 즉 Transaction 에 대한 4원칙 즉
ACID를 따르도록
되어 있으며 이 ACID를 보장하기 위해서는 Isolation Level (격리수준) 을 결
정해서
적용해야 한다.

Transacton 이란?

트랜잭션(Transaction) 에 대한 개념 정의를 먼저 할 필요가 있다.
데이터베이스에서 트랙잰션(Transaction) 이란 데이터에 대한 하나의 논리적 실행 단계를
말한다.  좀 어려운 용어정의인데.. 예를 들자면  계좌이체를 생각해 보면 계좌이체는
A라는 송신자 통장에서 돈을 빼서 B라는 수신자의 통장에 돈을 넣는 2가지 단계로 
이루어 지듯이 이 두단계에서 데이터에 대한 처리를 하는 논리적 행위를 트랜잭션
(Transaction) 이라고 한다.
그런데 만약 A송신자 통장에서 돈만 빠져나가고 B 수신자 통장에는 오류가 나서 돈이
안들어 왔다면 정말 큰일이다. 따라서 트랙잭션은 이 다음에 설명할 ACID 를 반드시
충족해야 한다.

데이터베이스의 읽기 이상 현상 (Read Phenomena)

데이터베이스에서 Isolation level 에 따라 발생할 수 있는 이상현상들을 정리해보면..

유형 내용 해결방안
Dirty Read 트랜잭션 T1 에서 A = 5 로 Update 하고 아직 commit 를 않았는데 다른 트랜잭션  T2가 이 A 값을 읽을 수 있도록 허용하는 경우 Dirty Read가 발생 할수 있다. 즉.   T1이 Update를 수행한 후 아직 commit 도 안했는데 다른 트랜잭션 T2가 A 를 select 했을 때 5 가 나올 경우 , T1 트랜잭션이 rollback을 했을 경우 결국 A 값은 5가 아님에도 T2 는 5로 잘못 읽는 (Dirty Read) 현상이 발생한다 공유 Lock 을 걸어서 T1이 A 에 접근하고 있는 동안 다른 트랜잭션이 접근하지 못하게 함.
Non Repeatable Read T1 트랜잭션이 같은 쿼리를 두번 실행했는데 그 결과값이
다른 경우, 즉 T1 이  select 를 두번 하는 사이에 T2 트랜잭션이 update 나 delete 를 한 경우
트랜잭션 완료 시까지 수정/삭제 제한
Phantom Read T1 트랜잭션이 같은 쿼리를 두번 수행 시 첫번째 실행시에 
없던 레코드가 두번째 실행시에 튀어 나오는 경우 
T1 트랜잭션이 읽은 데이터는 T2 트랜잭션에서 갱
신, 삭제하지 못할 뿐 아니라 중간에 새로운 레코드 삽입(Insert)까지 불허


데이터베이스의 Isolation Level (고립수준) 유형

유형 내용 읽기 이상 현상
Read Uncommitted  트랜잭션  T1이 아직 commit 하지 않은 데이터를 다른 트랜잭션 T2가 Read 하는 것을 허용 Dirty Read 
오라클은 미지원
Read Committed 트랜잭션  T1이 commit 을 한 데이터만 다른 트랜잭션 T2가 Read 하는 것을 허용 Dirty Read는 막을 수 있지만
Non Repeatable Read와 Phantom Read 는 막을 수없음
(대부분의 DBMS가 채택)
Repeatable Read 선택 트랜잭션 T1이 읽은 데이터는 T1이 종료될 때 까지는 다른 트랜잭션이 수정/삭제 (Update/Delete) 를 허용하지 않음
단 삽입(Insert) 은 허용 함.
Dirty Read와 Non Repeatable Read까지는 발생을 막을수 있으나 Phantom Read 는 막을 수없음
Serializable 선행 트랜잭션 T1이 읽은 데이터는 T이 종료될 때 까지 다른 트랜잭션이 수정/삭제는 물론 삽입 까지 허용하지 않음 Dirty Read와 Non Repeatable Read와 Phantom Read 까지 모두 막을 수 있음
(완벽하지만 실제 현실적으로는 불가능에 가깝다)



Isolation Level 과 읽기 이상 현상의 관계를 정리하면 다음과 같다

Isolation Level Dirty Read Non Repeatable Read Phantom Read
Read Uncommitted  가능 가능 가능
Read Committed 불가능 가능 가능
Repeatable Read 불가능 불가능 가능
Serializable 불가능 불가능 불가능



데이터베이스의  Isolation Level 과 동시성과의 상관관계

위에서 설명한 4가지 Isolation Level 중에서 Serializable 레벨이 가장 읽기 이상 현상을 모두 방어할 수 있는 방법이기
는 하지만 대신 그만큼 트랜잭션들이 동시에 병렬적으로 실행되지 못하고 하나씩 하나씩 실행순서대로 실행이
되기 때문에 대기시간이 늘어나고 전체적으로 performance 가 떨어 질수 밖에 없다. 
반대로 Read Uncommitted 는 그냥 트랜잭션 의 수행을 동시에 수행 가능하기 때문에 동시성이 높아진다.
이렇게 Isolaton Level 과 동시성(Concurrent) 은 서로 Trade-off  관계이다.

 

728x90
반응형
LIST
728x90
반응형
SMALL

데이터베이스는 혼자 쓰는 공간이 아니기 때문에 당연히 여러 사용자가 동시에
접근해서 읽기,수정하기,삭제하기 등의 Transaction을 마구잡이로 실행한다.
따라서 정확한 교통정리가 없으면 데이터베이스의 데이타는 정합성이 깨지면서
데이터는 엉망이 되고 말것이다.
그레서 데이터베이스에서는 Transaction 에 대한 4원칙 즉 ACID를 따르도록
되어 있으며 이 ACID를 보장하기 위해서는 Isolation Level (격리수준) 을 결정해서
적용해야 한다.

Transacton 이란?

데이터베이스에서 트랙잰션(Transaction) 이란 데이터에 대한 하나의 논리적 실행 단계를
말한다.  좀 어려운 용어정의인데.. 예를 들자면  계좌이체를 생각해 보면 계좌이체는
A라는 송신자 통장에서 돈을 빼서 B라는 수신자의 통장에 돈을 넣는 2가지 단계로 
이루어 지듯이 이 두단계에서 데이터에 대한 처리를 하는 논리적 행위를 트랜잭션
(Transaction) 이라고 한다.
그런데 만약 A송신자 통장에서 돈만 빠져나가고 B 수신자 통장에는 오류가 나서 돈이
안들어 왔다면 정말 큰일이다. 따라서 트랙잭션은 이 다음에 설명할 ACID 를 반드시
충족해야 한다.

ACID 란?

위 에에서 설명한 계좌이체 거래(트랜잭션,Transaction) 는 아래 4가지 원칙을 만족해야 한다.

종류 내용
Atomicity (원자성)

하나의 Transaction은 모두 수행되거나 모두 수행되지 말아야 한다. 
Commit ,Rollback 을 통해 모두 적용되거나 모두 취소되어야 한다.
수행 중간에 오류가 있으면 이미 한것도 모두 취소가 되어야 한다.
계좌이체 트랜잭션(Transaction) 에서 보면 A통장에서 돈인 인출되고
B통장에 돈이 입금되는 두 행위가 둘다 모두 성공하거나 아니면 둘다 모두
취소되어야 한다는 뜻이다.

Consitency (일관성)

트랜잭션(Transaction) 실행이 성공적으로 완료되었을 때에는 
이전의 상태와 실행후의 상태가 안정적이고 일관성(Consistency)이 있어야
한다는 뜻이다.
위 계좌이체에서 A통장에 3,000원이 있었고 B통장에는 2,000 원이 있었다면
총 합계는 5,000원이 된다.  이상태에서 500원을 A통장에서 B통장으로 이체
했을 경우 A통장은 2,500원이 되고 . B통장은 2,500원이 되고 총 합계는
트랜잭션 수행되기 이전인 5,000원과 동일해야 한다는 뜻이다.
(머 당연한 이야기이겠지만...) 

Isolation (고립성) 트랜잭션(Transaction) 간에는 서로 독립성이 있어야 한다는 뜻이다.
예를 들어 계좌이체에서 A통장에 5,000원이 있는 상태에서 B통장에 3,000원
을 이체하는 트랙잰션 도중에 A통장에서 4,000원을 인출해서 C통장에
이체하는 거래가 끼어드는 경우.. 어떻게 될까?? 이 고립성(Isolation)을 
만족시키지 못한다면 A통장에서 B통장으로 3,000원 , C통장으로 4,000원이
나가는 ...자기 통장잔액 5,000원 보다 더 많은 7,000원이 나가는 사태가 
발생할 것이다. 그러면 총합계도 틀어지면서 일관성(Consistency) 도 충족하지
못하게 되는 것이다. 
그러면 이때에는 어떻게 해야할까??. 첫번째 트랜잭션이 Commit 이나 Rollback 이 되기전까지는 두번째 트랜잭션은 기다려야 한다..

Durability (영속성/지속성) 성공적으로 수행이 완료된 트랜잭션의 결과는 영원해야 한다는 뜻이다.
즉 시스템에 장애가 발생해도 그 결과는 유지되어야 한다는 뜻이다.
이러한 것을 해주는 것이 데이터베이스의 복구 기능이다.


ACID와 데이터베이스 관계

구분 관계
Atomicity (원자성) Commit / Rollback
회복성의 보장

트랜잭션은 분해가 불가능한 논리적  최소 단위로 실행 전체가 승인되거나 취소 되어야 함. (All or Nothing)

Consitency (일관성) 무결성 조건 
동시성 제어

트랜잭션의 수행 이후 데이터는 무결성이 유지되고 모순되지 않아야 함.

Isolation (고립성) Isolation Level (고립수준)
분산 트랜잭션
Lock

다수의 트랜잭션이 동시에 수행되더라고 개별 트랜잭션의 결과에 영향을 미쳐서는 안됨.

Durability (영속성/지속성) 회복기법 (Redo/Undo)

성공적으로 수행된 트랜잭션은  해당 요인에 의해 변경 및 손실되지 않아야 함.

 

728x90
반응형
LIST
728x90
반응형
SMALL

오프쇼어링 (Off-Shoring)

오프쇼어링 (Off-Shoring) 의 반대말이 리쇼어링(Reshorijg) 이다 .
오프쇼어링이란 글자그대로 해석을 하면 다른 지역의 해안가(shore)로 이동한다는 뜻으로
생산,제조공장이나 업무를 비용이 싼 해외로 옮기는 것을 말한다.
대표적으로 우리나라도 국내 인건비의 증가로 인해 생산비가 증가하자 인건비가 저렴한
중국이나 동남아국가로 생산공장을 이전하는 사례는 흔한 일이다. 특히 노동집약적인 상품
에 대한 생산비에는 인건비가 큰 비중을 차지하기 때문에 노동집약적인 산업일 수록
오프쇼어링이 강세였다.

리쇼어링 (Reshoring)

그러나 이런 해외공장도 시간이 지나면서 공해,안전,세금,인건비상승 등의 문제가 발생하기
시작했고, 또 자국의 경제활성화, 일자리창출 등 자국의 이익을 중요시 하면서 각나라는 해외로
나갔던 생산시설이나 기업을 다시 자국으로 불러들이기 위해 인센티브나, 세금감면, 규제완화
등의 정책을 펴기시작 했는데. 이처럼 해외의 생산기지나 시설, 회사,업무 등이
다시 본국으로 돌아가는 것을 리쇼어링 (Reshoring) 이라고 한다
우리나라도 2012년부터 '유턴기업 지원정책'을 만들어서 리쇼어링을 유도하고 있다.
다른 말로 '온쇼어링','백쇼어링','인쇼어링' 이라고도 한다.

각국 사례

1.미국 - 2012년 오바마 정부시절 국내기업의 법인세인하 정책을 펴면서 리쇼어링(Reshoring) 이
           등장하기 시작했다. 금융위기 이후 국내 경기회복을 위해 귀환기업에 대한 법인세율 인하
           , 이전비용 지원 등의 당근책을 내세웠고 그 결과 캐터필러, GE, 애들 등이 미국으로
           귀환(Reshoring) 했다.
           최근에는 트럼프 대통령이 강력한 미국 우선주의를 내세우면서 리쇼어링 현상은 더 현실
           화 되고있다. 
 2.일본 - 일본도 잃어버린 20년 이후 경제활력을 찾고자 기업규제완화 등을 통해 리쇼어링 효과를
            보게 되었으며, 아베 정부는 대규모 양적 완화를 통해 엔저 정책을 추진하였는데. 환율효과로
            수출 경쟁력이 높아졌고 귀환기업에 대한 입지 지원등의 정책등으로 인해 유턴 기업이
            크게 증가했다.
 3. 유럽 - 유럽또한 리쇼어링 정책에 적극적이며, 영국 캐머런 총리는 GDP데비 제조업 비중을 
             15% 대로 끌어올리겠다는 목표아래 법인세 인하와 노동시작 개혁을 단행했다.
             프랑스는 농업과 저부가가치 제조업의 비중이 크다 보니, '르노' 등 특정 기업에 지원금을
             주는 전략을 펴기도 했다.

728x90
반응형
LIST
728x90
반응형
SMALL

머클트리 (Merkle Tree) 의 정의

머클트리(Merkle Tree)는 이진트리(Binary Tree) 의 형태를 띠고 있다.
이진트리는 아시겠지만 아래 그림과 같이 부모노드가 자식노드를 2개만 가지고
있는 트리구조를 말한다. 

이진 트리 (Binary Tree)

그럼 머클트리는 무었이냐?. 머클트리는 맨 마지막 노드 (Leaf Node) 는 값에 대한
Hash값을 저장하고 있고 그 상위 부모노드는 자식노드의 Hash값을  가지고 
다시 Hashing 한 Hash값을 저장하는 방식입니다.
예를 들어 a 에 대한 Hash값을 H(a) 라고 하고, b에 대한 Hash값을 H(b) 라고 하면
그 부모노드는 H(a)+(Hb) 에 대한 Hash값 H(ab)를 저장하고,, 계속 상위 노드로
올라가보면 결국 최상위 노드 즉 Root Node 는 전체  Node에 대한 Hash값을
가지고 있는 머클루트(Merkle Root) 가 되는 것이다.

머클트리 (Merkle Tree)

머클트리(Merkle Tree)의 특징

1. 이진트리와 동일한 방식이지만 노드값이 Hash값으로 이루어져 있으며노
2. Hash값은 항상 동일한 크기의 값을 리턴하기 때문에 머클트리의  모든 노드는
   동일한 크기를 가지게 된다.
3. 따라서 
공간절약을 장점으로 꼽을 수 있다. 
4. 일반적인 이진트리(Binary Tree)는 위에서 아래로 트리구조가 만들어지는
   반면 머클트리(Merkle Tree)는 아래에서 위로 올라가면서 노드가 생성되는 구조이다.
5. a,b,c,d 중 어느 값이 하나라도 변경되면 머클루트 도 변경된다.
   이는 곧 특정 노드값의 위변조를 알아차릴수 있다는 뜻으로 머클트리의 탄생배경의
   주된 이유라고 볼수 있을 만큼 제일 중요한 머클트리의 특징이다.

머클트리(Merkle Tree) 의 용도

그럼 이 머클트리는 왜 만들었을까?
요즘 이슈가 되고 있는 블록체인(Block Chain)은 각 블록(노드)마다 원장을 공유함으로써 특정
블록(노드)의 원장의 위변조를 검증할 수 있다는 게 가장 큰 특징이다.
그러면 모든 블록(노드)이 전체 거래원장을 가지고 있다면 어마어마한 용량의 PC가 있어야 하고
스마트폰에서는 블록체인 원장을 가지고 있을 수 도 없을 것이다.
물론 실제 이런 구조로 되어 있지도 않다.
노드(Node)는 크게 풀노드(Full Node)와 SPV노드(Simple Payment Verification)  로 분류할수
있다. 풀노드(Full Node)는 블록체인에 있는 모든 데이터를 자기의 로컬에 저장을 하는 노드
이며, SPV노드는 블록의 헤더값만 저장을 하는 노드입니다. 일반적인 블록체인의 블록들은
이 SPV노드이기 때문에 스마트폰과 같은 저장용량이 적은 경우에도 운용을 할수 가 있는
것이다.  따라서 SPV노드는 특정 거래를 검증을 위해서는 풀(Full Node) 로부터 데이터를
받아와서 비교를 해야 하는데 이때 쓰이는 것이 바로 머클트리(Merkle Tree) 이다.
SPV노드는 블록체인의 전체원장을 가지고 있지 않다고 했고, 대신 블록헤더(Block Header)라는
정보만 가지고 있는데 그 블록헤더에 머클루트(Merkle Root) 값이 저장되어 있다.
예를 들어 어떤 SPV노드가 있는데 이 노드에서 거래 c 에 대해서 진짜 유효한 거래 c 인지 
알고싶을때 SPV노드는 풀노드에게 물어본다. 그러면 풀노드는 SPV노드에게 H(d) , H(ab) 값을
전달해 준다. SPV노드는 H(c)를 만들어서 풀노드가 준  H(d)를 가지고  H(cd)를 만든다.
그리고 H(ab) 와 H(cd)를 가지고 H(abcd)를 만들어서 자기가 갖고 있는 블록헤더에 있는
H(abcd) 와 비교를 해서 같으면 c는 유효한 거래이고, 틀리면 먼가 위조된 거래인 것이다.
(요 방법을  머클패스(Merkle Path)  라고 함)


SPV노드

<출처 : https://blog.naver.com/mage7th/221457285394>

SPV노드는 위 그림과 같이 Chain으로 묶인 블록헤더(Block Header) 정보만을 가지고 있다.
그 안에  머클루트(Merkle Root) 값 즉, H(abcd) 값이 들어있다.

블록체인(Block Chain)의 용량은 시간이 갈수록 기하급수적으로 늘어나기 때문에  이제는 성능이
좋은 컴퓨터만 모든 블록체인을 다운받는 풀노드(Full Node)가 될수 있는데 이 머클트리(Merkle Tree)
방식은 우리가 들고 다니는 모바일 기기에서도 일부 블록체인만 다운받는 라이트노드(Light Node)
로도 특정 거래를 빠르게 찾을 수있게 해주는 역할을 한다.

728x90
반응형
LIST
728x90
반응형
SMALL

SW 변화 관리 ?

SW가 개발이 완료되어서 운영에 Release 되어서 사용자들이 사용을 하기 시작하며
당연히 오류,Error 가 발생을 하거나 사용자의 수정요청사항이 나오기 마련이다.
아무리 간단한 SW 프로그램이더라도 한번에 완벽하고 추가개발사항이 나올수 없는
프로그램은 이 세상에 존재하지 않는다고 할 수도 있을 만큼 SW에 대해서는 
끊임없이 유지보수를 통해 변화가 발생을 한다.
이때 SW에 대해 추가/수정 개발이 이루어지게 되는데 그 과정에서 해당 SW는 
어떤 일정한 패턴을 보이며 변화하고 진화하다는 논리가 바로 'Lehman의 SW 변화 원리'
이다.

Lehman SW 변화의 원리의 정의 및 개념

소프트웨어는 요구에 의해 계속적으로 변경되며, 변경에 따른 복잡성, 프로그램의 고유한 변경 추세,
SW조직 생산성의 일관성, 소프트웨어 각 버전의 변화에 대한 일관성을 제시한 개념이다.
즉 사용자 요구에 따른 SW의 계속적인 변경 시, SW 변화 관리 및 유지 관리를 위하여 활용하는
소프트웨어 변화의 법칙을 일컫는 말이다.


Lehman SW 변화의 원리의 중요성

소프트웨어 변화의 특성을 제대로 이해하고, 유지보수, 변경관리, 형상관리, 품질통제의 중요 
모델로 반영할 수 있으므로 효과적인 유지보수 및 변화관리가 가능하다. 
소프트웨어 변화의 특성을 반영하여 SW 조직(People), 프로세스(Process), 기술(Technology)에 반영하여
Baseline유지, CCB구성, 인력고도화, 버전관리 등을 설계하는 중요 원리로 사용할 수 있다.

Lehman 소프트웨어 변화의 법칙 주요 내용

구성요소 내용
Continuing Change
(
계속적 변경)
소프트웨어는 지속적으로 변경의 요청을 받는다. 이때 새로 개발하는 것보다는
수정하는 것이 경제적이라고 판단되는 동안은 변경을 가한다.
Increasing Complexity
(
복잡성 증가)
소프트웨어는 변경이 가해질 수록 그 구조는 복잡해진다.
Program Evolution
(
프로그램 진화)
프로그램 별 변경되는 고유 패턴/추세 가 있다.
Organizational Stability
(
조직적 안정)
개발 생산성이 변화에 민감하지 않고 안정적임. 즉 작업량에 큰 변화가 없음
Conservation of Familiarity
(친근성 유지)

소프트웨어 각 버전의 변화는 일정
- 소프트웨어는 규칙적인 수행 결과와 추이 보여주기 때문에 예측 가능

Continuing Growth
(지속적 성장)

- SW 생애주기동안, 사용자 만족 유지 위해 기능의 지속적 성장

Declining Quality
(품질 감소)

변화 지속 à 기능 증가, 품질 저하
- 엄격하게 관리/운영되지 않거나, 환경 변화에 미적응 시, 품질 감소

Feedback System
(피드백 시스템)

진화 프로세스는 다중레벨, 다중루프, Multi-Agent 피드백 시스템 수용,
중요 개선 달성 위해 피드백 필수


Lehman SW 변화 원리 적용 방안

< 출처 : 118회 정보관리기술사 두드림 >

 

728x90
반응형
LIST

'소프트웨어공학' 카테고리의 다른 글

기능점수 (Function Point) - 3탄  (0) 2019.10.04
기능점수 (Function Point) - 2탄  (0) 2019.10.03
기능점수 (Function Point) - 1탄  (0) 2019.10.02
SW 공학 - 소프트웨어 규모 산정  (0) 2019.10.01
COCOMO II  (0) 2019.09.02
728x90
반응형
SMALL

Customer Experience (CX) 란 ?
 
요즘 CX 즉 Customer Experience 라는 용어가 자주 등장한다.
예전에 Customer(고객) 과의 접점은 주로 영업사원,콜센터,판매직원 등 offline에서 이루어
지기 때문에 주로 그런 곳에서 고객에 대한 만족도를 중요시 했다. 그래서 가전회사에서
A/S를 위해 기사님이 방문하는 경우 엄청 친절하시고, 나중에 해피콜를 통해 만족도를
묻고 하는게 다 이런 고객 접점인 수리기사로부터 고객만족도를 끌어 올리기 위한 전략
의 일종이다.
하지만 지금은 단순한 offline 상의 고객의 경험에서 벗어나 택배를 통해 자사제품을
받아서 뚜껑을 여는 순간부터 그 제품을 online과 digital세계에서 사용하는 순간까지
확대된 범위에서의 소비자 경험, 즉 고객 경험(Customer Experience)를 뜻한다.
애플의 스티브 잡스는 제품을 기획할 때 기술보다는 사용자의 사용경험에 대한 아이디어를
착안하고 그에 맞는 기술을 선택 진화시켰다고 한다.

<출처 : https://blog.naver.com/yuhyojong/221331443775>

CRM 과 Customer Experience

이러한 Customer Experience 는 IT분야의 CRM (Customer Relationship Management) 솔루션
에도 필수적으로 적용되어지는 개념이 되고 있다.
전통의 CRM은 판매를 위한 잠재고객으로서 고객(customer)를 바라보고 일차원적으로 고객에게
물건을 팔면 그걸로 고객과의 관계(Relationship) 가 끝났었다. 하지만 지금은 고객과의 관계를
끊임없이 관리하고 체크함으로써 고객의 경험을 하나의 중요한 Data로 인식을 하게 되었다.

CRM 솔루션 소개

현재 CRM 솔루션의 대표 강자는 세일즈포스닷컴(salesforce.com) 이다. 그 뒤를 SAP 와 Oracle
이 2,3위 시장 점유율을 차지하고 있다.
세 기업 모두 CX(Customer Experience) 개념을 도입했으며, 모두 Cloud 형태의 SaaS 로 서비스
를 제공하고 있다.

  Salesforce.com SAP Oracle
특징 1. SaaS(Software as a Service) 형태로서 는 기존 설치형 솔루션보다는 비용이 저렴 
2.필요한 기능만을 선택해서 시스템을 구성할 수 있어서 보다 고객이 자유롭게 Customizing이 가능  
3.잠재고객 관리, 영업관리, 영업분석, 정확한 영업예측 등의 기능이 사용하기 편리하고 정확함.
.고객 경험(CX:Customer Experience)을  
  관리,지원할 수 있는 Front-End Platform으로 판매가 아닌 고객에 초점을 맞춘 새로운 버전인 SAP C/4 HANA를 2018년에 출시. 
2. 고객 데이터 보호,마케팅,커머스,세일즈, 고객 서비스 등 고객과 최접점에 있는 일명 '프론트 오피스' 기능을 모두 포함한 
  스위트 제품이다. 하이브리스(Hybris)를 비롯해 긱야(Gigya) 캘리더스클라우드 
  (CallidusCloud), 코로나(Corona) 등 지난 2013년부터 인수한 관련 솔루션들 통합해 '종합적인 고객 경험'을 제공
1.데이터와 사용자 경험, 비즈니스 성과를 연결하는 플랫폼으로 평가 
2.영업인력의 자동화를 넘어, 세일즈와 서비스, 마케팅, 커머스 역량이 통합된 서비스를 제공 
3.업데이트된 최신 혁신 기능은  
  - 새로운 오라클 데이터폭스(DataFox) 통합 기능 
  - 최신 AI 기반 세일즈 플래
    닝 기능 
  - 업무 기반의 UX와 적응
    형 검
 
  - 한층 똑똑해진 세일즈 
    비서
(Sales Assistant) 기능
제품 Sales Cloud Service Cloud 
Marketing Cloud 
Commerce Cloud 
Engagement Cloud 
Platform Cloud 
Integration Cloud 
Analytics Cloud
SAP Marketing Cloud 
SAP Commerce Cloud 
SAP Service Cloud 
SAP Customer Data Clouse  
SAP Sales Cloud
Oracle CX Marketing 
Oracle CX Commerce 
Oracle CX Sales 
Oracle CX Service
형태 SaaS (Software as a Service) SaaS (Software as a Service)  SaaS (Software as a Service) 
점유율 20% 14% 11%
레퍼런스 포춘(Fortune) 500대 기업의 83%가 사용 2015년도 까지는 CRM 시장점율 1위  

 

 

728x90
반응형
LIST
728x90
반응형
SMALL

신경망의 연결 가중치 최적화를 위한 경사하강법(Gradient Descent Algorithm)

경사하강법(Gradient descent)은 간단히 말해 우리가 고등학교 수학시간때 배운 미분의 개념을
최적화 문제에 적용한 대표적 방법 중 하나로서 함수의 local minimum을 찾는 방법 중 하나이다.
이 개념을 인공지능의 기계학습에 적용해서 기계학습시 예측의 오류를 줄이고 모델을 최적화
하기 위해 현재상태(신경망 가중치)의 기울기(미분)을 구하고, 여기서 기울기는 손실값
즉 (예측값-실제값)의 차이분을 가리키다. 이 상태에서 한 step을 나가서(하강해서) 다시
기울기(미분)을 구하고 또 한 step을 나가서 기울기를 구하고.. 를 반복해서 손실값 즉 
기울기(미분)값이 0 이되는 지점을 찾음으로서 최적해(손실값이 가장 작은) 를 찾는
알고리즘을 말한다.  (여기서 스텝량 step size 가 곧 학습률에 해당됨)
그래서  Gradient descent 방법을 다른 말로 steepest descent 방법이라고도 부른다.

좀더 쉽게 이야기를 해보자.
우리가 산속에서 지도나 나침반 없이 산정상을 오르는 방법은 현재 자신의 위치에서 
경사가 가장 가파른 쪽으로 이동하는 것이다. 산 정상이 어디인지는 모르나 일단 경사가 가파른
쪽으로 계속 올라가다 보면 산정상에 오를 수 있다. 이 방법을 Gradient Ascent (경사상승법)
이라하고, 그 반대로 산정상에서 지면으로 갈 때는 경사가 가장 가파르게 내려가는 곳을
따라 가면 된다. 이 방법을 Gradient Descent (경사하강법)  이라고 한다.


경사하강법(Gradient Descent Algorithm)의 메커니즘

<출처 : 118회 정보관리기술사 모임 두드림 >

Gradient (그레디언트) 란 ?

어떤 다변수 함수 f(x1,x2,...,xn)이 있을 때, f의 그레디언트(gradient)는 아래 식과 같이 각 변수로의
1차 편미분 값을 구성되는 벡터(vector)이다. 
그 이 벡터(vector)는 f의 값이 가장 가파르게 증가하는 방향을 나타낸다고 할수 있다.
그래서 벡터(vector)의 크기는 그 증가의 가파른 정도(기울기,미분)를 나타낸다.

예를 들어, f(x,y) = x2 + y2의 그레디언트(gradient)를 구해보면
이므로, (1,1)에서 f값이 최대로 증가하는 방향은 (2,2), 그 기울기는 ∥(2,2)∥= sqrt(8) 입니다.

반대로 그레디언트(gradient)에 음수를 취하면 즉, -▽f는 f값이 가장 가파르게 감소하는 방향을
나타내게 된다. 이러한 그레디언트(gradient)의 특성은 어떤 함수를 지역적으로
선형근사(linear approximation)하거나 혹은 함수의 극점(최대값, 최소값 지점)을 찾는
용도로 활용될 수 있다
<출처 : 블로그 : 다크 프로그래머 https://darkpgmr.tistory.com/133>

경사하강법 (gradient descent algorithm) 의 문제점

산속에서 정상을 찾기 위해서 경사가 가파른곳방향으로 이동을 해서 정상에 올라갔지만 막상
이 정상은 진짜 정상이 아니고 작은 봉우리였고 다시 내려갔다가 올라가보면 진짜 정상이
있는 경우가 있을 수 있다, 즉 local minimum에 빠지는 것이다.
또 하나의 문제점은 해에 근접할수록 |∇f|가 0에 가까워지기 때문에 수렴속도가 느려진다는 것이다
그렇다고 수렴속도를 조절하는 step size 를 너무 크게 하면 알고리즘이 발산할 수 있는
문제점이 있다.

 

728x90
반응형
LIST
728x90
반응형
SMALL

샤드(shard) 의 정의

샤드(shard) 란 데이터베이스를 물리적으로 분할하는 기법 중에서 수평분할 즉 수평 파티셔닝(partitioning) 
을 했을 때 그 분할된 파티셔닝을 가리키는 말이다.
데이터베이스를 분할 하는 이유는 다 아시겠지만 데이터의 양이 많아지면 그 만큼 성능이나 퍼포먼스가
떨어지게 마련이기 때문에 가용성,확장성,성능향상을 위해 물리적으로 데이터베이스를 분할하는 것이다.

샤드(shard) 분할 기준

샤드(shard) 단위의 결정은 분할 즉 샤딩(sharding) 을 어떤 기준으로, 어떤것을 Key로해서 분할(샤딩)
하느냐에 달려있다. 

< 출처 : 118회 정보관리기술사 두드림 모임>

위 그림에서 보는 봐와 같이 하나의 물리적 데이터베이스에 통으로 들어있는 대용량 DB를
어떤 분리 기준에 의한 분할 알고리즘을 통해서 Shard Key를 생성하고 이 Key값을 기준으로
해당 샤드(shard) DB에 저장하고 있다.
이 때 shard key를 정하는 방법에 따라 다음과 같이 분류할 수 있다.

구분 내용 특징 사례
vertical
partitioning
테이블 컬럼증가에 따른 수직으로 분할 -구현간단
-각 서버의 데이터가 커지
 면 추가 샤딩(sharding)이
 필요
회원마스터의 컬럼들을
기준으로 분리
- 회원 개인정보 shard
 
- 회원 가족 shard 
- 회원 학력 shard
range based partitioning 테이블 레코드의 증가에
따른 날짜나 지역 등으로
수평 분할
데이터를 분할하는 방법
이 예측 가능해야 함.
년도별로 테이블을 생성하거나 지역별로 테이블을 생성해서 저장
Key or Hash Based Partition 엔터티값을 hash 함수에 넣어서 나온 hash 값을  기준으로 어느 서버에 저할지를 결정  균등분할  사용자ID가 숫자로만 구성된 경우 이 ID를 일정한 숫자로 나눈 나머지값을 기준으로 저장할 서버 결정

 

DB 확장성 확보 방안

<출처 : 118회 정보관리기술사 모임 두드림 >


샤드(shard) 와 파티셔닝(partitioning) 의 차이점

파티셔닝(partitioning)이란 성능(performance), 가용성(availability) 또는 유지보수용이성(maintainability)를
목적으로 논리적인 데이터 엘리먼트들을 다수의 엔티티(table)로 쪼개는 행위를 뜻하는 일반적인
데이터베이스 용어이다.
샤딩(sharding)은 수평 파티셔닝(horizontal partitioning)과 동일하다.
데이터베이스를 샤딩하게 되면 기존에 하나로 구성될 스키마를 다수의 복제본으로 구성하고 각각의 샤드에
어떤 데이터가 저장될지를  shard key를 기준으로 분리한다. 
예를 들면, 나는 고객의 데이터베이스를 CustomerId를 샤드키로 사용하여 샤딩하기로 하였다.
0 ~ 10000 번 고객의 정보는 하나의 샤드(shard)에 저장하고 10001 ~ 20000 번 고객의 정보는
다른 샤드(shard)에 저장하기로 하였다.
요약하면 파티셔닝은 퍼포먼스, 가용성, 정비용이성등의 목적을 위해 논리적인 엔티티들을 다른 물리적인
엔티티들로 나누는것을 의미하는 일반적인 용어이다. 수평 파티셔닝 또는 샤딩은 스키마 복제 후
샤드키를 기준으로 데이터를 나누는것을 말한다. 수직 파티셔닝(vertical partitioning)은 스키마를 나누고
데이터가 따라 옮겨가는것을 말한다. (발췌: 아이군의 블로그 http://theeye.pe.kr/archives/1917)

728x90
반응형
LIST

+ Recent posts