<서론>

프로시저에 비즈니스 로직이 녹아있는 프로젝트를 하다보니 여러 프로시저 안에서 다른 프로시저를 부르는 경우를 많이 봤다. 그런데 간혹 프로시저 말고, 사용자 정의 함수를 호출하는 경우도 보였는데, 갑자기 사용자 정의 함수는 왜 쓰는 건지 궁금해졌다. 계속 프로시저만 써도 될 것 같은데 어째서 사용자 정의 함수를 쓰는 걸까? 

 


 

<본론>

프로시저와 사용자 정의 함수 모두 호출하게 되면 미리 정의 해놓은 기능을 수행하는 프로그램들이다. 인터넷에서 쉽게 찾을 수 있는 이 둘의 차이점이라면 아마 리턴 값인 것 같다.

프로시저는 리턴값이 없어도 되지만, 사용자 정의 함수는 꼭 있어야 한다.
또한 프로시저는 리턴값이 하나가 아닌 여러 개로 나와도 되지만, 함수는 오직 하나의 값만 있어야 한다.

인터넷에서 찾은 답은 이해하기는 쉬웠지만 와닿지는 않았다. 왜냐, 정말 차이가 저것뿐이라면 굳이 사용자 정의 함수를 쓸 필요가 없기때문이다. 프로시저로 사용자 정의 함수가 할 수 있는 일을 다 할 수 있는데, 굳이 둘을 섞어가며 쓸 이유는 없을 것이다. 그래서 좀더 인터넷을 찾아 봤다. 찾은 답은 다음과 같다.

 

프로시저 사용자 정의 함수
업무를 맡기는 목적 로직을 도와주는 목적
SP 안에 트랜잭션을 사용할 수 있음 사용자 정의 함수 안에 트랜잭션을 사용할 수 없음
파라미터 형식이 입,출력임 입력 파라미터만 가능
프로시저 안에서 다른 프로시저를 호출할 수 있음 사용자 정의 함수 안에서 프로시저를 호출할 수는 없음
SELECT, WHERE, HAVING 절에 프로시저를 사용할 수 없음 SELECT, WHERE, HAVING 절에 사용자 정의 함수를 사용할 수 있음
try-catch 블럭을 사용할 수 있음 try-catch 블럭을 사용할 수 없음

 

위 표와 같이 정리할 수 있는데, 특별히 굵게 처리된 부분이 사용자 정의 함수를 쓰는 이유의 핵심인 것 같다. 사실 표만 보면 프로시저는 되는데, 사용자 정의 함수는 안되는 것들이 무척이나 많다. 하지만 그 중 유일하게 가능한 것이 SELECT 쿼리 안에서는 사용자 정의 함수만 사용 가능하다는 점인 것 같다.

 


 

<결론>

배움이 부족하여 위와 같이 밖에 알아내지 못했다. 영어 실력이 좋았다면 영어로 된 문서들도 참고하면서 공부했을테지만, 한글도 제대로 못읽는 관계로 이정도로 마무리 지으려 한다.

 

<참고자료>

자료 출처를 적어놓지 못했다.. 원작자분들 죄송합니다.

'IT 공부 > 이론 공부' 카테고리의 다른 글

[DB]RAC, HA가 뭐지?  (3) 2019.03.20
[기본] SP(Stored Procedure - 저장 프로시저)  (1) 2019.03.04

<서론>

프로젝트를 진행하면서 RAC와 HA라는 말을 듣게 되었다. 개발 지식 및 상식은 없다시피한 초보 코더라서 그 자리에서는 못알아들었지만 그저 웃으며 고개를 끄덕였다. DB 관련 용어라 앞으로도 많이 마주할 것 같아 이렇게 따로 정리해보려고 한다. 블로그에 있는 나의 대부분의 글들이 그러하듯 이 글 역시도 인터넷에 돌아다니는 내용을 내 입맛대로 짜깁기 한 것이라 매우매우 부정확한 내용임을 미리 경고해둔다.




<본론>


HA와 RAC 모두 DB 서버의 구성에 관한 것이고, 고가용성을 위해 만들어진 구성이라는 것


