반응형

1. L2 스위치

- L2 스위치는 가장 흔하게 볼 수 있는 스위칭 방식으로 다른 방식의 스위치에 비해 가격이 저렴하다.

- L2 주소는 MAC 주소를 뜻한다. 즉 L2 스위치의 역할은 MAC 주소를 읽어 스위칭을 하고, 이것을 어떤 포트로 보낼 것인지 스위칭하는 장비를 말한다.

- 스위치는 MAC 테이블을 가지고 있어서 이것을 기준으로 패킷을 해당 포트로 전달한다.

- 하지만 라우팅이 불가능 하며, 상위 레이어 프로토콜을 이용한 스위칭이 불가능하다.

 

2. L3 스위치(라우팅)

- L3 스위치는 IP 또는 IPX ㅈ소를 읽어서 스위칭을 한다. 

- 네트워크상에 흘러가는 패킷이 들어오면 L3 스위치는 목적이 IP 주소를 보고 적절한 포트로 패킷을 전송(라우팅) 한다.

- 즉  A라는 IP는 어느 방향으로 가고 B는 IP는 어느 방향으로 가게 하는 라우팅을 할 수 있다. 

 

3. L4 스위치

- L4 스위치는 TCP/UDP 프로토콜에서 스위칭을 수행하므로 TCP와 UDP의 포트를 보고 적절한 서버로 패킷을 전송한다.

- 즉, L4 주소는 포트번호를 뜻하며 여기서 포트번호는 웹 80, ftp는 20/21번, 텔넷은 23번 이런 것을 뜻한다.

- 그리고 똑같은 IP에 대하여 포트번호가 다를 경우 다른 서버로 보낼 수 있다.

- 이런식으로 하나의 IP이지만, L4주소(포트번호) 별로 따로따로 분배하여 보낼 수 있다.

- 또한 L4 스위치는 로드밸런싱 기능이 지원된다. L4 장비의 VIP(Virtual IP)를 통해, 요청받은 작업을 여러 개의 서버로 분산시킬 수 있다. 

- 그리고 Failover 기능이 지원된다. 한 대의 서버가 VIP를 통해 서비스를 하다가, 어떤 이유로 서비스가 중단되면 자동으로 다른 서버가 같은 역할을 수행한다.

 

4. L7 스위치

- L7은 어플리케이션 영역이다.

- L7 스위치는 L4가 가지고 있는 문제점들을 해결하기 위해 패킷의 IP, PORT 정보뿐만 아니라 패킷의 URL 정보, 쿠키, 플레이 로드 정보 등을 종합적으로 검사하여 사용자별로 연속적이고 차별화된 서비스를 제공할 수 있다. 

- L4 스위치의 문제점: VoIP나 P2P와 같은 어플리케이션에 대해 다양한 형태의 패킷 내용을 살펴보기 어렵고 사용자의 IP가 수시로 변경되는 경우 해당 사용자에 대한 연속적인 서비스를 제공하기 어렵다.

- L7 스위치는 L4 스위치가 갖고 있는 기능들을 모두 수용하면서, 불필요한 트래픽에 대한 차단이나 네트워크에 대한 공격을 완화시켜 준다.

- 높은 레이어 스위치가 가격이 비싸고 각각의 스위치는 자기보다 낮은 레이어 스위치 기능까지 다 할 수 있다. 즉 L7 스위치가 L4, L3, L2 기능을 다 할 수 있다. 

반응형

'Tech > Software' 카테고리의 다른 글

Google Cloud Essential Workshop  (0) 2019.09.03
EJB, JTA, XA, JMS  (0) 2019.03.09
java jvm core dump  (1) 2018.12.30
sorting algorithm  (0) 2018.12.13
HTTP Status Code List  (0) 2018.12.13
반응형

2019-09-03(화요일)

 

 

 

[Key Word]

Titan : 

Project Zero: 하드웨어 밴더를 믿지 않는다. 하드웨어단에서 새로 점검

DLP: Data Loss Prevention(DLP) API: 들어오는 데이터에서 PID나 카드번호 같은 것들을 자동적으로 마스킹하거나 암호화함

    - 카드번호와 유사한지 폰넘버와 유사한지 확률적으로 알아내서 안전하게 보관함

