2010-06-17 3 views
6

우리는 여전히 우리의 데이터 저장소에 대해 카산드라를 평가 중입니다. 매우 간단한 테스트로 약 100 바이트의 데이터에 해당하는 로컬 컴퓨터의 Keyspace1/Standard1 열 패밀리에 4 열 값을 삽입했습니다. 그럼 나는 줄 키로 할 수있는 한 빨리 그것을 읽었다. 160,000/초로 다시 읽을 수 있습니다. 큰.카산드라 랜덤 읽기 속도

다음으로 나는 X와 Y의 형태로 모든 키를 가진 비슷한 모든 레코드를 넣습니다. 여기서 X는 (1..10)이고 Y는 (1..100,000)이고 나는 임의 레코드를 쿼리했습니다. 성능은 초당 26,000 개의 쿼리로 떨어졌습니다. 이것은 여전히 ​​우리가 지원해야하는 쿼리의 수 (약 1,500/초)입니다.

마지막으로 저는 1.1에서 10.10000까지 1 천만 개의 레코드를 넣었고 1000 만 개의 레코드 중 하나를 무작위로 쿼리했습니다. 초당 60 개의 쿼리에서 성능이 저하되 내 디스크가 미친 듯이 쓰러지고 있습니다.

또한 데이터의 하위 집합 인 3,000,000 ~ 3,001,000의 1,000 개 레코드를 요청하면 처음에는 천천히 반환 된 다음 캐시 할 때 초당 최대 20,000 개의 쿼리와 내 디스크 미쳤어.

사람들은 Cassandra에 수십억 개의 레코드를 저장하고 초당 5-6k를 가져 오는 것을 읽었지 만 10mil 레코드로는 그 근처에 갈 수 없습니다. 내가 뭘 잘못하고 있는거야? 기본값에서 변경해야 할 설정이 있습니까? 나는 overclocked Core i7 상자에 6gig의 램을 장착하고있어 그것이 기계라고 생각하지 않습니다.

여기에 키 행을 통해 하나의 열에서 하나 개의 값을 요청 I 8 개 스레드에 산란하고있어 기록을 가져 오기 위해 내 코드입니다 :

ColumnPath은 cp = 새로운 ColumnPath(); cp.Column_family = "Standard1"; cp.Column = utf8Encoding.GetBytes ("site"); 문자열 키 = (1 + sRand.Next (9)) + "." + (1 + sRand.Next (1000000)); ColumnOrSuperColumn logline = client.get ("Keyspace1", key, cp, ConsistencyLevel.ONE); 메모리에 모든 레코드를 저장하기에 충분한 RAM을 가지고하지 않은 것 같습니다 어떤 통찰력

답변

-1

에 대한

감사합니다.

디스크로 전환하면 문제가 발생하며 특히 임의로 읽는 경우 성능이 크게 떨어질 것으로 예상됩니다.

다른 일반적인 대안 (예 : Redis 또는 VoltDB)을 벤치마킹 할 수도 있습니다.

+0

확실히 메모리에 모두 저장할 수는 없지만 10mil 레코드는별로 좋아 보이지 않습니다. 사람들은 수십억 개의 레코드를 어떻게 다루고 있습니까 ?? –

+0

열쇠는 가능한 디스크에 저장하는 것이 아니라 RAM에 최대한 저장하는 것입니다. 수십억 개의 레코드를 처리하려면 여러 머신에 걸쳐이를 배포하고 전체적으로 사용하십시오. 또 다른 인기있는 NoSQL 솔루션 인 Riak에서 어떻게 달성되는지에 대한 아주 멋진 기사 [1]가 있습니다. 이 기사에서 논의 된 많은 측면이 카산드라에게도 적용됩니다. 카산드라는 동일한 기본 아이디어를 토대로 구축 되었기 때문입니다. [1] : https://wiki.basho.com/display/RIAK/An+Introduction+to+Riak –

4

순전히 무작위 읽기는 사용자의 OS (키 또는 행 캐시를 설정 한 경우 Cassandra)가 수행하려고 시도하는 캐싱에 대한 최악의 동작입니다.

카산드라 소스 배포판의 contrib/py_stress를 보면 임의의 읽기를 수행하지만 다른 일부보다 더운 키를 가진 구성 가능한 stdev가 있습니다. 이것은 가장 실제적인 작업 부하를 대표합니다.

+0

불행히도 우리는 임의의 간격으로 우리 사이트에 도착하는 임의의 방문자를 갖게 될 것입니다. 캐시 히트를 더 많이 얻으려면 사전에 알고 있어야합니다. 이 경우 단순히 디스크 속도로 제한됩니까? –

+0

진정한 무작위는 없습니다. 귀하의 실제 실적은 귀하의 테스트보다 더 좋을 가능성이 큽니다. 즉, 카산드라는 실제로 상자의 모든 메모리를 사용하고 있습니까? 60 reads/sec는 하드웨어에 너무 끔찍해서 설치 문제가 발생할 가능성이 있습니다 (디스크가 얼마나 끔찍한 지에 따라). 또한 Cassandra가 물리적 메모리 인 것처럼 스왑을 사용하지 않도록하십시오 - 경쟁 방식으로 인 메모리 페이지를 독립적으로 최적화하려고 시도하는 카산드라와 OS 모두에서 병적 인 성능 문제를 만듭니다. –

3

더 많은 Cassandra 노드를 추가하고 메모리를 많이 할당합니다 (-Xms/-Xmx). 보유하고있는 Cassandra 인스턴스가 많을수록 데이터는 노드에서 분할되어 메모리에 있거나 디스크에서보다 쉽게 ​​액세스 할 수 있습니다. 단일 워크 스테이션 클래스 CPU를 확장하려는 경우 매우 제한적입니다. 또한 기본 -Xms/-Xmx 설정을 확인하십시오. 기본적으로 1GB라고 생각합니다.

-6

VoltDB은 확실히 읽기 성능뿐만 아니라 서버 클러스터를 사용하여 쓰기 및 작동을 처리 할 수 ​​있습니다. 메모리 내 솔루션으로 모든 데이터를 RAM에 저장할 수있는 충분한 크기의 클러스터를 구축해야합니다.