처음 RAC와 HA를 들었을 때, 완전히 다른 두 개념인 줄 알았다. 하지만 조금 찾아보니, HA 구성이 먼저 나왔고 HA에서 몇가지를 보완한 것이 RAC라는 것을 알았다(아, 물론 RAC 이전에 OPS라는 것도 있었지만 그건 넘어가도록 하자).


우선 HA.

HA(High Availability)는 2개의 서버를 이용하여 하나는 Active 상태, 나머지 하나는 Standby 상태로 정해놓는다. 거의 모든 부하는 Active에서 부담하고 Standby 상태의 서버는 Active 서버가 장애가 발생하지 않는 이상, 거의 가동하지 않는다. 실제 서비스를 운영하는 Active 서버가 어떠한 장애로 정상적인 작동이 불가능해진다면, 곧바로 Standby 서버가 Active 되면서 다시 서비스를 정상 작동할 수 있게 하는 구성이다.

이해하기 쉬운만큼 구조도 단순하고 따라서 구축 비용도 저렴하다. 또한, 서버 하나만 가동되면 되므로 유지비 역시 저렴하다는 장점이 있다.

하지만, 몇가지 문제점이 있다. 각 서버 별로 별도의 storage를 가지고 있기 때문에 수시로 동기화가 이루어져야 하고, 따라서 성능 저하를 야기할 수 있다. 또한 이런 특성 때문에 각 서버간 데이터 싱크가 맞지 않는 상황도 존재할 수 있다. 마지막으로 굉장히 큰 문제인데, Active 서버가 동작을 멈추면 Standby 서버가 활성화 될 때까지의 트랜잭션을 모두 유실하게 된다는 것이다. 이는 실시간 트랜잭션량이 많은 서비스에서는 치명적인 문제이다.


그렇다면 HA에서 더 보완을 한 RAC는 어떨까?

RAC(Real Application Cluster)는 2개, 혹은 그 이상의 인스턴스가 하나의 storage를 바라보고 있는 구성이다. 각각의 인스턴스를 서버라고 생각하고 HA와 비교한다면 Active, Standby가 아닌 모두 Active 상태라고 할 수 있다. 그리고 모두 하나의 storage를 바라보는 상황이므로 별도의 동기화로 인한 성능 저하는 없다. 또, 하나의 인스턴스에서 장애가 발생해도 곧바로 다음 인스턴스에서 처리해줄 수 있으므로 데이터 유실에 대한 우려도 없다. HA에서는 하나의 서버가 모든 처리를 해야했으므로 상대적으로 큰 부하가 발생하지만, RAC 구성에서는 균형있게 분산되어 처리할 수 있다.

하지만, 이 역시도 단점이 존재한다. 우선 Oracle RAC가 매우 고가의 제품이라는 것이다. 또한 매우 복잡한 환경 구성으로 인해 유지보수 절차 역시도 복잡하며, 운영 인력은 RAC에 대한 충분한 이해도 필수이다. HA구조보다 빠른 복구 시간을 보장하지만, 실제로는 RAC 구조를 다루는데 미숙해서 복구시간을 연장시킬 가능성도 있다.




<결론>


HA : Acitve-Standby 구조. 비용이 적게 들고 간단하지만, 데이터 동기화 문제와 장애 발생 시, 정보 유실 우려

RAC : 여러 인스턴스가 하나의 Storage를 바라보는 구조. HA에 비해 성능과 안정성 모두 뛰어나지만, 비용이 많이 들고 다루기 어려움


장황하게 적어놨지만 결론은 이렇다!

사실 표를 그리거나 이해하기 좋은 그림을 넣고 싶었지만, 이런 막글을 누가 본다고 정성을 쏟을까.. 나중에 내가 다시 볼때 알아보기 쉽게 볼드 처리만 해놔야겠다.



<참조>

1. https://sksstar.tistory.com/63

2. http://blog.naver.com/PostView.nhn?blogId=dark009&logNo=150171352412

3. http://www.dator.co.kr/dataworld/textyle/42729

4. https://codelib.tistory.com/23


그리고 이건 그냥 참고하면 좋을 것

https://irkim.tistory.com/entry/HA%EC%99%80-RAC%EC%99%80%EC%9D%98-%EB%B9%84%EA%B5%90

1. 변수 사용