Access Transparency

    - 내가 학습시킨 데이터를 구글이 가져다 쓰지 않을까?

    - 유저 데이터는 청크 단위로 암호화 저장되어 구글은 확인 할 수 없음

pricing

    - sustained use discounts: 2주부터는 쓰면 쓸수록 할인됨

custom machine type을 제공: 사용량에 따라 타입을 사용자가 정할 수 있음

    - 5일 정도 사용하면 자동으로 추천을 해줌

preemptible VMs: 80%할인된 가격으로 제공, 대신에 24시간 뒤에는 자동으로 내려감

[big query demo]

- https://bigquery.cloud.google.com 

[network]

- google edge pod 에서 2홉만에 목적지 DC까지 감(vs 15 홉 정도 소요)

[cloud IAM]

https://

GSP002

Qwiklabs

[compute engine]

- NW: 2Gbps per core, 16Gbps per VM

- Live Migration: 서버 점검시 무정지 상태로 다른 물리머신으로 이동 시킨후 점검

정기 점검으로 인한 다운 타임이 없음(3~4ms 정도 튐, 인지 못함, 수동 트리거 시킬 수 있음)

- Sole Tenancy: Bare metal은 아님, dedicated된 resource 사용을 보장함

- limit: vcpu:up to 96, GPU: upto 8, RAM: up to 624GB, HDD/SDD: upto 16, 64TB total,  local ssd: 375GB each, upto 3TB 

%azure, google은 kvm(kernel based virtual machine)으로 구성, AWS는 zen based vm --> kvm으로 옮겨갈 예정

- persistent disks

    - regional disk: zone 이 공동사용할 수 있는 disk생성 가능, DB HA 구성에 사용, 한쪽은 rw, 한쪽은 read (linux disk io 제약사항)

- disk 스로틀링 없어서 disk에 할당된 io capa 모두 사용할 수 있음

- vpc 베이스로 방화벽 설정함

[virtual private cloud network]

- 단일 anycast IP를 사용한 글로벌 부하 분산기

- 서브넷은 지역(region) 단위로 구축 가능

- 소프트웨어 정의 라우터

- 쉽게 네트워크 공유 및 피어링(peering) 가능

- 유연한 방화벽 규칙

- 프로젝트당 글로벌 네트워크 최대 5개

- pre-warming 필요없음(하드웨어 대역폭을 바로 사용가능)

- VPN: 

- Interconnect(Direct connect)

- Direct Peering

- Shared VPC: Cross Project Network

   - 여러개의 프로젝트를 같은 네트워크로 통합 가능

   - 프로젝트별로 과금, 사용량 통제 가능

