DB구조가 어떻게 생기고 또한 작동이되는지? 관심이 없었으며 몰라도 된다란 생각을 그동안 하였습니다.
하지만 최근 최고 선배개발자님의 오라클 아키텍 사내 교육을 들으면서 생각이 바뀌었습니다.
오라클(DB)에서 이미 고민했던 문제가 알게모르게 어떠한 개발컨셉에서 활용되고 있으며
우리의 어플리케이션 설계에 있어서도 도움이된다란것입니다.
물론 성능좋고 유연한 SQL문을 작성할수 있는것은 보너스입니다.
오라클의 주요 아키텍쳐
오라클 아키텍쳐를 설명할 내공이 없어서 원본사진을 그대로 담았으며
오라클에서 사용되는 고유 단어에 대한 설명은 하지 않고 언급만 하겠습니다.(역시 내공부족)
여기서 정리한 오라클-어플리케이션 연관성은 개인적인 기준에의해 연결한것으로 연관성이 없을수도 있음을 인지 하십시오
어플리케이션 설계에 있어서 공통해결과제
Dispatcher
대량의 클라이언트 요청을 어떻게 합리적으로 처리를 하느냐에 대한 고민이며
어플리케이션에 있어서도,대량의 요청을 처리하기 위해
스레드를 옵션화하고 최적화할수 있는 Dispatcher 개념에대해 고민해야합니다.
관련 개인 학습 자료 :Dispatcher
데이터 무결성
데이터 무결성을 지키기 위해, 오라클은 많은 노력을 합니다.
그러면 어플리케이션 개발자는? 데이터가 저장되기전 메시지 전송 보장을 해야합니다.
데이터가 무결해도, 거짓된 메시지처리( 값이 중간에 바뀌거나? 드랍되었는데 성공처리를 한다거나?)에 의해
DB의 노력이 물거품이 될수 있기때문입니다.
데이터가 전송은 100% 이루어진다. '예스' 라고 한다면 언랭에서는 그것은 거짓화된 추상화처리라고 정의하고 있습니다.
메시지 전송보장 : http://erlang.org/faq/academic.html#idp32880720 ( 10.9절 참고 : 언랭에서 크게 성공을 거둔 컨셉 )
관련 개인 학습 자료 : MessageDeliveryReliability
장애대응
오라클 관련 키워드 : LGWR
오라클은 장애에 대응하기위해 DB의 부분 스냅샷을 유지하려고 합니다.
어플리케이션 개발자는? 대부부분의 DB이외의 처리를 메모리에서 하고 있으며
이것이 휘발될때에 대해 대응을 하지못하여 완전한 복구가 안된다란 것입니다.
필요하면 , 메모리에 복구와 관련된 스냅샷처리에대해 고민을 해야합니다.
관련 개인 학습 자료 : 03. Persistence
모니터링
오라클 관련 키워드 : PMON , SMON
서비스를 원활하게 유지를하고 대응하기위해서는 오라클에서는 자체 모니터링
데몬이 존재합니다.
어플리케이션에 있어서도 동일한 목적으로
자체 진단기능에대해 고민을 해야합니다.
학습중인 관련 컨셉
http://getakka.net/articles/concepts/supervision.html