데이터를 통합할 때, 성능 향상과 가용성을 높이기 위해 데이터베이스 차원의 파티셔닝 또는 클러스터링을 이용한다.
- 파티션 사이의 병렬 처리를 통한 빠른 데이터 검색 및 처리
-성능의 선형적인 증가 효과
-고가용성(특정 파티션에서 장애 발생시에도 서비스가 중단되지 않음)
시스템 구성
- 단일 서버 내의 파티셔닝
-다중 서버 사이의 파티셔닝
리소스 공유 관점
- 공유 디스크(Shared Disk)
- 무공유 디스트(Shared Nothing)
1) 무공유(Shared Nothing) 클러스터
각 데이터베이스 인스턴스는 자신이 관리하는 데이터 파일을 자신의 로컬 디스크에 저장하며, 노드 간에 공유하지 않는다.
각 인스턴스나 노드는 완전히 분리된 데이터의 서브 집합에 대한 소유권을 가지고 있으며, 각 데이터는 소유권을 갖고 있는 인스턴스가 처리한다. 한 노드가 데이터 처리 요청을 받으면, 해당 노드는 처리할 데이터를 갖고 있는 노드에 신호를 보내 데이터 처리를 요청한다.
장점- 노드 확장에 제한이 없다.
단점- 장애 발생시 대비해 별도의 폴트톨러런스(fault-tolerance)를 구성 필요
Oracle RAC(Real Application Cluster)를 제외한 대부분의 데이터베이스 클러스터가 무공유 방식을 사용.
2)공유 디스크(Shared Disk) 클러스터
데이터 파일은 논리적으로 모든 데이터베이스 인스턴스 노드들 과 공유, 각 인스턴스는 모든 데이터에 접근할 수 있다. 데이터를 공유하려면 SAN(Storage Area Network)과 같은 공유 디스크가 반드시 있어야 하며, 모든 노드가 데이터를 수정할 수 있기 때문에 노드간의 동기화 작업 수행을 위한 별도의 커뮤니케이션 채널이 필요하다.
장점- 높은 수준의 폴트톨러런스 제공(클러스터를 구성하는 노드 중 하나의 노드만 살아 있어도 서비스가 가능)
단점- 클러스터가 커지면 디스크 영역에서 병목현상 발생 (Oracle RAC가 공유디스크 방식을 이용)
가. Oracle RAC 데이터베이스 서버
_________________________________________________
그림은 일반적인 4노드 RAC 구성모델.
Oracle RAC 데이터베이스 서브는 클러스터의 모든 노드에서 실행되며, 데이터는 공유 스토리지에 저장된다.
클러스터의 모든 노드는 데이터베이스의 모든 테이블에 동등하게 액세스하며, 특정 노드가 데이터를 '소유'하는 개념이 없다. 따라서 데이터를 파티셔닝할 필요가 없지만, 성능 향상을 위해 빈번하게 파티셔닝 된다. 응용 프로그램은 클러스터의 특정 노드가 아니라 RAC 클러스터에 연결하며, RAC는 클러스터의 모든 노드에 로드를 고르게 분산한다.
-가용성
클러스터의 한 노드가 어떤 이유로 장애를 일으키면 Oracle RAC는 나머지 노드에서 계속 실행된다. 장애가 발생한 노드에 연결됐던 모든 응용 프로그램(사용자)은 투명하게 다시 연결되어 클러스터의 나머지 노드에 분산된다.
-확장성
추가 처리 성능이 필요하면 응용 프로그램이나 데이터베이스를 수정할 필요 없이 새 노드를 클러스터에 쉽게 추가할 수 있다. 클러스터의 모든 노드 간에 균형이 유지되도록 로드가 다시 분산된다. Oracle 10g R2 RAC 는 클러스터 내에 최대 100개의 노드를 지원한다.
-비용 절감
RAC는 표준화된 소규모(CPU 4개 미만)저가형 사용 하드웨어의 클러스터에서도 고가의 SMP 시스템만큼 효율적으로 응용 프로그램을 실행함으로써 하드웨어 비용을 절감한다. 예를 들어 4CPU의 16노드 클러스터를 사용하면 동급 성능의 64CPU SMP 시스템에 대해 비용을 크게 절감할 수 있다.
Oracle RAC는 여러 장점을 갖고 있지만 일반적으로 4노드 이상 잘 구성하지 않는다. 도입 비용 때문에 확장성이 중요한 데이터보다는 고가용성을 요구하는 데이터에 많이 사용한다.
나. IBM DB2 ICE(Integrated Cluster Environment)
DB2는 CPU.메모리.디스크를 파티션별로 독립적으로 운영하는 무공유 방식의 클러스터링을 지원한다. 애플리케이션은 여러 파티션에 분산된 데이터베이스를 하나의 데이터베이스(Single View Database)로 보게되고, 데이터가 어느 파티션에 존재하고 있는지 알 필요가 없다. 따라서 데이터와 사용자가 증가하면 애플리케이션의 수정 없이 기존 시스템에 노드를 추가하고 데이터를 재분배함으로써 시스템의 성능과 용량을 일정하게 유지할 수 있다.
하지만 각 노드로 분산되는 파티셔닝을 어떻게 구성하느냐에 따라 성능의 차이가 많이 발생할 수 있으며 하나의 노드에 장애가 발생할 경우, 해당 노드에서 서비스하는 데이터에 대한 별도의 페일오버(failover)메커니즘이 필요하게 된다. 따라서 DB2를 이용하여 클러스터를 구성할 때에도 가용성을 보장하기 위해 공유 디스크 방식을 이용한다. 공유 디스크에 저장된 데이터 파일에 대해 특정 시점에서는 특정 노드에 의해 서비스 되지만 장애 상항이 발생하게 되면 다른 노드가 해당 데이터에 대한 서비스를 처리하는 방식으로 가용성을 보장한다.
다. 마이크로소프트 SQL Server
연합(Federated) 데이터베이스 형태로 여러 노드로 확장할 수 있는 기증을 제공
연합데이터베이스는 디스크 등을 공유하지 않는 독립된 서버에서 실행되는 서로 다른 데이터베이스들 간의 논리적인 결합이며, 네트워크를 이용하여 연결된다.
데이터는 관련된 서버들로 수평적으로 분할된다. 테이블을 논리적으로 분리해 물리적으로는 분산된 각노드에 생성하고, 각 노드의 데이터베이스 인스턴스 사이에 링크를 구성한 후 모든 파티션에 대해 UNIO ALL 을 이용해 논리적인 뷰(VIEW)를 구성하는 방식으로 분산된 환경의 데이터에 대한 싱글 뷰를 제공한다.
SQL Server 에서는 이런 뷰를 DVP(Distributed Partitioned View)라고 한다.
DBA나 개발자가 파티셔닝 정책에 맞게 테이블과 뷰를 생성해야 하고, 전역 시키마(Global schema)정보가 없기 때문에 질의 수행을 의해 모든 노드를 액세스해야 한다는 점.
노의가 많아지거나 노드의 추가/삭제가 발생하는 경우 파티션을 새로 해야 하는 문제
페일오버에 대해서는 별도로 구성.
SQL Server에서도 페일오버 메커니즘을 제공하지만, Active-Activie가 아닌 Active-Standy 방법을 사용
라. MySQL 크러스터
무공유 구조에서 메모리(최근에는 디스크도 제공)기반 데이터베이스의 클러스터링을 지원
특정한 하드웨어 및 소프트웨어를 요구하지 않고 병렬 서버구조로 확장이 가능.
-관리 노드(Management Node):클러스터를 관리하는 노드로 클러스터 시작과 재구성 시에만 관여한다.
-데이터 노드(NDB Node):클러스터의 데이터를 저장하는 노드
-MySQL 노드: 클러스터 데이터에 접근을 지원하는 노드
MySQL 클러스터는 데이터의 가용성을 높이기 휘해 데이터를 다른 노드에 복제시키며, 특정 노드에 장애가 발생하더라도 지속적인 데이터 서비스가 가능하다. 장애가 났던 노드가 복구되어 클러스터에 투입된경우에도 기존 데이터와 변경된 데이터에 대한 동기화 작업이 자동으로 수행된다. 데이터는 동기화 방식으로 복제되며, 이런 작업을 위해 일반적으로 데이터 노드 간에는 별도의 네트워크를 구성한다.
MySQL의 최근 버전(5.1.6 이상)에서는 디스크 기반의 클러스터링을 제공한다. 디스크 기반 클러스터링에서는 인덱스가 생성된 칼럼은 기존과 동일하게 메모리에 유지되지만, 인텍스를 생성하지 않은 칼럼은 디스크에 저장된다. 따라서 디스크에 저장된 데이터는 모두 인덱스가 없는 데이터다. 이 경우 디스크에 저장된 데이터와 JOIN 연산을 수행할 경우 성능이 좋지 않기 때문에 애플리케이션 개발 시 주의해야 한다. 또한 디스크 기반이라 하더라도인텍스로 구성된 컬럼은 메모리에 있기 때문에 데이터의 크기와 메모리 크기를 고려하여 인덱스 생성과 클러스터의 참여하는 장비의 메모리르 산정해야 한다.
제한사항
- 파티셔닝은 LINEAR KEY 파티셔닝만 사용 가능하다.
- 클러스터에 참여하는 노드(SQL 노드, 데이터노드, 메니저를 포함)수는 255로 제한한다. 데이터 노드는 최대 48개까지만 가능하다.
- 트랜잭션 수행 중에 롤백을 지원하지 않으므로 작업 수행 중에 문제가 발생하였다면, 전체 트랜잭션 이전으로 롤백해야 한다.
- 하나의 트랜잭션에 많은 데이터를 처리하는 경우 메모리 부족 문제가 발생할 수 있으며, 여러 개의 트랜잭션으로 분리해 처리하는 것이 좋다(예:Delete from .. LIMIT ...).
- 칼럼명 길이는 31자, 데이터베이스와 테이블명 길이는 122자까지로 제한된다. 데이터베이스 테이블, 시스템 테이블, 블롭(BLOB) 인덱스를 포함한 메타데이터(속성정보)는 2만 320개까지만 가능하다.
- 클러스터에서 생성할 수 있는 데이블 수는 최대 2만 320개다. 한 로우(row)의 최대 크기는 8KB다(BLOB를 포함하지 않는 경우), 테이블의 키는 32개가 최대다.
- 모든 클러스터의 기종은 동일해야 한다. 기종에 따른 비트 저장방식이 다르면 문제가 발생할 수 있다.
- 운영 중에 노드를 추가/삭제할 수 없다.
- 디스크 기반 클러스터인 경우 tablespace의 개수는 2^32(4294967296), tablespace당 데이터 파일의 개수는 2^16(65535), 데이터 파일의 크기는 32GB까지 가능하다.
2017년 12월 16일 토요일
1. 분산 파일 시스템
사용자 중심의 인터넷 서비스와 유비쿼터스 컴퓨팅 환경은 대규모 클러스터 시스템 플랫폼의 필요성을 부각.
대규모 클러스터 시스템: 네트워크상에 분산된 많은 서버들을 클러스터로 구성
- 대용량 저장공간
- 빠른 처리 성능
- 시스템 확장의 용의
- 시스템 신뢰성 및 가용성(시스템 장애가 발생시 안전 보장)
NFS(Network File System) 기존 단순한 클라이언트/서버 수준의 분산 파일 시스템으로는 시스템 성능과 확장에 한계 발생
비대칭형(asymmetric)클러스터 파일 시스템은 성능과 확장성, 가용셩 면에서 적합한 분산 파일 시스템 구조로, 최근에 연구와 개발이 활발히 진행
비대칭형 클러스터 파일 시스템: 파일 메타데이터를 관리하는 전용 서버
(메타데이터 서버에 부하가 집중될 수 있으며 single-of-failure 지점이 돌 수 있는 문제점 내표)
가. 구글 파일 시스템(GFS, Google File system)
구글의 대규모 클러스터 서비스 플래폼의 기반
- 저가형 서버로 구성된 환경으로 서버의 고장이 빈번히 발생할 수 있다고 가정한다.
-대부분의 파일은 대용량이라고 가정한다. 따라서 대용량 파일을 효과적으로 관리할 수 있는 방법이 요구된다.
- 작업 부하는 주로 연속적으로 많은 데이터를 읽는 연산이거나 임의의 영역에서 적은 데이터를 읽는 연산이다.
- 파일에 대한 쓰기 연산은 주로 순차적으로 데이터를 추가하며, 파일에 대한 갱신은 들물게 이루어진다.
-여러 클라이언트에서 동시에 동일한 파일에 데이터를 추가하는 환경에서 동기화 오버헤드를 최소화 할 수 있는 방법이 요구된다.
-낮은 응답 지연시간보다 높은 처리율이 보다 중요하다.
GFS는 그림과 같이 클라이언트, 마스터, chunk 서버를 구성된다.
GFS의 클라이언트는 POSIX(Portable Operating System Interface)인터페이스를 지원하지 않으며, 파일 스스템 인터페이스와 유사한 자체 인터페이스를 지원 한다. 또한 여러 클라이언트에서 원자적인 데이터 추가(atomic append)연산을 지원하기 위한 인터페이스를 지원한다.
GFS에서 파일은 고정된 크기의 chunk들로 나누어 chunk서버들에 분산.저장된다.
그리고 각 chunk 에 대한 여러 개의 복제본도 chunk 서버에 분산.저장된다.
따라서 클라이언트는 파일에 접근하기 위하여 마스터로부터 해당 파일의 chunk가 저장된 chunk 서버의 위치와 핸들을 먼저 받아온다.
이어서 직접 chunk 서비로 파일 데이터를 요청한다. GFS의 마스터는 단일 마스터 구조로 파일 시스템 이름 공간과 파일의 chunk 매핑 정보, 각 chunk 의 크기를 64MB로 지정함으로써 파일 메타데이터의 크기를 줄인다. 또한 기존 트리 구조가 아닌 해시 테이블 구조 등을 사용함으로써 메모리상에서 보다 효율적인 메타데이터 처리를 지원한다. 마스터에서는 주기적으로 하트비트(heartbeat)메시지를 이요하여 chunk 서버에 저장된 chunk 들의 상테를 체크해 상태에 따라 chunk를 재 복제하거나 재분산하는 것과 같은 회복동작을 수행한다.
마스터에 대한 장애 처리와 회복을 위해 파일스스템 이름 공간과 파일의 chunk 매핑 변경 연산을 로깅하고 마스터의 상태를 여러 새도 마스터에 복제한다.
Chunk 서버는 로컬 디스크에 chunk를 저장.관리하면서 클라이언트로보터의 chunk입출력 요청을 처리한다. chunk는 마스터에 의해 생성/삭제될 수 있으며, 유일한 식별자에 의해 구별된다. 마스터는 하나의 chunk 서버를 primary로 지정하여 복제본의 갱신 연산을 일관되게 처리할 수 있도록 보장한다.
나. 하둡 분산 파일 시스템
하둡(Haddop)은 아파치(Apache)의 검색엔진 프로젝트인 루씬(Lucene)의 서브 프로젝트로 진행되었지만, 2008년 1월에 아파츼의 최상위 프로젝트로 승격되었다. 하둡은 하둡 분산 파일시스템(HDFS)과 MapReduce 구현 등을 포함한다. HDFS는 처음에 아파치 너치(Apache Nutch)웹 검색 엔진의 파일 시스템으로 개발되었으며, 구글 파일 시스템과 아키텍처와 사상을 그대로 구현한 클로닝(Cloning)프로젝트라고 할 수 있다.
_____________________________________________________________________________
HDFS 는 그림에서와 같이 하나의 네임노드(NameNode)와 다수의 데이터노드(DataNode)로 구성된다.
네임노드는 파일 시스템의 이름 공간을 관리하면서 클라이언트로부터의 파일 접근 요청을 처리한다.
HDFS에서 파일 데이터는 블록 단위로 나뉘어 여러 데이터 노드에 분산.저장된다. 그리고 블록들은 가용성을 보장하기 위하여 다시 복제.저장된다.
따라서 데이터노드는 클라이언트로부터의 데이터 입출력 요청을 처리한다. HDFS에서 파일은 한 번 쓰이면 변경되지 않는다고 가정한다. 따라서 HDFS는 데이터에 대한 스트리밍 접근을 요청하며, 배치작업에 적합한 응용을 대상으로 한다.
네임노드는 데이터노드들로부터 하트비트(Heartbeat)를 주기적으로 받으면서 데이터노드들의 상태를 체크한다. 또한 하트비트, 네임노트, 데이터노드 간의 통신을 위하여 TCP/IP네트워크상에 RPC(Remote Procedure Call)를 사용한다.
다. 러스터(Luste)
클러스터 파일 시스템(Cluster File Systems Inc.)에서 개발한 객체 기반 클러스터 파일 시스템이다.
리스터는 그림과 같이 클라이언트 파일 시스템, 메타데이터 서버, 객체 저장 서버들로 구성되며, 이들은 고속 네트워크로 연결된다. 리스터에서는 계층화된 모듈 구조로 TCP/IP, 이니니밴드(Infiniband), 미리넷(Myrinet)과 같은 네트워크를 지원한다. 클라이언트 파일 시스템은 리눅스 VFS(Virtual File System)에서 설치할 수 있는 파일 시스템으로, 메타데이터 서버와 객체 저장 서버들과 통신하면서 클라이언트 응용에 파일 시스템 인터페이스를 제공한다. 메타데이터 서버는 파일 시스템의 이름 공간과 파일에 대한 메타 데이터를 관리하며, 객체 저장 서버는 파일데이터를 저장하고 클라이언트로부터의 객체 입출력 요청을 처리한다. 객체는 객체 저장 서버들에 스트라이핑되어 분산.저장된다.
리스터는 유닉스(Unix) 시맨틱을 제공하면서 파일 메타데이터에 대해서는 라이트백 캐시(Write Back Cache)를 지원한다. 이를 위해 클라이언트에서 메타데이터 변경에 대한 갱신 레코드를 생성하고 나중에 메타데이터 서버에 전달한다. 그러면 메타데이터 서버는 전달된 갱신 레코드를 재수행하여 변경된 메타데이터를 반영한다. 더불어 메타데이터 서버에서는 메타데이터를 도시에 접근하는 부하에 따라 클라이언트 캐시에서 라이트백 캐시를 지원하거나 메타데이터 서버에서 메타데이트를 처리하는 방식을 적용한다.
__________________________________________________________________
리스터는 메타데이터 서버에서 처리하도록 하는 방식을 사용해 메타데이터에 대한 동시 접근이 적으면 클라이언트 캐시를 이용한 라이트백 캐시를 사용하고, 메타데이터에 대한 동시 접근이 많으면 클라이언트 캐시를 사용함으로써 발생할 수 있는 오버헤드를 줄인다.
리스터는 파일 메타데이터와 파일 데이터에 대한 동시성 제어를 위해 별도의 잠금을 사용한다. 메타데이터에 접근하기 위해서는 메타데이터 서버로부터 잠금을 획득해야 한다. 파일 데이터를 접근하기 위해서는 해당 데이터가 저장된 객체 저장 서버의 잠금을 획득해야 한다.
또한 리스터에서는 클라이언트와 메타데이터 서버 간의 네트워크 트래픽을 최호화하기 위하여 메타데이터에 대한 요청 시에 메타데이터 접근 의도를 같이 전달하는 인텐트(intent)기반 잠금 프로토콜을 사용한다. 따라서 메타데이터 서버는 메타데이터 접근 의도에 따라 해당 동작을 후생하고, 잠금을 승인하는 처리를 함께 수행함으로써 클라이언트와 메타데이터 서버 간의 네트워크 트래픽을 줄인 수 있다.
클러스터 파일 시스템 비교
구분 GFS 하둡 DFS 리스터
Open Source 지원 지원 지원
Chunk base 지원 지원 지원 안함
Support Replication 지원 지원 지원 안함
Multiple metadata server supported 지원 안함 지원 안함 지원 안함
Locks used to maintain aoomicity 지원 지원 지원
Uses a DB for storing metadata 지원 안함 지원 안함 지원 안함
Adding nodes widthout shutting 지원 지원 지원
down the System.
POSIX support 지원 안함 지원 안함 지원
Supports file modification 지원 안함 지원 안함 지원
(append는 지원함)
대규모 클러스터 시스템: 네트워크상에 분산된 많은 서버들을 클러스터로 구성
- 대용량 저장공간
- 빠른 처리 성능
- 시스템 확장의 용의
- 시스템 신뢰성 및 가용성(시스템 장애가 발생시 안전 보장)
NFS(Network File System) 기존 단순한 클라이언트/서버 수준의 분산 파일 시스템으로는 시스템 성능과 확장에 한계 발생
비대칭형(asymmetric)클러스터 파일 시스템은 성능과 확장성, 가용셩 면에서 적합한 분산 파일 시스템 구조로, 최근에 연구와 개발이 활발히 진행
비대칭형 클러스터 파일 시스템: 파일 메타데이터를 관리하는 전용 서버
(메타데이터 서버에 부하가 집중될 수 있으며 single-of-failure 지점이 돌 수 있는 문제점 내표)
가. 구글 파일 시스템(GFS, Google File system)
구글의 대규모 클러스터 서비스 플래폼의 기반
- 저가형 서버로 구성된 환경으로 서버의 고장이 빈번히 발생할 수 있다고 가정한다.
-대부분의 파일은 대용량이라고 가정한다. 따라서 대용량 파일을 효과적으로 관리할 수 있는 방법이 요구된다.
- 작업 부하는 주로 연속적으로 많은 데이터를 읽는 연산이거나 임의의 영역에서 적은 데이터를 읽는 연산이다.
- 파일에 대한 쓰기 연산은 주로 순차적으로 데이터를 추가하며, 파일에 대한 갱신은 들물게 이루어진다.
-여러 클라이언트에서 동시에 동일한 파일에 데이터를 추가하는 환경에서 동기화 오버헤드를 최소화 할 수 있는 방법이 요구된다.
-낮은 응답 지연시간보다 높은 처리율이 보다 중요하다.
GFS는 그림과 같이 클라이언트, 마스터, chunk 서버를 구성된다.
GFS의 클라이언트는 POSIX(Portable Operating System Interface)인터페이스를 지원하지 않으며, 파일 스스템 인터페이스와 유사한 자체 인터페이스를 지원 한다. 또한 여러 클라이언트에서 원자적인 데이터 추가(atomic append)연산을 지원하기 위한 인터페이스를 지원한다.
GFS에서 파일은 고정된 크기의 chunk들로 나누어 chunk서버들에 분산.저장된다.
그리고 각 chunk 에 대한 여러 개의 복제본도 chunk 서버에 분산.저장된다.
따라서 클라이언트는 파일에 접근하기 위하여 마스터로부터 해당 파일의 chunk가 저장된 chunk 서버의 위치와 핸들을 먼저 받아온다.
이어서 직접 chunk 서비로 파일 데이터를 요청한다. GFS의 마스터는 단일 마스터 구조로 파일 시스템 이름 공간과 파일의 chunk 매핑 정보, 각 chunk 의 크기를 64MB로 지정함으로써 파일 메타데이터의 크기를 줄인다. 또한 기존 트리 구조가 아닌 해시 테이블 구조 등을 사용함으로써 메모리상에서 보다 효율적인 메타데이터 처리를 지원한다. 마스터에서는 주기적으로 하트비트(heartbeat)메시지를 이요하여 chunk 서버에 저장된 chunk 들의 상테를 체크해 상태에 따라 chunk를 재 복제하거나 재분산하는 것과 같은 회복동작을 수행한다.
마스터에 대한 장애 처리와 회복을 위해 파일스스템 이름 공간과 파일의 chunk 매핑 변경 연산을 로깅하고 마스터의 상태를 여러 새도 마스터에 복제한다.
Chunk 서버는 로컬 디스크에 chunk를 저장.관리하면서 클라이언트로보터의 chunk입출력 요청을 처리한다. chunk는 마스터에 의해 생성/삭제될 수 있으며, 유일한 식별자에 의해 구별된다. 마스터는 하나의 chunk 서버를 primary로 지정하여 복제본의 갱신 연산을 일관되게 처리할 수 있도록 보장한다.
나. 하둡 분산 파일 시스템
하둡(Haddop)은 아파치(Apache)의 검색엔진 프로젝트인 루씬(Lucene)의 서브 프로젝트로 진행되었지만, 2008년 1월에 아파츼의 최상위 프로젝트로 승격되었다. 하둡은 하둡 분산 파일시스템(HDFS)과 MapReduce 구현 등을 포함한다. HDFS는 처음에 아파치 너치(Apache Nutch)웹 검색 엔진의 파일 시스템으로 개발되었으며, 구글 파일 시스템과 아키텍처와 사상을 그대로 구현한 클로닝(Cloning)프로젝트라고 할 수 있다.
_____________________________________________________________________________
HDFS 는 그림에서와 같이 하나의 네임노드(NameNode)와 다수의 데이터노드(DataNode)로 구성된다.
네임노드는 파일 시스템의 이름 공간을 관리하면서 클라이언트로부터의 파일 접근 요청을 처리한다.
HDFS에서 파일 데이터는 블록 단위로 나뉘어 여러 데이터 노드에 분산.저장된다. 그리고 블록들은 가용성을 보장하기 위하여 다시 복제.저장된다.
따라서 데이터노드는 클라이언트로부터의 데이터 입출력 요청을 처리한다. HDFS에서 파일은 한 번 쓰이면 변경되지 않는다고 가정한다. 따라서 HDFS는 데이터에 대한 스트리밍 접근을 요청하며, 배치작업에 적합한 응용을 대상으로 한다.
네임노드는 데이터노드들로부터 하트비트(Heartbeat)를 주기적으로 받으면서 데이터노드들의 상태를 체크한다. 또한 하트비트, 네임노트, 데이터노드 간의 통신을 위하여 TCP/IP네트워크상에 RPC(Remote Procedure Call)를 사용한다.
다. 러스터(Luste)
클러스터 파일 시스템(Cluster File Systems Inc.)에서 개발한 객체 기반 클러스터 파일 시스템이다.
리스터는 그림과 같이 클라이언트 파일 시스템, 메타데이터 서버, 객체 저장 서버들로 구성되며, 이들은 고속 네트워크로 연결된다. 리스터에서는 계층화된 모듈 구조로 TCP/IP, 이니니밴드(Infiniband), 미리넷(Myrinet)과 같은 네트워크를 지원한다. 클라이언트 파일 시스템은 리눅스 VFS(Virtual File System)에서 설치할 수 있는 파일 시스템으로, 메타데이터 서버와 객체 저장 서버들과 통신하면서 클라이언트 응용에 파일 시스템 인터페이스를 제공한다. 메타데이터 서버는 파일 시스템의 이름 공간과 파일에 대한 메타 데이터를 관리하며, 객체 저장 서버는 파일데이터를 저장하고 클라이언트로부터의 객체 입출력 요청을 처리한다. 객체는 객체 저장 서버들에 스트라이핑되어 분산.저장된다.
리스터는 유닉스(Unix) 시맨틱을 제공하면서 파일 메타데이터에 대해서는 라이트백 캐시(Write Back Cache)를 지원한다. 이를 위해 클라이언트에서 메타데이터 변경에 대한 갱신 레코드를 생성하고 나중에 메타데이터 서버에 전달한다. 그러면 메타데이터 서버는 전달된 갱신 레코드를 재수행하여 변경된 메타데이터를 반영한다. 더불어 메타데이터 서버에서는 메타데이터를 도시에 접근하는 부하에 따라 클라이언트 캐시에서 라이트백 캐시를 지원하거나 메타데이터 서버에서 메타데이트를 처리하는 방식을 적용한다.
__________________________________________________________________
리스터는 메타데이터 서버에서 처리하도록 하는 방식을 사용해 메타데이터에 대한 동시 접근이 적으면 클라이언트 캐시를 이용한 라이트백 캐시를 사용하고, 메타데이터에 대한 동시 접근이 많으면 클라이언트 캐시를 사용함으로써 발생할 수 있는 오버헤드를 줄인다.
리스터는 파일 메타데이터와 파일 데이터에 대한 동시성 제어를 위해 별도의 잠금을 사용한다. 메타데이터에 접근하기 위해서는 메타데이터 서버로부터 잠금을 획득해야 한다. 파일 데이터를 접근하기 위해서는 해당 데이터가 저장된 객체 저장 서버의 잠금을 획득해야 한다.
또한 리스터에서는 클라이언트와 메타데이터 서버 간의 네트워크 트래픽을 최호화하기 위하여 메타데이터에 대한 요청 시에 메타데이터 접근 의도를 같이 전달하는 인텐트(intent)기반 잠금 프로토콜을 사용한다. 따라서 메타데이터 서버는 메타데이터 접근 의도에 따라 해당 동작을 후생하고, 잠금을 승인하는 처리를 함께 수행함으로써 클라이언트와 메타데이터 서버 간의 네트워크 트래픽을 줄인 수 있다.
클러스터 파일 시스템 비교
구분 GFS 하둡 DFS 리스터
Open Source 지원 지원 지원
Chunk base 지원 지원 지원 안함
Support Replication 지원 지원 지원 안함
Multiple metadata server supported 지원 안함 지원 안함 지원 안함
Locks used to maintain aoomicity 지원 지원 지원
Uses a DB for storing metadata 지원 안함 지원 안함 지원 안함
Adding nodes widthout shutting 지원 지원 지원
down the System.
POSIX support 지원 안함 지원 안함 지원
Supports file modification 지원 안함 지원 안함 지원
(append는 지원함)
2017년 12월 9일 토요일
1.5. 오토 레이아웃(Auto Layout)
아이폰 화면 해당도
아이폰 3gs 320 x 480 pixels
아이폰 4/4s 640 x 960 pixels
아이폰 5/5c/5s 640 x 1136 pixels
아이폰 6 750 x 1334 pixels
아이폰 6+ 1242 x 2208 pixels (1080x1920 다운 샘플링 처리)
어뎁티브 사용자 인터페이스는 향상된 ViewController 기능, 스토리보드, 오토레이아웃(Auto Layout)기능, 동적 텍스트(Dynamic Text) 기능, 사이즈 클래스(Size Classes)
Use Auto Layout 체크상자에 체크되어 있으면 뷰 아래쪽에 오토레이아웃 메뉴가 표시
-3가지 오토 레이아웃 메뉴
Align: 왼쪽, 중앙, 오른쪽에 위치시키는 것과 같은 제약조건 생성
Pin: 뷰의 높이, 상호 간의 거리 등의 제약조건 생성
Resolve Auto Layout lssues : 설정된 제약조건을 처리 혹은, 취소할 때 사용
1.5.1. 컨트롤을 가로, 세로의 중앙에 위치하는 폼 작성
Horizontal Center in Container
Vertical Center in Container
아이폰 3gs 320 x 480 pixels
아이폰 4/4s 640 x 960 pixels
아이폰 5/5c/5s 640 x 1136 pixels
아이폰 6 750 x 1334 pixels
아이폰 6+ 1242 x 2208 pixels (1080x1920 다운 샘플링 처리)
어뎁티브 사용자 인터페이스는 향상된 ViewController 기능, 스토리보드, 오토레이아웃(Auto Layout)기능, 동적 텍스트(Dynamic Text) 기능, 사이즈 클래스(Size Classes)
Use Auto Layout 체크상자에 체크되어 있으면 뷰 아래쪽에 오토레이아웃 메뉴가 표시
-3가지 오토 레이아웃 메뉴
Align: 왼쪽, 중앙, 오른쪽에 위치시키는 것과 같은 제약조건 생성
Pin: 뷰의 높이, 상호 간의 거리 등의 제약조건 생성
Resolve Auto Layout lssues : 설정된 제약조건을 처리 혹은, 취소할 때 사용
1.5.1. 컨트롤을 가로, 세로의 중앙에 위치하는 폼 작성
Horizontal Center in Container
Vertical Center in Container
1.4. 첫 번째 애플리케이션-싱글 뷰 컨트롤러(Single View Controller)
- 일반적으로 Swift 가 아닌 Object-C 에서 작성된 아이폰 애플리케이션은 항상 프로젝트의 Supporting Files 폴더에서 자동으로 생성되는 main.m 파일에서 시작한다.
int main(int argc, char *argv[])
{
@autoreleasepool{
return UIApplicationMain(argv, argv, nil,
NSStringFormClass([AppDelegate class]))
}
}
하지만 Swift 에서는 Object-c 언어의 main.m에 해당하는 main.swift 파일이 존재하지 않는다. 바로 AppDelegate 클래스에서 처리하게 된다.
AppDelegate 클래스를 선언하는 AppDelegate,swift 파일을 보면 다음과 같이 파일 앞쪽에 @UIApplication 서브 클래스를 ㅊ처리하고 이어서 AppDelegate 객체를 생성하게 된다.
import UIKit
@UIApplicationMain
......
즉, 위 코드 하나를 사용하여 UIApplicationMain 함수를 호출하고 이 함수는 다시 내부적으로 UIApplication 객체를 생성하고 AppDelegate 클래스를 호출하게 된다.
AppDelegate 클래스에서는 다음과 같은 func application(application, didFinishLaunchingWithOption) 메소드를 자동으로 호출하는데 이전 xCode 에서는 이메소드에서 스토리 보드 파일의 화면 구성을 처리하였다. 하지만 현재는 단지 "return true"라는 코드가 있을 뿐 다른 아무런 코드가 존재하지 않는다. 그렇다면 어떻게 스토리보드 파일의 화면을 호출 할 수 있을까?
fun application(application: UIApplication, didFinishLauchingWidthOptions
launchOptions: [NSObject: AnyObject]?) -> Bool {
//Override point for customization after application launch.
return true
}
프로그램 탐색기의 Supporting Files 폴더 아래쪽에 있는 Info.plist 파일에서 이 일을 자동으로 처리한다.
-ViewController
import UIKit
class ViewController: UIViewController{
....
@IBOutlet var textField: UITextField!
@IBAction func clickedCompleted(sender: AnyIbject){
......
참고: @IBOutlet 과 @IBAction 키워드
컴파일 코드에 아무런 여향을 주지 않는 컴파일러 지시자이다. 두 개 보두 현재 선언된 객체 변수가 .storyboard 파일에 지정된 객체 컨트롤과 연결되어 있다는 것을 알려준다.
int main(int argc, char *argv[])
{
@autoreleasepool{
return UIApplicationMain(argv, argv, nil,
NSStringFormClass([AppDelegate class]))
}
}
하지만 Swift 에서는 Object-c 언어의 main.m에 해당하는 main.swift 파일이 존재하지 않는다. 바로 AppDelegate 클래스에서 처리하게 된다.
AppDelegate 클래스를 선언하는 AppDelegate,swift 파일을 보면 다음과 같이 파일 앞쪽에 @UIApplication 서브 클래스를 ㅊ처리하고 이어서 AppDelegate 객체를 생성하게 된다.
import UIKit
@UIApplicationMain
......
즉, 위 코드 하나를 사용하여 UIApplicationMain 함수를 호출하고 이 함수는 다시 내부적으로 UIApplication 객체를 생성하고 AppDelegate 클래스를 호출하게 된다.
AppDelegate 클래스에서는 다음과 같은 func application(application, didFinishLaunchingWithOption) 메소드를 자동으로 호출하는데 이전 xCode 에서는 이메소드에서 스토리 보드 파일의 화면 구성을 처리하였다. 하지만 현재는 단지 "return true"라는 코드가 있을 뿐 다른 아무런 코드가 존재하지 않는다. 그렇다면 어떻게 스토리보드 파일의 화면을 호출 할 수 있을까?
fun application(application: UIApplication, didFinishLauchingWidthOptions
launchOptions: [NSObject: AnyObject]?) -> Bool {
//Override point for customization after application launch.
return true
}
프로그램 탐색기의 Supporting Files 폴더 아래쪽에 있는 Info.plist 파일에서 이 일을 자동으로 처리한다.
-ViewController
import UIKit
class ViewController: UIViewController{
....
@IBOutlet var textField: UITextField!
@IBAction func clickedCompleted(sender: AnyIbject){
......
참고: @IBOutlet 과 @IBAction 키워드
컴파일 코드에 아무런 여향을 주지 않는 컴파일러 지시자이다. 두 개 보두 현재 선언된 객체 변수가 .storyboard 파일에 지정된 객체 컨트롤과 연결되어 있다는 것을 알려준다.
1.3. Xcode 시작하기
1.3.1. 프로젝트 생성
1.3.1.1. 프로젝트 APP 종류
Xcode 에서 새로운 프로젝트를 사용하기 위해서 Xcode 의 Create a new Xcode project 항목 선택
Choose a template for your new project: 에서 iOS 탭 선택
-Master-Detail App
리스트 형식의 마스터 화면을 보여주고 마스터 화면 중 하나의 항목을 선택하면 디테일 화면으로 이동하고 해당 항목에 대한 자세한 내용을 보여주는 기능을 제공한다. 여기서 다시 백(back)버튼을 선택하면서 다시 이전 마스터 화면으로 이동한다.
-Page-Based App
전자책에서 사용되는 기본적인 기능을 제공하여 원하는 내용을 화면에 표시한다. 또한, 페이지를 넘기는 애니메이션 기능 혹은, 페이지 화면 이동하는 애니메이션 기능 등을 옵션으로 제공하고 있다.
-Single View App
하나의 ViewController 와 하나의 View 화면을 제공하는 가장 일반적인 기능을 제공.
-Tabbed App
탭 바(Tab Bar) 애플리케이션을 생성하고자 할 때 사용된다. 일반적으로 탭 바는 아래쪽에 위치하는데 탭 바에 여러 버튼이 위치하여 버튼을 누를 때마다 화면이 변경되는 기능을 제공해서 한 번에 여러 화면을 사용하고자 할 때 사용
-Game
애플에서 직접 제공하는 게임 프레임워크를 사용하여 게임을 만들고자 할때 사용
여기서는 Single View App 선택 -> Next 버튼 프로젝트 옵션 화면
1.3.1.2. 프로젝트 속성
- Product Name
애프리케이션 이름
-Organization Name
개발자 속한 조직 이름 즉, 회사 이름 혹은, 학교 이름을 지정한다.
-Organization identifier
현재 애플리케이션을 다른 애플리케이션과 구별하기 위한 유일한 이름을 사용한다.
일반적으로 자신 혹은, 회사의 웹사이트 URL 에서 www 를 뺀 이름의 역순으로 표기한다.
-Language
사용하고자 하는 언어(Object-c, Swift)
-Devices
개발하고자 하는 기기이름
아이폰 앱만 개발하고자 한다면 iPhone, 아이패드 앱만 개발하고자 한다면 iPad, 아이폰, 아이패드 둘 모두를 지원하고자 한다면 Universal 을 선택한다.
FirstApp이라는 프로젝트 이름 입력 하고 Language 에는 Swift, Devices 에는 iPhone을 선택한다.
1.3.2. 파일 추가
FirstApp 에서 New File 생성
iOS-Source를 선택 오른쪽의 CoCoa Touch Class 를 선택
이름을 SecondViewController 이름 지정
두 번째 Subclass of 항목은 생성하고자 하는 클래스의 부모클래스를 지정한다.
가운데 위치한 Also create XIB file 체크상자에는 체크하지 않느다.
이 체크상자는 아이폰 앱의 사용자 인터페이스를 담당하는 .xib 파일을 생성하는 기능인데 여기서는 .xib 파일 기능과 비븟한 스토리보드를 사용할 것이므로 체크하지 않도록 한다.
마지막으로 Language 항목에 Swift를 지정하여 Swift 언어를 사용하도록 설정한다.
1.3.3. Xcode 에디터와 에디터 보조 기능 창 표시
에디터는 Xcode의 중앙에 위치하며 항상 나타난다. Xcode 오른쪽 위에 위치한 에디터 선택기는 왼쪽에서 오른쪽으로 표준 에디터, 도움에디터, 버젼 에디터를 선택할 수 있도록 해주고 이어서 왼쪽 탐색기 지역 표시/숨기기, 아래쪽 디버거 지역 표시/숨기기, 오른쪽 유틸리티 지역 표시/숨기기를 처리할 수 있는 버튼 제공.
표준에디터: 일반적으로 소스 코드를 편집할 수 있는 1개의 원도우를 가진 에디터
도움에디터: 2개 원도우를 가진 에디터, 서로 비교하거나 2개의 소스코드를 동시에 작업하거나 스토리보드에서 자동으로 객체 변수를 생성할 때 사용.
버젼 에디터: 동일한 파일을 버전에 따라 2개의 원도우에 각각로드하여 이 파일이 어떤 과정으로 변경되었느닞 그 수정 기록 보관
탐색기 지역: 누를 때마다 왼쪽 탐색기 지역을 표시하거나 숨김
디버거 지역: 누를 때마다 아래쪽 디버거 지여긍ㄹ 표시하거나 숨김
유틸리티 지역: 누를 때마다 오른쪽 유틸리티 지역을 표시하거나 숨김
1.3.4. 스토리보드 파일 및 xib 파일
Xcode 프로젝트 탐색깅는 소스코드 외에 .xib 파일이나 .storyboard 라는 파일을 제공
.xib 파일은 Xcode 초기 때부터 이러한 인터페이스를 담당하여 화면 처리에 사용
Xcode 5.x부터는 기능이 더 확장된 스토리보드 파일(.storyboard)을 사용하여 거의 모든 인터페이스를 담당하고 있다.
프로텍트 탐색기에서 스토리보드 파일을 선택했을 때 도움말, 인스펙터, 라이브러리 등을 제고하는 유틸리티 지역을 사용할 수 있다. 캔버스의 여러 컨트롤을 관할 수 있는 인스펙터(inspector)는 오른쪽 위에 위치하고 여러 컨트롤을 제공하는 라이브러리는 오른쪽 아래에 나타난다.
인스펙터는 그 인스펙터 패인(inspector Pane)위에 위치한 인스펙터 선택 바(inspector Selector Bar)를 사용하여 원하는 인스펙터를 표시할 수 있고 라이브러리 역시 라이브러리 패인(Library Pane)위쪽에 위치한 라이브러리 선택 바(Libary Selector Bar)를 사용하여원하는 라이브러리를 선택할 수 있다.
1.3.4.1. 인스펙터(Inspector)
인스펙터(Inspector)는 주로 캔버스에 위치된 컨트롤과 실제 코드 사이를 연결시키는 기능을 하는데 왼쪽에서 오른쪽으로 File 인스펙터, Quick Help 인스펙터, Identity 인스펙터, Attributes 인스펙터, Size 인스펙터, Connection 인스펙터 등의 위치한다.
File 인스펙터: 프로젝트에서 사용 중인 파일에 대한 이름, 타입, 위치, 인코딩 방법 등을 가지고 있는 메타 파일을 관리한다.
Quick Help 인스펙터: 핸재 소스 안에서 선택된 변수 혹은, 메소드에 대한 설명 혹은, 그 변수, 메소드가 있는 파일 정보를 보여준다.
Identity 인스펙터: 클래스 이름, 참조 정보, 런타임 속성, 라벨 등에 대한 메타 정보를 보여주거나 관리해 준다. 기존 클래스 대신 별도의 클래스로 대치시킬 때 사용된다.
Attributes 인스펙터: 선택된 객체에 대한 속성 즉, 특성화된 기능을 보여주거나 설정할 수 있다.
Size 인스펙터: 선택된 객체애 대한 초기 크기, 위치, 최소 크기, 최대 크기에 대한 정보를 보여주거나 설정 할 수 있다.
Connections 인스펙터: 선택한 객체와 실제 코드 사이를 연결하여 객체 초기화를 자동으로 처리해 준다.
1.3.4.2. 라이브러리
라이브러리는 파일 템플릿 라이브러리(File Template Library), 코드 스니핏 라이브러리(Code Snippet Library), 오브젝트 라이브러리(Object Library), 미디어 라이브러리(Media Library) 등이 있다.
파일 템플릿 라이브러리: Object-c 클래스, C++ 클래스, 헤더 파일, Swift 파일 등 원하는 파일 형태를 생성하고자 할 때 사용
코드 스니핏 라이브러리: 인라인 블록, try/catch 문장 등 원하는 형태의 코드 블록을 자동으로 생성하고자 할때 사용
오브젝트 라이브러리: 버튼(Button), 라벨(Label), 텍스트 필드(Text Field)등 사용자 확면을 자성하고자 할 때 사용.
미디어 라이브러리: 현재 프로젝트에서 사용되는 그림, 아이콘과 같은 리소스 파일을 관리
오브젝트 라이브러리 컨트롤
Label: 글자를 출력할 때 주로 사용
Button: 버튼 생성 컨트롤
Text Field : 텍스트를 입력할 수 있는 상자 컨트롤
Slider: 볼륨과 같이 정해진 크기 안에서 임의의 수만큼 지정할 때 사용 되는 컨트롤
Switch: On/Off 처리할 수 있는 컨트롤
Progress View: 시간이 걸리는 경우 현재 진행 상항을 표시할 수 있는 컨트롤
Page Control: 마치 책의 페이지를 넘기듯이 다음 페이지 혹은, 이전 페이지로 이동할 수 있는 컨트롤
Stepper: 숫자를 증가시키거나 감소시킬 수 있는 컨트롤
Table View: 많은 자룔를 일렬로 표시하여 정리할 수 있는 컨트롤
Map View :지도를 표시할 수 있는 컨트롤
Text View: 텍스트 문자열을 표시할 수 있는 컨트롤
Image View: 이미지 파일(jpg, png)을 표시할 수 있는 컨트롤
Scroll View: 데이터양이 현재 뷰 크기보다 클 경우 스크롤 바를 사용하여 좌, 우 혹은, 위, 아래로 이동할 수 있는 컨트롤
Picker View: 날짜, 혹은, 숫자를 선택할 때 사용되는 컨트롤
1.3.5. 도큐먼트 아웃라인(Document Outline)창
.Storyboard 파일을 선택했을 때 캔버스 왼쪽에 나타나는 창. 현재 스토리보드가 구성되어 있는 컨트롤 구조를 계층화 형태로 노출.
1.3.1.1. 프로젝트 APP 종류
Xcode 에서 새로운 프로젝트를 사용하기 위해서 Xcode 의 Create a new Xcode project 항목 선택
Choose a template for your new project: 에서 iOS 탭 선택
-Master-Detail App
리스트 형식의 마스터 화면을 보여주고 마스터 화면 중 하나의 항목을 선택하면 디테일 화면으로 이동하고 해당 항목에 대한 자세한 내용을 보여주는 기능을 제공한다. 여기서 다시 백(back)버튼을 선택하면서 다시 이전 마스터 화면으로 이동한다.
-Page-Based App
전자책에서 사용되는 기본적인 기능을 제공하여 원하는 내용을 화면에 표시한다. 또한, 페이지를 넘기는 애니메이션 기능 혹은, 페이지 화면 이동하는 애니메이션 기능 등을 옵션으로 제공하고 있다.
-Single View App
하나의 ViewController 와 하나의 View 화면을 제공하는 가장 일반적인 기능을 제공.
-Tabbed App
탭 바(Tab Bar) 애플리케이션을 생성하고자 할 때 사용된다. 일반적으로 탭 바는 아래쪽에 위치하는데 탭 바에 여러 버튼이 위치하여 버튼을 누를 때마다 화면이 변경되는 기능을 제공해서 한 번에 여러 화면을 사용하고자 할 때 사용
-Game
애플에서 직접 제공하는 게임 프레임워크를 사용하여 게임을 만들고자 할때 사용
여기서는 Single View App 선택 -> Next 버튼 프로젝트 옵션 화면
1.3.1.2. 프로젝트 속성
- Product Name
애프리케이션 이름
-Organization Name
개발자 속한 조직 이름 즉, 회사 이름 혹은, 학교 이름을 지정한다.
-Organization identifier
현재 애플리케이션을 다른 애플리케이션과 구별하기 위한 유일한 이름을 사용한다.
일반적으로 자신 혹은, 회사의 웹사이트 URL 에서 www 를 뺀 이름의 역순으로 표기한다.
-Language
사용하고자 하는 언어(Object-c, Swift)
-Devices
개발하고자 하는 기기이름
아이폰 앱만 개발하고자 한다면 iPhone, 아이패드 앱만 개발하고자 한다면 iPad, 아이폰, 아이패드 둘 모두를 지원하고자 한다면 Universal 을 선택한다.
FirstApp이라는 프로젝트 이름 입력 하고 Language 에는 Swift, Devices 에는 iPhone을 선택한다.
1.3.2. 파일 추가
FirstApp 에서 New File 생성
iOS-Source를 선택 오른쪽의 CoCoa Touch Class 를 선택
이름을 SecondViewController 이름 지정
두 번째 Subclass of 항목은 생성하고자 하는 클래스의 부모클래스를 지정한다.
가운데 위치한 Also create XIB file 체크상자에는 체크하지 않느다.
이 체크상자는 아이폰 앱의 사용자 인터페이스를 담당하는 .xib 파일을 생성하는 기능인데 여기서는 .xib 파일 기능과 비븟한 스토리보드를 사용할 것이므로 체크하지 않도록 한다.
마지막으로 Language 항목에 Swift를 지정하여 Swift 언어를 사용하도록 설정한다.
1.3.3. Xcode 에디터와 에디터 보조 기능 창 표시
에디터는 Xcode의 중앙에 위치하며 항상 나타난다. Xcode 오른쪽 위에 위치한 에디터 선택기는 왼쪽에서 오른쪽으로 표준 에디터, 도움에디터, 버젼 에디터를 선택할 수 있도록 해주고 이어서 왼쪽 탐색기 지역 표시/숨기기, 아래쪽 디버거 지역 표시/숨기기, 오른쪽 유틸리티 지역 표시/숨기기를 처리할 수 있는 버튼 제공.
표준에디터: 일반적으로 소스 코드를 편집할 수 있는 1개의 원도우를 가진 에디터
도움에디터: 2개 원도우를 가진 에디터, 서로 비교하거나 2개의 소스코드를 동시에 작업하거나 스토리보드에서 자동으로 객체 변수를 생성할 때 사용.
버젼 에디터: 동일한 파일을 버전에 따라 2개의 원도우에 각각로드하여 이 파일이 어떤 과정으로 변경되었느닞 그 수정 기록 보관
탐색기 지역: 누를 때마다 왼쪽 탐색기 지역을 표시하거나 숨김
디버거 지역: 누를 때마다 아래쪽 디버거 지여긍ㄹ 표시하거나 숨김
유틸리티 지역: 누를 때마다 오른쪽 유틸리티 지역을 표시하거나 숨김
1.3.4. 스토리보드 파일 및 xib 파일
Xcode 프로젝트 탐색깅는 소스코드 외에 .xib 파일이나 .storyboard 라는 파일을 제공
.xib 파일은 Xcode 초기 때부터 이러한 인터페이스를 담당하여 화면 처리에 사용
Xcode 5.x부터는 기능이 더 확장된 스토리보드 파일(.storyboard)을 사용하여 거의 모든 인터페이스를 담당하고 있다.
프로텍트 탐색기에서 스토리보드 파일을 선택했을 때 도움말, 인스펙터, 라이브러리 등을 제고하는 유틸리티 지역을 사용할 수 있다. 캔버스의 여러 컨트롤을 관할 수 있는 인스펙터(inspector)는 오른쪽 위에 위치하고 여러 컨트롤을 제공하는 라이브러리는 오른쪽 아래에 나타난다.
인스펙터는 그 인스펙터 패인(inspector Pane)위에 위치한 인스펙터 선택 바(inspector Selector Bar)를 사용하여 원하는 인스펙터를 표시할 수 있고 라이브러리 역시 라이브러리 패인(Library Pane)위쪽에 위치한 라이브러리 선택 바(Libary Selector Bar)를 사용하여원하는 라이브러리를 선택할 수 있다.
1.3.4.1. 인스펙터(Inspector)
인스펙터(Inspector)는 주로 캔버스에 위치된 컨트롤과 실제 코드 사이를 연결시키는 기능을 하는데 왼쪽에서 오른쪽으로 File 인스펙터, Quick Help 인스펙터, Identity 인스펙터, Attributes 인스펙터, Size 인스펙터, Connection 인스펙터 등의 위치한다.
File 인스펙터: 프로젝트에서 사용 중인 파일에 대한 이름, 타입, 위치, 인코딩 방법 등을 가지고 있는 메타 파일을 관리한다.
Quick Help 인스펙터: 핸재 소스 안에서 선택된 변수 혹은, 메소드에 대한 설명 혹은, 그 변수, 메소드가 있는 파일 정보를 보여준다.
Identity 인스펙터: 클래스 이름, 참조 정보, 런타임 속성, 라벨 등에 대한 메타 정보를 보여주거나 관리해 준다. 기존 클래스 대신 별도의 클래스로 대치시킬 때 사용된다.
Attributes 인스펙터: 선택된 객체에 대한 속성 즉, 특성화된 기능을 보여주거나 설정할 수 있다.
Size 인스펙터: 선택된 객체애 대한 초기 크기, 위치, 최소 크기, 최대 크기에 대한 정보를 보여주거나 설정 할 수 있다.
Connections 인스펙터: 선택한 객체와 실제 코드 사이를 연결하여 객체 초기화를 자동으로 처리해 준다.
1.3.4.2. 라이브러리
라이브러리는 파일 템플릿 라이브러리(File Template Library), 코드 스니핏 라이브러리(Code Snippet Library), 오브젝트 라이브러리(Object Library), 미디어 라이브러리(Media Library) 등이 있다.
파일 템플릿 라이브러리: Object-c 클래스, C++ 클래스, 헤더 파일, Swift 파일 등 원하는 파일 형태를 생성하고자 할 때 사용
코드 스니핏 라이브러리: 인라인 블록, try/catch 문장 등 원하는 형태의 코드 블록을 자동으로 생성하고자 할때 사용
오브젝트 라이브러리: 버튼(Button), 라벨(Label), 텍스트 필드(Text Field)등 사용자 확면을 자성하고자 할 때 사용.
미디어 라이브러리: 현재 프로젝트에서 사용되는 그림, 아이콘과 같은 리소스 파일을 관리
오브젝트 라이브러리 컨트롤
Label: 글자를 출력할 때 주로 사용
Button: 버튼 생성 컨트롤
Text Field : 텍스트를 입력할 수 있는 상자 컨트롤
Slider: 볼륨과 같이 정해진 크기 안에서 임의의 수만큼 지정할 때 사용 되는 컨트롤
Switch: On/Off 처리할 수 있는 컨트롤
Progress View: 시간이 걸리는 경우 현재 진행 상항을 표시할 수 있는 컨트롤
Page Control: 마치 책의 페이지를 넘기듯이 다음 페이지 혹은, 이전 페이지로 이동할 수 있는 컨트롤
Stepper: 숫자를 증가시키거나 감소시킬 수 있는 컨트롤
Table View: 많은 자룔를 일렬로 표시하여 정리할 수 있는 컨트롤
Map View :지도를 표시할 수 있는 컨트롤
Text View: 텍스트 문자열을 표시할 수 있는 컨트롤
Image View: 이미지 파일(jpg, png)을 표시할 수 있는 컨트롤
Scroll View: 데이터양이 현재 뷰 크기보다 클 경우 스크롤 바를 사용하여 좌, 우 혹은, 위, 아래로 이동할 수 있는 컨트롤
Picker View: 날짜, 혹은, 숫자를 선택할 때 사용되는 컨트롤
1.3.5. 도큐먼트 아웃라인(Document Outline)창
.Storyboard 파일을 선택했을 때 캔버스 왼쪽에 나타나는 창. 현재 스토리보드가 구성되어 있는 컨트롤 구조를 계층화 형태로 노출.
2017년 11월 29일 수요일
데이터 연계 및 통합 기법 요약
1. 데이터 연계 및 통합 유형(동기화 기준)
데이터 연계 및 통합 시 일괄(Batch)작업 또는 비동기식 근접 실시간(Near Real Time)또는 동기식 실시간(Real Time) 방식의 혼요.사용될 수 있다.
일괄 작업 :
- 비실시간 데이터 통합
- 대용량 데이터 대상
- 높은 데이터 조작 복잡성
- 데이터 추출
- 데이터 변형
- 데이터 적재
- CDC(Change data capture)
- 감사 증적
- 웹 서비스/SOA
- 교차 참조
- 데이터 재 처리 허용
- 점대점 데이터 연계
- 자도화 도구 및 자체 개발 SW 혼용
비동기식 실시간 통합
- 근접 실시간(Near Real Time)데이터 통합
- 중간 용량 데이터
- 중간 데이터 조작 복잡성
- 데이터 추출.변형.적재
- CDC(Change data capture)
- Data pooling and DB Streams
- 웹 서비스/SOA
- 감사 증적(audit trail)
- 교차 참조
- 다수 데이터 원천 및 목표 시스템
- 데이터 재 처리 허용
- 자동화 도구 및 자체 개발 SW 혼용
동기식 실시간 통합
- 실시간(Real Time)데이터 통합
- 목표 시스템 데이터 처리 가능시에만 원천 데이터 획득
- 데이터 추출.변형.적재
- 웹 서비스/SOA
- Single transaction integrations
- 단일 트랜잭션 단위 데이터 통합
- 데이터 재처리 불가
- 단일 또는 다수 데이터 원천
- 감사 증적
데이터 연계 및 통합 시 일괄(Batch)작업 또는 비동기식 근접 실시간(Near Real Time)또는 동기식 실시간(Real Time) 방식의 혼요.사용될 수 있다.
일괄 작업 :
- 비실시간 데이터 통합
- 대용량 데이터 대상
- 높은 데이터 조작 복잡성
- 데이터 추출
- 데이터 변형
- 데이터 적재
- CDC(Change data capture)
- 감사 증적
- 웹 서비스/SOA
- 교차 참조
- 데이터 재 처리 허용
- 점대점 데이터 연계
- 자도화 도구 및 자체 개발 SW 혼용
비동기식 실시간 통합
- 근접 실시간(Near Real Time)데이터 통합
- 중간 용량 데이터
- 중간 데이터 조작 복잡성
- 데이터 추출.변형.적재
- CDC(Change data capture)
- Data pooling and DB Streams
- 웹 서비스/SOA
- 감사 증적(audit trail)
- 교차 참조
- 다수 데이터 원천 및 목표 시스템
- 데이터 재 처리 허용
- 자동화 도구 및 자체 개발 SW 혼용
동기식 실시간 통합
- 실시간(Real Time)데이터 통합
- 목표 시스템 데이터 처리 가능시에만 원천 데이터 획득
- 데이터 추출.변형.적재
- 웹 서비스/SOA
- Single transaction integrations
- 단일 트랜잭션 단위 데이터 통합
- 데이터 재처리 불가
- 단일 또는 다수 데이터 원천
- 감사 증적
EAI(Enterprise Application Integration)
1. EAI 개요
EAI(Enterprise Application Integration)는 기업 정보 시스템들의 데이터를 연계.통합하는 소프트웨어 및 정보 시스템 아키텍처 프레임워로서, 기업 또는 기업 간 복수의 이질적 정보 시스템들의 데이터를 연계함으로써 상호 융화 내지 동기화돼 동작하도록 한다.
2. EAI 구현 유형
가. Mediation(intra-communication)
EAI 엔진의 중개자(Broker)로 동작하며, 틀정 정보 시스템 내 데이터 신규 생성 또는 갱신.신규 트랜잭션 완료(Commit)등 유의미한 이벤트 발생을 식별해, 사전 약속된 정보 시스템들에게 그 내용(데이터)을 전달 한다. Publish/subscribe Model
나. Federation(inter-communication)
EAI 엔진이 외부(고객 또는 파트너)정보 시스템으로부터의 데이터 요청들을 일괄적으로 수령해 필요한 데이터를 전달한다.
3. EAI 기대 효과
- 향후 정보 시스템 개발 및 유지 보수비용 절감 도모
- 기업 업무 정보 시스템들의 지속적 발전 기반 확보
- 협력사.파트너.고객과의 상호 협력 프로세스 연계 발전 기반 확보
-웹 서비스 등 인터넷 비즈니스를 위한 기본 토대
EAI(Enterprise Application Integration)는 기업 정보 시스템들의 데이터를 연계.통합하는 소프트웨어 및 정보 시스템 아키텍처 프레임워로서, 기업 또는 기업 간 복수의 이질적 정보 시스템들의 데이터를 연계함으로써 상호 융화 내지 동기화돼 동작하도록 한다.
2. EAI 구현 유형
가. Mediation(intra-communication)
EAI 엔진의 중개자(Broker)로 동작하며, 틀정 정보 시스템 내 데이터 신규 생성 또는 갱신.신규 트랜잭션 완료(Commit)등 유의미한 이벤트 발생을 식별해, 사전 약속된 정보 시스템들에게 그 내용(데이터)을 전달 한다. Publish/subscribe Model
나. Federation(inter-communication)
EAI 엔진이 외부(고객 또는 파트너)정보 시스템으로부터의 데이터 요청들을 일괄적으로 수령해 필요한 데이터를 전달한다.
3. EAI 기대 효과
- 향후 정보 시스템 개발 및 유지 보수비용 절감 도모
- 기업 업무 정보 시스템들의 지속적 발전 기반 확보
- 협력사.파트너.고객과의 상호 협력 프로세스 연계 발전 기반 확보
-웹 서비스 등 인터넷 비즈니스를 위한 기본 토대
피드 구독하기:
글 (Atom)