- 역할 분할 가능 (운영부서: {네트워크 정의, 방화벽 통제, 로드밸런서 설정, 라우팅 경로 설정}, 각서비스 개발팀:{VM 생성, 오토스케일링}

- VPC당 15000개 vm limit

- Global load balancing: single VIP, Global Reach

 

 

반응형

'Tech > Software' 카테고리의 다른 글

스위치 구분(L2, L3, L4, L7)  (0) 2019.09.03
EJB, JTA, XA, JMS  (0) 2019.03.09
java jvm core dump  (1) 2018.12.30
sorting algorithm  (0) 2018.12.13
HTTP Status Code List  (0) 2018.12.13
반응형

EJB: Enterprise JavaBeans, 기업환경의 시스템을 구현하기 위한 서버측 컴포넌트 모델이다. 즉, EJB는 어플리케이션의 업무 로직을 가지공 있는 서버 어플리케이션이다. EJB 사양은 Java EE의 자바 API중 하나로, 주로 웹 시스템에서 JSP는 화면 로직을 처리하고, EJB는 업무 로직을 처리하는 역할을 한다. 

EJB는 다음 3가지 종류가 있다. 

- 세션 빈(Session Bean): DB연동이 필요 없음

- 엔티티 빈(Entity Bean): 

  - 데이터베이스의 데이터를 관리하는 객체

  - Insert(삽입), Update(수정), Delete(삭제), Select(조회)

  - DB관련 쿼리는 자동으로 만들어지고 개발자는 고급 업무 처리에 집중할 수 있음

  - DB가 수정되면 코드 수정 없이 다시 배포(설정 문서 만들어서 복사)

- 메시지 구동 빈(Message-drive Bean): JMS로 빈을 날려줌


JTA: JAVA Transaction API,  플랫폼마다 상이한 트랜잭션 매니저들과 어플리케이션들이 상호작용할 수 있는 인터페이스를 정의하고 있다. JAVA에서 제공되는 대부분의 API와 마찬가지로, JTA는 실제 구현은 다르지만 어플리케이션이 공통적으로 사용할 수 있는 하나의 인터페이스를 제공한다. 이 말은 트랜잭션 처리가 필요한 어플리케이션이(API의 사용 방식 그대로만 사용한다면) 특정 벤더의 트랜잭션 매니저에 의존할 필요가 없음을 의미한다. Atomikos와 같이 JTA 구현체들을 오픈소스로 제공하는 벤더들도 있고, IBM 같이 JTA 구현체를 어플리케이션 서버의 한 부분으로 제공하는 벤더들도 있다. 

JTA의 구현체를 사용할 때에는 주의를 기울여야 한다. 자세히 들여다 보면 뭔가 잘 못 되어 있는 것처럼 보이기 때문이다. 믿기 어렵겠지만 J2EE 호환됨'이라고 검증을 받은 어플리케이션 서버들도 트랜잭션 관리를 제대로 지원하지 않거나 가상적으로만 지원할 수도 있다. 


XA: eXtended Architecture, 동일한 전역 트랜잭션(Global Transaction)내에서 몇 개의 백엔드 데이터 저장소에 접근하기 위한 X/Open 그룹 표준의 하나이다. XA표준 규격은 하나의 트랜잭션 매니저가 어떤 트랜잭션의 한 부분으로 어떤 작업이 수행되고 있는지를 데이터베이스에 통보하는 방식과, 각 트랜잭션이 완료될 때 2단계 커밋(2 Phase Commit)을 수행되는 방식을 관장한다. 또 데이터 저장소에서 지연되고 있는 트랜잭션을 회복시키는 방법도 포함하고 있다. 

XA의 장점: XA 역시 하나의 표준이기 때문에, 모든 호환되는 데이터 저장소(혹은 드라이버)들이 전역(분산) 트랜잭션의 부분으로서의 트랜잭션 매니저와 연동할 수 있다. 다른 말로, 2단계 커밋이 고려되어야 하는 상황이라면 XA는 트랜잭션 매니저와 데이터 저장소를 연결해 주는 역할을 담당한다는 말이다. 이것이 Atomikos와 같은 솔루션들이 Oracle이나 Sysbase와 같은 데이터베이스와 연동하여 커밋과 롤백 등의 모든 작업을 수행할 수 있는 이유이다. 


JMS: 자바 메시지 서비스(Java Message Service; JMS)는 자바 프로그램이 네트워크를 통해 데이터를 송수신하는 자바 API이다.

자바 메시지 서비스는 API는 두 개 혹은 그 이상의 클라이언트 간 메시지 통신을 위한 자바 메시지 기반 미들웨어 API( 자바 메시지 지향 미들웨어(MOM) API)이다. JMS는 자바 플랫폼, 엔터프라이즈 에디션에 포함되어 있으며, 자바커뮤니티 프로세스의 JSR 914로 개발된 명세서에 의해 정의된다. 자바 메시지 서비스는 자바 플랫폼, 엔터프라이즈 에디션에 기반을 둔 애플리케이션 컴포넌트들끼리 메시지를 생성, 송/수신, 읽기 기능을 제공하는 메시징 표준이다. 분산된 애플리케이션끼리 느슨하게 연결해주고 신뢰성을 보장하며, 비동기 처리가 가능하도록 해준다.

반응형

'Tech > Software' 카테고리의 다른 글

스위치 구분(L2, L3, L4, L7)  (0) 2019.09.03
Google Cloud Essential Workshop  (0) 2019.09.03
java jvm core dump  (1) 2018.12.30
sorting algorithm  (0) 2018.12.13
HTTP Status Code List  (0) 2018.12.13
반응형

Core dump

- 리눅스에서 gcore라는 명령어를 사용해서 코어 덤프를 남길 수 있다. 

- JVM은 hs_err_pid.log라는 파일을 남기고 죽는다. 

- java에서 1GB의 메모리를 사용하면 코어 덤프는 수십기가에 달하는 파일을 생성한다. 

- 아무 근거 없이 죽었다면 kill -9 <pid>로 죽었거나 segfault와 같이 프로세스 내의 오류로 죽은 경우

    --> /var/log messages 로그를 봐야한다. 

- JVM에서 Thread Dump는 현재 수행중인 쓰레드에 대한 호출 경로 StackTrace를 보기 위한 것이고 Heap Dump는 현재 Heap에서 점유되고 있는 객체들에 대한 조사를 위하여 필요한 내역


1. 코어덤프 자동으로 생성하게 만들기

- ulimit -a 명령어로 서버 설정을 확인한다. 

- core file size (blocks, -c) 0 <-- 이처름 0이면 core dump는 안남는다. 

- ulimit -c unlimited <-- core dump를 남기도록 변경


2. Core dump 분석하기

- gdb 프로그램 사용하면

- gdb / 자바실행파일 Full path /java core.pid <-- 실행

- 인터프리터 방식으로 이 툴을 사용할 수 있다. 


3. 명령어

- bt

- info thread

- thread 쓰레드번호

- where

- x/i 메모리 주소값


[Thread dump]

4. 기타

- jstack / 자바실행파일 fullpath/java core.pid <-- core dump에서 쓰레드 덤프를 추출해준다. 

- jmap <-- core dump에서 힙 덤프를 만들 수 있다. 


5. Thread dump

- 명령: kill - 3 <pid>

- <pid>: jvm의 process Id


6. JVM 스레드 덤프 가져오는 방법

- 스레드 덤프를 2개 이상 가져오는 것이 좋다.

- 정기적으로 10개의 스레드 덤프를 가져오는 것이 좋다. 


6-1 1단계 JAVA 프로세스에서 PID가져오기

- jps -l 70660 sun.tools.jps.Jps 70305

- Linux및 Unix에서 이 명령을 sudo -u user jps -l로 실행해야 할 수 있습니다. 여기서 user는 java 프로세스에서 실행중인 사용자의 사용자 이름임

- ps -el |grep java


6-2 JVM에서 스레드 덤프 요청

- jstack -l <pid>

- 콘솔 출력 리디렉션을 사용하여 파일로 연속 스레드 덤프를 출력하거나 지시문을 첨부할 수 있음

  --> jstack -l <pic> >> threaddumps.log

     --> sudo -u <java-user> jstack -l <pid>

- Xrs jvm 매개 변수가 활성화되어 있어도 jstack이 작동함

- sudo -u <java-user> jstack -l <pid>


6. 스레드 덤프로 확인할 수 있는 상황

- 모든 시스템에 응답이 없을 때

- 사용자 수가 많지 않은데 cpu 사용량이 높을 때

- 특정 어플리케이션 수행 시 응답이 없을 때

- 서비스 실행시간이 길어질 수록 응답시간이나 CPU 사용량이 늘어날 때 등등

- java.lang.Thread를 이용해서 직접개발하지 않았는데 이미 프레임워크, WAS, 라이브러리 내부적으로 사용하고 있을 때 내부적으로 문제가 생긴다면?


7. Thread의 종류

7-1. Deamon Thread

  - 작업을 돕는 보조적인 역할을 수행하는 쓰레드(GC도 여기에 해당)

        - 프로세스 종료 시 데몬 스레드는 강제적으로 자동 종료

        - 언제든지 종료가 되어도 상관없는 작업 시에 사용(그래서 주로 데몬쓰레드를 쓴다.)

        - Thread t = new Thread(); t.setDaemon(thue); 로 설정가능

7-2. Non-Daemon Thread

   - 실제 주 작업을 하는 스레드

        - 프로세스 종료 시 논 데몬 쓰레드가 살아있는 경우 종료 불가능(가끔 톰캣을 종료했지만 안꺼져서 kill 해야되는 이유)

        - 매우 중요 데이터 처리시에 사용하는 것이 일반적


8. Thread 읽기

    - 

- 스레드 이름

   - lang.Thread 클래스로 생성하면 'Thread-숫자' 형식으로 생성됨

   - DefaultThreadFactory를 사용하면 pool-숫자-thread-숫자 형식으로 생성된다. 

   - 하지만 이런 디폴트 이름들로 쓰레드가 가득하다면 덤프를 읽기가 매우 힘들다. 멀티 스레드 프로그래밍을 직접할 경우 setName을 이용해서 직관적인 스레드명을 써주는게 좋다. 

- 우선순위: 스레드 우선순위(스펙에서도 안중요하다고 함)

- 스레드 아이디

    - 16진수

 - tid: 자바레벨 쓰레드ID, 자바프로세스마다 1부터 시작. 겹칠 수 있겠다.

- nid: 네이티브 쓰레드 ID, OS영역이고 유니크함

    - ps 명령어를 이용해 CPU사용율 등도 알 수 있음


- 스레드 상태

    - runnable

    - blocked

    - deadlock

    - wait

- 스레드 콜스택


9. 스레드 덤프의 각종 도구

- JVisualVM

    -jdk 설치할 때 같이 설치되므로, 환경변수가 잘 잡혀있다면 jvisualvm이라고 치면 바로 뜬다.

- TDA

    - Thread Dump Analyzer

    - 오래되고 jvm 별로 포맷이 달라 안읽히는 경우도 있음

- fastThread 사이트

    - fastthread.io


[heap dump]

10. heap

    - JVM GC 블로깅에서 Old 영역을 많이 사용할 경우 일반적으로 사용되지 않는 객체들이 Reference되어 GC되지 않고 남아 있을 가능성이 높다. 이때는 어떤 객체들이 많이 점유되고 있는지 조사할 필요가 있다.

    - Old 영역을 많이 점유하고 있으면 Full GC가 자주 오래동안 발생할 수 있으므로 업무 응답시간에 문제 또는 장애를 일으킬 소지가 있다. 

    - JDK6 명령: jmap -dump:format=b, file=<fileName> <PID>

    - jmap은 JDK_HOME/bin에 포함되어있음


11. Heap Dump의 분석

    - Eclipse Memory Analyzer Tool(mat) 을 이용한다. 

    - 독립 프로그램 다운로드:  Heap Dump Size는 몇 Gbytes씩 되므로 64bit OS에서 64bit mat를 다운로드 받는다.

    - memoryAnalyzerTool.ini파일의 초기값 설정을

      + ex) -Xms2048m -Xmx8192m (heap Dump file size 6Gbytes 일때)

               -XX; MaxPerm Size=256m

               -Xms40m

               -Xm x512m

    - mat에서 Heap Dump 파일을 로딩한다. 이 때 파일 확장자는 .hprof여야 한다. 6Gbytes로딩에 대략 수시간이 소요되니 인내심이 필요하다.

    - mat통하여 Heap Dump 분석할 때 로컬 메모리가 부족할 경우 Swap Size를 확장하여 준다. 

