반응형

불과 1년전 딥런닝 관련하여 관심을 가지면서 해당 스터디에서 만나 뵙던 분 중 한분인 이재석님이란 분이 계셨다.


비록 2번정도의 스터디 이후 개인적인 일로 더이상 참여를 못했지만 그 때의 인연을 지금까지 페북에서 이어 나갈 수 있었다.


그 때 당시에 python 도 제대로 이해 못하셨던 분이었지만 꾸준히 하시던걸 보며 감명 받았는데, 어느새 챗봇을 만들어 세미나까지 연다고 하시니,

참석을 안할 수가 없었다.(정말 존경하는 분 중의 한분이 되셨다....많이 본받을 분이라고 생각한다)


DBA로써 다양한 지표에 대해서 알고 싶을때나 장애 발생 시 또는 모니터링을 위해 챗봇을 하면 좋다고 막연하게 생각하던 도중이라 더욱더 참가하고 싶었다.


여기의 포스트에는 당시의 ppt 내용 일부와 내가 한 결과물에 대해서 공유만 하려고 한다.

왜냐하면 이 모든게 그냥 소스를 가져와서 나의 카카오봇과 연동한 것 뿐이기 때문이다.



챗봇과 관련한 구글 영상




챗봇은 그리 대단한게 아니지만...만들면 만들수록 대단한거고,

우리가 만드는것은 대단한게 아니라 필요에 의해서 편의를 위해 만드는거라는 내용이 인상 깊었다(-이재석 님)


테스트를 위해 필요한 건 python / flask / ngrok 으로 카카오 봇을 만들수 있었다.


그리고 에코봇을 만들수 있는 소스

https://github.com/software-engineer-mj/chat-bot-seminar


심화로 구글 번역을 이용한 번역봇? 소스


https://github.com/Bricoler/chatbot-seminar


난 여기까지 운이 좋게 테스트를 할 수 있었다.


에코봇


아래는 번역봇이다.


세미나 ppt 는 아무래도 저작권이 있다고 생각하기에 공유는 못하고 깃헙은 이미 공유되어 있는거라 공유해 봤다.


이제 시작이다. 내가 필요한거를 어떻게 공유를 하고 좋을지에 대해서 하나씩 설계해 나갈 예정이다.


그리고 다시 한번 이재석님 감사합니다.

반응형
반응형

공부를 한다고 하지만..어느 순간되면 자만에 빠지기 마련이다.
내가 그런 케이스이다..

Hash index 와 B-Tree index에 대해서 제대로 몰라 진땀을 흘렸다...


다시 공부하다가 이렇게 좋은 경험담 덕분에 제대로 이해했다..


다시 한번 느낀다...공부에는 끊이 없다. 學不可以已 (학불가이이)


좋은 내용은 아래를 참고하자..

http://gywn.net/2015/01/innodb-adaptive-hash-index/


비슷한 내용이다(동일하다..)

http://tech.kakao.com/2016/04/07/innodb-adaptive-hash-index/


반응형

'MySQL' 카테고리의 다른 글

[Percona] pt-query-digest 사용 방법  (0) 2021.10.28
[MySQL] ARCHIVE Engine  (0) 2017.07.19
[펌][MySQL] CockroachDB in Comparison  (0) 2017.07.03
[펌] [MyISAM] myisamchk 사용하기  (0) 2016.11.25
[MySQL] auto_increment duplicate entry for key 1  (0) 2016.11.14
반응형

한번 더 말씀드리지만 저는 redis에 대해서 거의 모릅니다...

공부해 가는 단계지만 그래도 한글로 된 내용이 거의 없어서 공유해 봅니다.

(제가 못 찾은게 맞는듯 싶습니다.)


각설하고 이제 공유 진행하겠습니다.




AWS ec2 에 올린 redis4.0을 백업과 모니터링 문제로 고민하다가

Elasticache 로 옮기는 것에 대해 고민하게 되었다.


정확하게는 내가 아닌 다른 팀에 의해서.


redis의 r도 모르는 내가 직접 찾아보면서 관련 내용은 좀 있어 보이나,

제대로 이해하기도 힘들었고, 한글로 된 내용도 없어서 애를 좀 먹었다.


아래 github 자료의 도움으로 무사히 테스트까지 완료 할 수 있었다.


