카산드라 모니터링 메트릭 

- cassandra 3.0부터는 ops center가 없기 때문에 devops가 잘 살펴봐야 한다. 



https://www.datadoghq.com/blog/how-to-monitor-cassandra-performance-metrics/


https://github.com/QuentinAmbard/cassandra-troubleshooting


https://wiki.apache.org/cassandra/Metrics


https://www.datadoghq.com/blog/how-to-collect-cassandra-metrics/


http://www.datastax.com/dev/blog/pluggable-metrics-reporting-in-cassandra-2-0-2


Posted by '김용환'
,


카산드라 테이블에 STATIC을 선언에 사용할 수 있다. 



STATIC으로 선언된 컬럼은 파티션 키당 하나의 값을 가진다. 

예를 들어 user 라는 테이블이 있고 username, password라는 필드가 있다면, 주어진 username 이름과 연관된 password 값은 정확히 하나만 있다. 이런 모델링을 위해 STATIC이라는 키워드를 사용할 수 있다.


정적 컬럼의 목표는 파티션 키 값을 공유하는 로우가 다른 데이터도 공유하도록 허용하는 것이다. 

정적 컬럼 기능을 유용하게 사용하려면 파티션 키마다 여러 로우가 있어야 한다. 

즉 적어도 하나 이상의 클러스터링 컬럼이 있어야 함을 의미한다. 

클러스터링 컬럼이 없는 테이블에서 정적 컬럼을 선언할 수 없다.


또한..
STATIC은 두 개의 테이블을 하나로 합쳐 JOIN된 결과처럼 보이게 하는 효과가 있다.
A와 B 테이블의 SQL LEFT JOIN 결과와 매우 유사하게 동작한다. (A 테이블의 값은 고정되어 있다. STATIC 적용)



참고 
https://www.datastax.com/dev/blog/cql-in-2-0-6


Posted by '김용환'
,



먼저 authenticator:로 시작하는 라인을 찾고 다음과 같이 변경한다.


authenticator: PasswordAuthenticator 



이전과 같이 변경하면 클라이언트가 클러스터에 연결할 때 사용자 이름과 암호가 필요하다는 것을 카산드라에 알린다. 그러나 사용자가 로그인할 때마다 접근을 제한하지는 않는다. 접근을 제한하려면 권한을 활성화해야 한다. authorizer:로 시작하는 라인을 찾아서 다음과 같이 변경한다.


authorizer: CassandraAuthorizer 



이제 클러스터는 사용자에게 주어진 권한에 따라 로그인 사용자의 접근을 제한할 것이다. 해당 권한 설정을 적용하려면 카산드라 인스턴스를 재시작해야 한다.





사용자 계정, google을 설정한다.


CREATE USER 'google'

WITH PASSWORD 'strongpassword'

NOSUPERUSER;





system_auth 키 스페이스에서 roles 테이블에 접근해 슈퍼 유저와 기존 사용자 계정을 살펴볼 수 있다.


SELECT role, is_superuser FROM "system_auth"."roles";


키 스페이스 이름과 테이블 이름 사이에 마침표를 사용하면 USE 문으로 활성화한 키 스페이스와 상관없이 system_auth 키 스페이스를 살펴볼 것을 CQL에 알린다.


알다시피 사용자 계정은 system_auth.roles 테이블에 매우 투명하게 저장된다.



 role               | is_superuser

----------------+--------------

      cassandra |         True

google           |        False

(2 rows)





암호가 저장되는 위치와 방법이 궁금할 수 있을 것이다. 해당 정보는 동일 테이블인 system_auth.roles의 salted_hash 필드에 저장되어 있다. 암호는 일반 텍스트로 저장되지 않고 bcrypt 해시로 저장된다.




권한 목록은  다음과 같이 확인할 수 있다.


 SELECT * FROM system_auth.role_permissions;


 role           | resource                           | permissions

----------------+------------------------------------+--------------------------------

      cassandra |               roles/data_analytics | {'ALTER', 'AUTHORIZE', 'DROP'}

google |                     data/my_status |                     {'SELECT'}






참조 :

https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/secureConfigNativeAuth.html


https://support.datastax.com/hc/en-us/articles/207932926-FAQ-How-to-recover-from-a-lost-superuser-password



Posted by '김용환'
,





카산드라의 저장 경로는 4 단계로 구성된다.


1. 커밋로그에 데이터를 추가한다.

