Tag Archives: Pelops

[NoSQL/Cassandra] Java용 클라이언트 Pelops 소개

Pelops

그리스 신화중에 승리의 왕 아가멤논 트로이의 몰락 이후에 카산드라를 잡아가게 되는데 카산드라는 Pelops, Teledamus 두명의 아들이 있었습니다. 이 Pelops 자바 라이브러리는 Cassandra 데이터베이스를 아름다운 방법의 코드(?)로 이용할수 있도록 해주기 때문에 카산드라의 아름다운 아들인 Pelops의 이름을 따 명명 되었습니다.

이 라이브러리의 코드는 이곳에서 다운받을 수 있습니다 : https://github.com/s7/scale7-pelops

목표

Pelops는 복잡한 상업 프로젝트들의 데이터베이스에 대한 광범위한 사용을 위해 사용되는 코드의 질적 향상을 위해 만들어졌습니다. 이 라이브러리의 주요한 목표는 다음과 같습니다.
– Cassandra의 API 심플하지만 아름다운 방법으로 누구에게나 충실하게 즉시 이해될 수 있도록 해야 한다.
– 데이터를 처리하는 코드로 부터 커넥션풀링과 같은 로우레벨에 대한 관심을 완전히 분리시켜야 한다.
– “드레싱 코드(dressing code?)”를 제거하여 의미있는 데이터 처리를 위해 명확하고 분명한 형태의 코드를 유지 하도록 해야 한다.
– 함수 오버로딩 또는 강력한 하이레벨의 메소드를 통해 개발 속도를 가속할 수 있어야 한다.
– 운영중인 노드의 숫자에 기초한 로드밸런싱 전략을 구현할 수 있어야 한다.
– 어플리케이션 레벨의 로직의 문제를 감추지 않는 강력한 에러 핸들링 및 복구 기능을 포함해야 한다.
– 변화에 의한 문제가 발생하는것을 유발하지 않고 카산드라의 새로운 릴리즈나 기능을 따라갈 수 있어야 한다.
– 이러한 클라이언트 코드에 대한 오래 지속될수 있는 패러다임을 정의할 수 있어야 한다.

5분만에 세팅하고 구동하기

Pelops와 Cassandra를 함께 구동하기 위해서 다음의 3가지를 알아야 합니다.

  1. 한번의 시작으로 어떻게 커넥션풀을 생성할 수 있는가.
  2. Mutator 클래스를 이용하여 어떻게 데이터를 쓸 수 있는가.
  3. Selector 클래스를 이용하여 어떻게 데이터를 읽을 수 있는가.

매우 쉽죠?

커넥션풀 생성하기

Cassandra 클러스터를 이용해 어떤 작업을 처리하기 위해 당신은 커넥션 풀을 정의할 필요가 있습니다. 일반적으로 당신의 어플리케이션의 시작부분에 한번만 정의되기만 하면 됩니다. 때때로 당신은 하나 이상의 커넥션풀을 정의해야 할 경우도 있을것입니다. 예를 들어 우리의 프로젝트에서 2개의 Cassandra 클러스터를 사용하였는데 하나는 Random Partitioning 데이터 저장소로 사용되고 다른 하나는 인덱스 사용을 위해 Order Preserving Partitioning을 사용하였습니다. 당신은 원하는 만큼의 커넥션풀을 생성하는것이 가능합니다.

풀을 생성하기 위해 알려진 노드들의 리스트를 정의하는 이름을 특정 지어야 합니다. 네트워크 포트와 커넥션풀을 컨트롤하기 위한 정책을 포함할 수 있습니다. 다음은 기본 정책을 사용하여 풀을 생성하는 예시입니다.
[code]Pelops.addPool(
    “Main”,
    new String[] { “cass1.db.com”, “cass2.db.com”, “cass3.db.com”},
    9160,
    new Policy());[/code]

Mutator 사용하기

Mutator클래스는 Keyspace가 돌연변이(?)를 일으키도록 하여줍니다(데이터에 어떤식으로든지 변화를 준다는 의미에서 시작하는것 같습니다). 당신은 Pelops에 새로운 Mutator를 요청할 수 있고 당신이 원하는 어떤 변화를 일으키도록 할 수 있습니다. 이러한 일련의 작업들은 하나의 배치 메소드인 execute 가 호출될 때 Cassandra로 전송됩니다.