https://github.com/p/redis-dump-load


참고로 해당 스크립트는 python으로 개발 되었으며 나는 오로지 가지고 사용하기만 했다..ㅠ


내용은 아래와 같다.

1. redis에서 dump를 받아 해당 내용을 json 으로 추출

2. json 파일로 추출된 내용을 Elasticache로 Load 진행

>> json 파일가지고 커스터 마이징을 한다면 다른 DB로 Import도 가능할 것으로 예상


사용방법은 잘 나와있지만, 공유 차원으로...


Export (현재 redis에서 실행하는데, -d 옵션은 해당 추출하고자 하는 DB 를 뜻함)

$ python redisdl.py -H localhost -d 1 > susun_dump.json


Import (Elasticache 로 진행 / H옵션은 elasticache로 다이렉트 접속이 안되기 때문에 ec2에서 elasticache로 접속할 때 해당 주소host  / d옵션으로 2번 DB에 import 하였으며, -l 옵션을 사용하여 import 한다고 명령)

$ python redisdl.py -H apn2.cache.amazonaws.com -d 2 -l < susun_dump.json


내 과제는 python 커스터 마이징 하는것이 나의 또다른 과제..


반응형
반응형

Redis를 기존에는 개발자들이 관리 하였지만,

이제는 DBA가 관리하는게 더 수월할 것 같아서 관리하기에 앞서 선행 학습중이다.


이리저리 접속 진행해 보았지만,

관리자는 콘솔에서도 작업이 기본!!!이라고 생각하기에


콘솔로 접속 후 데이터 확인을 하기 시작했다.


기본 명령어도 모르니 확인하는건 불가능....


여러모로 찾다가 노하우를 찾아 공유해 본다.


여러 redis 블로그를 보면 기본적으로 사용 방법만 나와있지,

어떻게 확인하는지는 못찾아서 꺼이꺼이 찾아서 공유해 본다.


1. select 로 db??? 선택

(rdbms는 db를 생성하지만 redis는 정해져 있다. 1 ~ 15까지 / select 1 또는 select 15 이런식으로 선택)


2. RANDOMKEY 를 사용하여 또는 KEYS * 를 사용하여 해당 KEY들 검색


 - keys * 를 하게 되면 모든 키가 검색된다.

 - 10만개의 데이터를 테스트로 저장했기에 만건이 표시된다.

..

중략...

..


3. 확인하고 싶은 KEY 의 type 확인을 위해 type 키내용 확인

- string으로 저장했기에...(단순히 set 으로 INSERT 하였다)


4. 해당 Key 타입에 맞는 명령어를 찾아 내용확이

- 명령어를 모른다면 아래 참조 사이트에서 찾아보자..


명령어 참고 사이트 : http://redisgate.kr/redis/command/commands.php


하아....정말 가급적 관리자가 아니라면 RedisDesktopManager 를 설치해서 간편하게 확인하는 것이 편할 듯 싶다.



반응형
반응형

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를 진행 하였다.


--innodb

sysbench --test=/usr/share/sysbench/tests/include/oltp_legacy/insert.lua --threads=8 --mysql-host=192.168.56.101 --mysql-user=root --mysql-port='8001' --mysql-table-engine=innodb --db-driver=mysql --oltp-table-size=10000000 --oltp-test-mode=complex --events=10000 --oltp-read-only=off  --db-ps-mode=disable  run;


--rocksdb

sysbench --test=/usr/share/sysbench/tests/include/oltp_legacy/insert.lua --threads=8 --mysql-host=192.168.56.101 --mysql-user=root   --mysql-port='8001' --mysql-table-engine=rocksdb --db-driver=mysql  --mysql-db=sbtest_rocksdb --oltp-table-size=10000000  --oltp-test-mode=complex --events=10000  --oltp-read-only=off  --db-ps-mode=disable  run;



결과는 아래와 같다


1. innodb



2. myrocks



Conclusion


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

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



* 추가 20초 동안 INSERT 진행

1. innodb

# sysbench --test=/usr/share/sysbench/tests/include/oltp_legacy/insert.lua --threads=8 --mysql-host=192.168.56.101 --mysql-user=root --mysql-port='8001' --mysql-table-engine=innodb --db-driver=mysql --max-requests=0 --max-time=20 --oltp-test-mode=complex --oltp-read-only=off  --db-ps-mode=disable  run;