반응형

'Tech > Software' 카테고리의 다른 글

스위치 구분(L2, L3, L4, L7)  (0) 2019.09.03
Google Cloud Essential Workshop  (0) 2019.09.03
EJB, JTA, XA, JMS  (0) 2019.03.09
sorting algorithm  (0) 2018.12.13
HTTP Status Code List  (0) 2018.12.13
반응형

1. 버블 정렬 ( Bubble Sort )


- 과정

인접한 두 개의 데이터를 비교해가며 정렬을 진행한다.

가장 크기가 큰 값 ( 또는 정렬의 우선 순위가 가장 낮은 값 ) 을 맨 뒤로 보내고,

그 다음으로 크기가 큰 값을 맨 뒤에서 두번째로 보내고.. 이 과정을 반복한다.


- 시간 복잡도

데이터의 수가 n 개일 때,

제일 처음 비교 횟수 : n-1

그 다음 비교 횟수 : n-2

(n-1) + (n-2) .... + 2 + 1 = n(n-1)/2 =  O(n⌒2)


2. 선택 정렬 ( Selection Sort )


- 과정

가장 크기가 작은 값 ( 또는 정렬의 우선 순위가 가장 큰 값 ) 을 선택해서 가장 왼쪽으로 이동시키고,

원래 그 자리에 있던 데이터는 빈 자리에 가져다 놓는다.


