DB Tips

다음은 wikipedia에 기재되어 있는 No Sql의 정의이다.

NoSQL is a movement promoting a loosely defined class of non-relational data stores that break with a long history of relational databases. These data stores may not require fixed table schemas, usually avoid join operations and typically scale horizontally. Academics and papers typically refer to these databases as structured storage.^[1][2][3][4]

Notable production implementations include Google's BigTable and Amazon's Dynamo. However, there are also many publicly available open source variants including MongoDB and Cassandra.

NoSQL이란, 관계 데이타베이스의 긴 역사의 틀을 깨는 것으로서 넓은 의미로의 비관계 모델에 속하는 데이터 스토어의 발전을 촉진 시키려고 하는 운동이다. 비관계 모델의 데이터 스토어의 특징으로서 고정된 테이블 스키마를 필요로하지 않고, Join을 필요로 하지 않고 일반적인 수평 스케일을 확보하는 것을 들 수 있다. 학술 논문이나 정식문서에서는 이런 종류의 데이타베이스를 Structured Storage라고 부르는 것이 많다.^[1][2][3][4]

구글의 BigTable ,아마존의 Dynamo, 오픈 소스는 MongoDB , Cassandra등이 있다.

아무리 새로운 지식이나 기술이 나와도 기존에 구축되어 있는 기반기술에 대해 적개심이나, 반감은 되도록 갖지 않는것이 좋다.

Facts and Fallacies of Software Engineering에서 말하는 소트프웨어 업계에는 과대선전이 만연해 있다고 주장하는 것도 일리가 잇는 말이다. 왜냐하면 소프트웨어 도구와 기술의 진보로 인해 생산성과 품질이 5~35% 향상된다고 하고는 있지만, 그러나 예전에도 이 정도의 향상은 10배 이상 뛰어난 사람이 있으면 가능한 일이었다.

또한 뭔가 새로운 것을 배울 때 비용이 수반되는 것은 명확한 문제이기도 하고 새로운 커버리지를 사용해 테스트 프로세스에 지니는 의미를 생각하는 것이든, XP를 하면서 새로운 기법으로 개발을 하든, 우리가 인정할 수 있는 것은 기존의 비 효율을 알고 새로운 도구의 효율을 알고 있을 때 모두가 인정할 수 있는 기틀을 마련해 줄 수 있지 않을가 한다.

이는 No sql! No sql 단어 하나만을 보더라도 기존의 Sql은 여전히 가치가 있다는 강한 반증이기도 하다.
그 파워가 얼마나 막강하면 No sql운동까지 생겨났을까? 그래서 어떤 새로운 패러다임이 나올 때 기존의 지식을 완전히 버리려는 위험한 생각은, 자칫 잘못 생각하면 고스란히 무대앞에서 혼자 춤추는 꼴을 보이게 될 것이다. 그리고 기존의 관념을 무시하는 것보다 차차 서로 변해가자는 것이 오히려 호소성 있는 주장이라 할 수 있을 것이다.




이미 사용한 SQL의 실행계획을 개선시켜 수행속도를 향상시키는 것도 중요하지만 우리는 무엇보다도 먼저 SQL을 잘 활용하는 방법을 익혀 두는 것이 필요하다. SQL을 잘 사용한다는 사실은 상당히 많은 의미를 내포하고 있다. 제대로 SQL을 활용한다는 것은 어쩌면 지금까지 구현해 왔던 거의 모든 처리 방법의 근본적인 변화를 의미한다. 혁신이 필요하다는 이야기다. 그러나 대부분의 개발자들은 처음 정보시스템을 접하면서부터 지금까지 절차형으로 처리하는 방법만 접해왔기 때문에 비절차형이면서 집합적으로 처리하는 방법에 대해서는 매우 낮설다. 또한 그들은 애플리케이션이라면 당연히 한 레코드 씩 차례로 읽어 가면서 각각의 경우에 따라 마치 곡예를 하듯이 모든 처리 방법을 일일이 자신이 기술해야만 한다는 그릇된 책임감을 버리지 못하고 있다.

1. SQL활용의 당위성

어떤 처리를 위해 여러 번의 SQL을 반복 수행시키거나 여러 가지 SQL을 사용하는 것은 한두 가지의 SQL로 처리되도록 하는 것보다 불리하다. 이것은 단지 SQL 수행 횟수에 대한 차이 외에도 훨씬 다양하고 중요한 이유들을 가지고 있다.

2. SQL 수행 횟수의 차이

