라벨이 어플리케이션 개발인 게시물 표시

(어플리케이션 개발) 이미지서버를 분산시키는 것.

이미지
*이미지 호스팅 시스템에서는 고려해야 할 다른 측면이 있다. 저장될 이미지의 개수에 제한이 없다. 따라서 저장공간의 확장성에 대해서도 고려해야 한다. 이미지 보기나 다운로드를 요청할 때 응답시간이 빨라야 한다. 사용자가 이미지를 업로드하고 난 후, 해당 이미지는 항상 시스템에 저장되어 있어야 한다. (데이터에 대한 신뢰성) 시스템을 운용하기 쉬워야 한다.(관리성) 이미지 호스팅 서비스 자체의 이익율이 높지 않기 때문에, 시스템은 비용 효율적으로 운용될 필요가 있다. 다음은 이미지 호스팅 애플리케이션의 기능을 간단하게 도식화한 것이다.                                      그림 1 이미지 호스팅 애플리케이션의 아키텍처 다이어그램 이미지 호스팅 시스템에서는 고려해야 할 다른 측면이 있다.  서비스들(Services) 확장성있는 시스템을 설계할 때 각각의 명확한 인터페이스를 기반으로 나누어 생각하는 것은 좋은 방법이다. 이러한 방식으로 설계하는 시스템을 SOA(Service-Oriented Architecture)라고 부른다. 그리고 각각의 서비스는 다른 서비스와 상호작용을 위해 다른 서비스에서 공개하는 API형태인 추상화된 인터페이스를 사용한다. 시스템을 상호 보완적인 서비스로 분할한다는 것은 시스템을 기능단위로 분리시키는 것을 말한다. 이러한 추상화는 서비스와 서비스가 처한 환경 그리고 서비스와 서비스 사용자 사이의 명확한 관계를 수립하는데도 도움이 된다. 이러한 명확한 기술은 문제를 분리시키는데도 도움이 되지만, 각각을 독립적으로 확장시키는 것에도 효과적읻. 이런의미에서 시스템에서의 SOA는 객체 지향 프로그래밍과 아주 유사하다. 예제 애플리케이션에서 모든 이미지 업로드와 검색을 ...

(어플리케이션 개발) 데이터베이스 주의사항

*애플리케이션 개발 후 회원수가 많아져서 로그인 과정이 예전보다 상당히 느려진 경우 -> 서버에 투자하는 것 보다는 효율적인 인덱스 구성과 인덱스에 맞는 쿼리를 구현하는 일이 더 바람직하다. 주의사항: 회원테이블의 기본키를 무심코 회원ID로 정의하면 안된다. 기본키를 일련번호 칼럼으로 정의해야 한다. 예를들어, Korea라는 회원ID를 사용하고 있던 회원이 물건을 구매한 후 탈퇴를 했다고 가정하자. 그러면 그 회원의 데이터를 지울 수 있는가? 지울 수 없다. 왜냐하면 물건을 구매했기 때문에 그 회원의 회원ID가 상품 테이블의 포린키로 남아있기 때문이다. 그러므로 회원ID칼럼과 비밀번호 컬럼에 인덱스를 부여해야 한다. 그리고 당연히 각각으 칼럼에 인덱스를 부여하는 것 보다 두 개의 칼럼을 하나의 인덱스로 구성해야 한다. 인덱스 유형은? 회원 테이블의 기본키인 회원번호는 분명 넌 클러스터드 인덱스로 만들어져야 하며 회원ID와 비밀번호 칼럼에도 역시 넌 클러스터드 인덱스를 만들어야 할 것이다. 그러면 어떠한 칼럼에 클러스터드 인덱스를 만들까? 그것은 조회의 조건에도 자주 등장하면서 데이터가 순차적으로 입력되는 칼럼에 부여하는 것이 좋다. 아마도 등록일 컬럼이 될 듯 싶다. 조회문장(Query)에 대한 고려 Select * from 회원 where 회원ID='1111' and 비밀번호='1111' 이거은 조건에 맞는 해당 회원의 모든 컬럼의 데이터를 가져오라고 하는 것이므로 검색 프로세서는 인덱스의 리프레벨에서 해당 회원의 존재유무를 확인했지만 해당 회원의 모든 칼럼을 가져오기 위해 데이터 페이지까지 내려가서 데이터를 가져오는 작업을 진행하게 된다. 단지, 회원을 인증하기 위해 질의를 하는 것이지 회원의 정볼르 보기 위해 질의를 하는 것이 아님을 명심하자 그러므로 Select 회원ID from 회원 where 회원ID='1111' and 비밀번호=...

(어플리케이션 개발) Comet with Tomcat

Tomcat 6.0/conf/server.xml 수정 기존 <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> 수정 <Connector port="8080" protocol="org.apache.coyote.http11.Http11 Nio Protocol"                connectionTimeout="20000" redirectPort="8443" /> 공통 속성 protocol:  커넥터들의 비교 HTTP/1.1 (=org.apache.coyote.http11.Http11Protocol) [기본값] org.apache.coyote.http11.Http11NioProtocol  - 논 블로킹 자바 커넥터(Comet을 사용시) / NIO를 사용 org.apache.coyote.http11.Http11AprProtocol -  APR 커넥터 (아파치 등과 연동시 유용) redirectPort: SSL요청이 아닌 연결에 대해 리다이렉트 할 포트를 지정 port: 연결이 들어올 서버 소켓의 TCP 포트 번호 표준 구현 connectionTimeout: 커넥터를 위해 기다릴 밀리초의 숫자를 적음. 연결이 이루어진 이후에 URI에 대해 보존될 시간    (기본값: 60초 / 60000, AJP의 경우 기본값은 unlimited이다.) NIO 구현 useComet : comet 서블릿을 허용할지 여부 설정 (기본값: true) maxKeepAliveRequests : 서버에 의해 닫을 HTTP 연결의 최대 제한수(1: HTTP/1.0 keep-alive 미사용&HTTP/1.1 ...

(어플리케이션개발) 서버사이드 LongPolling방식으로 구현