IT's 잡탕찌개 블로그

O.R.M(Object Relational Mapping) 이란 무엇인가

간단히는 C#의 property / Java의 getter,setter를 이용하여

객체지향프로그래밍(O.O.P)의 객체와 관계형 데이터베이스 간의 Mapping을 지원해주는

Framework 혹은 Tool들을 의미한다.

그렇다면 ORM에는 어떤 것들이 있을까?

대표적으로 아래의 ORM들이 가장 대중적이다.

• MyBatis.
• iBatis.
• JPA.
• Hibernate

이 중 MyBatis, ibatis가 많이 쓰인다고 한다.

그렇다면 ORM들의 장단점은 어떨까

우선 장점에 대해서 알아보자.

1. 개발자로 하여금 좀 더 직관적이고 로직에 집중할 수 있게 도와준다.

 - SQL이 아닌 객체에 접근해서 Data를 조작하기 때문에 좀더 직관적이다.

 - SQL사용시 필요한 부수적인 코드들을 줄일 수 있다.

 - 객체에 관해 코드를 작성하므로 가독성이 높아진다.

2. 코드 재사용성 증 및 유지보수의 편리성이 증가한다.

 - Mapping 정보를 명확히 하기 때문에 ERD를 일일히 확인하지 않아도 된다.

 - MVC패턴에 활용하기 쉽다.

3. DBMS에 대한 종속성을 줄일 수 있다.

 - 개발자는 객체 정의에 집중함으로써 DBMS를 교체하는 등의 작업에서 작업 시간, 리스크를 줄일 수 있다.

4. SQL을 몰라도 독립적으로 개발이 가능하다.

반대로 단점들은 무엇이 있을까

1. 오롯이 ORM만 사용해서 모든 서비스를 구현할 수 없기 때문에 DBMS로 부터 완벽히 독립할 수 없다.

 - 필요한 경우 DBMS를 사용해야 하는 상황이 발생한다.

2. ORM으로 인해 프로젝트의 복잡성, 난이도가 증가할 수 있다.

3. 잘못된 사용으로 인해 속도가 느려지거나 기타 문제가 발생할 수 있다.

4. DBMS의 고유 기능을 사용 못하는 경우가 발생한다.

5. 프로시저 사용이 많은 환경에서는 ORM 적용으로 얻는 장점을 활용하기 힘들다.

 - 기존의 프로시저를 많이 사용하던 경우, 일일히 객체와 Mapping 시켜줘야 하며,

   이 과정에서 비용(리스크, 시간소모 등)이 발생한다.

 - 예 : User라는 table에 대해서 Person, Address 라는 객체를 구분해서 생성하는 경우

6. The Object-Relational Impedance Mismatch( 객체와 DBMS의 불일치성 ?)

 - Granualrity ( 세분성 )

    . 경우에 따라서 DB의 Table 명세보다 객체를 과도하게 만들 수 있다.

      -> User라는 Table이 Person, Address라는 클래스로 구분해서 생성하는 경우 등등

 - Inheritance ( 상속 )

    . ORM에서는 상속 개념을 사용할 수 없다.

 - Identity ( 일치 )

    . RDBMS에서는 Pk값등으로 일치여부를 판별하지만 자바는 객체주소 비교, 객첵밧 비교를 모두 지원한다.

 - Associations ( 연관성 )

    . 객체 지향 언어는 Referance를 통해 객체를 참조하지만 RDBMS는 외래키로 객체를 참조한다.

     -> 이 경우 쌍방향 참조를 할 때 java는 각 객체가 서로를 참조할 변수를 지녀야 하지만

         RDBMS는 외래키만 참조하면 된다.

      -> 즉, Java의 경우 방향정을 지니며 RDBMS는 방향성을 지니지 않는다.

 - Navigation ( 탐색 / 순회 )

    . Java의 경우 객체간의 연결을 통해서 이동하며 탐색/순회 한다

    . RDBMS에서는 일반적으로 쿼리를 최적화하여 엔티티를 탐색 및 선택한다.

예제 및 내용 출처 : http://www.gamedevforever.com/83

비교적 최근에 알게된 개념인데 LockFree라는게 있다.

맨처음에 LockFree라는 이름만 듣고는 Lock을 안쓰는 알고리즘같은건줄 알았다.

근데 좀 딴얘기라서 당황

LockFree가 하는일은 무엇일까?

우선적으로 알아둬야 할 개념으로서 Atomic 연산이 있다.

"Atomic연산은 일련의 모든 연산이 끝나기 전에는 다른 프로세스가 해당 연산에 대해서 

어떠한 변화도 줄수 없어야 한다. 또한 전체 연산 중 어느 하나라도 실패할 경우 

모든 연산은 실패하며 시스템은 연산이 시작하기 전으로 복구되어야 한다."

사실 아직도 위글만 보면 감이 좀 안잡히는데 중요한건 아래 내용이다.

특정 값이 예상한 값과 같다면 다음단계로 넘어가고, 

만약 변경되었을 경우 해당 연산을 다시 시작하도록 한다.

윈도우에서는 CAS(Compare And Swap)을 Interlocked함수를 활용하여 구현한다

LockFree를 사용하는 이유는 어떤 블로그에서 읽었는지 기억은 안나지만 아래의 이유였다.

" LockFree는 lock을 사용않아도 되도록 하는것이 아니라 여러 스레드에서 lock을 요청할 때 

발생할 수 있는 데드락을 막고 최소한 하나의 스레드가 작업을 수행할 수 있도록 해주기 때문이다. "

사실 이 LockFree알고리즘에 대해서 ABA문제라던가 아니면 들인 노력에 비해서 미비한 효과라던가 하는 포스팅도 볼 수 있는데 이부분은 좀더 알아본 후 추가 포스팅으로 작성할 것이다.

