금일은 Mongodb 랑 Spark하는 방법에 대해서 알아보겠다. 2020년 Mongodb에서 Spark 3.x 지원을 하기 시작했다. 2020년 7월쯤 Spark 3.x 으로 먼저 업그레이드를 한 뒤... Mongodb에서 Spark 3.x를 지원하지 않아서 멘붕에 빠진적이 있었다. 하긴 Spark 3.0이 6월 18일이니까, 너무 바로 다음달 7월에 적용한다는게, 지금 생각해보면 무리였다. 당시 나온 Spark 3.0은 소개글이다. Spark3.0이 Spark 2.4 대비 성능이 2배이상 차이가 난다. 그래서 아무생각 없이 무조건 업그레이드를 해야겠다고 생각했다.. 결국 그 생각이 화근이 되어 당시 Spark3.0 를 업글은 없던 일이 되었다.. 그 후, 한달 뒤, 2020년 8월쯤에 해당 서비스를 ..

금일은 샤드 추가에 대해서 알아보겠다.. 하면서 당황스러웠으나,,, 다행히..시간이 해결해준다는 걸을 알게 되었다.. 오늘 할 작업은 아래와 같다. 위에서 말한 당황스러운 일은 바로 데이터 건수가 맞지 않는 것이다. 시간이 지나니 데이터 건수는 맞아졌다. 그럼 샤드 추가하는 방법과 데이터의 건수가 어떻게 변화하는지 알아보겠다. 1. 샤드 구성도 $ use config $ db.shards.find( { } ) 그럼 아래 사진처럼 현재 shard 01 만 구성이 되어 있다. mongos에서 데이터 건수를 확인해 보면 $ db.getCollection('test').find({}).count() 요래 1000건이 들어있다. 이걸 다시 shard 01에서 검색을 해보면 $ db.getCollection('te..

음, 오늘은 몽고디비 구성된 샤드를 제거하는 방법을 배워보겠다. 요즘 계속 몽고디비에 관련된 글만 쓰는거 같다. 몽고 덕후가 되어 가고 있다... 현재 구성된 몽고디비의 구성도는 아래와 같다. 몽고디비 설정을 하고 싶다면 내가 블로그에 작성한 글을 찾아보면 된다. 일단 주의할 점을 먼저 말을 하겠다. 운영중에 해당 명령어를 날리면,,, 큰일 난다,,,, 결론부터 말하자만, 샤드가 제거된 서버의 데이터가 제거되지 않는 모든 서버로 이관이 된다. 쉽게 말해, 위 그림 shard 03이 샤드에서 제거되면, shard 01, shard 02로 데이터가 마이그레이션이 자동으로 진행된다. 즉, 이 과정에서...성능 저하가 발생해 운영이 불가능해진다.. ㅠ-ㅠ 뭐 그래도 샤드 제거가 성공만 하면, 데이터의 유실없이 ..

금일은 몽고디비 샤드에 대해 알아보겠다. 금일 몽고디비 구성도는 아래와 같다. 2번정도 쭉 따라서 확인차 만들어 보았다. 큰 문제 없이 구성이 된다. 단, 위 그림에서 회색으로 표현된 부분은 레플리카 셋이므로 구성에서 빼겠다. 레플리카 셋을 설정이 쉬우니, 내가 정리한 글을 참고하면 되겠다. ( 해당 링크 : urame.tistory.com/entry/mongodb-%EA%B5%AC%EC%A1%B0 ) 그럼 일단 mongodb 설정을 위해, 디렉트리를 만들어 보겠다. 특별히 해줄 작업은 없다. 볼때는 어려운데, 막상 해보면, config 설정이 작업의 전부이다. 그러니!!! 아래 명령어를 그대로 따라온다면 충분히 설정이 가능할 것이다. 본 환경에서는 shard 구성과 replication 설정을 각각 1..

오늘은 과거에 은근 찾기 어려웠던, 그 명령어 union에 대해 알아보겠다. 왜 찾기 어려웠냐면... mongodb에서도 비슷한 명령어가 존재한다.. 당시 내가 하고 싶은 명령어는 sql로 단순했다. [SQL] select * from plc where time > '2020-03-01 00:00:00' limit 1 union all select * from plc where '2020-03-01 01:00:00'

그냥 요즘 MongoDB를 모니터링 하던 중.. 옛 추억이 떠올라 글을 하나 작성하기로 했다. DataBase란 차고로 DML이 꽃이라고 개인적으로 생각한다. 1. DML이란 무엇인가? 그냥 단순하게 말해서, 우리가 생각하는 데이터 핸들링 방법이다. 즉, 조회하고(SELECT), 수정하고(UPDATE), 저장하고(INSERT), 지우는(DELETE) 기능!!! 근데 몽고디비를 관리하는데, 왜 이런게 생각 났냐 하면, 바로 delete 이슈이다. 성능이 느리다거나 그런 이슈가 아니다. Delete를 하고 Disk를 반환하지 않는다. MongoDB 운영 당시 Disk 사용률이 78%까지 올라간 상황이였다. 아직 시간은 있었으나, 개발서버로 사용하던 MongoDB의 디스크 사용량이 3개월도 안되서 가득차가고 ..