저는 전산쪽과 1%도 상관이 없는 사람인데 어떠한 계기로 데이터베이스를 쓰게 되었습니다.
데이터베이스가 괜히 어렵고 시작하기 어려운 분들께 도움이 되었으면 합니다.
지식이 많지 않은 저같은 사람도 쓸 수 있을 만큼..
데이터베이스는 그저 편의를 위해 존재한 다는 것을 알려드리고 싶습니다.
그리고 조심해야할 점도…
실제 다른 방법으로 운영하는 분들의 의견도 들어보고 싶습니다..
데이터베이스를 시작하게된 계기
윈도우 프로그램을 시작할 무렵 할 수 있는 거라고는 파일 처리 뿐이었습니다.
주로 연구과제 성격의 로그데이터를 저장하고 읽는 일이었습니다.
매일 파일을 여러개 저장하는 것이라 저는 이렇게 처리 했습니다.
저장 위치: 년 / 월 / 일 / 차량번호_시작시분초_끝시분초.log
eg) 2011/08/22/서울12가3456_172255_191211.log
저장 위치를 리스팅해서 어떤 표에 그리고 클릭하면 차트도 나오고 약간의 분석도 나오는 그런 것들을 만들었죠..
혈기왕성 초심 가득한 개발자라 모든 요청은 들어오는 즉시 처리했습니다.
신경 안쓰고 1년이 지나니 파일이 만개도 넘어서 엄청나게 버벅인다고 연락이 옵니다.
그래서 선택상자를 만들어서 년월일을 고르면 리스팅이 되게 처리했습니다.
또 요청이 옵니다.
8월치만 날짜 거꾸로 정렬해달라고..
버블소트니 뭐니 공부해서 구현 완료…
또 요청이 옵니다.
차량번호 기준으로 정렬해달랍니다..
만개가 넘는 파일을 다 뒤져서 추출 후 정렬..
또 다른 요청..
해당 로그파일의 요약 값중 속도 평균 값만 정리된 표는 안되나요?
로그파일을 반복문으로 돌려서 요약 값을 만든 후 년 / 월 / 일 / 차량번호.calc 라는 말도 안되는 파일을 만듭니다.
또 요청..
현재까지 최고 속도는 어느 차량이죠?
해보니 뭔가 목차, 인덱스 같은 것이 필요할 것 같았습니다.
한번 전체 파일을 다 뒤져서 요약한 값들을 summary.info 라는 파일을 만들어서 저장해두었습니다.
이제 요약본이 있어서 빠르게 색인된 파일들 위치가 금새 나오게 되었습니다.
그런데 하다보니 뭔가 다른 것 필요할 것 같았습니다.
어디서 들어봤던 데이터베이스를 검색해보고 살펴보았습니다.
느꼈습니다.. 내가 했던 개고생을 다들 이렇게 쉽게 극복하고 있었구나…
그렇게 제가 시작했던 첫 데이터베이스는 MySQL이었습니다.
운영 문제
데이터베이스로 색인을 해두니 간소한 테이블 몇개로 데이터를 찾고 넣고 하는 것이 너무 부드러웠습니다.(행복함..)
문제는 서버 구축이었습니다.
지금 생각해보면 sqlite 같은 것이 적격이었을 텐데..
시작을 MySQL로 하는 바람에 서버를 구축하게 되었습니다.
그 서버는 바로 제 피씨였답니다..
제 피씨에 고정아이피를 주고 한참을 운영을 했는데요..
제 피씨는 늘 느리고 끄지도 못하는 피씨가 되었습니다.
몇달을 고생하다.. 그 핑계로 데이터베이스도 최적화되어있고 앱개발 가능한 iMac이 필요하다고 하여 말도 안되는 득템을 하게 됩니다.
그래서 클라우드 서버를 알아보기 시작했습니다.
제일 유명한 AWS를 알아보고 해봤지만 지식도 얕고 온통 영어인데다가 버지니아에 서버를 둬야하는 상황 같아서 패스하고 다른 것을 알아봤습니다.
그중 KT 클라우드를 선택하여 윈도우서버 2012에 mysql을 깔아서 운영하게 됩니다.
KT를 선택한 이유는 한글 메뉴가 전부였습니다.
리눅스
쓰는 거라곤 화면 필요 없는 MySQL 뿐인데 굳이 화려한 화면의 윈도우2012가 부적절해보였습니다.
리눅스서버보다 OS비용 2만원이 더 들거든요.. 약이 올랐습니다.
KT 클라우드에 리눅스서버를 한대 추가해서 MariaDB(MySQL과 거의 비슷함)을 구동 시키는데는 1시간도 안걸린 것 같습니다.
제가 생각한 OS(리눅스,윈도우)는 어플리케이션을 편하게 구동시켜주는 그 이상 그 이하도 아닌 것이 라고 늘 생각해 왔는데, 왠지 증명된 듯 하였습니다.
그러나 자주는 아니지만.. 글자를 수정하거나 하는 에디터(vi)같은 걸 써야될 때는 정말 고역이였습니다.
몇 일 해보면 할 만 하기도 해서..
vim 같은 걸로 코딩도 가능하겠는데? 라고 생각했다가.. 고수의 플레이를 보고..
저 길은 내가 절대 갈 수가 없는 길이구나… 라고 생각하고 접었습니다.
AWS RDS
생각해보니 내가 왜 리눅스 같은 걸 다뤄야하지? 누가 만들어주면 안되나? 라고 생각한 것이 이미 있었습니다.
바로 AWS(아마존이 운영하는 클라우드 서버) RDS 서비스인데 리눅스 운영 같은 거 상관 없이 그냥 읽고 쓰면(CRUD) 되는 획기적인 것입니다..
당장 가장 가까운 서버(도쿄였나?)에 뚫어서 돌려봤습니다.
리눅스 서버(ec2)도 몇개 만들고 NoSQL(DynamoDB)도 한번 만져보고 재미있게 놀았습니다.
몇개 되지도 않는 데이터인데.. 한달에 백만원이 넘었습니다.
얼른 연결된 카드 정지시키고 서버 꺼버렸습니다.
이유는 사실 지금도 잘 모릅니다. 과금 체계가 상당히 복잡한데 아마도 코드에 버그가 있지 않았을까? 하는 의심만 있고 귀찮아서 검증은 안했습니다.
대인배 아마존은 역시 사정을 얘기했더니 돈을 받지 않더군요..
하지만 앞으론 이런 걸 써야할 것이야.. 라는 확신은 가졌습니다..
개발자는 좀 더 생산적인 고민을 해야한다는 생각이 늘 있었으니까요..
NoSQL
RDBMS 운영중 고민했던 부분은 2가지였습니다.
- 날(raw) 데이터 처리
초데이터를 저장해야하는데 100대의 장비가 하루에 86400개의 데이터를 디비에 넣으니 역시 느리고 답답했습니다.
테이블도 일로 쪼개보고 장비별로도 다 쪼개보고 튜닝도 해봤지만, 정렬도 찾는 것도 정상이 아닌 것 같아서 파일로 저장했습니다.
그 파일들의 요약부분만 디비에 담아놨죠..
단일 서버에서는 상관 없지만 수평확장(scale-out)식의 서버에서 파일이란 것은 사실 엄청 불편한 것입니다.
부하에 따라서 서버를 복제해서 늘려야하는데 파일서버를 따로 둬야하는 번거로움이 있었거든요.
- 필드 추가
추가하는 것(alter) 자체는 어려운 일이 아닌데 이게 참 관리적으로 복잡했습니다..
테이블이 여러개일 때 짜증입니다.(구조를 잘못 설정한 이유가 더 크지만…)
혹시 이런 문제를 해소해줄 수 있나?(사실 구조만 잘 짜면 해결된다고 생각합니다…)
전에 해봤던 AWS DynamoDB가 생각나서 NoSQL을 찾아봤습니다.
그래서 찾은 것이 NoSQL계의 1인자 MongoDB..
MongoDB
리눅스 가상서버 하나 만들어서 바로 MongoDB를 깔아버렸습니다.
NoSQL 홀릭 그자체였습니다.
마침 자바스크립트(node.js) 많이 하던 때인데 데이터 자체가 자바스크립트 데이터(JSON)이라 행복했습니다.
요약데이터 몇개 설정 후 날 데이터 처리는 컬렉션(테이블) 하나 잡고 막 써버렸습니다.
게다가 규격에도 안맞는 데이터를 몽땅 넣어버렸습니다.
eg)
- 시간, 장비명, 유형, 거리, 속도
- 시간, 장비명, 유형, 길이, 높이, 파워
시간, 장비명, 유형에 색인을 걸어두면 다양한 장비를 유형별로 몇 억개의 데이터도 빠르게 검색이 가능했습니다.
문제는 두가지였습니다.
- 조인
조인이라 함은 요약된 정보와 매치되는 데이터들을 묶어 주는 것인데.. 이게 좀 한계가 있습니다.
여기 설명하긴 너무 길어져서.. (agregate, lookup등과의 차이) 접습니다..
사실 RDBMS가 너무 그리웠습니다..
그래서 색인은 RDBMS로 하고 날데이터만 NoSQL로 가볼까도 고민했습니다.
하지만 관리적으로 짜증나죠.. 혼자 다해야하는데..
- 용량
미친드시 늘어납니다.
사실 저렇게 날 데이터를 한 곳에 다 넣는 것은 미친 짓입니다.
적당히 분리해줘야죠..(파티셔닝)
리눅스 서버에 300기가 몇달만에 다 차갑니다.
안절부절.. 몽고디비 짱이라고 다 떠들고 다녔는데 혼날 것 같습니다…
MongoDB Sharding
서버를 늘려서 데이터를 나눠 가지는 시스템을 찾아봤습니다.
사실 이걸 알고 설치했어야 합니다. 이게 이들의 모토니까요(Scale-out)
100개의 데이터는 3개의 서버가 33(4)개씩 나눠 가집니다.
그리고 서버를 하나 늘리면 25개씩 나눠 가집니다.
그리하여 구현하게 됩니다.
까먹을까봐 정리도 나름 해놓습니다.
예전에 고민했던 흔적: 몽고디비 샤드 구성
만족스러웠습니다.
4대의 서버중 몇대를 세워도 멀쩡하고 데이터도 잘나눠가지고 늘어난다 싶으면 서버 한대(샤드) 한 대 더 추가하고..
그렇게 잘 운영하다 문제가 생깁니다.
몇십억개의 데이터가 쌓여서 이제 데이터를 좀 지워야했습니다.(과거 데이터는 별도로 아카이빙)
물리 하드 용량 90%즈음의 일입니다.
지웠는데도 불구하고 용량이 줄지 않습니다..
초긴장상태가 됩니다..
찾아보니 논리는 지운공간을 어짜피 다시 쓴다는 것입니다.(Wired Tiger)
논리대로라면 90%에서 멈춰야되는데 데이터가 왜 91%가 되고 있는 걸까..
당장 줄이는 방법(compact())을 알아봅니다.
서버 한대에 걸어놓은니 복구모드(Recovering) 상태가 됩니다.
약 2주의 시간이 지나고 정상(40%)이 되었습니다.
남은 2대도 이걸 하고 나니 6주가 걸렸습니다.
그 밖에도 자질 구레한 문제(StartUp2 상태에서 멈춤..등)에 봉착할 때마다 노이로제에 걸릴 것 같았습니다.
항상 중요한건 디비였으니까요..
운영을 너무 우습게 본 죄인 것이죠..(DBA분들이 있어야 되는 것입니다.)
도저히 참을 수가 없었기 때문에 대안을 모색합니다.
이제 돈이 문제가 아닙니다.
2가지를 고민 합니다.
AWS의 Dynamo, 아틀라스(MongoDB Atlas)
AWS는 아무래도 변환이 필요하니 아틀라스로 선택합니다.
MongoDB Atlas
아틀라스는 MongoDB에서 운영하는 클라우드 서비스입니다.
실제 서버는 AWS, GCP(Google꺼)둘 중 선택해서 사용합니다.
구글은 한국에 서버가 없어서 서울 리젼이 있는 AWS로 선택하였습니다.
결과는 대만족..
직관적으로 여러가지 차트로 상태도 볼 수 있고 확장도 클릭한번으로 해결되었습니다.(절대 몽고디비 직원 아닙니다.. 뽑아주지도 않겠죠..)
몇억개의 데이터도 꿀꺽 잘 삼키는 것도 확인했습니다.
자동확장(Auto Scaling)으로 40G에서 160G까지 늘어나는 것도 확인했습니다.
돈은 계산해보니 직접 운영하는 것 보다 15%정도 더 들지만, 이제 서버 노이로제는 좀 없어진 것 같습니다.
단점은 다 영어인게 문제인데.. 뭐 뻔히 데이터 읽고/쓰기만 하는데 전혀 지장 없습니다.
아직 구상중이지만 몽고디비 스티치(stitch)라는 것을 사용하면 백엔드 서버 조차 필요가 없게 됩니다.
어짜피 웹서버 돌려야되기 때문에 아직 크게 고민은 안하고 있지만..
프론트에서 디비까지 다이렉트로 읽고 쓰기가 됩니다.
구글 파이어베이스나 몽고디비 스티치 같은 행보를 보면.. 백엔드는 점점 더 필요 없어지는 것 같습니다.
백엔드를 정말 열심히해왔기 때문에.. 아쉽긴 하지만.. 이제 정말 프론트(React, Angular, Vue등) 중심 생산성의 시대가 오는 것 같습니다.
MongoDB Atlas 서비스
친절도 조사를 위해 한번 1:1채팅으로 문의를 넣어봤습니다.
영어를 잘 하지는 못하지만.. 대충 말 만들어서 보내봅니다.
일부러 데이터를 쌓아둔 후에 지워봤습니다.
그런데 하드 용량은 줄지 않은 이유에 대해 질문 해봤습니다.
- 질문:
Why is the data storage capacity still the same?
When will data storage be reduced?
- 답변: 3시간 후에 옴(아마도 미국 시차 때문일 듯?)
Hi memi thank you for getting in touch.
In MongoDB, document deletion does not decrease the size of the DB storage size.
Atlas uses WiredTiger as the default storage engine and it will not release disk space created by deleting documents. However, following a checkpoint, WiredTiger will mark any space freed due to deletes or updates as being available for re-use. WiredTiger is a no-overwrite data engine, so when page items are updated/deleted, the page is eventually written into the file in a new location, and the block that holds the previous version of the page is made available for re-use. The WiredTiger block manager maintains a list of reusable blocks, sorted by size, and when new blocks need to be written, blocks available for reuse are checked and used before the file is extended.
Please feel free to reach out here if you have any further MongoDB Atlas questions.
대략: 와이어드 타이거가 어떤 블록을 지우면 그 공간을 바로 빈공간으로 만들지 않지만, 업데이트나 지운 블록에 대해서 와이어드 타이거가 바로 오버라이팅하는 엔진이 아니기 때문에 지워진 블록에 대해 다시 쓸수 있는 블록이라고 마킹을 해두고, 용량별로 소팅해 두었다가 새로운 블록을 쓰려고 할때 파일을 늘리지 않고 이공간을 다시 쓴다는 얘기인듯… 결국 와이어드 타이거가 용량관리를 해준다는 이야기인거 같음.. 단 맥락을 보면 데이터를 업데이트하면 바로 오버라이팅이 안되어서 일시적으로 용량이 늘어날 수는 있을 듯.
- 만족도 조사 메일
Help Mary understand how they’re doing:
Good!
- 결과
뭐 더 물어봐야겠지만. 일정 시간 후에 데이터 용량은 줄어 있었습니다.
그리고 매 자정마다 뭔 짓을 하는 지 줄어 있고요.
또 이것 저것 물어봐야겠죠~
결론
데이터베이스는 편하라고 있는 것입니다.
아무리 어려운 얘기 해봤자.. 여러가지 디비가 있어봤자..
쓰고, 읽고, 수정하고, 삭제하고(CRUD: Create Read Update Delete)가 전부입니다.
데이터의 양에 따라 구조와 운영은 완전 갈립니다.
만개 - 백만개 - 십억개 가 늘 때 서버 용량만 늘리는 것은 절대 해결책이 될 수 없습니다.
솔루션 자체를 달리가져가야 합니다.
같은 프로그램(외형)이지만 그냥 다른 프로젝트라고 생각하는 게 좋습니다.(만개짜리 프로젝트, 백억개짜리 프로젝트)
만개짜리 프로젝트라도 백억개짜리 프로젝트라고 생각하고 설계부터 확장성을 염두해두고 만드시면 좋습니다.(그런데 염두하다 시작도 못하니.. 적당히 해야합니다.)
구조가 제일 중요합니다.
색인 용량 늘린다고 빨라지진 않습니다.
나중되서 설계 바꾸기가 힘드니 처음에 많은 고려를 해야합니다.
DBA 없는 열악한 환경이라면 클라우드 서비스를 사용하세요..
괜히 돈 아끼다 돈 더듭니다.
마치며
이게 사용기인지 팁인지 좀 헷갈리는데 우선 여기 놓아봅니다..
지난 강좌에 언급한 데이터베이스는 저렇게 시작 되었답니다..
모던웹 만들기: https://www.clien.net/service/board/lecture/11939401CLIEN
일렉트론뷰 데스크탑앱 만들기: https://www.clien.net/service/board/lecture/12267795CLIEN
개발자분들이 있을 까하는 마음에.. 강좌를 혹시나 하는 마음에 공유 차원에서 예전에 소개해드렸는데요..
생각보다 많은 분들이 잘 사용하고 계셔서 뿌듯합니다.
다음엔 팁이나 가능성이 주제가 아닌 실사용할 수 있을 만한 강좌로 다시 찾아뵙겠습니다.
/Vollago
개념 잘 안잡힌 중소기업에서 뭔지 조차 모르는 경우가 많더라고요..
사실 저희 회사도 그랬고요 ㅜ 예전에 글로 한번 정리한적 있습니다.
https://fkkmemi.github.io/talk/dba/
그리고 데이터 다 날리고 우울했던 경험도 있어서 기록해봤어요 ㅜㅜ rm -rf /data 해본 사람 입니다.
https://fkkmemi.github.io/talk/db-stability/
아무리 클라우드가 대단하다 해도 DBA를 완전 대체하지는 못한다고 생각합니다..
뭔가 뼈가되고 살이되는 중요한 교훈을 얻은것 같기는 한데. 기억회로가 고장났습니다...
DB관련된건 역시 한발걸치기만해도 디비지게 되는군요...냉장고에 머리 디밀고 잠시 식혀야겠습니다..
이래서 인공지능이 필요할걸까요 ?...
fuzzy 하면 퍼진다고 하던데...디비지고 퍼지고..거기에 뉴런(스펠링잊음)까지.
고생하였습니다...
혹시 일하는 중에 뭔가 저장하고 싶고 잘 찾고 싶다면 한번 도전해보세요.. sqlite 같은 로컬디비로 시작하셔도 되요
현업에 계시는분들에게 도움 많이 되겠네요~
프로그래밍을 하다 보면 결국 구조를 잘 잡아야 유지보수도 좋아지고 확장하기도 좋더라고요..
처음에 제가 만든 DB는 테이블 두개로 만들었어요. 그렇게 쉽게 한번 친해지고 나면 테이블 선정이나 추가가 자연스럽게 이루어지더라고요.
아무 디비나 하나 선정해서 쓰고, 읽기 한번만 해보세요. 점점 원하는 방향으로 나아질 꺼에요
DBA고용하느니 크라우드서비스에 인공지능 자동화 튜닝으로 업계가 가고있어서 DBA를 안뽑는다고 ㅠㅠ
개인적으로 연구용 데이터 관리하다보면 db를 써보고 싶었는데 처음은 유사한 고민으로 비슷한 방식으로 풀어가셧는데 결국 db를 건드시면서 다른세상으로 가시느군요 ㅎㅎ
근데 mongodb atlas는 mongodb shard 기반인거 아닌가요?
클라우드서비스에서 직접 dba가 튜닝해주는거가 아니면 가상화를 통한 서버추가를 서비스하니 똑같은거 같고
wired tiger도 shard에서 동일하게 적용되는 기술이니 본인이 관리하시려고 하면 클라우드 안쓰고도 가능하셧던거죠?
연구직이다보니 백엔드 같은데 오히려 집중하는 입장이어서 프론트엔드 중심으로 가게되는게 아쉽긴 하네요..
결국 백엔드를 소수의 회사가 독점하게되서 언젠가 독점적인 시장에서 갑질하게되면 따를수밖에 없는거 아닌가...싶습니다.
아마 DBA 롤모델은 아래 링크 같은 방향이 되지 않을까해요..
https://news.naver.com/main/read.nhn?mode=LSD&mid=sec&sid1=001&oid=092&aid=0002123148&viewType=pc
몽고디비는 클라우드 안쓰고 샤딩해서 4대까지(300G*4) 잘 운영했는데 위기 대처가 어려웠습니다.
양이 많아지면 뭐하나 건들면 2,3주 걸리는데 이게 될거란 보장도 없어요.. 물어볼 때도 없고 외로웠습니다.
우울하지만.. 디비시장은 조만간 공룡들이 다 먹을 것 같아요.
지금은 저렴하게 편하게 내놓고 끌어들여서 생태계장악하면 이거 쉽게 못바꾸거든요..
아무리 더 좋은게 나오고 어쩌고 해도 쓰던 거 바꾸는 거 어렵거든요.
저 또한 최근 디비, 백엔드는 거의 신경도 안씁니다.
그냥 화면 구현(front: vue.js)하는데만 초점을 맞추죠..
저도 dba 없이 db를 만지려니 정말 머리가 터질 것 같습니다. noSQL와 RDBMS를 선택하는 기준은 어떻게 되는 것일까요? 그냥 때려박는거에는 noSQL이 편하긴 할텐데. 이 둘을 선택할 때 어떤 기준이 있으면 좋을까요?
요약정보는 RDBMS 로데이터는 noSQL
하지만 제 경험으로는 솔직히 noSQL 하나로도 충분했습니다. 물론 용도에 따라 다르겠지만...
RDBMS 있으면 당연히 설계가 편할 테지만 관리 측면에서 적은 인원이 2 디비를 고민하는게 복잡하기도 하고요..
써보면 압니다. atlas 나 mongolab 이었나? 무료 서버 몇개 있는데 좀 느리지만.. 함 어떤가 쓰고 읽고 해보세요..
현재 프로젝트에서 써먹을 만한 건지..
사람 홧병나게 하더군요.
그래서 node.js랑 궁합이 잘 맞는 이유가. mongoose라는 odm을 이용하면 정말 쉽게 CRUD 되요..
몽구스로 읽고 쓰기 간단 예: https://fkkmemi.github.io/nembv/nembv-08-back-end-mongoose-model/
sqlite as application format 이라는 문서를 보면, open office 의 파일포맷을 sqlite 로 구현한다면 이렇게 구현한다는 것을 보여주는데, 현재의 워드나 오픈 오피스가 문서를 전체 압축후, 다시 전체 압축풀기 방식으로 하는 것보다 훨씬 좋은 것 같습니다
최근 플젝에 함 이용해봐야겠네요!
첫줄만 읽고 전산쪽과 상관없는 분이라 해서 현업이 DB공부를 한 글인줄 알았는데
(그리고 개발 하시는 분이시네요)
DB가 필요한 비전산 현업의 고민 보다는 오히려 클라우드를 고민하는 전산들의 고민에 공감되는 글 같습니다.
아무튼 각설하고, 저는 텍스트로 로깅을 하거나 Redshift같은 data warehouse에 데이터를 쌓아서 보는게 좋은 방법이라고 생각합니다. 이미 AWS를 쓰고 계시다니 좀 더 설명을 드리자면, 로깅 데이터 수집은 스트림 서비스인 Kinesis Stream으로 수집을 하고, Kinesis Firehose로 스트림에 쌓인 레코드들을 S3로 내보냅니다. Kinesis Stream은 어느정도 어느정도 data retention이 보장되기 때문에, consumer에서 장애가 터져도 데이터를 잃지 않을수 있습니다. Kinesis Firehose는 알아서 스트림에 들어온 데이터를 알아서 시간별로 s3로 정리해서 쌓아주기 때문에, 따로 로깅 데이터를 합치고 쪼갤 필요도 없습니다.
S3에 쌓인 텍스트 데이터들은, Athena로 편하게 SQL로 조회하시면 됩니다. 1TB 스캔당 $0.5이고, parquet이나 gzip으로 압축된 파일을 읽는것도 지원하기 때문에, 텍스트가 gzip으로 압축되어 있으면 scan 비용이 내려가서 추가적인 비용 절감도 가능합니다.
관심이 있으시다면 작년에 했던 re:invent 2017에서 진행한 data lake 세션들을 참고해보세요 ^^
다이나모에 대한 얘기는 너무 길어서 위에 언급안했는데 말씀대로 4K제한이 제일 컸습니다.
진짜 모르고 쓰면 장난 아닌 AWS 과금입니다. 잘 알고 써야합니다.
글에 작성된 로깅등은 개발 초기때하던 것이고 현재는 다른 정보를 저장중입니다.
그래도 시스템로깅등에서 쓸만한 고급정보 감사드립니다.
참고로 말씀해주신 Athena의 Concurrent Query Limit의 경우 support에 티켓 남기면 늘려주고, Query timeout은 30분이라 파티셔닝만 잘 해도 대부분 겪지 않을거에요. 저는 개인적으로 서비스 API에서 Athena에 직접 액세스하는 것 보다는 큐에 쌓아서 처리하고, 따로 RDB로 처리된 데이터만 읽게하는게 가장 이상적이라고 생각합니다 :)
일반적인 의미는 트래픽이나 부하가 커질때 서버가 자동으로 늘어나서 부하 처리하는 느낌입니다.
프론트나 백엔드 개발자는사용자가 늘어나던 말던 개발생산성에만 집중할 수 있죠.
RDB 계열의 경우 어제 Aurora Serverless가 GA로 출시되었는데, DynamoDB와 비슷하게 auto scaling이 가능합니다.
디비 솔루션은 저대로 두고 수신서버나 웹서버를 AWS로 이전 기획중입니다.
지금 거의 반자동으로 서버들를 늘리고 있는데 완전 자동화를 위해 학습중입니다.
좋은 의견 감사드립니다.
DBA현업분들도 클라우드 컴퓨팅 때문에 변화는 필요하실 듯합니다.
IT공룡들의 파워가 날로 증가하는 것 같아요.
최종 목표를 고객의 관점에서 바라 보면.. 개발은 늘 바뀔 수 있다고 생각합니다.
그래서 선구현후개선(아름다운 화면이 먼저, 문법등은 만들며 수정하고 공부함)의 개발 과정을 지향합니다.
디비, 백엔드, 프론트엔드 자체가 중요한 것이 아닌 무언가를 만드는 데 초점을 두는 것이 좋다고 봅니다.
현재 node.js, mongoDB를 꽤 오래 다루었지만. 타솔루션의 장점이 확실하다면 언제 갈아탈 지 모릅니다.
당장도 vue를 하고는 있지만 점유율 괴수인 react는 계속 검토중입니다.
트렌드의 고저는 뭔가 이유가 있기 때문이겠죠
무엇을 만드는 것에 초점을 두세요. 개발은 거들 뿐.
결국 고생끝에 클라우드사용이 답이라는 ㅠㅠ
3년치 데이터가 쌓여있는데 점점 비어있는 용량이 없어져서
명절때 이관작업 한번 했다가 일주일 걸렸던 기억이나네요.
물론 어떻게 될지 몰라 백업하느라 늦었지만요
가장 큰문제는 Info table이 구조체가 C#의 SortedDictionary 하위 트리 몇번 타게 만들어져있어서
참 애먹었던 기억이 납니다.
join, group등 sql에 익숙한 사람은 진입장벽이 어려운게 흠이지만
Data관리하기는 편하더군요.
디비는 데이터 그 자체가 되어야된다는 생각을 합니다.
join group은 여전히 그립습니다....
정규화, 인덱싱 매우 중요하지만 이를 바탕으로한
데이터베이스를 활용할 업무에 대한 빠삭한 이해가 가장 중요한것 같습니다.
데이터베이스 설계 기말 프로젝트를 진행했는데 교수님이 업무파악을 정말 중요하게 코치해주셨던
기억이 납니다.
다량의 데이터일지, 적은 데이터일지, 그룹핑이 필요한 데이터일지..
우선 스키마를 대충 만들어 놓고 (주로 나오는 학생, 선생, 학교) 직접 써보고 찾아보면.
어떤 장단점이 있는 지 드러나게 됩니다.
근데 이렇게 맨땅에서 배워도 잘 잊혀지드라고요.. 메모리 용량이 안 받쳐주는 듯 ㅜ
오래 했던 C/C++ 는 아직도 본능적으로 클래스나 키워드가 안보고도 타이핑 되는 거 보면 진득하게 했던 것만 각인되나봐요.
그래서 어짜피 다 까먹었으니 늘 새로운 시작을 하지만..
경험들을 토대로 딱 필요한 것만 하나씩 늘려가면 되는 것 같아요..
이를 통한 기술을 내재화 하신 것도 대단하고요^^
무식한 게 가끔 좋다는 생각도 듭니다.
서론 이론 다 무시하고 일단 '쓴다 읽는다' 만 가지고 시작한 것들이니까요.
만약 공부로 디비를 시작했다면 잘 다루지 못했을 것 같아요.. 어떤 이론에 막혀서..
일단 굴려보고 문제점을 찾는 것이 더 쉬운 것 같아요..
프로젝트 할때마다 고객사가 그 디비 안쓰고 이거 쓰면 안되나? 할때마다 뜨끔뜨끔 합니다..
저흰 DBA 없는 소기업인데........ 진짜 맨땅에 헤딩 많이 했습니다.... ㅠㅠ
저희도 raw 가 많아서, nosql 이나 뭐나 관심있게 보고 있는데 (RDBMS는 정말 이럴때 한계가 많아요)
여튼 요즘 버티카가 좋다는데, 궁금하긴 해요.. 유료라....
아카이브 용이고 실제 구동에 쓰진 않는데요.
테스트겸 날짜, 식별번호 오직 2키워드로 조회하면 0.12초 나옵니다.
씨피유는 꿀렁 한번하네요.
그리고 아틀라스가 좋은게 느리게 만드는 쿼리라고 바로 알려 줍니다.
인덱스 어떤 필드에 걸면 빠를텐데 지금 거시겠어요? 그러면 백그라운드에서 인덱스 걸립니다.
로데이터 저장용으로는 정말 괜찮다고 생각합니다.
제가 운영중인 서비스는 noSQL 온리가 가능합니다.
분명 안되는 서비스가 더 많을 거란 생각은 합니다.
순위는 1. oracle 2. mysql 3. mssql 4. PostgreSQL 5. mongoDB 인데
https://pypl.github.io/DB.html
점유율이 1.2.3위 점유율이 벌써 70%가 4,5위는 4%정도죠 ㅜ
목적성도 중요하지만 아직 보편적이지 않은 이유가 커보입니다.
혹시 Atlas를 쓰면 글로벌 서비스에 유리한가요?
한국리전에 Atlas를 운영하고 독일리전에 EC2로 서버를 돌려서 서로 연계하면 퍼포먼스가 어떠할까요?