마무리로 간단한 예제를 적어본다.

1. void Push(Node* pNewNode)  
2. {  
3.  do {  
4.    Node* t = pTopNode;  
5.    pNewNode->pNext = t;  
6.  } while( !CAS(&pTopNode, t, pNewNode) );  
7. }  

메모리 거짓공유라는 용어가 있다. [MemoryFalseSharing]

인터넷에서는 거의다 메모리 거짓공유라고 부르는데 해당 용어에 대해서 알아본후에

개인적으로는 잘못된 메모리공유가 좀더 의미가 명확한 것 같다.

MemoryFalseSharing이란 무엇일까?

우선 이에 대해서 설명하기 전에 메모리 캐싱에 대해서 간략하게 알아보려고한다.

컴퓨터는 특정 데이터를 참조할때 훑어보는 순서가 있다.

바로 메모리들의 계층구조에 의한 순서인데 레지스터-캐시-메모리-하드디스크 순이다.

위의 순서대로 읽는 속도가 빠른것은 검색해보시면 바로 알수있으니 생략한다.

컴퓨터는 특정 데이터를 찾았다면 아래와 같은 가정을 통해 효율을 높이도록 되어 있다.

1. 현재 읽은 데이터는 다시 읽힐 확률이 높다.

2. 현재읽은 데이터 주변의 경우 빠른시일내에 참조될 확률이 높다.

아는게 적어서 개념적으로 간단하게 살펴보겠다.

위 코드에서 변수 i의 경우가 1번에 해당한다고 보면 된다. i의 경우 반복문 횟수만큼의 접근이 필요하기 때문에 캐시를 해두는 것이 성능에 좋을 것이다.

그리고 그 밑의 sum의 경우 arr에 대해서 연속적으로 참조를 하고 있다.

배열의 경우 메모리상에서 연속적으로 할당되어 있기 때문에 처음으로 참조한곳외에도 주변지역에 대해서 참조하게 되는 경우이다.

간단하게나마 예를 들어서 설명해봤는데 사실 능력자가 아니라 확실한 예가 되었는지는 잘 모르겠다.

아무튼 이 두가지에 의거해서 컴퓨터는 캐시를 관리하는데 이러한 캐시들이 얼마나 잘 적중하는지에 따라서 성능에 영향을 미친다.

그렇다면 캐시가 MemoryFalseSharing과 어떤 상관이 있는지 알아보자.

컴퓨터가 위의 두 작업을 위해서 특정 data를 참조시 우선적으로 현재 캐시메모리[L1]에 있는지를 확인한다.

만약 data가 없을 시 현재 캐시메모리에 있는 캐시라인을 비우고(flush) data을 찾은 후 

그 근처에 있는 주소를 캐시라인에 다시 채워준다.

그러나 이 때 MemoryFalseSharing이 발생하는 경우가 생긴다.

예를 들면 스레드A와 스레드B가 작업을 진행했는데 

참조하는 영역이 미묘하게 겹친다고 생각을 해보자.

AAAACCCCCCCCCCCBB

A : A가 캐시라인에 넣을 영역

C : A와 B 둘다 캐시라인에 적재할 영역

B : B가 캐시라인에 넣을 영역

자 이제 A가 우선 캐시라인에 넣는다고 생각을 해보자.

기존에 있던 캐시라인을 flush한 후 A의 참조영역을 캐시라인에 저장한다.

그 후 B가 다시 데이터를 참조한다.

여기까진 괜찮지만 다시 A가 캐시라인을 확인할 때 MemoryFalseSharing가 발생하게 된다.

A가 캐시라인을 읽을 때 C영역에 대해서 데이터가 변경되었을 확률이 있기때문에 

캐시라인을 비우고 다시 A영역에 대해서 캐시라인을 채우게 된다.

이러한 경우가 바로 MemoryFalseSharing이다.

이해한 내용 기반으로 포스팅했기때문에 세부적인 성능차이에 대해서는 코딩을 통해서 확인해봐야할 것 같다.

최근에 C#으로 Server프로그래밍을 하다가 일반적인 generic 컨테이너외에도 Concurrecny가 붙어있는 컨테이너들이 존재한다는 것을 알게 되었다.

이때는 단순히 동시접근에 대해서 내부적으로 관리해주는 컨테이너라고만 알고있다가 

심심해서 단어를 검색해봤는데 Parallelism과 다른 의미를 지닌다는 것을 알게되었다.

다른 블로그에서 정리되어 있는 글들을 보고 내가 이해한 내용은 아래와 같다.

Parallelism과 Concurrency는 각각 평행성, 동시성이라는 의미를 지닌다.

이 둘은 언뜻 비슷한것 아닌가라는 생각이 들수 있지만 엄연히 다른것이다.

우선 대표적인 Parallelism은 멀티스레딩이라고 생각한다.

이는 멀티스레딩이 여러개의 스레드가 '평행적'으로 실행되기 때문이다.

반대로 대표적인 Concurrenct는 유니티의 코루틴이라고 생각한다.

Concurrenct가 의미하는 동시성이라는 의미는 같은 스레드 내에서 '동시'에 실행되는 것이라고 생각한다.

유니티의 경우 우선 싱글스레드 기반으로 작동하며 하나의 스레드 내에서 코루틴을 활용하여 일종의 서브루틴을 만듦으로써 마치 일종의 '비동기'함수처럼 활용할 수 있기 때문이다.

Concurrency의 장점은 유니티의 코루틴이 충분히 보여주고 있다고 생각한다.

기존의 Parallelism의 경우 멀티스레드를 통해서 많은 작업을 빠르게 처맇라 수 있지만

Lock, 버그등을 생각해본다면 Concurrency한 로직으로 구현하는 것도 충분히 좋은것 같다