- 시간 복잡도

데이터의 수가 n 개 일때, ( 배열이니까 0~ n-1 )

제일 처음 비교 횟수: 1에서 n-1까지 보니까 n-1

그 다음 비교 횟수: 2에서 n-1 까지 보니까 n-2

(n-1) + (n-2) .... + 2 + 1 = n(n-1)/2 =  O(n⌒2)


** 버블 정렬과 시간 복잡도는 똑같지만, 데이터의 이동 횟수에는 차이가 있다.

데이터의 교환이 이뤄질 때

temp = A;

A = B;

B = temp;

이므로, 총 3번의 연산이 일어난다.

선택 정렬의 경우 안쪽 for문 바깥쪽에서 이 연산이 일어나고, 버블 정렬의 경우  안쪽 for문의 안쪽에서 이 연산이 일어난다.

따라서 데이터 이동 횟수의 시간 복잡도는, 선택 정렬은 O(n)이고 버블 정렬은 O(n⌒2) 이다.


** 그러나 버블 정렬의 경우 최선의 경우에는 단 한번의 데이터 이동도 발생하지 않으나, 선택 정렬의 경우 최악이나 최선이나 데이터 이동이 같다.

따라서 버블 정렬이나 선택 정렬이나 우열을 가릴 수 없다.