구글링 결과 제일 많이 나온 방법.. 잠깐 쓰고 버릴 변수를 만들고 그 변수로 ROW_NUMBER() 뒤에 오는 OVER() 조건에 넣어줬다.


1
2
3
4
DECLARE @RN INT = 1;
SELECT ROW_NUMBER() OVER(ORDER BY @RN) AS ROWS
       , *
  FROM [TABLE_NAME];

이것이 그 쿼리...

DECLARE 부터 통째로 MyBatis 쿼리 xml 파일에 넣었다.

그랬더니 깔끔하게 동작!


2. 서브 쿼리 사용

OVER()의 조건에 상수가 들어가지 않는다는 것이 문제였는데.. 생각하다보니 서브쿼리를 넣으면 어떻게 될까 궁금했다.


1
2
3
SELECT ROW_NUMBER() OVER(ORDER BY (SELECT 1)) AS ROWS
       , *
  FROM [TABLE_NAME];


결과는 성공. 결국 상수 직접은 아니면서 1이기만 하면 다 되는 것 같다.




깨알팁.. 잊어버리지 않기 위해 블로그에 정리해서 올린다. 다음에도 MSSQL 쓸일이 있겠지.....


<서론>

최근 진행한 프로젝트는 쿼리대신 SP(Stored Procedure)를 이용했고, xml 파일에 별도에 쿼리를 작성하지 않았다.

내 개발 경력이 없다시피 한 수준이고 따라서 SP를 사용한 프로젝트가 처음이라, SP를 사용하면 어떤 장점과 단점이 있는지 이번 기회에 공부 겸 정리하고자 이렇게 블로그에 끄적여본다.



<본론>

1. SP란?

- SQL 명령문들을 마치 하나의 함수처럼 사용하기 위해 DB 내부에 저장된 쿼리의 집합이다.


2. SP의 장점

- 성능 측면

1. SP는 최초 컴파일 시 최적화되며 이후 DB에 캐싱되어 저장된다.

 최초 컴파일 이후엔 다시 컴파일 하거나 최적화 되지 않는다. 즉 자주 사용하는 쿼리일수록 SP로 처리하는 것이 큰 성능 향상을 야기할 수 있다.

2. 네트워크 트래픽을 감소시킬 수 있다.

 SP가 서버에 저장되기 때문에 쿼리가 필요할 때마다 쿼리를 전달해주지 않아도 되며, 필요한 매개변수만 던져주면 되기때문에 트래픽을 줄일 수 있다.

- 개발 측면

1. 개발 언어에 비의존적이다.

비즈니스 로직을 SP로 구현해 놓았다면 개발 언어가 바뀌더라도, 해당 DB에 SP를 호출할 수만 있으면 된다.

2. 유지 보수가 매우 편리해진다.(개발자 == 유지보수)

프로그램을 개발한 사람이 유지보수까지 하게 된다면 DB관련 작업을 할 때, SP만 수정해주면 된다. 비즈니스 로직도 SP로 구현했다면 WAS를 재기동할 필요 없이 SP만 수정하면 된다.


3. SP의 단점

- 개발 측면

1. 유지보수가 어렵다.(개발자 != 유지보수)

앞서 유지보수에 강점이 있다 서술했지만, 유지보수를 하는 사람과 개발한 사람이 다르다면 유지보수는 어려워질 것이다. 데이터 분석이 까다롭고 하나의 프로시저를 여러 곳에서 사용했을 경우 영향도 분석이 어렵다.

2. DB 확장이 매우 힘들다.

서비스 사용자가 많아져 서버의 수를 늘려야할 때, DB의 수를 늘리는 것이 더 어렵다. 또한,  DB 교체는 거의 불가능해진다.



<결론>

SP에 대해 알면 알수록 얻는 것에 비해 잃는 것이 많은 것 같았다. 위 단점에 서술하진 않았지만, DB 자원이 상대적으로 더 비싼데, SP로 비즈니스 로직을 처리하면 당연히 개발 단가가 올라갈 수 밖에 없을 것이다. 또한 서비스 확장을 위해 서버의 수를 늘릴 경우, DB의 수를 늘리는 것보다 WAS의 수를 늘리는 것이 더 효율적이기에 최근 대부분의 개발에서 DB에는 최소의 부담만 주고 대부분의 로직은 WAS에서 처리할 수 있게 한다고 한다.

