MariaDB의 Storage 엔진 중 하나인 myrocks 는 페이스북에서 개발한 엔진 이다.

개념 정리 및 테스트를 하고 싶어서 작년에 잠깐 진행하다가 중단된 이후 지난주부터 다시 진행 중이다.

여러 테스트 이전에 개념 정리가 중요한데,

아직 정리를 진행중이며, 공유를 하기에도 민망할 정도로 정리가 안되어 일단은 간단 sysbench 테스트 정도 진행한거 공유하려고 한다.

공유에 앞서 myrocks의 경우 기존 innodb의 B Tree 방식이 아닌 LSM-tree 기반 INDEX를 사용한다.

추후 mongo DB도 진행 예정이지만 이때도 페이스북에서 개발한 rocks engine?을 설치해서 테스트 예정이다.

mryocks는 아무래도 INSERT 와 SELECT 에 초점을 맞춘? storage engine 이기에 간단하게 INSERT 테스트를 먼저 진행해 보았다.

참고로 myrocks 는 아래와 같이 확인 할 수 있다.

(Engine : ROCKSDB / Index : LSMTREE)

당연 동일 DB에 sysbench를 이용하여 INSERT를 진행 하였다.

결과는 아래와 같다

1. innodb

2. myrocks

Conclusion

- time 은 innodb가 myrocks 보다 적게 소요

- transaction 처리량 또한 innodb(2420건) myrocks (935건)으로 더 높은 처리량

* 추가 20초 동안 INSERT 진행

1. innodb 결과

\

2. myrocks 결과

- 하아..myrocks에 대해 기대한 만큼 뭔가가 아쉽다. 물론 내가 잘못 테스트 할 수 있기 때문에 그냥 참고 자료로 활용하려고 한다...ㅠ

★ Redis Replication 구성 방법은 아래 블로그 참조

- 정말 쉽게 작성하여서 나도 쉽게 구성을 완료 하였다.

- 아쉽게도 replication 관련해서 check 방법에 대해서는 잘 나와 있지 않아 아쉬움 부분이 있다.

http://jdm.kr/blog/157

★ Redis HA 구성 방법은 동일 블로그 내에 참조

- 아직 진행은 하지 않았지만 별 문제 없이 가능하도록 잘 설명되어 있음

http://jdm.kr/blog/159

★ 주요 설정값

http://jdm.kr/blog/139

maxmemory 2mb
maxmemory-policy allkeys-lru

추후 MongoDB 진행하면서 이 분 블로그 참조하면 빨리 익힐 수 있을 듯 싶다.

다음 참조하면 좋을 블로그(사이트)

★ redis 구성 시 어떤 부분을 유의하면서 실무에 적용하면 좋을 지 설명하는 내용

http://redisgate.kr/redis/configuration/replication.php

오랜만에 블로그 하는 만큼 좋은 정보를 공유해야 하는데...퍼온 거라니...에휴...ㅠ

sql server 나름 한것들에 대해서 공유도 해야 하지만...이건 정리하는게 삼만리라...포기..ㅠ

다음으로는 mongo DB를 R&D 하는 것이며, 다음 게임 프로젝트는 mongoDB를 고려해볼까 한다....

Redis를 직접 관리하기 위해 MongoDB와 함께 nosql 에 대해 공부를 시작하였다.

그 중 현재 사용하였던 redis 내용을 보기 위해 접속을 진행 하였다.

개발자 분들에 의해 관리가 되어 오다 보니, 

히스토리도 없었으며, 알고 계시는 분이 거의 없었다.

redis를 테스트DB에서 설치하여 진행하다가 실무에 사용된 redis를 접속하려고 했더니

접속이 거절되었다.

몇번의 검색을 해도 나오지를 않아서 mysql 처럼 IP접속 권한과 비슷하지 않을까 해서 시도 했더니

정상적으로 접속이 되었다.

사소한 것일지 모르겠지만 모르는 사람에게는 순간 당황할 수 있는 상황...

깨알 지식 공유

Transaction Backup을 매 시간 마다 받고 있다.

여러가지 이유가 있지만 그 중에는 Transaction log가 Full 차는 경우도 있는걸로 알고 있다.

이 부분은 추가 적으로 정리해서 공유 하도록 하겠습니다.

그래서 매 시간마다 받고 있는데, 이것을 이용하여 시간마다 백업 DB에 동기화 하여 기획자나, 운영자가 Read only로 

조회 하는 것을 만들고자 제안을 했다.

이것을 Log shipping 이라고 하는 것인데, SQL Server 내 기능이 아닌 (SQL Log shipping) Transaction backup을 이용하여 log shipping을 만드는 것이다.