2. myrocks

# sysbench --test=/usr/share/sysbench/tests/include/oltp_legacy/insert.lua --threads=8 --mysql-host=192.168.56.101 --mysql-user=root   --mysql-port='8001' --mysql-table-engine=rocksdb --db-driver=mysql  --mysql-db=sbtest_rocksdb --max-requests=0 --max-time=20 --oltp-test-mode=complex --oltp-read-only=off  --db-ps-mode=disable  run;



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를 접속하려고 했더니


접속이 거절되었다.

$redis-cli

Could not connect to Redis at 127.0.0.1:6379: Connection refused

not connected>


왜 접속이 안되는거야!!!


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

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


-- 혹시나 해서 redis 가 down 되어 있는지 확인


$ ps -ef | grep redis

redis     1204     1  0 Jan04 ?        01:04:04 /usr/bin/redis-server 192.168.1.101:6379

root    13423 12834  0 13:35 pts/0    00:00:00 grep redis


--redis가 정상적으로 올라와 있구나..
-- 혹시나 해서 -h 옵션을 사용해서 아이피를 적어 봤다.

$ redis-cli -h 로컬아이피

로컬아이피:6379>


ex) $ redis-cli -h 192.168.1.101

192.168.1.101:6379>


접속이 되는구나!!!



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


깨알 지식 공유

반응형
반응형

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 모드로 테이블 조회가 가능하다.


RESTORE DATABASE [shipping2] FROM  DISK = N'C:\repl\backup.bak'
WITH  FILE = 1
,  MOVE N'Shipping2_Data' TO N'c:\Shipping2_data.mdf'
,  MOVE N'Shipping2_Log' TO N'c:\Shipping2_log.ldf'
, standby = 'E:\Shipping\standby.ldf'
,  norecovery
GO
- 순차 복구
restore log shipping2
from disk = N'C:\repl\Shipping2_log1.bak'
with standby = 'E:\Shipping\standby.ldf'
;
RESTORE LOG shipping2
FROM  DISK = N'C:\repl\Shipping2_log2.bak'
WITH standby = 'E:\Shipping\standby.ldf'

;




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


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


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


http://aruesoft.tistory.com/16


공식 문서

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

반응형

'SQL Server(MSSQL)' 카테고리의 다른 글

[mssql] database mdf/ldf 파일 이동  (0) 2017.09.28
[MSSQL] 시작..  (0) 2017.09.28
반응형

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

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


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




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

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


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

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


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


공식 문서(GUI)

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


create database shipping;


use shipping;

-- 해당 데이터 파일 생성된 위치 및 이름을 확인하자(위치는 물리파일 이동 해야 되기 때문에 위치는 반드시 파악하자)
-- log는 트랜잭션 log이므로 같이 옮기자. 물론 둘을 물리적 디스크로 분리하는 것이 성능적으로는 효과 적이다.
-- 하지만 우리는 테스트 이기에 같이 옮기자.

select name, physical_name from sys.database_files;

--원하는 위치로 설정
alter database shipping modify file (NAME = shipping, FILENAME='E:\Shipping\Shipping_data.mdf');
alter database shipping modify file (NAME = shipping_log, FILENAME='E:\Shipping\Shipping_log.ldf');

use master;
--오프라인으로 설정(이제 해당 DB는 사용 불가 / 운영시에는 session 유입을 꼭 확인하자)
alter database shipping set offline;

--이제 물리적인 파일을 서버 상에서 이동하자(위에 physical_name의 결과가 해당 물리적인 파일 위치이므로 참고하자)
windows cmd> move "기존 물리파일 위치(physical_name)" "E:\Shipping\Shipping_data.mdf"
windows cmd> move "기존 물리파일 위치(physical_name)" "E:\Shipping\Shipping_log.ldf"

-- online 으로 변경한 후 제대로 변경 되었는지 확인하자
alter database shipping set online;

use shipping;
select namephysical_name from sys.database_files;


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


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


반응형

'SQL Server(MSSQL)' 카테고리의 다른 글

[MS SQL] Transaction Backup Restore (with Standby)  (0) 2017.10.10
[MSSQL] 시작..  (0) 2017.09.28
반응형

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

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


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


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

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


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

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


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

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


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

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


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



반응형

+ Recent posts