2. 멤테이블에 데이터를 저장한다.

3. 멤테이블에서 데이터를 플러시한다.

4. 불변 SSTables에 데이터를 저장한다.



카산드라의 저장 경로의 1번째 컴포넌트는 커밋 로그이다. 저장이 추가되는 추가 전용 로그 구조이다. 커밋로그는 특정 크기로 사전 할당 된 다양한 세그먼트 파일로 설정된다. 세그먼트 파일이 가득 차면 저장이 다음 세그먼트에 저장된다. 세그먼트 내의 모든 저장이 각각의 멤테이블에서 플러시될 때, 세그먼트의 이름이 바뀌고 재활용된다. 재활용된 세그먼트를 다시 사용할 준비가 되었다. 시스템 재시작할 때 모든 멤테이블은 지워진다.


커밋로그 세그먼트가 리플레이된 다음 멤테이블이 디스크에 플러시된다. 그 다음에 커밋로그 세그먼트는 재사용을 위해 재활용된다. 이는 시스템 장애이 발생할 때에 내구성을 제공한다. 키스페이스를 생성할 때 영구 저장을 false로 설정하여 커밋로그 기능을 비활성화할 수 있지만. 성능이 저하될 수 있어서 권장하지 않는다.


커밋 로그에 데이터를 추가하는 것 외에도 카산드라는 멤테이블이라 불리는 인메모리 구조에 데이터를 저장한다. 멤테이블이 특정 임계 값 크기에 도달하면 디스크에 플러시된다. 일부 멤테이블 관련 설정 매개 변수를 조정할 수 있다. 멤테이블 할당 타입을 지정해 힙(heap) 또는 오프-힙(off-heap) 메모리를 사용할 수 있다. 멤테이블에 할당될 힙 또는 오프-힙 메모리 크기를 지정할 수 있다. 


멤테이블 플러시는 멘테이블의 전체 크기 값과 클린업(cleanup) 임계 값을 기반으로 일어난다. 커밋로그 크기를 설정 매개 변수로 지정할 수도 있다. 멤테이블 플러시는 커밋 로그 크기를 기반으로 발생한다. 기본적으로 플러시는 이전에 설명한 대로 설정 가능한 특정 임계 값을 기반으로 자동으로 발생한다. 그러나 nodetool 유틸리티를 사용해 수동으로 플러시를 동작시킬 수도 있다.


플러시 임계 값에 도달하면 멤테이블은 SSTables(Sorted String Tables)라는 불변 파일에 플러시된다. 멤테이블은 토큰 값으로 정렬되고 순차적으로 디스크에 저장된다. SSTable은 변경 불가능하기 때문에 동일한 파티션 키에 변경이 일어나면 특정 레코드는 여러 SSTable에 분산될 수 있다. 카산드라는 SSTable로 플러시할 때 파티션 인덱스, 파티션 요약, 블룸 필터와 같은 여러 구조를 생성한다. 해당 구조는 읽기 속도를 높이고 디스크 검색을 줄이는 데 도움을 준다.




