2012-08-24 5 views
1

"DeviceID"및 "DayOfYear"와 같은 열에 대해 2 차 인덱스가있는 카산드라 0.8을 사용하고 있습니다. 필자는 일정 범위 내의 장치에 대한 데이터를 검색하기 위해이 두 가지 인덱스를 가지고 있습니다. 언제든지 날짜 필터를 가져올 때마다 이것을 DayOfYear로 변환하고 .net Thrift API를 사용하여 인덱싱 된 슬라이스를 사용하여 검색합니다. 현재 DB를 업그레이드 할 수 없습니다.카산드라 보조 인덱스 get_indexed_slices 시간 초과

내 문제는 일반적으로 현재 날짜를 사용하여 get_indexed_slices 쿼리를 사용하여 행을 검색하는 데 문제가 없다는 것입니다. 그러나 어제 (인덱스 된 열 중 하나 인) 요일을 쿼리 할 때마다 쿼리를 처음 만들 때 시간이 초과됩니다. 그리고 대부분의 경우 두 번째 시간과 세 번째 시간 동안 100 %를 쿼리하면 반환됩니다.

두 열은 열 패밀리에서 이중 데이터 형식으로 만들어지며 일반적으로 분당 1 회의 레코드가 생성됩니다. 클러스터에 3 개의 노드가 있고 nodetool 보고서는 nodetool의로드 분포 보고서가 다음과 같이 보이지만 노드가 실행 중이라고 제안합니다.

Starting NodeTool Address DC Rack Status State Load Owns
xxx.xx.xxx.xx datacenter1 rack1 Up Normal 7.59 GB 51.39%
xxx.xx.xxx.xx datacenter1 rack1 Up Normal 394.24 MB 3.81%
xxx.xx.xxx.xx datacenter1 rack1 Up Normal 4.42 GB 44.80%
이며 YAML의 구성은 다음과 같습니다.

hinted_handoff_enabled: true
max_hint_window_in_ms: 3600000 # one hour
hinted_handoff_throttle_delay_in_ms: 50
partitioner: org.apache.cassandra.dht.RandomPartitioner
commitlog_sync: periodic
commitlog_sync_period_in_ms: 120000
flush_largest_memtables_at: 0.75
reduce_cache_sizes_at: 0.85
reduce_cache_capacity_to: 0.6
concurrent_reads: 32
concurrent_writes: 24
sliced_buffer_size_in_kb: 64
rpc_keepalive: true
rpc_server_type: sync
thrift_framed_transport_size_in_mb: 15
thrift_max_message_length_in_mb: 16
incremental_backups: true
snapshot_before_compaction: false
column_index_size_in_kb: 64
in_memory_compaction_limit_in_mb: 64
multithreaded_compaction: false
compaction_throughput_mb_per_sec: 16
compaction_preheat_key_cache: true
rpc_timeout_in_ms: 50000
index_interval: 128

내가 누락 될 수 있습니다 뭔가가 있나요? 구성에 문제가 있습니까?

+0

언급 된 버전에 실수가있었습니다. 설치된 버전은 .8이 아닌 1.0.5입니다. 문제를 일으켜서 미안 해요. – Muthu

답변

-1

마침내 다른 방식으로 문제를 해결했습니다. 사실 나는 문제가 내 데이터 모델에 있다는 것을 깨달았습니다.

우리가 RDBMS 배경에서 왔기 때문에 문제가 발생합니다. 데이터 모델을 조금 재구성했고 지금은 응답 속도가 빨라졌습니다.

2

키가 검색 데이터 인 다른 열 패밀리에 데이터를 복제하십시오. 행 슬라이스가 더 빨라졌습니다

개인적으로 프로덕션 환경에서 보조 인덱스를 사용하지 않아도됩니다. 또는 시간 초과 문제가 있거나 보조 색인에 의해 검색되는 데이터의 속도가 삽입 된 데이터의 양보다 적습니다. 순차적으로 데이터를 읽지 않고 HD 검색 시간과 관련이 있다고 생각합니다.

+0

관련성이있는 https://issues.apache.org/jira/browse/CASSANDRA-3545 ~ http://stackoverflow.com/questions/9741522/cassandra-performance-for-longrows를 찾았습니다. 최신 버전이 해결책을 제공하는지 확인하고 있습니다. 카산드라 버전에 문제가 있다면 다른 옵션은 없지만 새로운 버전으로 마이그레이션하는 것이 좋습니다. – Muthu

1

관계형 모델에서 나온 경우 playOrm도 빠르며 noSQL 저장소에서 관계형 일 수는 있지만 매우 큰 테이블을 분할하면됩니다. 그런 다음 "확장 가능한 JQL"을 사용하여 작업 할 수 있습니다.

@NoSqlQuery (name = "findJoinOnNullPartition", query = "PARTITIONS t (: partId)"t INNER JOIN t.security "s.securityType = : type 및 t.numShares = : shares")

IT는 또한 기본 ORM에 대한 @ManyToOne, @OneToMany 등의 주석을 가지고 있지만 일부는 noSQL에서 다르게 작동하지만 제비는 유사하다.

+0

감사합니다. – Muthu