Mutator를 생성하기 위해 미리 지정해둔 커넥션풀의 이름과 변화를 주고 싶은 Keyspace의 이름을 명시해주어야 합니다. 다음과 같은 방식으로 SupportTickets Keyspace를 수정할 수 있는 Mutator를 가져옵니다.
[code]Mutator mutator = Pelops.createMutator(“Main”, “SupportTickets”);[/code]
한번 Mutator를 생성하게 되면 이제부터 다양한 변화를 줄 수 있게 됩니다.
[code]/**
 * 다수의 서브컬럼 값을 슈퍼 컬럼에 다중 쓰기를 합니다.
 * @param rowKey                    수정을 원하는 로우의 키
 * @param colFamily                 작업을 수행하기 원하는 슈퍼컬럼 패밀리 이름
 * @param colName                   슈퍼컬럼의 이름
 * @param subColumns                값을 쓰기 원하는 서브 컬럼들의 이름
 */
mutator. writeSubColumns(
    userId,
    “L1Tickets”,
    UuidHelper.newTimeUuidBytes(), // 시간순 정렬
    mutator.newColumnList(
        mutator.newColumn(“category”, “videoPhone”),
        mutator.newColumn(“reportType”, “POOR_PICTURE”),
        mutator.newColumn(“createdDate”,
            NumberHelper.toBytes(System.currentTimeMillis())),
        mutator.newColumn(“capture”, jpegBytes),
        mutator.newColumn(“comment”) ));

/**
 * 컬럼의 리스트나 슈퍼 컬럼을 삭제합니다.
 * @param rowKey                    수정을 원하는 로우의 키
 * @param colFamily                 작업을 수행하기 원하는 컬럼 패밀리 이름
 * @param colNames                  삭제를 원하는 서브/슈퍼 컬럼 이름
 */
mutator.deleteColumns(
    userId,
    “L1Tickets”,
    resolvedList);[/code]
모든 변화에 대한 작업을 명시한 다음 단일 배치 명령인 execute를 호출하여 Cassandra로 전송합니다. 이 작업에는 Cassandra의 Consistency 레벨값을 파라미터로 사용합니다.
[code]mutator.execute(ConsistencyLevel.ONE);[/code]
여기서 알아두어야 하는 점은 당신이 원하는 어떤 후속작업을 시작하기 전에 execute가 실행되었다면 추가적인 작업이 함께 적용될 수 없습니다. Mutator를 execute가 실행된 이후에 재사용될 수 없으며 이런 경우가 생긴다면 두개 또는 그 이상의 Mutator를 생성하여야 하며 그들을 execute할때는 최소한 QURUM Consistency 레벨을 사용하여야 합니다.

사용가능한 오버로드된 메소드들의 리스트를 확인하기 위해 Mutator 클래스 [소스]를 확인하세요.

Using a Selector

Selector 클래스는 Keyspace로부터 데이터를 읽어들이는데에 사용됩니다. Pelops에게 새로운 Selector를 요청하고 Selector의 메소드를 사용하여 데이터를 읽어옵니다.
[code]Selector selector = Pelops.createSelector(“Main”, “SupportTickets”);[/code]
한번 Selector 인스턴스 생성을 하게 되면 다양한 오버로드 메소드를 통해 데이터를 읽어올 수 있게 됩니다.
[code]/**
 * 로우로 부터 슈퍼컬럼을 읽어오기
 * @param rowKey                로우의 키
 * @param columnFamily          슈퍼컬럼을 포함하고 있는 컬럼패밀리
 * @param superColName          데이터를 가져오고 싶은 슈퍼컬럼의 이름
 * @param cLevel                Consistency Level
 * @return                      요청된 슈퍼컬럼
 */
SuperColumn ticket = selector.getSuperColumnFromRow(
    userId,
    “L1Tickets”,
    ticketId,
    ConsistencyLevel.ONE);

assert ticketId.equals(ticket.name)

// 서브컬럼들 순환하며 데이터 읽기
for (Column data : ticket.columns) {
    String name = data.name;
    byte[] value = data.value;
}