블로그 글을 쓰기 위해 공부하면서 SP를 사용하는 프로젝트를 앞으로 또 만날 수 있을까 생각이 들었지만, 그냥 이런 게 있구나 하는 심정으로 글을 정리한다.


ps. 틀린 부분은 지적해주세요.


<참초>

https://itability.tistory.com/51

https://okky.kr/article/396251

'IT 공부 > 이론 공부' 카테고리의 다른 글

[DB]프로시저 vs 사용자 정의 함수  (2) 2019.04.11
[DB]RAC, HA가 뭐지?  (3) 2019.03.20

파이썬의 장점

  1. Guido가 생각했던 Python 문법적 특징은 들여쓰기를 철저하게 지키도록 언어를 설계
  2. 가독성이 좋음
  3. ... 놓침
  4. 파이썬 코드는 재사용하기 쉬움
  5. 코드의 분석이 쉽기 때문에 다른 사람이 작성한 코드를 받아서 작업하는 사람들이 훨씬더 작업이 편리
  6. 생태계가 좋음


파이썬의 구현

  1. C파이썬 : C로 작성된 인터프리터를 사용하는 일반적인 파이썬. ipython이라고도 함
  2. 스택리스 파이썬 : C 스택을 사용하지 않는 인터프리터
  3. 자이썬 : 자바 가상 머신용 인터프리터
  4. IronPython : .NET용
  5. PyPy : 


사용가능한 플랫폼

  1. 윈도
  2. 매킨토시
  3. 각종 유닉스
  4. 리눅스
  5. 팜 OS
  6. 노키아 시리즈 60


파이썬의 활용분야

  1. GUI Programming : 기본 모듈인 Tkinter 이용
  2. Web Programming : django framework
  3. Game Programming : PyOpenGL
  4. Database Programming(빅데이터 연관)
  5. Text 처리
  6. 수치 연산(Numeric Python, networkx)
  7. 병렬 연산
  8. IoT : 라즈베리 파이
  9. C, C++, Java와 결합한 Programming
  10. data 분석 분야 : NumPy, Pandas, Scipy
  11. 시각화 : Matplotlib


'IT 공부 > 과거의 흔적들' 카테고리의 다른 글

[spring] 파일 업로드  (0) 2017.06.22
[Spring] 스프링 시작  (0) 2017.06.14
답변형 게시판 - 2  (0) 2017.06.14
[Cent OS]리눅스  (0) 2017.06.14
답변형 게시판  (0) 2017.06.13

첨부파일 등록

  • 사용처리 프로세스
    • 게시판 등록 화면에서 여러 첨부파일 등록
  • 프로그램 처리 프로세스
    • DB 설계
      첨부파일 table / key / 게시판 no(참조키) / 파일명 / 기타 / 등록일
  • 게시판 등록 화면 처리
    • <form enctype="multipart/form-data">
          <input type="text" name="name" />
          <input type="file" name="report" />



Spring 첨부 파일 필요 부분

  • 파일을 업로드/다운로드 하는 viewResolve setting이 필요
    • dispatcher-servlet.xml에 파일 업로드/다운로드 모듈 설정
      • 파일 업로드 모듈
            <bean id="" class="org.springframework.web.multipart.commons.CommonMultipartResolver" />
      • 파일 다운로드 모듈
            사용자 정의로 클래스 선언
            ex) <bean id="" class="springweb.z01_util.A03.DownloadViewResolver" />
  • json이나 파일 처리 시 필요로 하는 viewResolver 선언
<bean id="bnViewResolver" class="org.springframework.web.servlet.BeanNameViewResolver" >
<property name="order" value="0" />    // 최우선 사항