우리가 10000건의 데이터를 처리하기 위해 한건씩 읽어내는 SQL로 10000번을 수행한 경우와 하나의 SQL로 10000건을 범위 처리로 수행한 경우를 서로 비교해 보자. 이 두가지의 경우는 처리 방법의 차이만 있을 뿐이지 처리한 로우의 수는 동일하다. 그러나 SQL이 수행된 회수만 놓고 비교해 보면 10000배의 차이가 난다.

3. 랜덤 액서스 발생의 차이

관계형 데이터베이스의 수행속도에 가장 많은 영향을 미치는 경우는 인덱스를 경유하여 넓은 범위의 데이터를 처리하고자 할 때이다. 그 이유는 인덱스를 액세스하는 부담때문이 아니라 인덱스에 있는 ROWID로 테이블을 랜덤으로 액세스하기 때문이다. 만약 우리가 위의 예와 같이 인덱스까지도 랜덤으로 넓은 범위를 액세스해야 한다면 이미 수행 속도의 향상은 도저히 기대할 수가 없을 것이다.
그리고 그 차이는 몇 백초, 몇 시간의 차이로 나타날 수 있는 것이다. 이것은 개발자가 결정할 수 있는 문제는 아니다. 고객은 항상 빠른 것을 원하기 때문이다.

4. 처리경로 최적화의 차이

각각의 최적화가 전체의 최적일 수는 없다. 가령 생산자의 입장에서 최적은 판매가 되든 말든 지속적으로 다량을 생산하는 것이 가장 최적일 것이요, 판매자의 입장에서 보면 구매자가 요구하는 다양한 제품을 즉시 생산해 주는 것이 최적일 것이다. 전체적인 입장에서의 최적이 아니라 특정 부분에 대한 최적이 강요되면 오히려 전체적인 최적화에 역행되는 경우가 많다. 우리가 원하는 것은 전체적인 처리가 최적화되는 것이지 특정한 단계의 최적화는 아니다.

5. 클라이언트 / 서버환경에서의 SQL 역할

누차 강조했지만 SQL이 분리되면 그 사이에는 엄청난 깊이의 계곡이 파여 있는 것과 같아서 수많은 사용자의 절차형 처리가 있어야 메워지게 되어 있다. 관계형 데이터베이스의 장점을 살리려면 반드시 대부분의 처리를 데이터베이스가 가장 효율적으로 처리하도록 종합적인 SQL을 만들어야 하게쓴데 도대체 이러한 SQL을 사용할 수가 없게 만들어져 잇으니 참으로 난감하지 않을 수 없었다.

6. 처리경로 개선의 용이성

비록 문제는 있지만 SQL의 활용을 제대로 한 경우에는 문제의 핵심만 찾아내어 액세스 효율을 개선해주면 수 배에서 많게는 수백 배의 효율이 쉽게 향상된다. 한번의 SQL수행은 최적화되었으나 수행한 횟수를 보면 천문학적인 숫자가 나와있는 것이 보통이다. 아무리 한번 수행에 0.01초 이하로 최적화되었더라도 이것이 10000,100000,1000000번 수행되었다면 티끌이 모여서 태산이 된다. 어떤 프로젝트에서는 조인이 전혀 없는 곳도 있으며 더욱 놀라운 것은  Group By가 전혀 없는 곳도 잇다는 것이다. 액세스를 효율화시키는 방법은 대용량 데이터베이스 솔루션의 전편에 걸쳐 설명되었으므로 여기서는 다시 언급하지 않겠다.

7. 병렬처리에서 SQL의 역할

병렬 처리의 수행속도에 큰 영향을 주는 요소는 정렬 영역뿐만 아니라 데이터가 물리적으로 얼마나 잘 분산되어 있어 I/O의 경합을 피할 수 있느냐는 것도 매우 중요하다. 데이터의 분산을 위해서 데이터베이스에 따라 데이터를 분산 저장하는 방법이 서로 다르다. 정말 중요한 것은 SQL을 어떻게 사용하였느냐에 있다. 병렬처리는 SQL로 수행된다. 우리가 해야할 전체적인 처리 중에서 얼마나 많은 부분이 SQL로 통합되었느냐가 결국 얼마나 많은 처리를 병렬로 처리할 수 있느냐의 관건이 된다. 동일한 데이터 100만건을 단순하게 액세스만 하거나 정렬을 하는데 어떤 데이터베이스가 조금 더 빠르더라라는 사실은 그렇게 중요한 것이 아니다.
.. 그렇다면 우리는 자신이 해야 할 처리를 SQL내로 통합할 수 있도록 연구를 해야 할 것이며 그러한 처리가 가능하도록 데이터베이스의 우수한 SQL기능을 제공하는 것이야 말로 병렬 처리의 수행속도 향상에 보다 큰 비중을 차지한다고 하겠다.