/**
 * 로우로 부터 슈퍼컬럼 리스트 읽어오기
 * @param rowKey                로우의 키
 * @param columnFamily          슈퍼컬럼을 포함하고 있는 컬럼패밀리
 * @param colPredicate          슈퍼컬럼의 Selector 정의
 * @param cLevel                Consistency Level
 * @return                      매칭된 컬럼의 리스트
 */
List<SuperColumn> allTickets = selector.getSuperColumnsFromRow(
    userId,
    “L1Tickets”,
    Selector.newColumnsPredicateAll(true, 10000),
    ConsistencyLevel.ONE);

/**
 * 로우로부터 슈퍼컬럼 셋 읽어오기
 * @param rowKeys                로우의 키
 * @param columnFamily           슈퍼컬럼을 포함하고 있는 컬럼패밀리
 * @param colPredicate           슈퍼컬럼의 Selector 정의
 * @param cLevel                 Consistency Level
 * @return                       매칭된 슈퍼컬럼으로 이루어진 Map 객체
 */
Map<String, List<SuperColumn>> allTicketsForFriends = selector.getSuperColumnsFromRows(
    Arrays.asList(new String[] { “matt”, “james”, “dom” }, // 친구들
    “L1Tickets”,
    Selector.newColumnsPredicateAll(true, 10000),
    ConsistencyLevel.ONE);

/**
 * 순서로 저장된 슈퍼컬럼의 페이지 네비게이션 구현
 * @param rowKey                로우의 키
 * @param columnFamily          슈퍼컬럼을 포함하고 있는 컬럼패밀리
 * @param startBeyondName       읽어오고자 하는 정렬된 데이터의 시작 키 값
 * @param orderType             어떤 타입의 정렬을 사용하는가
 * @param reversed              오름차순, 내림차순 정의
 * @param count                 데이터를 가져올 최대 갯수
 * @param cLevel                Consistency Level
 * @return                      슈퍼컬럼들의 페이지단위 리스트
 */
List<SuperColumn> pageTickets = getPageOfSuperColumnsFromRow(
    userId,
    “L1Tickets”,
    lastIdOfPrevPage, // null이면 처음부터
    Selector.OrderType.TimeUUIDType, // 슈퍼컬럼 패밀리가 어떻게 정렬되어있는가
    true, // 블로그글과 같은 역순으로 데이터 읽음
    10, // 페이지당 데이터 갯수
    ConsistencyLevel.ONE);[/code]
매우 많은 데이터를 읽어오는 Selector메소드 사용시 많은 Cassandra에 많은 부하를 줄 수 있을것입니다. 하지만 이러한 페이징 기법을 사용하게 되면 단순하게 이 문제를 해결 할 수 있습니다. Selector 클래스의 [소스]를 확인해 보세요.

다른 기능들

Pelops를 사용하기 위한 핵심적인 기능들에 대해 알아보았습니다. 마지막으로 Pelops에서 지원하는 다른 유용한 기능들에 대해 설명하겠습니다.

– 로우 키 레벨의 삭제를 원할 경우 KeyDeletor 클래스를 사용하면 됩니다. (Pelops.createKeyDeletor)
– Cassandra 클러스터의 정보를 가져오기를 원할 경우 Metric 클래스를 사용하면 됩니다. (Pelops.createMetrics)
– 시간순으로 정렬되는 유니크한 ID값인 Time UUID를 사용하기 위해서는 UuidHelper 클래스를 사용하면 됩니다.
– 숫자를 이진값으로 저장하기 위해서는 NumberHelper 클래스를 사용하면 됩니다.
– 문자열을 이진값으로 저장하기 위해서는 StringHelper 클래스를 사용하면 됩니다.
– Pelops 라이브러리의 메소드와 Cassandra의 통신중에 발생하는 예외는 Cassandra에서 정의한 예외들을 사용합니다.

참고 :
http://ria101.wordpress.com/2010/06/11/pelops-the-beautiful-cassandra-database-client-for-java/ 

[NoSQL/Java] Cassandra 클라이언트 퍼포먼스 비교 (Pelops/Hector/Kundera)

Java용으로 쓸만한 Cassandra 클라이언트 라이브러리를 찾다보니 대충 Pelops, Hector, Kundera정도로 나뉘어 지는것 같더군요. 셋중에 무엇이 가장 좋은가를 놓고 비교해 보자면 다양한 결론이 나오겠지만 Kundera에서 자체적으로 내놓은 퍼포먼스 테스트 결과가 있습니다. 퍼포먼스만 달랑 놓고 보면 Kundera가 가장 떨어지는 결과를 보여주니 일부러 거짓말 하는 데이터는 아닌것 같아 보입니다.

Kundera Performance 발번역

Kundera의 퍼포먼스를 Hector / Pelops와 비교해 보았습니다. 왜 Hector / Pelops인가요? Kundera는 데이터 저장소에 객체를 매핑해주는 툴이고 Hector / Pelops는 하이 레벨의 Cassandra 클라이언트입니다. 그렇기 때문에 이 비교는 논란이 될 수 있습니다. 이 비교의 의도는 Kundera 가 추가적으로 제공하는 매핑이나 다른 멋진 기능들의 오버헤드가 얼마나 되는지 계산해 보기 위함입니다.

Kundera – Cassandra는 Lucene기반의 인덱싱을 제공하며 그렇기 때문에 Hector/Pelops가 할수 있는 것들외에 추가적인 작업이 가능합니다. 그러므로 테스트는 이 Lucene인덱싱을 사용할때와 안할때 두가지 시나리오를 가지고 진행됩니다. 전자는 이 추가적인 인덱싱 기능을 사용하지 않으므로 비교해볼만한 상대가 될지 모르겠지만 후자의 경우에는 인덱싱을 내장 지원하기 때문에 비교대상이라 보기 어려운 퍼포먼스를 보여주긴 합니다.

Kundera Without Indexing Support

Bulk Load:

Number Of Records
(Single Thread)
Pelops Time
(in ms)
Hector Time
(in ms)
Kundera
(in ms)
1 22 56 82
1000 550 666 925
4000 1791 1928 2952
40000 10533 10645 12392
100000 23832 24675 25994
1000000 221154 229619 236242

Concurrent Load:

Number Of Threads
(1 record)
Pelops Time
(in ms)
Hector Time
(in ms)
Kundera
(in ms)
10 53 57 80
100 232 259 250
1000 1560 1443 1718
10000 9120 8514 10127
40000 28869 28330 29506
50000 36454 34823 36336
100000 68586 65513 69513

Concurrent Load + Bulk Load:

Number Of Threads
(1000 rec/ thread)
Pelops Time
(in ms)
Hector Time
(in ms)
Kundera
(in ms)
10 3968 4434 5085
100 21560 22329 25274
1000 227232 207834 226541

Kundera With Indexing Support

Bulk Load:

Number Of Records
(Single Thread)
Pelops Time
(in ms)
Hector Time
(in ms)
Kundera
(in ms)
1 25 40 93
1000 677 957 1719
4000 2131 2429 3901
40000 13009 13075 22158
100000 28884 30097 44876
1000000 256986 262067 375137

Concurrent Load:

Number Of Threads
(1 record)
Pelops Time
(in ms)
Hector Time
(in ms)
Kundera
(in ms)
10 53 56 118
100 232 281 552
1000 1560 1823 2762
10000 9120 9776 14104
40000 28869 32331 39549
50000 36454 37172 50099
100000 68586 74304 95410

Concurrent Load + Bulk Load:

Number Of Threads
(1000 rec/ thread)
Pelops Time
(in ms)
Hector Time
(in ms)
Kundera
(in ms)
10 4343 4738 9546
100 26010 24619 35196
1000 227232 219247 308975


위의 단순한 결과들로만 보면 Kundera는 모든 면에서 다른 라이브러리에 비교해 뒤쳐지는 속도를 보여줍니다. 하지만 Kundera는 Lucene인덱싱 POJO에 직접적인 데이터 매핑등 사용상에 많은 장점을 가지고 있습니다. 대충 검색해 보았을때는 Kundera는 Full-Text 검색도 지원한다고 합니다. 사실상 NoSQL에서 지원하기 어려운 점들입니다. 사용해 보진 않았지만 다양한 기능을 제공하는것으로 보여집니다.

참고: https://github.com/impetus-opensource/Kundera/wiki/Kundera-Performance