첨부파일 처리 시 Ctrl / Server

  • Controller에서 Param
    • view단
          <input name="id" />
          <input type="file" name="report" />
    • controller
          list(@RequestParam("id") String id){}
          list(@RequestParam("report" MultipartFile report){}
  • MultipartFile를 물리적 저장, DB 저장
    • getOriginalFilename() : 업로드 파일명
    • transferTo("저장할 경로 파일 객체")
    • FileInputStream, FileOutStream을 통해서 전달받은 파일을 서버에 특정한 위치로 저장
    • DB에 getOriginalFilename() 로 DB insert


'IT 공부 > 과거의 흔적들' 카테고리의 다른 글

[Python] 파이썬 시작!  (0) 2017.07.18
[Spring] 스프링 시작  (0) 2017.06.14
답변형 게시판 - 2  (0) 2017.06.14
[Cent OS]리눅스  (0) 2017.06.14
답변형 게시판  (0) 2017.06.13

Spring Framework

: 복잡한 엔터프라이즈 애플리케이션 개발을 겨냥. 단순성, 테스트 용이성, 느슨한 결합성의 측면이 스프링의 이점




Spring MVC


그림



Spring Module

  • Core
    • framework에서 가장 기본적인 부분. 의존성 삽입(Dependency Injection) 기능을 제공
  • DAO
    • JDBC 코딩과 Database 업체 별 특정 처리할 필요 없는 JDBC 추상화 레이어 제공
  • ORM
    • 객체 관계 mapping API를 위한 통합 레이어 제공. " Mybatis " 활용하여 DB를 효율적으로 처리
  • Web
    • 화면 view뿐만 아니라 웹에서 파일 업로드 / 다운로드
  • MVC
    • 웹 application의 모델2 패턴을 스프링에서 지원


Spring 개발환경처리

개발환경 구성 방식
framework 구조


'IT 공부 > 과거의 흔적들' 카테고리의 다른 글

[Python] 파이썬 시작!  (0) 2017.07.18
[spring] 파일 업로드  (0) 2017.06.22
답변형 게시판 - 2  (0) 2017.06.14
[Cent OS]리눅스  (0) 2017.06.14
답변형 게시판  (0) 2017.06.13

게시물 등록

  • 프로세스
    • 메인화면에서 등록 버튼 클릭
    • 등록 화면
          제목, 내용, 패스워드, 작성자, 이메일
          등록 처리
    • 메인 화면에서 등록된 list 확인
  • 개발 순서
    • DB SQL 작성
    • DTO 구성 내지 선택
    • DAO(Repository)
    • 화면 구성 : DTO 연결되는 name 부분
    • Controller 연결 처리 / Service, DAO


초기 화면 구성

  • main에서 연결하는 등록화면. Controller로 등록할 수 있도록
    • akfj;sdfj;


답글 처리 프로세스

  • 메인화면
    • 해당 글을 더블 클릭 시, 상세화면으로 이동
  • 상세화면
    • 답글 달기, 수정처리, 삭제
    • 답글 메뉴 버튼 클릭 시 출력
  • 답글 화면
    • RE: 메인 글제목
    • 내용 : ---------- 기존 글 내용 -----------
    • 답글 등록 버튼 클릭, 답글 등록처리. 메인화면에 처리


답글 처리 프로그램

  • 메인화면
    • jquery 해당 글을 더블 클릭 시, 상세화면 이동
  • 상세화면
    • Controller - view(jsp) : 화면 구성
    • 모델 데이터 - 단일 data 로딩
      • DAO, mybatis.xml, Service 연결, Controller에 모델처리, 화면단에서 호출
    • 답글 메뉴 버튼 클릭 시 처리해야할 화면, DB
      • submit로 key값 no 전달
      • DB : 단일 data 로딩(Service) : 제목에 [RE:] 첨부 / 내용에 -------------------- 첨부
      • 답글 화면 구현
  • 답글 화면
    • 답글화면 로딩
    • 답글처리 등록
      • refno : 원본 글의 no를 입력처리

  • 메인화면
      • 계층형 sql
        • select * from board
          where ...
          start with refno = 0
          connect by prior no = refno
      • 화면단
        • 해당 답글의 level(단계) 표시


'IT 공부 > 과거의 흔적들' 카테고리의 다른 글

[spring] 파일 업로드  (0) 2017.06.22
[Spring] 스프링 시작  (0) 2017.06.14
[Cent OS]리눅스  (0) 2017.06.14
답변형 게시판  (0) 2017.06.13
[mybatis] 동적 SQL 처리  (0) 2017.06.13

리눅스 기본 명령어

rm : remove 파일이나 디렉토리를 삭제할 때 쓰는 명령어.

권한 설정이 필요. root 사용자는 모든 권한이 있으므로 삭제 가능

기본형식

rm [옵션] 파일명, rm [옵션] 디렉토리명

옵션

-i : 삭제할 지 확인 메세지 출력 (default)

ex) rm -i abc.txt