3. 삽입 정렬 ( Insertion Sort )


- 과정

정렬이 완료된 부분과 완료되지 않은 부분으로 나눈 후, 정렬 안된 데이터를 정렬 된 데이터의 특정 위치에 삽입한다.

정렬이 완료된 영역 다음의 데이터가 정렬해야할 데이터이므로,

만약 정렬해야할 데이터의 위치가 k 라면,  k-1 위치의 데이터와 비교하여 자신이 더 작으면 k-1의 데이터를 k 위치로 이동시킨다.

다음 k-2의 데이터와 비교하고, 만약 k-2보다 자신이 크다면  k-1의 위치에 정착한다.

= 데이터를 한 칸씩 뒤로 밀면서 내가 들어갈 자리를 찾는다.


- 시간 복잡도

최악의 경우 모든 데이터를 보고 모든 데이터를 비교하며 이동시켜야하므로

1 + 2 + .... + (n-1) = n(n-1)/2 =  O(n⌒2)


4. 힙 정렬 ( Insertion Sort )


- 과정

힙의 루트 노드에 저장된 값이 가장 커야 한다는 특성을 힙의 루트 노드에 저장된 값이 정렬 순서상 가장 앞선다는 특징을 갖도록 하여 정렬에 이용한다.

데이터를 모두 힙에 넣은 후, 히벵서 다시 데이터를 꺼낸다.


- 시간 복잡도

힙의 데이터 저장 시간 복잡도와 삭제 시간 복잡도는 O(log n)이다.

n개의 데이터가 있을 때 총 n 개의 데이터를 삽입 및 삭제해야 하므로 O(n log n)이다.


5. 병합 정렬 ( Merge Sort )


- 과정

데이터가 1개만 남을 때 까지 분할을 한다.

다시 데이터를 합칠 때, 우선순위를 고려하여 묶는다.



- 시간 복잡도

데이터의 수가 n 개일때, 각 병합 단계마다 최대 n번의 비교연산이 진행된다.

데이터가 8개일 때, 병합은 3번 진행되고, 16개일때, 병합은 4회 진행된다.

병합 과정의 횟수는 log n 이다.

따라서 시간 복잡도는 O(n log n) 이다.


6. 퀵 정렬 ( Quick Sort )


- 과정