멤테이블의 플러시 전략은  https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsMemtableThruput.html 에 소개되어 있다.  멤테이블의 전체 크기 값은  (https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configCassandra_yaml.html#configCassandra_yaml__commitlog_total_space_in_mb) 과 클린업 임계 값(https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configCassandra_yaml.html#configCassandra_yaml__memtable_cleanup_threshold)을 기반으로 한다.

commitlog_total_space_in_mb 
(Default: 32MB for 32-bit JVMs, 8192MB for 64-bit JVMs)note Total space used for commit logs. If the total space used by all commit logs goes above this value, Cassandra rounds up to the next nearest segment multiple and flushes memtables to disk for the oldest commitlog segments, removing those log segments from the commit log. This reduces the amount of data to replay on start-up, and prevents infrequently-updated tables from keeping commitlog segments indefinitely. If thecommitlog_total_space_in_mb is small, the result is more flush activity on less-active tables.

Related information: Configuring memtable thresholds



memtable_cleanup_threshold 
(Default: 1/(memtable_flush_writers + 1))note. Ratio used for automatic memtable flush. Cassandra adds memtable_heap_space_in_mb to memtable_offheap_space_in_mb and multiplies the total bymemtable_cleanup_threshold to get a space amount in MB. When the total amount of memory used by all non-flushing memtables exceeds this amount, Cassandra flushes the largest memtable to disk.

For example, consider a node where the total of memtable_heap_space_in_mb andmemtable_offheap_space_in_mb is 1000, and memtable_cleanup_threshold is 0.50. The memtable_cleanup amount is 500MB. This node has two memtables: Memtable A (150MB) and Memtable B (350MB). When either memtable increases, the total space they use exceeds 500MB and Cassandra flushes the Memtable B to disk.

A larger value for memtable_cleanup_threshold means larger flushes, less frequent flushes and potentially less compaction activity, but also less concurrent flush activity, which can make it difficult to keep your disks saturated under heavy write load.

This section documents the formula used to calculate the ratio based on the number of memtable_flush_writers. The default value in cassandra.yaml is 0.11, which works if the node has many disks or if you set the node's memtable_flush_writers to 8. As another example, if the node uses a single SSD, the value for memttable_cleanup_threshold computes to 0.33, based on the minimum memtable_flush_writers value of 2.


Posted by '김용환'
,




카산드라에서 쿼리 추적을 하고 싶다면 TRACING ON을 실행한다.


consistent level에 따른 쿼리 추적을 잘 확인할 수 있다. 




cqlsh> TRACING ON;

Now Tracing is enabled



cqlsh>INSERT INTO "my"."users"\n   ("username", "email", "encrypted_password")\n   VALUES (\n     'samuel.kim',\n     'aaa@google.com',\n     0x8914977ed729792e403da53024c6069a9158b8c4\n   );


Tracing session: 43cd0780-8da5-11e7-b58b-4f93372ce090


 activity                                                                                                                                                                                                                           | timestamp                  | source    | source_elapsed | client

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+-----------+----------------+-----------

                                                                                                                                                                                                                 Execute CQL3 query | 2017-08-31 02:04:20.475000 | 127.0.0.1 |              0 | 127.0.0.1

 Parsing INSERT INTO "my"."users"\n   ("username", "email", "encrypted_password")\n   VALUES (\n     'samuel.kim',\n     'aaa@google.com',\n     0x8914977ed729792e403da53024c6069a9158b8c4\n   ); [Native-Transport-Requests-1] | 2017-08-31 02:04:20.481000 | 127.0.0.1 |           6355 | 127.0.0.1

                                                                                                                                                                                  Preparing statement [Native-Transport-Requests-1] | 2017-08-31 02:04:20.481000 | 127.0.0.1 |           6914 | 127.0.0.1

                                                                                                                                                                    Determining replicas for mutation [Native-Transport-Requests-1] | 2017-08-31 02:04:20.482000 | 127.0.0.1 |           7411 | 127.0.0.1

                                                                                                                                                                                           Appending to commitlog [MutationStage-3] | 2017-08-31 02:04:20.482000 | 127.0.0.1 |           7726 | 127.0.0.1

                                                                                                                                                                                         Adding to users memtable [MutationStage-3] | 2017-08-31 02:04:20.482000 | 127.0.0.1 |           7895 | 127.0.0.1

                                                                                                                                                                                                                   Request complete | 2017-08-31 02:04:20.487524 | 127.0.0.1 |          12524 | 127.0.0.1





사실 쿼리 추적은 keyspace system_traces 아래에 존재하는 events 테이블에 저장된다. 또한 모든 쿼리의 요약은 system_traces 키 스페이스 아래에 존재하는 sessions 테이블에 저장된다.


추적 정보는 여러 컬럼으로 구성되어 있는데, 

activity, activity가 발생한 타임스탬프, 

activity 요청 시작부터 경과 시간을 포함한다. 


완료(Request complete)까지 걸리는 시간과 함께 요청 완료 확인을 찾을 수 있다.


또한 source_elapsed 컬럼은 소스 노드에서 이벤트가 발생하기 전의 경과 시간(ms)이다. 



일관성 레벨을 변경한 후 검색을 실행하면 요청 완료 시간에 약간의 차이가 있음을 알 수 있다. 


요청 완료에 대한 source_elapsed는 일관성 레벨 ALL일 때는 가장 높고 일관성 레벨 1일 때는 가장 낮다. 


ALL 일관성 레벨은 클라이언트에게 요청 완료 확인을 보내기 전에 모든 복제본에 확인을 보내야 하기 때문에 경과 시간을 예상할 수 있다. 


단일 서버에서 3개의 인스턴스를 실행 중이므로 요청 응답 시간의 차이는 별로 없을 것이다. 상용 클러스터에서 수백 개의 인스턴스로 작업할 때 훨씬 높은 불일치가 존재할 수 있음을 주목해야 한다.



Posted by '김용환'
,


카산드라 cqlsh에서 일관성 레벨을 확인하고 싶다면, consistency를 입력한다.


ONE 일관성 레벨을 기본값으로 갖고 있다. 




cqlsh> consistency


Current consistency level is ONE.




일관성 레벨을 QUORUM으로 변경하려면 다음과 같이 실행한다.



cqlsh> CONSISTENCY QUORUM;

Consistency level set to QUORUM.

Posted by '김용환'
,

nodetool status 커맨드 결과를 살펴보면 UN이라고 나온다. 


설명에 나와있긴 한데, 나처럼 생각없이 결과를 보는 이들을 위해.. 





UN은 status가 UP이면서 state가 Normal임을 나타낸다.




$ nodetool status mykeyspace


Datacenter: datacenter1

=======================

Status=Up/Down

|/ State=Normal/Leaving/Joining/Moving

--  Address    Load       Tokens  Owns    Host ID                               Rack

UN  127.0.0.1  47.66 KB   1       33.3%   aaa1b7c1-6049-4a08-ad3e-3697a0e30e10  rack1

UN  127.0.0.2  47.67 KB   1       33.3%   1848c369-4306-4874-afdf-5c1e95b8732e  rack1

UN  127.0.0.3  47.67 KB   1       33.3%   49578bf1-728f-438d-b1





Posted by '김용환'
,


cql에서 필드마다의 저장 시간을 확인하고 싶다면 WRITETIME을 사용한다.



SELECT "email", WRITETIME("email"), "location", WRITETIME("location")

FROM "member"

WHERE "username" = 'samuel.kim';



 email               | writetime(email) | location | writetime(location)

---------------------+------------------+----------+---------------------

samuel.kim@google.com | 1501879907661000 |      seoul |    1502024896943000



참고

http://docs.datastax.com/en/cql/3.1/cql/cql_using/use_writetime.html

Posted by '김용환'
,


각 카산드라 노드에는 특정 토큰 범위가 지정되며 모든 데이터의 부분 집합을 담당한다. 

파티션 키 해시 생성을 담당하는 컴포넌트를 파티셔녀(partitioner)라 한다. 따라서 파티셔너는 주어진 파티션 키의 해시를 계산할 때 사용되며 데이터가 어느 노드에 위치해야 하는지 결정하는 해시 함수이다. 카산드라는 3개의 파티셔너를 제공한다.




1. Murmur3Partitioner : 카산드라 1.2이후의 기본 파티션이다. 해당 파티셔너는 머머(Murmur) 해시 값을 계산하여 클러스터 전체에 데이터를 균일하게 분배한다. 머머 해시 값의 범위는 -263에서 -263-1이다. 해당 파티셔너는 해싱 알고리즘이 빠르고 다른 파티셔너보다 성능이 뛰어나기 때문에 선호된다.



2. RandomPartitioner : 해당 파티셔너는 파티션 키의 MD5 해시 값을 계산해 데이터를 균일하게 분산한다. 해당 파티셔너는 카산드라 초기 버전의 기본 파티셔너였다. 해시 값의 범위는 0에서 2127-1 범위이다.



3. ByteOrderedPartitioner : 해당 파티셔너는 키 바이트 단위로 정렬된 데이터 분포를 어휘적으로 유지한다. 해당 파티셔너는 카산드라의 최신 버전(2.x)에서 사용되지 않고 앞으로 사라질 예정이다. 하지만 예전부터 사용해왔기 때문에 삭제는 되지 않은 상태이다. 해당 파티셔너는 일반적으로 핫스팟(hotspot)과 고르지 않은 로드 밸런싱을 유발시킬 수 있어서 사용하지 않는 것이 좋다.

Posted by '김용환'
,

[cassandra3]

cassandra 2017. 8. 15. 00:59



카산드라 테이블의 컬럼을 삭제할 때 보조 인덱스(secondary)가 걸려 있다면 삭제할 수 없다. 


> ALTER TABLE "users" DROP "year";


InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot drop column year because it has dependent secondary indexes (users_idx)"



먼저 보조 인덱스를 삭제한 후 테이블의 컬럼을 삭제한다. 정상 종료..


> DROP INDEX "users_idx";

> ALTER TABLE "users" DROP "year";


Posted by '김용환'
,