-f : 삭제 시 확인하지 않고 바로 삭제(force)

-r : 해당 디렉토리를 삭제할 때 활용

-rf : 디렉토리에 파일이 있을 때, 디렉토리 / 파일 삭제


mv : move 파일이나 디렉토리의 이름을 변경하거나 다른 디렉토리로 이동

기본형식

mv 원본파일명/디렉토리

ex) mv abc.txt /etc/sysconfig

mv 원본파일명 변경할파일명

ex) mv abc.txt ccc.txt

mv 이동할파일1 이동할파일2 ... 디렉토리    (파일은 여러 개 가능)

ex) mv abc.txt def.txt /etc/sysconfig


mkdir : make directory 디렉토리를 만든다


rmdir : remove directory 디렉토리를 지움


cat : concatenate


head, tail : 시작과 끝라인. 파일의 앞 뒤 10행을 화면에 출력할 때 활용

형식 : head -라인수 파일명

ex) head abc.txt            abc.txt 파일의 앞 10줄 출력

head -5 abc.txt        abc.txt 파일의 앞 5줄 출력

tail -5 abc.txt          abc.txt 파일의 뒤 5줄 출력


more : space, B 텍스트 형식으로 적성된 파일을 페이지 단위로 화면에 출력할 때 활용

space : 다음 페이지 이동, B : 앞 페이지 이동, Q : 종료

ex) more aaa.txt

more + 시작할 행번호 aaa.txt    : 해당 행 번호부터 출력



less : 텍스트 형식으로 작성된 파일을 페이지 단위로 화면에 출력할 때 사용

more 활용되는 key + PgUp, PgDn


file : 해당 파일의 종류 표시

dlkfsjldkfs

'IT 공부 > 과거의 흔적들' 카테고리의 다른 글

[spring] 파일 업로드  (0) 2017.06.22
[Spring] 스프링 시작  (0) 2017.06.14
답변형 게시판 - 2  (0) 2017.06.14
답변형 게시판  (0) 2017.06.13
[mybatis] 동적 SQL 처리  (0) 2017.06.13

Database 설계

결과화면 (화면 UI)

답변형 list로 paging 처리된 게시판

조회 : 글제목, 글내용, 작성자

버튼 : 조회, 등록, exceldown

한라인의 글을 클릭 시, 상세화면이 나타나고 답글 수정 삭제 다운로드

pageSize : 한 페이지 몇 개의 data를 list할 것인가

pageBlock : 여러 페이지를 번호를 붙여서 나타낼 때 쓰이는 block, blockSize

결과화면에 따른 내용처리



처리 프로세스

초기화면

조회화면

등록 버튼

상세

paging처리 - page block에 해당하는 page 번호를 클릭, 이동

등록화면



주요 기능

초기 글 리스트 화면

답변형 계층구조

등록화면

첨부파일

상세화면

수정, 삭제



구현 순서

화면 ui 결정 및 프로세스 결정

초기화면(html, css)

DB 설계

ERD, table 생성

각 화면단에 활용할 SQL 구현

계층형 SQL 구현(답변 처리)

위 SQL에 mapping되는 VO, DTO 클래스 구현



초기 화면 구성

ctrl
공통 RequestMapping를 클래스명 위에 선언
각 기능별 mtd.에 params = "method=list"
view
검색항목
제목, 작성자, 내용
list 항목
번호, 제목, 작성자, 작성일


DB 설계

관리할 data List
list table : num(key), 제목, 내용, 패스워드, 작성자, 읽은 수, 등록일, e mail
첨부파일 table : num(key), 파일명, 생성일
sequence : board_seq


'IT 공부 > 과거의 흔적들' 카테고리의 다른 글

[spring] 파일 업로드  (0) 2017.06.22
[Spring] 스프링 시작  (0) 2017.06.14
답변형 게시판 - 2  (0) 2017.06.14
[Cent OS]리눅스  (0) 2017.06.14
[mybatis] 동적 SQL 처리  (0) 2017.06.13

+ Recent posts