가장 처음 값을 피벗으로 잡는다.

a : 왼쪽에서 오른쪽으로 피벗보다 큰 값을 만날때까지 이동하고,  

b: 오른쪽에서 왼쪽으로 피벗보다 작은값을 만날때까지 이동한다. 

그리고 그 값을 교환한다. 만약 a와 b가 교차하게 되면 ( a>b)가 되면 탐색을 멈추고, b와 피벗을 교환한다.

-> 이 과정을 통해  피벗의 왼쪽에는 피벗보다 작은 값들만, 오른쪽에는 피벗보다 큰 값들만 있게 된다.

그리고 피벗을 중심으로 왼쪽과 오른쪽을 나누어 재귀적으로 진행한다.


사실 피벗이 가장 중간값이라면 제일좋은 성능을 보일 수 있다. 만약 이미 잘 정렬되있는 배열을 돌린다면, 1부터 n-1까지의 값들이 순서대로 피벗이 되어 정렬을 하게 된다.

중간 값을 찾는 알고리즘이 있긴 하지만 오히려 그거 때문에 성능이 더 나빠져서 실제로는 안쓴다고 한다.

그냥 세 개 데이터를 추출하여 그 중에 중간 값을 피벗으로 선택하는 것이 ....



- 시간 복잡도

하나의 피벗이 자신의 자리를 찾아가기 위해 n번의 비교 연산이 진행된다.

그리고 분할은 총 log n 번 진행된다. ( 피벗이 중간값인 경우 )

따라서 시간 복잡도는 O(n log n)


** 피벗이 중간 값일 때를 최선의 경우라 생각할 수 있지만, 퀵 정렬의 경우 예외적으로 중간에 가까운 피벗을 선택하는 방법을 적용하여 최선에 가까운 성능을 평균적으로 보인다고 한다. 

** 병합 정렬과 시간 복잡도는 같지만, 별도의 메모리 공간을 필요로 하지 않으므로 실제로 가장 빠르다.



7. 기수 정렬 ( Radix Sort )


- 소개

기수 정렬은 비교 연산을 하지 않고 데이터를 정렬할 수 있다. 그러나 데이터의 길이가 제한적일 수 있다.

간단하게 생각해보면, 0,8,3,5,4의 데이터를 비교한다면, 크기 10짜리의 배열의 인덱스의 그 값을 넣고 ( arr[8] = 8 이런식 ) 그냥 배열을 순차적으로 출력하면 되는 것...

하지만 이를 좀 바꾸어서, 3자리 수의 데이터 비교를 5개의 버킷(공간)을 가지고 정렬할 수 있다. 이를 LSD 기수 정렬(Least Significant Digit)라고 하며, 덜 중요한 자리 수인 일의자리수 부터 정렬을 진행해 나간다는 것이다.


- 과정

데이터: 134, 224, 232, 122


일의자리수 기준으로 하여 순서대로 버킷에 넣는다.

버킷 2: 122, 232 ( -> 넣은 순서)

버킷 5: 224, 134

현재 상태 : 232, 122, 134, 224 ( 꺼낼때는 먼저 넣은 것부터 )


십의 자리수 기준으로 버킷에 넣는다.

버킷2: 224, 122

버킷3: 134, 232

현재 상태 : 122, 224, 232, 134


백의 자리수 기준으로 버킷에 넣는다.

버킷 1: 134, 122

버킷 2: 232, 224

현재 상태 : 122, 134, 224, 232


** MSD 기수 정렬 (Most Significat Digit)은 가장 중요한 자리수, 큰 자리수부터 정렬을 진행한다. 이 정렬의 가장 큰 장점은 중간에 정렬이 완료될 수 있으므로 끝까지 가지 않아도 된다. 그러나  중간에 정렬이 완료되었는데도 불구하고 끝까지 정렬할 시 정렬이 제대로 되지 않는다. 따라서 중간에 데이터를 점검해야하는 상황이 발생한다. ( 모든 데이터에 일괄적 과정을 거칠 수 없다 ) 따라서 이를 해결할 알고리즘을 필요로 하는데 이게 더 시간이 오래 걸릴 수 있음...


