이 시리즈 전체에서 필자는 다수의 비관계형 데이터 저장소(총칭하여 NoSQL)를 사용자와 공유했다. 최근 기사에서는 문서 중심 데이터 저장소(CouchDB)와 스키마 중심 관계형 데이터베이스의 엄청난 차이에 대해 설명했다. 게다가 CouchDB의 전체 API는 RESTful이며 다른 조회 방법(JavaScript에 정의된 MapReduce 함수)를 지원한다. 이 부분은 기존의 JDBC와 명백히 구분된다.

또한 필자는 최근에 관계형 또는 문서 중심 데이터 솔루션이 아니어서 어떤 방식으로도 JDBC를 지원하지 않는 Google의 Bigtable에 대한 기사를 작성했다. Bigtable은 키/값 저장소로 알려져 있다. 즉, Bigtable은 스키마가 없고 주차 티켓, 레이스 목록 또는 레이스에 참여한 러너의 인스턴스 등 원하는 모든 항목을 기본적으로 저장할 수 있게 한다. Bigtable에 스키마가 없다는 사실은 엄청난 유연성을 부여하여 신속하게 개발을 수행할 수 있도록 한다.

Bigtable은 항목을 선택해야 하는 키/값 데이터 저장소이기만 한 것은 아니다. Amazon에는 Amazon SimpleDB라는 자체 클라우드 기반 키/값 저장소가 있다. Bigtable은 Google App Engine에 의해 촉진되는 추상화를 통해 Java 개발자에게 노출되지만 Amazon의 SimpleDB는 웹 서비스 인터페이스를 통해 노출된다. 따라서 웹과 HTTP를 통해 SimpleDB 데이터 저장소를 조작할 수 있다. Amazon의 웹 서비스 인프라 위의 바인딩을 사용하면 선택한 언어(PHP, Ruby, C# 및 Java 언어가 포함됨)를 사용하여 SimpleDB를 활용할 수 있다.

이 기사에서는 Amazon의 공식 SDK를 사용하여 SimpleDB를 소개한다. 필자는 또다른 레이스로 돌아가기 예제를 사용하여 이 강력한 클라우드 기반 데이터 저장소의 특이한 면 중 하나(사전 편집순 검색)에 대해 설명한다.

SimpleDB 소개하기

기본적으로 SimpleDB는 Erlang으로 작성된 광범위하게 확장 가능한 고가용성 데이터 저장소이다. 개념적으로는 Amazon의 S3와 비슷하다. 하지만 S3에는 버켓에 오브젝트가 있고 SimpleDB는 항목이 포함된 도메인으로 논리적으로 정의된다. 또한 SimpleDB에서는 항목이 속성을 포함할 수 있다. 도메인은 S3의 버켓이나 관계형 관점에서의 테이블(더 적절한 표현은 Bigtable의 "유형" 표기법)과 매우 비슷한 것으로 생각하면 된다. 하지만 SimpleDB는 Bigtable과 마찬가지로 스키마가 없기 때문에 SimpleDB의 개념에 관계형 관점을 적용하지 않도록 주의한다. 도메인에는 다수의 항목(행과 비슷함)이 포함될 수 있고 항목에는 다수의 속성(관계형 관점에서의 열과 비슷함)이 포함될 수 있다.

속성은 단순히 이름/값 쌍(Bigtable과 비슷함)이며 "쌍"이라는 것은 하나의 값으로 제한되지 않는다. 즉, 속성 이름은 연관된 값의 콜렉션(또는 목록)을 포함할 수 있다. 예를 들어, 단어 항목은 다중 정의 속성 값을 가질 수 있다. 게다가 SimpleDB에 있는 모든 데이터는 String으로 표시되며 이는 일반적으로 많은 데이터 유형을 지원하는 표준 RDBMS 또는 Bigtable과 확연히 다르다.

SimpleDB의 속성 값에 대한 단일 데이터 유형 접근 방식은 관점에 따라 장점이 될 수도 있고 제한사항이 될 수도 있다. 어느 방식을 사용하든 쿼리가 실행되는 방식에 대한 의미가 포함되어 있다. 또한 SimpleDB는 상호 도메인 결합 표기법을 지원하지 않으므로 다중 도메인에 있는 항목에 대해서는 쿼리를 수행할 수 없다. 하지만 다중 SimpleDB 쿼리를 수행한 후 사용자측에서 결합을 수행하여 이러한 제한사항을 극복할 수 있다.

Bigtable과 마찬가지로 항목에는 키가 자체적으로 포함되어 있지 않다. 항목의 키 또는 고유 ID는 항목의 이름이다. 또한 SimpleDB는 해당 항목의 속성이 변경된 경우 중복 작성 요청이 발생되면 항목을 업데이트할 수 있다.

다른 Amazon Web Services와 마찬가지로 SimpleDB는 HTTP를 통해 모든 항목을 노출하므로 여러 가지 방법으로 인터페이스를 제공한다. Java 환경에서는 옵션의 범위가 Amazon의 자체 SDK(뒤이어 나오는 예제에서 사용함)에서 Topica라는 유명한 프로젝트와 성숙한 JAP 구현(Part 2에서 다룸)에까지 이른다.

위로

클라우드에서의 레이싱

지금까지 이 시리즈에서는 레이스와 주차 티켓 비유를 사용하여 다양한 Java 2.0 기술의 기능에 대해 설명했다. 익숙한 문제 도메인을 사용하면 시스템 간 차이점과 공통점을 더 쉽게 알 수 있다. 따라서 이번에는 결승선 비유를 사용하여 Amazon의 SimpleDB에서 러너와 레이스가 어떻게 표시되는지 확인한다.

SimpleDB에서는 레이스를 도메인으로 모델링할 수 있다. 레이스 인스턴스는 SimpleDB의 항목이 되고 해당 이름과 날짜는 값이 포함된 속성으로 표현된다. 이 경우 이름은 항목 자체의 이름이 아니라 속성이라는 것에 유의해야 한다. 항목 인스턴스에 제공하는 이름이 키가 된다. 이 항목의 키는 마라톤의 이름이 될 수 있다. 또는 하나의 특정 시점으로 레이스 인스턴스를 제한하는 대신(레이스는 연례 행사인 경우가 많음) 항목에 고유 이름(예: 시간소인)을 제공하여 복수의 격년 레이스를 SimpleDB에 저장할 수 있다.

마찬가지로 runner는 도메인이 된다. 개별 러너는 항목이 되고 러너의 이름과 연령은 속성이 된다. 레이스의 경우와 마찬가지로 각각의 runner 항목 인스턴스에는 고유 이름이 필요하다(예: Marty Howard와 구별되는 Pete Smith). Bigtable과는 달리 SimpleDB에서는 사용자가 각 항목에 지정하는 이름에 신경을 쓰지 않기 때문에 실제로 키 생성기를 제공하지 않는다. 이 경우에는 시간소인을 사용하거나 각각의 러너에 대한 카운터를 증분할 수 있다(예: runner_1, runner_2 등).

스키마가 없기 때문에 개별 항목의 속성은 다양하다. 마찬가지로 원하는 경우에는 도메인에 다양한 항목을 보유할 수 있다. 하지만 데이터가 정돈되지 않아 찾거나 관리하는 데 어려울 수 있기 때문에 이러한 가변성을 제한할 수 있다. 스키마 없는 정돈되지 않은 무질서한 데이터는 재앙으로 가는 지름길이라는 것을 잊어서는 안 된다.

Amazon SDK로 시작하기

Amazon은 최근에 SimpleDB를 포함하여 모든 웹 서비스에 대해 작업하는 데 필요한 코드가 포함된 라이브러리를 표준화했다. 이 라이브러리는 이러한 서비스에 액세스하여 사용하기 위해 필요한 기본 통신을 추출하여 클라이언트가 원래 방식대로 작업할 수 있도록 한다. 예를 들어, Amazon의 SimpleDB용 Java 라이브러리를 사용하면 도메인과 항목을 작성한 후 해당 도메인과 항목에 대해 쿼리할 수 있는 것은 물론 해당 도메인과 항목을 업데이트하고 —스토리지에서 제거할 수 있다. 그동안 이러한 조작이 HTTP를 통해 클라우드로 이동하는 것을 인식하지 않는다.

Listing 1에서는 Races 도메인과 함께 평범한 Java 코드를 사용하여 정의된 AmazonSimpleDBClient를 보여 준다. (워크스테이션에서 이러한 예제를 복제하려는 경우에는 Amazon에 계정을 작성해야 한다.)

AmazonSimpleDB sdb = new AmazonSimpleDBClient(new PropertiesCredentials(
                new File("etc/AwsCredentials.properties")));
String domain = "Races";
sdb.createDomain(new CreateDomainRequest(domain));

Request 오브젝트의 Amazon SDK 패턴은 모든 SimpleDB 활동을 위해 남아 있는다. 이 경우 CreateDomainRequest를 작성하면 도메인이 작성된다. Listing 2에 있는 것과 같은 항목의 List를 반드시 사용하는 클라이언트의 batchPutAttributes 메소드를 통해 항목을 추가할 수 있다.

List<ReplaceableItem> data = new ArrayList<ReplaceableItem>();

data.add(new ReplaceableItem().withName("Race_01").withAttributes(
   new ReplaceableAttribute().withName("Name").withValue("Charlottesville Marathon"),
   new ReplaceableAttribute().withName("Distance").withValue("26.2")));

Amazon의 SDK에서 Item은 ReplaceableItem 유형으로 표시된다. 각각의 인스턴스에 이름(즉, 키)을 제공한 후 속성(ReplaceableAttribute 유형)을 추가할 수 있다. Listing 2에서는 단순 키 "Race_01"을 가진 마라톤이라는 레이스를 작성했다. Listing 3과 같이 BatchPutAttributesRequset를 작성한 후 AmazonSimpleDBClient에 전송하여 Races 도메인에 이 인스턴스를 추가한다.

sdb.batchPutAttributes(new BatchPutAttributesRequest(domain, data));

위로

SimpleDB의 쿼리

레이스를 저장했으므로 당연히 SimpleDB의 쿼리 언어(SQL과 매우 비슷함)를 통해 해당 레이스를 검색할 수 있다. 하지만 한가지 주의사항이 있다. 모든 항목 속성 값은 String으로 저장된다고 한 필자의 말을 기억하고 있는가? 즉, 데이터 비교는 사전 편집순으로 수행되며 이는 검색에 영향을 미친다.

예를 들어, 숫자를 기반으로 쿼리를 실행하면 SimpleDB는 실제 정수 값이 아니라 문자를 기반으로 검색한다. 지금 SimpleDB에는 하나의 레이스 인스턴스가 저장되어 있으며 Listing 4와 같이 SimpleDB의 SQL 유사 명령문을 사용하여 쉽게 해당 인스턴스를 검색할 수 있다.

String qry = "select * from `" + domain + "` where Name = 'Charlottesville Marathon'";
SelectRequest selectRequest = new SelectRequest(qry);
for (Item item : sdb.select(selectRequest).getItems()) {
 System.out.println("Race Name: " + item.getName());
}

Listing 4에서의 쿼리는 일반적인 SQL처럼 보인다. 이 경우 필자는 단순히 Race에서 Name이 "Charlottesville Marathon"과 동일한 모든 인스턴스를 요청한다. SelectRequest를 AmazonSimpleDBClient에 전송하면 Item의 콜렉션이 결과로 생성된다. 이와 같이 항목에 대해 반복하여 이름을 인쇄할 수 있으며 이 경우에는 하나의 항목만 다시 수신된다.

그러면 이제 Listing 5와 같이 다른 거리 속성을 가진 또다른 레이스를 추가하면 무슨 일이 발생하는지 살펴보자.

List<ReplaceableItem> data2 = new ArrayList<ReplaceableItem>();

data2.add(new ReplaceableItem().withName("Race_02").withAttributes(
   new ReplaceableAttribute().withName("Name").withValue("Charlottesville 1/2 Marathon"),
   new ReplaceableAttribute().withName("Distance").withValue("13.1")));

sdb.batchPutAttributes(new BatchPutAttributesRequest(domain, data2));

거리가 다른 두 레이스가 있는 경우에는 Listing 6과 같이 거리를 기반으로 검색하는 것이 적절하다.

String disQry = "select * from `" + domain + "` where Distance > '13.1'";
SelectRequest selectRequest = new SelectRequest(disQry);
for (Item item : sdb.select(selectRequest).getItems()) {
 System.out.println("Race Name: " + item.getName());
}

역시나 Race_01이 리턴된다. 26.2는 수학적으로나 사전 편집순으로나 13.1보다 크기 때문에 이 결과는 올바른 것이다. 하지만 매우 긴 레이스를 추가하면 무슨 일이 발생하는지 살펴보자.

List<ReplaceableItem> data3 = new ArrayList<ReplaceableItem>();

data3.add(new ReplaceableItem().withName("Race_03").withAttributes(
   new ReplaceableAttribute().withName("Name").withValue("Leesburg Ultra Marathon"),
   new ReplaceableAttribute().withName("Distance").withValue("103.1")));

sdb.batchPutAttributes(new BatchPutAttributesRequest(domain, data3));		

Listing 7에서는 거리가 103.1인 레이스를 추가했다. Listing 6의 쿼리를 다시 실행하면 어떤 결과가 발생할까? 그렇다. 103.1이 사전 편집순으로 13.1보다 작기 때문에 103.1이 결과로 리턴된다. Leesburg Ultra Marathon이 목록에 표시되지 않는 이유가 바로 이때문이다.

이제 Listing 8과 같이 더 짧은 레이스를 검색하는 다른 쿼리를 실행하면 어떤 일이 발생하는지 살펴보자.

String disQry = "select * from `" + domain + "` where Distance < '13.1'";
SelectRequest selectRequest = new SelectRequest(disQry);
for (Item item : sdb.select(selectRequest).getItems()) {
 System.out.println("Race Name: " + item.getName());
}

의심을 가지고 있지 않은 입장에서는 Listing 8의 쿼리 실행 결과가 놀라울 것이다. 하지만 사전 편집순으로 검색이 수행된다는 점을 알고 있으면 확실히 이해가 된다. —단거리 레이스를 검색하는 경우에도 가상의 Leesburg Ultra Marathon은 결과에 포함되지 않는다.

위로

사전 편집순 검색

번호 지정된 데이터(날짜 포함)를 검색하는 경우 사전 편집순 검색을 수행하면 문제가 발생할 수 있지만 모든 항목이 손실되지는 않는다. 거리를 기준으로 한 검색을 수정하는 한 가지 방법은 거리 속성에 사용된 숫자에 숫자를 패딩하는 것이다.

현재 가장 긴 레이스는 103.6마일이다(개인적으로는 이 거리에 가까운 거리를 뛰어본 적은 없다). 이 숫자는 사전 편집순으로 소수점 왼쪽의 세 자리 숫자로 읽힌다. 따라서 나머지 레이스의 앞 부분에 0을 패딩하여 모든 레이스의 문자 수가 동일하게 만든다. 이렇게 하면 거리 기반 검색이 제대로 작동한다.

그림 1은 Simple DB 데이터베이스 도메인을 시각적으로 쿼리하고 업데이트하는 데 필요한 Firefox 플러그인인 SDB Tool(참고자료 참조)의 스크린샷이다.

표시된 대로 필자는 Race_01과 Race_02의 거리 값에 0을 추가했다. 비숙련자에게는 크게 와닿지 않겠지만 이를 통해 검색이 훨씬 편리해진다. 따라서 그림 2에서는 거리가 020.0마일(또는 일반적인 20마일)보다 짧은 거리의 레이스를 검색했으며 최종적으로 —올바르게— 표시되는 항목을 확인할 수 있다.

조금만 준비하면 사전 편집순 검색의 제한 요소를 극복하는 것은 어렵지 않다. 패딩을 사용하지 않는 경우에는 애플리케이션측에서 필터링을 수행할 수도 있다. 즉, 정수는 일반적인 정수로 유지한 상태에서 Amazon으로부터 필터링되지 않은 항목의 콜렉션을 확보한 경우 항목을 필터링할 수 있다. 즉, 모든 항목에서 select *를 실행한다. 데이터가 많은 경우 이 접근 방식은 비용이 많이 소요될 수 있다.

위로

SimpleDB의 관계

SimpleDB에서는 어렵지 않게 관계를 설정할 수 있다. 개념적으로는 race라는 러너 항목에 대한 속성을 쉽게 작성한 후 레이스 이름(예: Race_01)을 해당 항목에 추가할 수 있다. 또한 이 값에 레이스 이름의 콜렉션을 보유할 수도 있다. 그 반대도 적용된다. Listing 9와 같이 race 도메인에 러너 이름의 콜렉션을 쉽게 보유할 수 있다. Amazon의 쿼리 언어를 통해 두 도메인을 실제로 결합할 수는 없다는 것을 기억한다. 이 작업은 사용자측에서 수행한다.

sdb.createDomain(new CreateDomainRequest("Runners"));

List<ReplaceableItem> runners = new ArrayList<ReplaceableItem>();

runners.add(new ReplaceableItem().withName("Runner_01").withAttributes(
   new ReplaceableAttribute().withName("Name").withValue("Sally Smith")));

runners.add(new ReplaceableItem().withName("Runner_02").withAttributes(
	new ReplaceableAttribute().withName("Name").withValue("Richard Bean")));

sdb.batchPutAttributes(new BatchPutAttributesRequest("Runners", runners));

Runners 도메인을 작성하여 여기에 러너를 추가하고 나면 Listing 10과 같이 기존 레이스를 업데이트한 후 해당 레이스에 내 러너를 추가할 수 있다.

races.add(new ReplaceableItem().withName("Race_01").withAttributes(
  new ReplaceableAttribute().withName("Name").withValue("Charlottesville Marathon"),
  new ReplaceableAttribute().withName("Distance").withValue("026.2"),
  new ReplaceableAttribute().withName("Runners").withValue("Runner_01"),
  new ReplaceableAttribute().withName("Runners").withValue("Runner_02")));

결론은 관계를 사용할 수는 있지만 SimpleDB 외부에서 해당 관계를 관리해야 한다는 것이다. 예를 들어, Race_01에 있는 모든 러너의 전체 이름을 얻으려면 하나의 쿼리에서 이름을 확보한 후 쿼리(Race_01에는 속성 값이 둘밖에 없기 때문에 이 경우에는 두 개의 쿼리)를 runner 도메인에 대해 발행하여 답을 얻어야 한다.

위로

정리 조작

정리 조작은 중요하기 때문에 Amazon의 SDK를 사용한 신속한 정리로 끝을 맺는다. 정리 조작은 데이터 작성 및 해당 데이터에 대한 쿼리와 크게 다르지 않다. Request 유형을 작성하여 삭제를 실행하기만 하면 된다.

Listing 11과 같이 Race_01의 삭제는 매우 쉽다.

sdb.deleteAttributes(new DeleteAttributesRequest(domain, "Race_01"));

DeleteAttributesRequest를 사용하여 항목을 삭제한 경우 필자가 도메인을 삭제하려면 무엇을 사용해야 하는가? 그렇다. 바로 DeleteDomainRequest이다.

sdb.deleteDomain(new DeleteDomainRequest(domain));

위로

계속 둘러보기

Amazon의 SimpleDB를 통한 클라우드 둘러보기는 아직 끝나지 않않지만 Amazon SDK를 사용한 클라우드 둘러보기는 현재로서는 완료되었다. Amazon의 SDK는 실용적이며 어떤 면에서는 유용할 수 있지만 항목(예: 레이스 및 러너)을 모델링하려는 경우에는 JPA 등을 활용할 수 있다. 다음 기사에서는 JPA를 SimpleDB와 결합하면 어떤 일이 발생하는지 살펴본다. 그때까지는 사전 편집순 검색을 마음껏 사용하자.

참고자료

교육

• Java development 2.0: 이 developerWorks 시리즈에서 Java development 2.0: CouchDB와 그루비의 RESTClient를 이용한 RESTCouchDB(2009년 11월) 및 Java development 2.0: NoSQL(2010년 5월)을 포함하여 Java 개발 환경을 재정의하는 기술과 도구에 대해 살펴보자.
  
  
• "Amazon Web Services를 사용한 클라우드 컴퓨팅, Part 5: SimpleDB를 통해 클라우드의 데이터세트 처리하기"(Prabhakar Chaganti, developerWorks, 2009년 2월): 기본적인 Amazon SimpleDB(SDB) 개념에 대해 알아보고 SDB와 상호작용하기 위한 오픈 소스 Python 라이브러리인 boto에서 제공하는 일부 기능을 살펴보자.
  
  
• "Eventually Consistent - Revisited"(Werner Vogels, All Things Distributed, 2008년 12월): Amazon의 CTO가 Eric Brewer의 CAP 정리와 이 정리의 Amazon Web Services 인프라에 대한 영향에 대해 설명한다.
  
  
• "NoSQL Patterns"(Ricky Ho, Pragmatic Programming Techniques, 2009년 11월): NoSQL 데이터베이스의 개요 및 목록을 확인할 수 있고 NoSQL 데이터 저장소의 일반적인 아키텍처에 대한 자세한 설명을 볼 수 있다.
  
  
• "Bigtable: A Distributed Storage System for Structured Data"(Fay Chang 등, Google, 2006년 11월): Bigtable은 매우 큰 크기(수천 개의 상용 서버에 걸쳐있는 페타바이트 크기의 데이터)까지 범위를 확장하도록 설계된 구조화된 데이터를 관리하는 데 필요한 분산 스토리지 시스템이다.
  
  
• 기술 서점에서 다양한 기술 주제와 관련된 서적을 살펴보자.
  
  
• developerWorks Java 기술 영역: Java 프로그래밍과 관련된 모든 주제를 다루는 여러 편의 기사를 찾아보자.
  
  

제품 및 기술 얻기

• Amazon SDK: Amazon의 SDK를 다운로드하여 Amazon Web Services 인프라를 활용해 보자. (Amazon에 계정이 없는 경우에는 작성해야 한다.)
  
  
• SDB Tool: Amazon SimpleDB 사용을 용이하게 하는 Firefox GUI 플러그인이다.
  
  

토론

• My developerWorks 커뮤니티에 참여하자.
  
  

필자소개

아티클 순위

의견

위로

목차

• SimpleDB 소개하기
• 클라우드에서의 레이싱
• SimpleDB의 쿼리
• 사전 편집순 검색
• SimpleDB의 관계
• 정리 조작
• 계속 둘러보기
• 참고자료
• 필자소개
• 의견