Developer Log
  • Wiki
  • Books
    • 리눅스 시스템 프로그래밍
      • 핵심 개념 소개
        • 시스템 프로그래밍
        • API와 ABI
        • 리눅스 프로그래밍의 개념
          • 파일과 파일시스템
          • 프로세스
          • 사용자와 그룹
          • 권한
          • 시그널
          • 프로세스간 통신
          • 에러 처리
    • 데이터 베이스 첫걸음
      • 데이터베이스란
        • 데이터베이스의 역할을 생각해 보자
          • 우리와 데이터베이스의 관계
          • 데이터베이스의 기본 기능
          • 데이터베이스 종류
      • 관계형 데이터베이스란
        • 대표적인 DBMS를 알아보자
          • 관계형 데이터베이스란
          • SQL 기초 지식
          • 관계형 데이터베이스를 다루기 위한 사전 지식
      • 데이터베이스에 얽힌 돈 이야기
        • 초기비용과 운영비용을 생각하자
      • 데이터베이스와 아키텍처 구성
        • 다중화에 대해 생각해보자
          • 아키텍처란
          • 데이터베이스의 아키텍처
            • 역사와 개요
              • Stand-alone
              • 클라이언트/서버
              • Web 3계층
            • 가용성과 확장성의 확보
          • DB 서버의 다중화
            • 클러스터링
            • 리플리케이션
          • 성능을 추구하기 위한 다중화 - Shared Nothing
          • 적합한 아키텍처를 설계하기 위해
      • DBMS를 조작할 때 필요한 기본 지식
        • MySQL 설치해보자
        • MySQL과 커넥션 만들기, 데이터베이스에 전화걸기
        • SQL과 관리 명령의 차이
        • 관계형 데이터베이스의 계층
      • SQL 문의 기본
        • SELECT 문으로 테이블 내용을 살펴보자
        • SELECT 문을 응용해보자
        • 데이터를 갱신, 삽입, 제거해보자
        • 뷰를 작성하고 복수 테이블에서 선택해보자
      • 트랜잭션과 동시성 제어
      • 테이블 설계의 기초
      • 백업과 복구
      • 성능을 생각하자
    • 개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴
      • 객체 지향
        • 들어가기
        • 객체 지향
        • 다형성과 추상 타입
        • 재사용: 상속보단 조립
      • 설계 원칙 / DI와 서비스 로케이터
        • 설계 원칙: SOLID
          • 단일 책임 원칙(Single Responsibility Principle)
          • 개방 폐쇄 원칙(Open - Closed Principle)
          • 리스코프 치환 원칙(Liskov Substitution Principle)
          • 인터페이스 분리 원칙(Interface Segregation Principle)
          • 의존 역전 원칙(Dependency Inversion Principle)
          • SOLID 정리
        • DI(Dependency Injection)와 서비스 로케이터
      • 주요 디자인 패턴
        • 디지인 패턴이란?
        • 전략(Strategy) 패턴
        • 템플릿 메서드(Template Method) 패턴
        • 상태(State) 패턴
        • 데코레이터(Decorator) 패턴
        • 프록시(Proxy) 패턴
        • 어댑터(Adapter) 패턴
        • 옵저버(Observer) 패턴
        • 미디에이터(Mediator) 패턴
        • 파사드(Facade) 패턴
        • 컴포지트(Composite) 패턴
        • 널(Null) 객체 패턴
        • 팩토리 메서드 패턴
        • 커맨드 패턴
        • 추상 팩토리 패턴
    • 테스트 주도 개발
      • 1부
        • 다중 통화를 지원하는 Money 객체
        • 타락한 객체
        • 모두를 위한 평등
        • 프라이버시
        • 솔직히 말하자면
        • 돌아온 '모두를 위한 평등'
        • 사과와 오렌지
Powered by GitBook
On this page
  • Stand-alone의 특징
  • Stand-alone의 단점
  • Stand-alone의 장점

Was this helpful?

  1. Books
  2. 데이터 베이스 첫걸음
  3. 데이터베이스와 아키텍처 구성
  4. 다중화에 대해 생각해보자
  5. 데이터베이스의 아키텍처
  6. 역사와 개요

Stand-alone

Stand-alone의 특징

Stand-alone은 데이터베이스가 동작하는 머신(DB 서버)이 LAN이나 인터넷 등의 네트워크에 접속하지 않고 '독립되어' 동작하는 구성이다.

이 구성에서는 데이터베이스의 미들웨어(DBMS)와 애플리케이션의 소프트웨어는 같은 DB 서버에서 동작한다.

Stand-alone의 단점

1. 물리적으로 떨어진 장소에서 접근할 수 없다

네트워크에 연결되어 있지 않다는 것은 데이터베이스를 이용하려면 데이터베이스 서버 앞에까지 가서 이용하는 방법밖에 없다는 것을 의미한다.

2. 복수 사용자가 동시에 작업할 수 없다

네트워크에 연결되어 있지 않다는 것은 동시에 서버를 이용할 수 있는 사람 수가 1명으로 한정된다는 것이다.

3. 가용성이 낮다

서버가 1대밖에 없으므로 이 1대에 장애가 발생하면 서비스가 정지하기 때문에 가용성이 매우 낮다.

가용성(Availability) 이란?

시스템이 서비스 제공시간에 장애없이 서비스를 계속 지속할 수 있는 비율이 어느 정도인가를 나타내는 개념

4. 확장성이 부족하다

Stand-alone은 '성능이 나쁘다'는 것 이상으로 성능이 나쁠 때 '개선 수단'이 매우 부족하다. 실제 머신이 1대밖에 없다는 것은 머신 그 자체의 성능을 높이는 것 이외에 개선 수단이 없다는 것을 의미한다. 이런 구성을 '확장성(Scalability)이 부족하다' 고 표현한다.

Stand-alone의 장점

1. 소규모 작업이나 테스트를 빨리할 수 있다

구축이 매우 간단하기 때문에 성능이나 가용성을 무시하면 노트북을 사용해서도 만들 수 있다.

2. 보안이 매우 높다

네트워크를 매개로 침입할 위험이 없기 때문에 사용자가 외부에 물리적으로 들고 가지 않는 한 서버가 바이러스에 감염되거나 공격받는 일은 일어나지 않는다.

3. 데이터 유출 위험이 매우 낮다

사용자가 DB 서버로부터 데이터를 DVD나 USB 메모리 같은 매체에 복사하려고 할 경우, 하드디스크를 직접 가지고 나가지 않는 한 네트워크를 경유한 외부 해킹으로 데이터를 도둑맞을 걱정이 없다.

Previous역사와 개요Next클라이언트/서버

Last updated 6 years ago

Was this helpful?