- 시간 복잡도

비교연산이 아닌 데이터의 삽입과 추출이 핵심 연산이다.

가장 긴 데이터의 길이만큼 반복하고, 정렬대상의 수 만큼 버킷에 데이터를 삽입하고 추출한다.

데이터의 길이(l) x 데이터의 수(n) = O(ln) = O(n)

반응형

'Tech > Software' 카테고리의 다른 글

스위치 구분(L2, L3, L4, L7)  (0) 2019.09.03
Google Cloud Essential Workshop  (0) 2019.09.03
EJB, JTA, XA, JMS  (0) 2019.03.09
java jvm core dump  (1) 2018.12.30
HTTP Status Code List  (0) 2018.12.13
반응형

1xx Informational response

100 Continue
101 Switching Protocols
102 Processing (WebDAVRFC 2518)
103 Early Hints (RFC 8297)

2xx Success

200 OK

201 Created

202 Accepted
203 Non-Authoritative Information (since HTTP/1.1)
204 No Content
205 Reset Content
206 Partial Content (RFC 7233)
207 Multi-Status (WebDAV; RFC 4918)
208 Already Reported (WebDAV; RFC 5842)
226 IM Used (RFC 3229)

3xx Redirection

300 Multiple Choices

301 Moved Permanently

302 Found (Previously "Moved temporarily")
303 See Other (since HTTP/1.1)
304 Not Modified (RFC 7232)
305 Use Proxy (since HTTP/1.1)
306 Switch Proxy
307 Temporary Redirect (since HTTP/1.1)
308 Permanent Redirect (RFC 7538)

4xx Client errors


400 Bad Request
401 Unauthorized (RFC 7235)
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required (RFC 7235)
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed (RFC 7232)
413 Payload Too Large (RFC 7231)
414 URI Too Long (RFC 7231)
415 Unsupported Media Type
416 Range Not Satisfiable (RFC 7233)
417 Expectation Failed
418 I'm a teapot (RFC 2324RFC 7168)
421 Misdirected Request (RFC 7540)
422 Unprocessable Entity (WebDAV; RFC 4918)
423 Locked (WebDAV; RFC 4918)
424 Failed Dependency (WebDAV; RFC 4918)
426 Upgrade Required
428 Precondition Required (RFC 6585)
429 Too Many Requests (RFC 6585)
431 Request Header Fields Too Large (RFC 6585)
451 Unavailable For Legal Reasons (RFC 7725)

5xx Server errors

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates (RFC 2295)
507 Insufficient Storage (WebDAV; RFC 4918)
508 Loop Detected (WebDAV; RFC 5842)
510 Not Extended (RFC 2774)
511 Network Authentication Required (RFC 6585)

Unofficial codes

103 Checkpoint
218 This is fine (Apache Web Server)
419 Page Expired (Laravel Framework)
420 Method Failure (Spring Framework)
420 Enhance Your Calm (Twitter)
450 Blocked by Windows Parental Controls (Microsoft)
498 Invalid Token (Esri)
499 Token Required (Esri)
509 Bandwidth Limit Exceeded (Apache Web Server/cPanel)
526 Invalid SSL Certificate
530 Site is frozen
598 (Informal convention) Network read timeout error

Internet Information Services

440 Login Time-out
449 Retry With
451 Redirect
444 No Response
494 Request header too large
495 SSL Certificate Error
496 SSL Certificate Required
497 HTTP Request Sent to HTTPS Port
499 Client Closed Request

520 Unknown Error

521 Web Server Is Down
522 Connection Timed Out
523 Origin Is Unreachable
524 A Timeout Occurred
525 SSL Handshake Failed
526 Invalid SSL Certificate
527 Railgun Error
530 Origin DNS Error


반응형

'Tech > Software' 카테고리의 다른 글

스위치 구분(L2, L3, L4, L7)  (0) 2019.09.03
Google Cloud Essential Workshop  (0) 2019.09.03
EJB, JTA, XA, JMS  (0) 2019.03.09
java jvm core dump  (1) 2018.12.30
sorting algorithm  (0) 2018.12.13

+ Recent posts