기존 Full backup 파일이나 Transaction log를 가지고 복원을 한다면 매번 full backup을 이용한 복구 후에 Transaction log로 복원을 해야한다.

이렇게 되면 매 시간마다 불필요한 작업이 진행되기 때문에 전체적으로 resource 낭비라고 생각했다.

그래서 full backup은 한번만 복구 후 이 후 Transaction backup파일을 가지고 진행이 안될까 찾던 중 sql server 관련한 유명한 분께 용기내어 메일을 보냈고, read only로 진행하면 가능하다는 답변을 받았다.(영광영광!!!*_* http://sqlmvp.kr )

(여담이지만 read only까지는 생각을 했지만 어디까지나 가정이었다...여기저기 검색하던 중에 이렇게 하면 되지 않을까...라는 생각..)

아래는 내가 직접 진행하고 확인한 것들이다.

(With standby 를 해 주면 된다.)

이렇게 진행하면 굳이 restore 완료 후 recovery를 하지 않아도 read only 모드로 테이블 조회가 가능하다.

보는 바와 같이 logoff 시간을 보면 정상적으로 Transaction log가 적용 된 것을 확인할 수 있다.

더 자세한 내용은 아래 페이지에 접속해서 확인하면 좋을 듯 싶다.

개념 뿐만 아니라 많은 내용 들이 있어서 이해하기 수훨 하였다.

http://aruesoft.tistory.com/16

공식 문서

https://technet.microsoft.com/ko-kr/library/ms178034(v=sql.105).aspx

SQL Server의 가장 큰 장점은 한글로 된 공식 문서가 많다는 것이다.

단점보다 아쉬운건 다른 DBA분들의 공유 내용이 많지 않다는 것 같다.

그 공유란 것이 대부분 GUI로 하는 공유라 난 SQL를 원하고 있으며 공식 문서는 이런 부분이 조금 이해하기 힘들다?(적어도 나에게는)는 것이다.

현재 Replication 구축중이다. 이미 10년 넘게 운영되고 있는 DB라 건드는게 여간 쉽지가 않다.

하지만 Replication 구축도 제대로 안되어 있기에 이 부분을 집중하고 있다.

기본적으로 DB를 생성 후 디스크 용량으로 인해 이동하려는데 대부분 GUI로만 설명이 되어 있어서

SQL 문으로 설명 추가해 본다.

정말 사소한거지만 또 모르고 있으면 곤란하기에 간단한것부터 공유하며 적어 본다.

공식 문서(GUI)

https://support.microsoft.com/ko-kr/help/980163

GUI가 편하면 GUI로 진행하고 나같이 쿼리가 편하면 쿼리로 하는 것이 좋을 듯 싶다.

기초지만 다시는 안보고 할 정도로 정리는 필수!

DBA로써 여러 DB를 알고 있는것도 좋은거고..

또한 하나의 DB를 깊게 아는 것도 중요하다.

욕심은 MySQL 를 깊게 알고 Oracle / SQL Server를 중급레벨 이상이면 좋지만, 중급정도는 알고 싶었다.

하지만 모든게 내 뜻데로 되지 않듯이..

SQL Server를 본의 아니게 조금 더 일찍 시작하게 되었다.

후회는 없지만 MySQL 를 조금 더 깊게 파지 못하는 아쉬움이 있지만, 다행히 MySQL 도 놓지 않고 계속

컨트롤 할 수 있기에 여기서 SQL Server를 시작하게 되었다.

이것저것 어느정도 개념과 사용 방법을 어렵지 않게 익혔지만

아직 쉽지 않은것은 사실이다.

아쉬움은 있지만 후회는 없으며,

DBA로써 오히려 더 즐거움과 피드백이 생겼다.

시작이라고 적지만 이것은 DBA로써 연장이라고 생각하며 더 깊게 들어갈 수 있는 기회라고 생각한다.

우연히 ARCHIVE Storage 엔진에 대한 소식을 듣고 공식 홈페이지를 통해 구글 번역과 참고를 통해 

정리해 보았다.

구글 번역이 점점 자연스러워 지고 있네..!!!!(감사합니다.ㅠ)

어디에 어떻게 적용해 볼지 고민을 해봐야겠다.(Log DB를 생각중...)

혹시라도 도움을 주실 수 있다면 댓글로 감사히 받겠습니다. 경험담 좀 부탁 드립니다.ㅠ

• 대용량의 데이터를 작은 단위의 풋프린트(footprint)없이 저장하기 위해 사용
• 설치 하려면 source 에서 configure에 --with-archive-storage-engine 옵션 추가해야 함
• •  CMake with the -DWITH_ARCHIVE_STORAGE_ENGINE   (look in the storage/archive directory)(mysql공식 홈페이지)
• 체크 >> show variables like ‘have_archive’
• 테이블을 생성하면 하나의 테이블 포맷 파일을 생성(*.frm)
• 데이터 파일의 경우 *.ARZ / *.ARM 파일 생성
• ARN 파일은 최적화(Optimization operations)를 하는 동안 나타날 수도 있음
• 하지만 mysql5.7 에서는 ARZ/ARN/FRM 파일 3개만 생성 되
• 테이블 하나당 대략 4개의 파일이 생성된다고 보면 될 듯
• 
  
• INSERT와 SELECT만 가능(DELETE, REPLACE, UPDATE 미지원)
• • mysql5.7에서는 INSERT / REPLACE / SELECT 지원 (Order by 미지원, BLOB 등 미지원)
• Auto Increment속성 지원(다른 컬럼으로 index 를 생성되지 않음)
• row level lock
• row 추가 시(INSERT) zlib 무손실 데이터 압축 진행
• Optimizer Table를  사용하여 테이블 분석할 수 있음
• Check Table를 사용할 수 있음
• • 데이터 추가 시 압축 버퍼로 넣으며, 필요한 만큼 버퍼 플러시가 이루어 지는데, 이 때 데이터 보호를 위해 lock이 지원
  • select의 경우 강제 플러시 실행
• Bulk Insert의 경우 동시간에 다른 Insert가 발생하지 않더라도 완료 후에 볼수 있으며 부분적으로는 볼 수 있음
• 검색: 캐쉬에 없을 경우 압축을 해제한 후 select 진행
• • select 는 consistent read 로 진행
  • 대량 INSERT진행 시 SELECT를 사용하면 압축 관련 지연될 것이다.
• ARCHIVE 의 효과를 올리기 위해서는 Optimize Table , Repair Table을 사용할 수 있음
• ARCHIVE 테이블의 데이터 수는 show table status를 통해 항상 확일할 수 있음

텐써플로우 첫걸음 이라는 책을 사놓고..

보지도 않고 있다가

오늘에서야 조금씩 보기 시작했다.

DBA로써 내 분야에 대해 공부와 더불어 스트레스를 풀기 위해 데이터 분석도 진행하려고 샀다.

2. 비용함수와 경사 하강법 알고리즘

* 사실 이해를 제대로 못했다...하지만 한번 훑고 넘어 가고 다시 한번 보도록 해야겠다.

mysqldump로 백업을 진행하다 보니 테스트 기회가 생겨 테스트를 진행해 보았다.

sql파일을 바로 Import 진행하니 중간에 세션이 끊기거나 한다면 ㅊㅓ음부터 다시 진행해야하는 불상사가 발생해서.

검색 도중 innodb를 myisam으로 변경 후 진행하는 방식을 추천해 주어 진행해 보았다.

기본 테스트 테이블의 정보는 아래와 같다.

2번째 테이블이 대상이고 빈 테이블에 myisam으로 변경 후

68,769,549 건을 진행했다.

시간을 보면 알 수 있듯이

대략 7시간 정도 소요 되었다.

(메모리는 32G 기준 )

참고로, 동일 테이블에 동일 방식으로 innodb를 진행하였을 경우 10시간 이상 진행해도 끝나지 않았다.

이렇게 되면 MyISAM 으로 변경 후 진행해야 되는 걸까??

이 부분에 대해서 추가 작업이 있음을 인지하고 있어야 한다.

해당 테이블을 MyISAM 에서 InnoDB로 Storage 엔진을 또 변경해야 된다는 것이다.

데이터가 없을 때에는 바로 변경이 된다.

하지만 데이터가 있을 경우 temp 테이블에 추가하였다가 진행해야 되기에 시간이 만만치 않게 소요 된다.

아쉽게도 정확한 측정을 못했지만 대략 4시간 정도 소요 되었다.

약 7억건의 데이터를 옮기는데 이정도 소요된다.

다시 한번 21건에 대해서 진행 중인데, 정확한 수치를 알고 있어야 될 듯 싶으며,

이번 기회를 통해 백업 방식을 xtrabackup으로 테스트 및 변경을 고려 해 봐야 할 듯 싶다.

좋은 정보가 있어서 공유 합니다.

https://www.cockroachlabs.com/docs/stable/cockroachdb-in-comparison.html#yes-feedback

CockroachDB in Comparison

* In DynamoDB, distributed transactions and ACID semantics across all data in the database, not just per row, requires an additional transaction library.