습관처럼

리눅스를 설치하면 상당히 많은 디렉토리가 자동으로 생성됩니다. 이러한 디렉토리는 대부분 유닉스와 유사합니다. 파일 시스템의 구조는 유닉스의 종류(AT&T 계열과 BSD계열)에 따라 약간 차이가 있으며, 리눅스는 주로 AT&T를 중심으로 BSD가 섞인 형태입니다. 리눅스 연합에서는 이러한 배포판의 파일시스템 차이를 표준화하기 위해 FSSTND(File System Standard) 표준안을 마련해 놓고 있습니다.아래는 리눅스의 파일시스템 구조를 나타낸 것입니다.

파일과 디렉토리는 카테고리별로 조직화되어 있습니다. 위 그림에서 가장 분명하게 알 수 있는 카테고리는 고정(static)과 유동(dynamic)적인 파일들입니다. 또한 다른 카테고리로는 실행가능 여부, 환경설정, 데이터 파일들 등이 있습니다. 시스템 관리자라는 입장에서 볼 때, 이와 같은 파일 시스템 구조는 관리하기에 적합합니다.

고정적인 파일들과 디렉토리는 또한 네트워크 상의 다른 호스트들로부터 공유가 가능하기 때문에 공유 가능한(shared) 카테고리 분류에도 해당이 됩니다. /usr, /sbin, /opt 같은 디렉토리들이 여기에 해당합니다.

환경 파일들, 디바이스 파일들, 커널 파일들과 같이 특정한 호스트를 위한 파일들과 로그 파일들, 임시 파일들, 사용자의 홈디렉토리에 있는 파일들은 유동적인 파일들입니다. 관련 디렉토리로는 /boot, /home, /tmp, /dev, /etc, /var 등이 있습니다.

운영체제와 응용프로그램들은 서로 분리 시켜서 유지하여야 합니다. 오랜 시간 동안 많은 응용프로그램을 설치하다 보면 이러한 테크닉이 도움이 된다는 것을 알 수 있을 것입니다. 응용프로그램 제공업체들은 설치되는 위치에 대해서 사용자의 편의를 제공하지 않습니다. 부주의로 인해 운영체제 파일들을 응용프로그램 파일들이 덮어 쓰는 것을 방지하는 것은 시스템 관리자로써 매우 중요한 일입니다. 게다가 운영체제와 분리된 영역에 설치된 응용프로그램을 "모듈화"가 가능하므로 추가, 삭제 및 수정에 있어서 운영체제나 다른 응용프로그램에 영향이 미치지 않도록 할 수 있습니다. 

유닉스 계열의 운영체제들은 /opt 라는 디렉토리에 응용프로그램들이 설치되지만, 레드햇 리눅스는 이 디렉토리를 구성하지 않고 /usr/local 디렉토리에 응용프로그램 별로 설치가 되거나 RPM으로 설치를 하면 각각의 구성파일들이 필요한 디렉토리로 설치가 됩니다.

실행 파일들도 시스템 환경 파일들과 구분이 되어져야 합니다. 이는 호스트들 사이에 실행 파일들을 공유하기 위함이며, 운영체제를 업데이트 할 때 환경 파일들에게 영향을 주는 것을 방지할 수도 있습니다.

다음은 레드헷 리눅스를 기준으로 한 디렉토리의 구성과 용도에 대한 간략한 설명입니다.

 /

루트 디렉토리로 파일 시스템 계층 구조의 시작점입니다. 따라서 빈 상태로 유지하는 것이 바람직합니다.

 /boot

환경 설정 파일을 제외한 부팅 과정에서 필요한 모든 구성 요소들이 포함되어 있습니다.

 /bin

실행 파일들이 모두 모여 있습니다. 이 디렉토리에는 많은 필수적인 프로그램들이 포함되어 있습니다.

"ls /bin"을 해보면 이 안의 파일들을 볼 수 있으며 cp, ls, mv 같은 몇 개의 명령어들은 알아 볼 수 있을 것입니다. 이것들은 이들 명령어들의 실제 프로그램들입니다. 따라서 "cp" 명령을 입력하면, /bin/cp 프로그램이 실행되는 것입니다.

" ls -F"를 사용하면, /bin의 대부분의 파일들에서 "*"가 파일명 끝에 추가되어 있는 것을 볼 수 있습니다. 이것은 이 파일이 실행 가능한 파일임을 표시하는 것입니다.

 /dev

/dev 안의 파일들은 디바이스 드라이버들입니 다. 이것들은 디스크 드라이버, 모뎀, 메모리 등과 같은 시스템 디바이스나 자원들을 접근하는데 사용됩니다. 예를 들면, 파일들로부터 정보를 읽어 볼 수 있는 것과 같이, /dev/mouse를 access 함으로써 마우스로부터 입력되는 정보를 읽어 올 수 있습니다. fd로 시작하는 파일 이름들은 플로피 장치들입니다. fd0는 첫 번째의 플로피 디스크 드라이브이며, fd1은 두 번째입니다. 이 이외의 것들은 보통 플로피 디스크의 특정 형태를 표시합니다. 예를 들면, fd0H1440은 첫 번째 드라이브(A: 드라이브)의 고밀도 3.5 인치 디스켓을 말합니다.

/dev/console

시스템의 콘솔이며, 모니터가 시스템에 직접 연결되어 있음을 말합니다.

/dev/ttyS? 와 /dev/cua?

직렬 포트를 액세싱합니다. 예를 들면, /dev/ttyS0는 도스 상의 "COM1"을 뜻하며, /dev/cua는 "callout" 장치로써, 이것은 모뎀을 직접 액세스할 때 사용됩니다.

hd로 시작하는 디바이스 이름

하드 디스크를 액세스합니다. /dev/hda는 첫 번째 하드 디스크 전체를 뜻하며, hda1은 /dev/hda의 첫 번째 파티션을 의미합니다.

sd로 시작하는 디바이스 이름

SCSI 하드 디스크 드라이브나 테이프 드라이브 같은 SCSI 장치들을 의미합니다. 만약 SCSI 하드 디스크를 가지고 있다면, /dev/hda를 접근하는 대신에 /dev/sda를 액세스해야 합니다.

lp로 시작하는 디바이스 이름

병렬 포트를 말하며, /dev/lp1은 도스의 "LPT1"과 같습니다.

/dev/null

"black hole"로써 사용되는 것으로서 어떠한 데이터를 이 장치에 보내면 모두 없어지게 됩니다. 예를 들면, 화면에 아무 것도 출력되지 않기를 바랄 경우, /dev/null로 출력을 보내면 됩니다.

/dev/tty로 시작하는 디바이스 이름

시스템에 있는 "가상 콘솔 : Virtual Console(VC)"입니다. /dev/tty1은 첫번째 VC이며, /dev/tty2는 두 번째입니다. 가상 콘솔은 한 화면이 여러 개의 가상 터미널을 갖는 것입니다. 각각의 터미널은 [alt]+[F1], [alt]+[F2] 등을 누름으로서 전환할 수 있으며, 같은 사용자나 다른 사용자로 login할 수 있습니다.

/dev/pty로 시작하는 디바이스 이름

이것들은 원격 login 세션에서 사용되는 "pseudo-terminal"들입니다. 예를 들어, 사용 중인 컴퓨터가 네트워크에 연결되어 있고, telnet으로 login하려고 할 때, /dev/pty 디바이스를 사용합니다.

 /etc

시스템의 부팅, 셧다운 시에 필요한 파일들과 시스템의 전반에 걸친 설정 파일들 및 초기 스크립트 파일들이 있습니다. 시스템에 어떠한 문제가 발생한다거나, 시스템 전체 환경에 관한 설정을 바꾸기 위해서는 이들 디렉토리 내에 포함되어 있는 파일들에 대해서 잘 알아야 합니다.

/etc/rc.d/rc

/bin/sh shell이 시스템이 부트되면, 자동적으로 실행되는 스크립트입니다. 이것은 update, crond, inetd 같은 프로그램을 백그라운드로 실행시키며, 파일 시스템 마운팅, 스왑 영역 활성, 그리고 이런 유사한 다른 작업들을 합니다. /etc/rc.d/rc.local과 /etc/rc.d/rc.# 파일이 포함되기도 합니다.

/etc/passwd

사용자에 대한 정보를 포함하고 있는 문서 파일입니다.

/etc/fdprm

플로피 디스크 파라메터 표입니다.

/etc/fstab

이 파일은 /etc/rc.d/rc 파일 안의 mount -a 명령에 의해 마운팅되는 파일 시스템과 스왑 영역의 목록입니다.

/etc/getty (혹은 /sbin/getty)

이 프로그램은 터미널로 누군가가 login하기를 기다립니다. 명령어 init에 의해 자동적으로 실행되며, login 가능한 터미널 라인이나 가상 콘솔 당 한번씩 실행됩니다. 또한, 사용자의 패스워드를 기다리며, login을 실행합니다.

/etc/gettydefs 혹은 /etc/gettytab

getty가 터미널 라인의 속도, 패리티 검사 등을 어떻게 사용할 것인가를 설정합니다.

/etc/group

/etc/passwd와 유사하며, 사용자 대신에 그룹을 설정합니다.

/etc/init (혹은 /sbin/init)

이 프로그램은 부팅 시에 커널에 의해 첫 번째 프로세스로 실행됩니다. init가 실행된 후에 커널 부팅이 완료됩니다. init는 /etc/rc.d/rc와 getty 등을 실행합니다.

/etc/inittab

init가 시작할 때의 getty의 파일 목록입니다.

/etc/issue

로그인 프롬프트 이전에 출력되는 getty 출력 문서 파일입니다. /etc/issue.net 파일은 remote 로그인시 프로프트에 출력됩니다.

/etc/mtab

이 파일은 마운팅된 파일 시스템을 포함하고 있습니다. /etc/rc/rc.d와 mount나 umount 명령에 의한 셋업이며, 마운팅된 파일 시스템의 목록이 필요할 때 사용됩니다.

/etc/shadow

시스템의 shadow 패스워드를 포함하는 파일입니다.

/etc/login.defs

login 명령에 사용되는 설정 파일입니다.

/etc/printcap

/etc/termcap과 유사하며, 프린터를 사용할 때(lpr) 쓰입니다.

/etc/profile

Bourne shell(/bin/sh 혹은 bash)에 의해 로그인 할 때 실행되는 파일입니다.

/etc/securetty

터미널 보안을 위해 사용하는 것으로 root는 이 파일에 열거된 터미널로 로그인할 수 있습니다. 보통 가상 콘솔들이 열거되어 있으며, 모뎀이나 네트워크로 시스템에 접근하여 수퍼 유저의 권한을 얻는 것을 막을 수 있습니다.

/etc/shells

shell의 목록으로 chsh 명령으로 사용자 로그인 shell을 바꿀 때, 이 파일의 목록에 있는 shell만 바꿀 수 있도록 합니다.

/etc/termcap

터미널의 기능 데이터베이스입니다. 이것은 문서 파일로서 ESCAPE 문자들로서 터미널을 제어할 때 사용됩니다.

/etc/update (혹은 /sbin/update)

/etc/rc.d/rc에 의해 백그라운드로 실행되는 프로그램의 하나로 매 30초 마다 버퍼 캐시에 있는 하드로 쓰여지지 않은 데이터를 저장합니다. 이러한 것은 전원의 단절이나, 커널의 이상 등을 대비하여 매 30초 마다 데이터를 저장함으로써 데이터 손실의 위험을 줄이는 것입니다.

/etc/utmp (혹은 /var/run/utmp)

각각의 터미널에 로그인한 사용자나, 로그인에 관한 정보가 기록되어 있는 이진 파일입니다. 사용자가 로그인하면 login은 누가 로그인을 하고 언제 로그 아웃을 하였는가에 대한 정보를 기록합니다.

/etc/wtmp (혹은 /var/log/wtmp)

/etc/utmp와 유사하며, 단지 존재하는 정보를 덮어 쓰지 않고 계속 추가합니다. /etc/ftpusers, /etc/rpc, /etc/exports 네트워크에 관한 파일들입니다.

/home

사용자의 홈 디렉토리로써 login 하였을 경우, 처음으로 위치하게 되는 디렉토리입니다. 예를 들어, /home/foo는 사용자 "foo"의 홈 디렉토리입니다. 시스템이 새로 설치되면, 이 디렉토리 안에 아무 것도 포함되어 있지 않습니다.

 /lib

부팅과 시스템 운영에 필요한 공유 라이브러리(Shared Library)와 커널 모듈(Kernel Module)이 위치합니다. 공유 라이브러리란 windows 95/98의 DLL(Dynamic Link Library)과 같이 여러 가지 프로그램들에 의해서 사용되는 기능을 별도의 프로그램으로 분리시켜 놓은 것입니다. 커널 모듈도 공유 라이브러리와 같이 커널 안에 자체적으로 프함되지 않고 독립적인 형태로 분리되어 있으면서 부팅 시에 커널에 동적으로 연결되어서 전체적인 커널을 유기적으로 구성하게 되는 별도의 파일(Object File)들입니다.

/lost+found

파일 시스템의 이상 유무를 진단하고 복구하는 프로그램인 fsck(File System Check)에 의해서 사용되는 디렉토리입 니다. 손상된 파일이나 디렉토리를 /lost+found 디렉토리로 연결한 뒤에 오류를 수정하게 되며, 평상시에는 null 파일 링크에 의해서 비어있는 상태로 존재합니다. 리눅스의 파일 시스템인 ext2에 의한 fsck.ext2(File System Check.extended2) 프로그램도 이 디렉토리를 사용합니다.

/misc

시스템 아키텍처와 무관한 프로그램들과 자료들이 위치합니다. 레드햇 리눅스는 이 디렉토리를 구성하지 않습니다.

/mnt

루트 파일 시스템에 연결된 파일 시스템들의 마운트 디렉토리입니다. 마운트하지 않은 상태에서 빈 디렉토리로 존재하지만 마운트시키게 되면 해당 파일 시스템의 내용이 그대로 포함됩니다.

/opt

Add-On 소프트웨어 패키지가 설치됩니다. 레드햇 리눅스는 이 디렉토리를 구성하지 않습니다.

/proc

가상 파일 시스템입니다. 이 디렉토리의 내용들은 시스템에서 운영되고 있는 다양한 프로세서들에 관한 내용과 프로그램에 대한 정보를 포함하고 있습니다. 이 디렉토리에서 볼 수 있는 것은 실제 드라이브에 저장되어 있는 내용이 아니며, 메모리 상에 저장되어 있는 것입니다.

/root

시스템 관리자인 root의 홈 디렉토리입니다.

/sbin

시스템 관리를 위한 전반적인 실행 유틸리티를 담고 있습니다. 이 디렉토리에 있는 명령어들은 일반 사용자는 실행할 수 없습니다.

/tmp

프로세스 진행 중 발생하는 임시 파일들이 저장되는 작업 디렉토리입니다. 따라서 이 디렉토리 파일들은 수시로 생성되고 삭제되므로 중요한 자료일 경우, 이 디렉토리에 보관해서는 안됩니다. /tmp 디렉토리는 모든 사용자에 대해서 읽기와 쓰기 작업이 허용되며, 스티키 비트(sticky bit)라는 특별한 설정에 의해서 파일의 소유자만이 자신의 소유로 되어 있는 파일을 지울 수 있도록 되어 있습니다.

/usr

루트 디렉토리와 함께 중요한 시스템 디렉토리 계층을 구성합니다. /usr 디렉토리에는 공유 가능한 대부분의 프로그램들이 설치되며 네트워크를 이용해서 여러 개의 시스템을 연결할 경우, 이 디렉토리를 공유해서 설치된 프로그램들을 활용할 수 있게 됩니다. 따라서 /usr 디렉토리는 읽기 전용으로 마운트되어야 하며, 가변 자료들은 /var 디렉토리로 심볼릭 링크시켜서 사용하게 됩니다. /usr 디렉토리는 다른 시스템과 연결될 경우, 시스템 운영과 연관되기 때문에 내부적으로 전체 루트 디렉토리와 유사한 구조를 갖게 됩니다.

/usr/X11R6

X윈도우 시스템을 설치하였다면 이 디렉토리에 설치가 됩니다. X윈도우 시스템은 방대하여, 많은 그래픽 유틸리티와 프로그램들이 그래픽 윈도우로 출력되는 강력한 그래픽 사용자 환경입니다. 이 디렉토리에는 X윈도우 실행 파일, 사양 파일, 자원 파일들을 포함하고 있습니다. X11R6은 X의 버전과 릴리즈 번호를 뜻합니다.

/usr/bin

시스템이 소유하고 있는 소프트웨어를 담기 위한 warehouse입니다. /bin과 같은 곳에는 없는 유용한 실행 파일들을 가지고 있습니다.

/usr/etc

유틸리티와 파일들이 있습니다. 일반적으로 /usr/etc에 있는 파일들은 /etc에 있는 것만큼 반드시 필요한 것들은 아닙니다.

/usr/include

C 컴파일러를 위한 include 파일을 포함합니다. 이 파일은 데이터 구조 이름과 서브루틴, 상수 같은 C로 작성된 프로그램에서 사용되는 내용을 담고 있습니다. /usr/include/sys에 있는 파일들은 리눅스 시스템 레벨의 프로그래밍을 할 때 사용됩니다. 만약, C프로그래밍 언어에 익숙하다면, 여기에 printf()가 선언되어 있는 stdio.h같은 헤더 파일을 찾을 수 있을 것입니다.

/usr/lib

/lib에서 찾을 수 있는 "stub"와 "static"와 같은 라이브러리를 포함하고 있습니다. 프로그램을 컴파일할 때, 프로그램은 /usr/lib에 있는 파일들과 link되며 이 라이브러리 안에 실행 코드가 필요로 할 때, /lib를 찾습니다. 또한, 많은 프로그램들이 /usr/lib 안에 사양 파일을 저장합니다.

/usr/local

/usr에 포함된 것과 유사하고, 시스템에 반드시 필요로 하는 것은 아니지만, 매우 유용한 것들을 포함하는데 사용합니다. /usr/local에 있는 프로그램들은 시스템의 특성을 결정 짓는 소프트웨어들이 있을 수 있습니다.

/usr/man

이 디렉토리는 실제적인 man page를 포함하고 있습니다.

/usr/src

시스템에 있는 다양한 프로그램의 컴파일 되지 않은 소스 코드를 포함하고 있습니다. 여기서 가장 중요한 것은 /usr/src/linux이며, 이것은 리눅스 커널의 소스 코드를 포함하고 있습니다.

/usr/dict

사전 파일 디렉토리입니다.

/usr/doc

프로그램의 문서와 관련한 파일들이 저장되는 곳입니다.

/usr/games

게임 프로그램들이 위치하고 있습니다.

/usr/infi

GNU info 파일을 위한 디렉토리입니다.

/usr/sbin

시스템 명령어들이 위치합니다.

/usr/share

아키텍처 독립적인 자료들의 디렉토리입니다.

/var

내용이 수시로 변경될 수 있는 변수를 담고 있는 파일들이 위치합니다. 예를 들면, 부팅 중의 시스템 확인 과정은 부팅 때마다 달라질 수 있으므로 부팅 과정을 기록하는 파일은 이 디렉토리에 위치하게 됩니다. /tmp 디렉토리가 파일 자체에 대한 임시 디렉토리인데 반해서 /var 디렉토리는 변경될 수 있는 자료를 포함하고 있는 파일들을 위한 디렉토리입니다.

/var/adm

시스템 관리적인 문제의 파일, 로그 파일, 커널 크래쉬 덤프를 기록한 파일들을 포함합니다.

/var/spool

스풀 파일들이 위치합니다.

출처: https://firedev.tistory.com/entry/Linux-Unix-%EB%A6%AC%EB%88%85%EC%8A%A4%EC%8B%9C%EC%8A%A4%ED%85%9C-%EB%94%94%EB%A0%89%ED%86%A0%EB%A6%AC-%EA%B5%AC%EC%A1%B0%EC%99%80-%EA%B8%B0%EB%8A%A5

RAID

Redundant Array Inexpensive Disk 혹은 Redundant Array Independent Disk 의 약자

처음 개념이 등장할 때는 여러개의 저렴한 디스크를 하나로 모아 고성능의 디스크처럼 사용하자는 생각에서 출발.

현재는 꼭 저렴한 디스크 라기 보다는 여분의 독립적인 디스크들을 하나로 모아 고성능 혹은 고가용성을 위한 개념이다.

RAID는 구현 방법에 따라 여러개의 RAID LEVEL 로 표현된다.

단일 디스크 I/O

아래 그림은 단일디스크에서 I/O가 발생하는 상황이다.

모든 데이터는 조각(block 혹은 cluster로 표현됨)으로 나뉘어 디스크에 쓰여지기 때문에 아래와 같은 그림이 된다.

1번 조각이 디스크에 쓰여지고 있는 동안 나머지 조각들은 대기를 하게 되고, 1번이 다 쓰여진 이후에 2번, 3번 순으로 쓰기가 이루어진다.

RAID 0 (Striping)

처음 개념이 등장했을때, 즉 여러개의 저렴한 디스크를 하나로 모아 고성능의 디스크로 사용하는 개념에서 나온 Level 이다. 

패리티(오류검출기능)이 없이 striping 된 형태를 말한다. 최소 2개 이상의 디스크를 필요로 하며 안정성보다는 고성능을 위해 사용된다.

RAID 0의 경우는 I/O가 일어날때 데이터를 여러 조각으로 나누어 각각의 디스크에 순서대로 저장하게 된다. 아래 그림처럼 디스크 2개로 RAID-0 을 구성했을 경우, 1번 조각이 DISK1에 쓰여지고 있을 동안 2번 조각은 기다리지 않고 바로 DISK2에 기록이 된다. 1번 조각의 쓰기가 끝나는대로 DISK1 에서는 3번조각이 쓰여지고 2번 조각의 쓰기가 끝나는대로 4번 조각의 쓰기가 일어나 단일디스크일 경우보다 거의 2배에 가까운 성능을 발휘한다. (물론 실제적으로 2배까지는 아님) 하지만 두 디스크중 하나의 디스크에 Fault가 발생했을 경우, 데이터의 절반을 날리게 되므로, 나머지 하나의 디스크도 사실상 못쓰게 된다. 관리 포인트가 하나 늘어남으로 인해 안정성은 떨어지게 되는 것이다.

장점 : 빠른 I/O 성능, 디스크가 N개로 구성될 경우 N개의 디스크 용량 모두를 활용할 수 있음.

단점 : 낮은 안정성

RAID 1 (Mirroring)

RAID 0과는 달리 안정성에 중점을 둔 RAID Level 이다. 아래 그림에서 보면 1번 조각이 디스크에 쓰여질 때 양쪽 디스크(DISK1, DISK2)에 동시에 동일한 데이터가 기록됨을 볼 수 있다.

RAID 1은 하나의 데이터를 양쪽 디스크에 동일하게 기록함으로써, 하나의 DISK에 Fault가 발생해도 나머지  하나의 디스크를 통해 데이터에 접근할 수 있는, 안정성을 강화한 방법이라고 보면 된다. 일반적으로 서버에 있어 OS가 설치되는 디스크에 필수적으로 사용되는 구성방법이다.

장점 : 높은 안정성. 일반적인 구성대비 읽기 성능에서 아주 조금 향상된성능을 보임.

단점 : 전체 디스크 용량에 비해 사용가능한 용량은 절반이 됨. 즉 높은 비용.

RAID 2

RAID2는 RAID 0처럼 스트라이핑 구성이지만 일부 디스크에는 오류 검사 및 수정을 위해 ECC(Error Correction Code) 정보가 저장된다. RAID 3~4에 비해 이점이 없으며 현재는 더 이상 사용되지 않는 구성이다.

단점 : ECC를 위한 드라이브가 손상될 경우는 문제가 발생할 수 있으며 패리티 정보를 하나의 하드 드라이브에 저장하는 RAID 4가 나오면서 폐기되었다.

최소 디스크 개수 : 3

용량 : (디스크 수 - 1) X 디스크 용량

RAID 3

RAID 3 구성은 스트라이핑을 사용하고 하나의 드라이브를 패리티 정보를 저장하는데 사용된다. 내장 된 ECC 정보는 오류를 감지하는 데 사용된다. 데이터 복구는 다른 드라이브에 기록 된 정보의 배타적 OR (XOR)을 계산하여 수행된다.

I/O 작업은 동시에 모든 드라이브를 처리하므로 RAID 3은 I/O를 중첩 할 수 없습니다. 이러한 이유 때문에 RAID 3는 수행시간이 긴 응용 프로그램이있는 단일 사용자 시스템에 가장 적합하다.

최소 디스크 개수 : 3

용량 : (디스크 수 - 1) X 디스크 용량

RAID 4 (Parity)

RAID 0(Striping)의 성능에 안정성을 결합한 방식이다. 데이터는 RAID 0에서처럼 디스크에 순차적으로 쓰여지기 때문에 성능 향상의 이점이 있고, 불안한 안정성을 위해 하나의 디스크를 Parity 전용 디스크로 사용한다. 전체 디스크가 N개로 구성되면 실제 사용가능한 디스크는 N-1개가 된다. RAID 5로 인해 잘 사용되지는 않지만 NetApp의 스토리지 구성에서는 자주 볼 수 있다.(NetApp은 RAID 4,6을 사용)

※ Parity 가 어떻게 사용되는건지에 대해~~

 - 아래 그림에서 1번,2번,3번 데이터와 맨 윗줄의 P 하나가 한 셋트가 된다.

정말 간단하게 설명하면 1번 데이터의 실제 값은 1, 2번 데이터의 실제값은 0, 3번 데이터의 실제값은 1이라고 가정해 보자 

(이렇게 가정할 수 있는 이유는 컴퓨터는 실제 0과 1로만 이루어진 데이터를 주고받기 때문이라고 보면 된다)

맨 윗줄의 Parity는 같은 위치에 있는 1~3번 데이터의 실제값을 확인하게 되는데, 1이 홀수개면 1, 1이 짝수개면 0이라는 값이 쓰여진다.

이경우 맨 첫번째 Parity는 1번 데이터는 1, 2번 데이터는 0, 3번 데이터는 1 -> 즉 1이 총 짝수개, 따라서 Parity값은 0이된다. 

이후에 만약 DISK 1이 손상되어 1번 데이터 부분이 없어진다고 해도, Parity 값을 이용하여 1번 데이터 부분에 어떤 값이 있는지 역추적이 가능하기 때문에 복구가 가능해 지는 것이다.

장점 : RAID 0 대비 높아진 안정성, RAID 1 대비 뛰어난 성능

단점 : Parity 전용 디스크에 부하가 걸릴 경우(Parity 연산을 해야하는 경우가 많을수록) 전체적인 성능이 저하됨. 읽기 보다는 쓰기에서 성능의 저하가 큼(디스크에 쓸 때는 Parity를 연산하여 기록해야 하기 때문에, 읽기때는 데이터만 읽으면 됨)

RAID 5

이 구성은 패리티가있는 블록 레벨 스트라이핑을 기반으로합니다. 패리티 정보는 각 디스크에 스트라이핑되므로 하나의 드라이브가 고장 나더라도 다른 어레이로 대체 작동 할 수 있다. 어레이 아키텍처는 읽기 및 쓰기 작업을 여러 드라이브로 확장이 가능하기 때문에 일반적으로 단일 드라이브의 성능보다 좋지만 RAID 0 어레이의 성능은 높지 않습니다. RAID 5는 3개 이상의 디스크가 필요하지만 성능상의 이유로 적어도 5 개의 디스크를 사용하는 것이 좋다고 한다.

RAID 5 어레이는 일반적으로 패리티 정보 작성과 관련된 성능 영향으로 인해 쓰기 집약적 시스템에서 사용하기에는 좋지 않은 선택이다. 디스크에 장애가 발생하면 RAID 5 어레이를 재구성하는 데 오랜 시간이 걸릴 수 있기 때문이다. 성능은 대개 재구성 시간 동안 저하되며 어레이는 재구성이 완료 될 때까지 추가 디스크 오류에 취약할 수 밖에 없다.

즉, RAID 5는 RAID 3,RAID 4 에서 별도의 패리티 정보 디스크를 사용함으로써 발생하는 문제점을 보완하는 방식으로 패리티 정보를 stripe로 구성된 디스크 내에서 처리하게 구성한다. 만약 1개의 디스크가 고장 나더라도 남은 디스크들이 복구를 할 수 있기 때문이다.

최소 디스크 개수 : 3

용량 : (디스크 수 - 1) X 디스크 용량

RAID 6

RAID 5 의 경우 Parity bit을 이용하여 어느정도의 안정성을 보장할 수 있었다.(1개의 디스크 Fault까지는 Parity를 이용하여 복구 가능)

하지만 1개의 디스크가 손상된 후, 바로 또 하나의 디스크가 손상이 된다면 전체 디스크의 데이터를 사용할 수 없게 되었다. 이에 하나의 디스크를 추가로 Parity로 사용, 즉 Parity bit을 두개의 디스크에 두어 안정성을 더욱 강화한 방법이다. 전체 디스크가 N개일 경우, 실제 사용가능한 디스크는 N-2 개가 된다.

장점 : RAID 4,5 대비 안정성 증가

단점 : RAID 4,5 대비 비용 증가

RAID 1+0, 0+1 (RAID10)

RAID 0과 1을 합쳐놓은 방법이다. RAID 0으로 구성된 디스크들을 다시 RAID 1로 구성하면 0+1, RAID 1로 구성된 디스크들을 다시 RAID 0으로 구성하면 1+0 이 된다. RAID 0과 1의 장점들을 취한 방법으로, striping(RAID 0)의 성능과, mirroring(RAID 1)의 안정성을 갖는 방법이다.

디스크 4개로 구성된 0+1, 1+0의 경우 서로간에 성능 차이는 없다고 보면 된다. 하지만 디스크가 4N 개(4의 배수)가 아닌 6개로 구성되어 있을 경우는 0+1보다 1+0의 안정성이 더 높아지므로, 실질적으로 1+0 을 많이 사용하고 있다.

※ 왜 디스크가 6개일때 1+0의 안정성이 높은가???

디스크 6개를 1+0으로 구성하게 되면 2+2+2 형태로 구성이 가능하다

(2개씩 mirror 구성 후 3개의 셋트를 다시 striping). 

디스크 6개를 0+1로 구성하게 되면 3+3 형태로 구성이 가능하다

(3개씩 striping 구성 후 2개의 셋트를 다시 mirror). 

이경우 2+2+2 상태에서는 각각의 셋트에서 디스크가 하나씩 Fault가 발생해도 전체 데이터를 사용할 수 있는 반면 3+3 상태에서는 각각의 셋트에서 디스크가 1개씩만 fault가 허용될뿐 추가적으로 Fault 가 발생할 경우 전체 데이터를 손실하게 된다. 즉 2+2+2 상태에서는 최대 3개까지 디스크 Fault를 커버 가능, 3+3 상태에서는 최대 2개까지 디스크 Fault를 커버 가능하게 된다. 

장점 : 성능, 탄력성 및 비용은 RAID의 주요 장점이라고 볼 수 있다. 여러 개의 하드 드라이브를 함께 설치하면 RAID를 사용하여 단일 하드 드라이브의 작업을 향상시킬 수 있으며 구성 방법에 따라 충돌 후 컴퓨터 속도와 안정성이 향상 될 수 있기 때문이다.

단점 : 중첩 된 RAID 레벨은 많은 수의 디스크가 필요하기 때문에 기존의 RAID 레벨보다 구현 비용이 비싸다. 대다수의 디스크가 중복성을 위해 사용되기 때문에 중첩 된 RAID의 경우 스토리지 비용도 높습니다. 하지만 중첩 된 RAID는 표준 RAID 레벨과 관련된 일부 안정성 문제를 극복하는 데 도움이되므로 비용에도 불구하고 널리 보급되어 사용되었다.

※ 번외편

- Hardware RAID :

하드웨어 적으로 RAID를 구성하는 방법이다. 별도의 RAID 컨트롤러를 사용하여 구성하게 되며, RAID 컨트롤러에서 디스크 구성을 한 후 OS에게 전달하는 방식으로 OS는 해당 디스크가 RAID 구성되어있는지 아닌지의 여부를 알 수가 없게된다.

                           OS가 RAID에 관여하지 않고, 또 별도의 하드웨어가 RAID관련 연산을 처리함으로 인해 Software RAID 방식보다 더 나은 성능을 기대할 수 있다. 단, RAID 컨트롤러를 이중화 하지 않을 경우, 컨트롤러의 손상만으로 디스크 전체를 사용할 수 없게 될 수가 있다.

- Software RAID :

OS가 RAID 구성을 지원하는 방식이다. OS는 장치에 연결된 모든 디스크를 인식할 수 있으며 OS에서 제공하는 기능을 통해 RAID 구성이 가능하다. 별도의 RAID 컨트롤러가 필요가 없기에 비용적인 측면에서 조금 더 나을 수 있지만, Hardware RAID방식에 비해 성능은 더 낮다.

                           Windows OS에서는 동적디스크를 사용하여 RAID 구성이 가능하며, UNIX 계열에서는 LVM을 사용하여 구성이 가능하다. (HP나 IBM쪽에서는 LVM을 통해 Mirror를 구성하는, 즉 Software RAID방식을 사용해도 Hardware RAID 방법과

                           비교하여 성능차이가 거의 없다고 한다. 하지만 Windows의 경우에는 Software RAID 방식을 사용하면 성능 저하가

                           크다. 성능저하 뿐만 아니라 복구시에 안정성도 낮음)

오늘날 배울 수있는 가장 유용한 Linux 명령어

이 글에는 Linux 시스템 경험을 급격히 높이기 위해 Google 전문가가 엄선한 50가지 최고의 리눅스 명령어 모음이 나와 있습니다.

파일 시스템 탐색을 위한 리눅스 명령어

모든 최신 운영 체제와 마찬가지로 리눅스 파일 시스템은 기본 디자인의 핵심에 있으며, 시스템 계층을 시각화하고 조작할 수 있는 다양한 방법을 제공합니다. 파일 시스템을 창의적으로 탐색하는 법을 배우면 Linux 기술이 한 층 성장할 수 있습니다.

1. pwd

pwd는 Print Work Directory의 약자이며, 현재 작업 중인 디렉터리를 보여줍니다. 이것은 현재 사용자가 있는 디렉터리를 보여줍니다. 이는 사용자의 작업을 평화롭게 만드는 것을 목표로 하는 가장 편리한 리눅스 명령어 중 하나입니다.

2. ls

ls 명령 list segments의 약자이며, 아마도 유닉스 세계에서 가장 널리 사용되는 명령 중 하나일 것입니다. 파일과 디렉터리의 모든 정보를 제공하며 특정 디렉터리와 특정 파일의 내용도 제공합니다. 이 명령을 pwd와 함께 사용하여 강력한 Unix 파일 시스템 내에서 길을 탐색할 수 있습니다.

3. cd

리눅스/유닉스는 보통 디렉터리와 파일로 이루어져 있습니다. 특히 사용자가 리눅스를 사용하다 보면 특정 디렉터리 아래 하위 디렉터리를 만들게 되고 여기서 다양한 작업을 하게 됩니다.

리눅스에서 작업하고 있는 현재의 위치를 현재 디렉터리라고 합니다. 기본적으로 디렉터리를 기준으로 파일이나 디렉터리를 찾으려고 시도합니다. 즉 파일 또는 디렉터리의 이름을 절대 경로로 지정하지 않으면 현재 디렉터리를 기준으로 상대적인 위치에서 파일을 찾습니다. 시스템에 로그인하면 홈 디렉터리가 현재 디렉터리가 된다. 이에 해당 디렉터리로 이동하는 방법이 cd 명령어입니다.

4. mkdir

Windows os에서 문서 또는 이미지 파일 등을 정리하기 위해 새 폴더를 만드는 것과 같이 리눅스에서도 새 디렉터리를 만듭니다. 터미널을 통해 새 폴더를 만들고 싶습니까? mkdir 명령은 필요한 권한을 가지고 있다면 Linux 시스템에서 원하는 위치에 폴더를 만들 수 있습니다.

5. rmdir

rmdir은 remove directory의 약자이며, 빈 디렉터리를 삭제할 때 사용하는 명령어이다. 삭제하려는 디렉터리가 비어있지 않을 경우에는 삭제를 할 수 없없습니다.

6. lsblk

Linux 시스템에서 사용 가능한 블록 장치를 나열해야 할 경우가 종종 있습니다. lsblk는 이 목적으로 가장 많이 사용되는 Linux 명령어 중 하나입니다. 이 편리한 리눅스 명령어는 블록 장치의 트리 구조를 나타내며 전문 사용자가 많이 사용합니다.

7. mount

Windows와 달리 SD 카드 또는 USB를 연결할 때마다 배포판이 처음에 직접 표시되지 않을 가능성이 존재합니다. mount 명령을 사용하여 기존 파일 시스템으로 마운트 해야 합니다. 이 리눅스 명령어는 가장 강력한 터미널 명령 중 하나입니다.

8. df

df 명령은 파일 시스템의 디스크 공간에 대한 필수 정보를 표시하는 가장 강력한 Linux 터미널 명령 중 하나입니다. 시스템 관리자가 실시간 서버 또는 네트워크 지향 시스템을 모니터링하고 분석하는 데 널리 사용됩니다. 기본적으로 1,024Byte 블록 단위로 출력하며, 옵션을 통해서 다른 단위로도 출력이 가능합니다.

시스템 조작을 위한 리눅스 명령어

시스템 명령은 Linux 시스템에 대한 정보를 얻는 데 필수적입니다. 이 작업을 위해 많은 강력한 Linux 명령을 사용할 수 있습니다.

9. uname

uname 명령은 이름, 버전 및 기타 시스템 특정 세부 사항과 같은 시스템 정보를 얻기 위한 기본 Linux 명령어입니다. 이 명령으로 OS 및 커널 버전을 빠르게 확인할 수 있으며, 시스템의 명령 길이를 확인할 수 있습니다.

10. ps

이 리눅스 명령어는 현재 시스템에서 실행 중인 프로세스를 시각화할 수 있습니다. 시스템 리소스를 분석하는데 사용되는 매우 유연한 수단이며, 터미널을 통해 기본적으로 시스템 프로세스를 조작할 수도 있습니다. 이 리눅스 명령어는 기본 및 최상의 Linux 모니터링 도구 중 하나로 간주됩니다.

11. kill

kill 명령은 자원 제한으로 인해 멈춘 프로세스를 중지하는 강력한 방법입니다. Linux 시스템 기술을 발전시키시면 이 명령의 본질과 중요성을 알게 될 것입니다. 종종 재미있는 Linux 명령 목록에 표시되는 kill 명령은 이름만큼이나 강력합니다.

12. service

service 명령은 리눅스 터미널에서 시스템 전체 서비스를 호출하기 위한 명령입니다. 시스템 조작을 위한 강력한 Linux 터미널 명령. 터미널 창에서 직접 System V init 스크립트를 실행하기 위해 이 명령을 사용할 수 있습니다.

13. batch

미리 정의된 일정에 따라 시스템 서비스를 실행하는 깔끔한 도구를 찾고 있다면 배치 명령이 있습니다. 자동화 쉘 스크립트 작성을 위한 또 다른 강력한 Linux 명령어 중 하나로 Linux 생산성을 크게 향상시킬 수 있습니다.

14. shutdown

리눅스 명령어 shut down은 halt, init과 함께 시스템을 종료하는 명령어 중 하나입니다. shut down은 현재 접속 중인 모든 사용자에게 시스템이 종료된다는 메시지를 보낼 수 있습니다.

파일 관리를 위한 리눅스 명령어

파일은 Linux 시스템의 중심에 있습니다. 시스템에서 볼 수 있는 거의 모든 것이 일종의 파일이므로 그에 따라 조작할 수 있습니다. Linux 전문가가 되려면 파일 관리 방법을 숙달해야 합니다.

15. touch

touch 명령은 유효한 빈 파일을 작성하기 위한 필수 Linux 명령어입니다. 터미널에서 이동 중에 파일을 생성하고 요구 사항에 따라 나중에 또는 실시간으로 파일을 채울 수 있습니다. 타임스탬프를 변경하기 위한 이동 명령이기도 합니다.

16. cat

처음에 여러 파일을 연결하기 위해 고안된 cat 명령은 이후 다른 목적으로 사용됩니다. 이 리눅스 명령어는 새 파일을 작성하고 터미널에서 파일 내용을 보고 출력을 다른 명령행 도구 나 파일로 리디렉션하는 데 사용합니다.

17. head

head 명령을 사용하면 터미널에서 직접 파일 또는 파이프 된 데이터의 시작을 볼 수 있습니다. 텍스트 처리를 많이 사용하는 사용자가 가장 많이 사용하는 Linux 명령 중 하나입니다. 터미널에서 많은 파일을 처리할 때마다 이 명령을 사용하여 생산성을 향상시킬 수 있습니다.

18. tail

tail 명령어는 파일의 마지막 행을 기준으로 지정한 행까지의 파일 내용 일부를 출력합니다. 기본 값으로 마지막 10줄을 출력해 줍니다. 참고로 head 명령어의 경우에는 파일의 앞 부분을 출력합니다. 리눅스에서 오류나 파일 로그를 실시간으로 확인할 때 매우 유용하게 사용됩니다.

19. cp

cp 명령은 copy의 약어이며, 시스템에서 파일이나 디렉터리를 한 폴더에서 다른 폴더로 복사하도록 지시하는 간단한 방법입니다. 이 깔끔한 명령을 사용하면 터미널에서 바로 여러 파일을 디렉터리로 복사할 수 있습니다.

20. mv

move의 줄임말로 GUI에서 수행하는 절단 작업을 보완합니다. cp와 마찬가지로 mv 명령을 사용하여 하나 또는 여러 파일을 한 위치에서 다른 위치로 이동할 수 있습니다. 이 Linux 명령이 -f 매개 변수를 사용하여 큰 파일을 전송하도록 할 수 있습니다.

21. comm

Linux 세계로 향한 최초의 Unix 명령 중 하나인 comm을 사용하여 두 개의 파일을 공통 행과 구별되는 행으로 비교할 수 있습니다. 이것은 터미널에서 많은 양의 파일을 처리해야 하는 많은 사람들에게 필수적인 리눅스 명령어입니다.

22. less

가장 많이 사용되는 또 다른 Linux 명령어인 less 명령은 파일의 내용을 볼 때 제공하는 편리성 때문에 많이 사용됩니다. cat 과는 달리 less 명령을 사용하면 터미널 세션을 방해하지 않으면서 파일 내에서 양방향으로 탐색할 수 있습니다.

23. ln

ln 명령은 특정 파일에 대한 심벌릭 링크를 만들기 위한 가장 편리한 리눅스 명령어 중 하나입니다. 이 작지만 유연한 명령을 사용하여 디스크 공간의 특정 파일이나 디렉터리에 대한 심벌릭 링크의 여러 인스턴스를 생성할 수 있습니다.

24. cmp

두 파일을 비교하고 결과를 표준 출력 스트림에 인쇄하려면 cmp 명령을 사용하면 정확하게 수행할 수 있습니다. 이 명령어는 comm 명령과 함께 대량의 텍스트 파일을 정기적으로 처리하는 사용자들이 가장 많이 사용하는 Linux 명령어 중 하나입니다.

25. dd

이 명령어는 베테랑 사용자들이 파일을 한 유형에서 다른 유형으로 복사 및 변환하기 위해 가장 많이 사용하는 Linux 명령 중 하나입니다. 이 강력한 명령어에 대한 흥미로운 점은 부팅 가능한 라이브 USB 스틱을 만들 때 다른 터미널 명령 중에서 자주 사용한다는 것입니다.

26. alias

터미널에서 직접 파일의 다른 문자열로 단어를 바꿀 수 있으므로 시스템 관리자가 가장 많이 사용하는 리눅스 명령어 중 하나입니다. 다른 기능 중에서, 쉘을 사용자 정의하고 환경 변수를 조작할 수 있는 최상의 터미널 명령 중 하나입니다.

지루할 때 탐색 할 수 있는 재미있는 리눅스 명령어

터미널 앞에서 즐거운 시간을 보내기 위해 재미있는 리눅스 명령어를 사용할 수 있습니다. 이 터미널 명령은 유닉스 철학에 대한 심층적인 통찰력을 제공하면서 지루함을 되찾을 수 있는 재미있는 Linux 명령어입니다.

27. cal

유닉스가 터미널에 편리한 작은 달력 도구를 제공한다는 것을 알고 계셨습니까? cal 명령은 달력을 ASCII 텍스트 형식으로 표시하는 재미있는 Linux 명령어 중 하나입니다. 지정된 정보를 터미널에 바로 가져오려면 월 및 연도와 같은 매개 변수와 함께 이 명령을 입력해보세요.

28. fortune

이 명령어는 제가 가장 좋아하는 재미있는 리눅스 명령어 중 하나입니다. 터미널에 입력하고 직접 확인하십시오! 독창적이거나 어리석은 구절을 보여줄 것입니다.

29. history

터미널 세션 기록을 확인하고 싶습니까? history 명령을 사용하면 정확하게 수행할 수 있습니다. 매개 변수 없이 입력하면 작은 창에서 터미널 세션의 bash 기록이 인쇄됩니다. 터미널에서 사용할 유용하면서 재미있는 Linux 명령 일뿐만 아니라 터미널 사용에 대한 훌륭한 통찰력까지 제공합니다.

30. yes

yes 명령어는 주어진 문자열을 Ctrl + C키로 멈출 때까지 계속 반복해서 출력해줍니다. 이런 명령어가 왜 필요할까 싶겠지만, 시스템 성능 테스트 같은 것을 할 때 사용할 수 있습니다.
예를 들면 CPU를 100%까지 올려서 컴퓨터의 냉각 시스템이 작동하는지를 테스트할 때 사용할 수 있습니다.

31. banner

구식 유닉스에서 사용되는 멋진 ASCII 배너를 보았고 마음에 드셨나요? banner 명령은 자신만의 맞춤 배너를 만들 수 있는 재미있는 Linux 명령 중 하나입니다. 터미널에 일부 텍스트와 함께 이 명령을 입력해보세요.

32. rev

이것은 베테랑 리눅스 사용자를 위한 또 다른 재미있는 터미널 명령어 입니다. rev 명령은 입력 텍스트를 가져 와서 각 문자를 반대로하여 표준 출력에 기록합니다! 친구에게 비밀스럽고 미묘한 인상을 남기기 위해 사용할 수있는 Linux 명령어 중 하나입니다.

네트워크 관리자에게 가장 많이 사용되는 리눅스 명령어

Linux는 네트워킹을 위해 제공하는 강력함과 유연성으로 전 세계 sysadmins에게 유용한 솔루션입니다. Linux는 우리에게 익숙한 대부분의 컴퓨터 네트워크 뒤에 있습니다. 이 가이드는 초보자를위한 것이므로 네트워킹을 위한 가장 기본적인 터미널 명령만 간략하게 설명합니다.

33. wget

이 명령어는 네트워크 관리자가 터미널에서 바로 웹에서 파일을 다운로드하는데 활용하는 최고의 리눅스 명령어 중 하나입니다. 이것은 스크립트나 크론 작업에 사용될 수 있는 편리한 작은 터미널 명령 중 하나이며, 사용자에게 HTTP, HTTPS 및 FTP 인터넷 프로토콜을 사용할 수 있는 기능을 제공합니다.

34. iptables

iptables 명령은 시스템 관리자가 특정 호스트 시스템에서 들어오고 나가는 인터넷 트래픽을 제어할 수 있는 터미널 유틸리티를 호출합니다. sysadmins는 정기 트래픽을 정의하고 의심스럽거나 신뢰할 수 없는 네트워크 요청을 블랙리스트에 올리는 데 가장 많이 사용하는 Linux 명령어 중 하나입니다.

35. traceroute

이 명령은 네트워크 패킷이 한 시스템에서 다른 시스템으로 이동하는 경로를 결정하기 위해 이 명령을 다른 터미널 명령과 함께 사용하는 보안 전문가가 많이 사용합니다. 이것은 여러 가지 유해한 침입자로부터 컴퓨터를 보호할 수 있는 강력한 네트워크 명령입니다.

36. cURL

cURL은 네트워크를 통해 파일을 전송하여 새로운 Linux 시스템 사용자도 사용할 수 있는 매우 강력한 네트워크 도구입니다. 이것은 사용자 개입 없이 작동하도록 설계된 리눅스 명령어 중 하나이며, 일반적으로 네트워크 관련 쉘 스크립트에 사용됩니다.

Linux 명령어 검색 및 정규 표현식

Linux는 머신을 효과적으로 검색하기 위한 유연한 터미널 명령을 제공합니다. 이러한 Linux 터미널 명령을 강력한 정규식 명령과 결합하면 파일의 특정 파일 또는 시퀀스에 대한 정보를 매우 빠르게 얻을 수 있습니다.

37. find

find 명령어 는 터미널에서 파일을 검색하는데 가장 많이 사용되는 리눅스 명령어 중 하나입니다. 이 강력하면서도 유연한 터미널 명령을 통해 사용자는 파일 권한, 소유권, 수정 날짜, 크기 등과 같은 특정 기준에 따라 파일을 검색할 수 있습니다.

38. which

검색하려는 모든 파일이 실행 파일인 경우 which 명령은 매우 유용합니다. 이 편리한 터미널 명령은 특정 매개 변수를 취하여 $ PATH 시스템 환경 변수에서 이진 파일을 매우 효과적으로 검색합니다.

39. locate

locate 명령은 특정 파일의 위치를 ​​찾는데 사용되는 리눅스 명령어 중 하나입니다. Linux 시스템에서 특정 파일의 위치를 ​​모를 때 활용할 수 있는 가장 간단한 터미널 명령 중 하나입니다.

40. grep

대량의 텍스트 파일에서 패턴을 검색할 때 사용할 수 있는 가장 강력한 정규식 터미널 명령 중 하나입니다. 찾고자 하는 패턴을 입력으로 받아 특정 패턴에 대해 지정된 파일을 검색합니다.

41. sed

지정된 부분을 교체하여 파일 또는 스트림의 각 줄을 조작하는데 가장 많이 사용되는 Linux 명령어 중 하나입니다. 많은 양의 텍스트 데이터를 다루고 이동 중에도 변경해야 하는 사용자들이 많이 사용합니다.

I / O 및 소유권을 다루는 리눅스 명령어

Linux는 I/O 스트림과 파일 또는 디렉터리 소유권을 설정하고 조작하기 위한 강력한 터미널 명령 세트를 제공합니다. 아래에 나열된 Linux 명령어는 이러한 목적을 위한 가장 기본적인 Linux 터미널 명령 중 일부를 간략하게 보여줍니다.

42. clear

clear 명령은 기존 터미널 화면을 지우는데 편리합니다. 이전의 일부 Linux 명령이 터미널 화면을 깨져서 출력이 깨진 후 터미널 화면을 지워야 하는 경우가 종종 있습니다.

43. echo

echo 명령은 터미널 콘솔에 특정 텍스트를 출력할 수 있는 매우 강력한 명령 줄 유틸리티입니다. echo를 입력하고 괄호 안에 일부 텍스트를 입력하면 스스로 확인할 수 있습니다. 이 명령의 흥미로운 점은 출력을 다른 터미널 명령으로 파이프 할 수 있다는 것입니다.

44. sort

정렬 명령은 수행하는 작업에 매우 효과적입니다. 사전 순 또는 역순으로 파일을 정렬해야 할 때마다 이 명령을 사용하십시오.

45. sudo

sudo 명령은 Linux 명령의 성배입니다. 권한이 없는 사용자는 낮은 수준의 권한이 필요한 파일에 액세스하고 수정할 수 있습니다. 종종이 명령을 사용하여 일반 사용자 계정에서 루트에 액세스합니다.

46. chmod

chmod 명령은 시스템 파일 또는 객체의 액세스 권한을 변경하거나 수정하는데 사용하는 가장 강력한 Linux 명령어 중 하나입니다. 이 명령은 사용자로부터 매우 다양한 매개 변수 세트를 취할 수 있으며, 파일 권한 변경에 따라 다릅니다.

47. chown

chown 명령은 chmod 명령과 매우 유사합니다. 그러나 액세스 권한을 변경하는 대신 사용자가 파일 또는 디렉터리의 소유권을 변경할 수 있습니다. chmod 및 chown 터미널 명령은 모두 루트 권한이 필요합니다.

일상적인 사용을 위한 기타 명령어

아래 터미널 명령어는 생산성을 높이고 작업량을 줄이는 데 도움이 됩니다. 상황에 맞지 않을 때마다 이 Linux 명령을 사용하십시오.

48. man

man 명령은 manual을 나타내며, 사용자가 직접 사용할 수 있는 가장 유용한 Linux 명령어 중 하나입니다. 이 명령 다음에 다른 명령의 이름은 해당 명령의 매뉴얼 또는 설명서 페이지를 나열합니다. 특정 터미널 명령을 사용하는 방법을 결정할 때 이 명령을 자주 사용해야 합니다.

49. tar

tar 명령은 파일을 아카이브하고 추출하는데 사용됩니다. 파일을 압축하는데 널리 사용되는 명령으로 이러한 작업을 매우 효율적으로 처리할 수 ​​있습니다.

50. whatis

whatis 명령은 사용자가 제공한 간단한 설명으로 데이터베이스 세트를 순회하며 해당 데이터베이스 명령과 일치하는 시스템 명령을 인쇄합니다.

출처: https://dora-guide.com/linux-commands/

Sub Query: "쿼리 안에 또 다른 쿼리"

""

SELECT col1, (SELECT ...) -- 스칼라 서브쿼리(Scalar Sub Query): 하나의 컬럼처럼 사용 (표현 용도)

FROM (SELECT ...)            -- 인라인 뷰(Inline View): 하나의 테이블처럼 사용 (테이블 대체 용도)

WHERE col = (SELECT ...)-- 일반 서브쿼리: 하나의 변수(상수)처럼 사용 (서브쿼리의 결과에 따라 달라지는 조건절) """

1) Inline view (인라인 뷰)

먼저, FROM 절에 사용하는 서브쿼리부터 살펴볼까요?

위의 설명처럼 인라인 뷰는 SELECT 절의 결과를 FROM 절에서 하나의 테이블처럼 사용하고 싶을 때 사용합니다.

기존 단일 쿼리로는 '테이블에서 각 부서별 최대 연봉' 까지 알 수 있었다면, 서브쿼리를 통해서 누가 최대 연봉자인지 확인할 수 있게 되었습니다.

 EMP 테이블에서 각 부서별 최대 연봉자 확인  

▶ 인라인 뷰를 먼저 보면, '각 부서별 최대 연봉' 을 구한 결과를 메인 쿼리에서 테이블처럼 사용한 것입니다. 해석해보면, EMP 테이블에서 각 부서별 최대 연봉(인라인 뷰)과 같은 연봉 데이터(e.SAL = i.max_sal)를 갖는 직원 조회. 라고 할 수 있겠죠?

인라인 뷰도 테이블처럼 사용하기 때문에 EMP 테이블과 Join 을 하려면 where 절에 조건이 필요하답니다. 그래서 e.DEPTNO = i.DEPTNO 을 써준 것이죠.

여기서 주의할 점은 인라인뷰에 있는 max(sal) 컬럼에 Alias 를 명시해주지 않으면, i.max(sal) 로 사용하게 되겠죠. 이렇게 사용하면 오라클은 WHERE 절에서 max 함수로 인식하게 되므로, max_sal 과 같은 Alias 를 사용한 것입니다.

추가적으로. 서브쿼리에 ORDER BY 절은 올 수 없답니다. 사실 서브쿼리는 출력 용도가 아닌 테이블처럼 사용 용도이므로 굳이 정렬할 필요가 없는 것이죠.

2) Sub Query (일반 서브쿼리)

일반 서브쿼리는 SELECT 절의 결과를 WHERE 절에서 하나의 변수(상수)처럼 사용하고 싶을 때 사용합니다. 조건절은 서브쿼리의 결과에 따라 달라지겠죠.

일반 서브쿼리는 WHERE 절에 사용하는만큼 조건에 필요한 단일 행 서브쿼리와, 다중 행 서브쿼리와 함께 사용됩니다.단일 행 서브쿼리와 다중행 서브쿼리에 따라 연산자를 잘 선택하는 것도 중요하답니다!

1. Single Row Sub Query (단일 행 서브쿼리) : 

단일 행 서브쿼리는 수학을 배웠다면 누구나 다 알만한 연산자입니다.

•  ' = ' : 같다
•  ' <> ' : 같지 않다
•  ' > ' : 크다
•   ' >= ' : 크거나 같다
•  ' < ' : 작다
•  ' <= ' : 작거나 같다

EMP 테이블에서 allen 의 연봉보다 높은 연봉을 받는 사람의 정보 출력

Step 1) 먼저 allen 의 연봉을 확인합니다.

Step 2) 위에서 확인한 연봉을 기준으로 쿼리 작성합니다.

▶ Allen 의 연봉이 오른다면 이 식을 계속 사용할 수 없습니다. 변경될 때마다 계속 수정이 필요하죠. 이 때, where 절에 상수를 사용하지 않고, 상수 대신 무언가의 결과를 재사용하고 싶을 때 서브쿼리를 사용합니다!

Step 3) 위의 두 쿼리를 합쳐줍니다. 

          * 1600 대신 ALLEN 의 연봉을 조회하는 쿼리문을 넣어줍니다.

▶ WHERE 절에 상수를 사용하지 않았기때문에, 이 식은 더 이상 수정할 필요가 없게되겠죠?

2. Multi Row Sub Query (다중 행 서브쿼리) :

• IN : 같은 값을 찾음
• >ANY : 최소값을 반환
• <ANY : 최대값을 반환
• <ALL : 최소값을 반환
• >ALL: 최대값을 반환
•  '=' 은 in 으로 대체
•  '>' , '<' 은 any, all로 대체 가능

 EMP 테이블에서 A로 시작하는 직원과 같은 부서의 직원 출력

먼저, 이름이 A로 시작하는 직원이 있는 부서를 확인해봅니다.

두 개의 부서가 확인되네요. 비교의 대상이 두 개 이상은 대소비교가 불가합니다. 그럴 경우, in 연산자를 사용합니다. 같은 값을 찾는 연산자죠! 쉽게 풀어보면 아래와 같이 사용할 수 있겠죠? deptno 이 20 혹은 30인 행을 조회

 select *   
 from emp  
 where deptno in (20, 30);

이제, 다중 행 서브쿼리를 작성해보면, 아래와 같습니다.

서브쿼리의 결과가 여러 행일 경우 '=', '<', '>' 와 같은 대소비교가 불가합니다.

10 = 20, 30 (?),
10 > 20, 30(?),
10 < 20, 30(?) 

이럴 때 다중 행 서브쿼리의 in 연산자를 사용해주면 됩니다!

그러면 원하던 결과인 EMP 테이블에서 A로 시작하는 직원과 같은 부서(20, 30)의 직원이 출력되겠죠?

EMP 테이블에서 A로 시작하는 직원의 연봉보다 높은 직원 출력         

먼저, A로 시작하는 직원의 연봉을 확인합니다.

이번에도 결과가 두 개죠? 저 두 연봉보다 높은 직원을 조회하려면.. 일단 단일행 비교 연산자를 사용할 수 없겠네요.

select * 
from emp
where sal > min(1100, 1600); 

이렇게 쓰면 Error 입니다!

1100 과 1600 중 최소를 선택하기 위해 min 을 where 절에 사용하면 에러가 발생합니다.

왜냐! 그룹 함수는 where 절에 사용할 수 없기 때문이죠.

이럴 때! 다중 행 서브쿼리의 연산자 any와 all 표현식으로 대체해야합니다.

> any(a, b) : a,b 중 최소보다 큰

> all(a, b) : a,b 중 최대보다 큰

< any(a, b) : a,b 중 최대보다 작은

< all(a, b) : a,b 중 최소보다 작은

1100, 1600 을 대입해보면,

 > any 는 크다와 결합하면 최소를 리턴, 1100 또는 1600 이상이면 1100 리턴

 > all 은 크다와 결합하면 최대를 리턴, 1100 또는 1600 이상이면 1600 리턴

 < any 는 작대와 결합하면 최대를 리턴, 1100 또는 1600 이상이면 1600 리턴

 < all 은 작다와 결합하면 최소를 리턴, 1100 또는 1600 이상이면 1100 리턴

너무 헷갈리죠.. 헷갈리면 where 절이 아닌! 서브쿼리에 min, max 를 사용해도 문제 없습니다. 성능상으로 차이가 없기때문에 해석하기 편하고, 이해하기 편하게 작성하는게 좋습니다. 다시 한번, where 절에는 그룹함수 min, max 사용 불가!

select *
from emp
where sal > any(1100, 1600); 

서브쿼리에 min, max 를 사용할 때와, any, all 을 사용할 때의 결과는 당연히 같습니다.

<서브쿼리에 min 을 사용한 결과>

                                           <any 를 사용한 결과>

3) Multi Column Sub Query (다중 컬럼 서브쿼리)

다중 컬럼 서브 쿼리도 정말정말 중요하다고 합니다. 여러가지 쿼리들을 비교하면서 살펴보기 위해, '인라인 뷰', '다중 컬럼 서브쿼리',  '상호연관 서브쿼리' 와 비교하면서 진행해봅시다!

 Q1. EMP 테이블에서 부서별 최대 연봉자의 이름 조회

 ▶ 마음같아선 다음 식에 ename 을 넣고싶지만.. 문법상 오류로 Error 가 발생합니다. 이를 문제를 해결하기 위해 서브 쿼리를 사용해봅시다!

select deptno, max(sal), ename??(X)  
from emp 
group by deptno;

해결방법 1) Inline View (인라인 뷰) * 대체적으로 인라인뷰가 우수하지만, 간혹! 다중 컬럼 서브쿼리가 좋을 때도 있습니다. 

 ▶ 부서별 최대 연봉 결과를 테이블처럼 사용하였습니다. 그 후, 최대 연봉 결과와 같은 연봉을 가진 직원을 스캔해서 뽑아준 것이죠!

해결 방법 2) Multi Column Sub Query (다중 컬럼 서브 쿼리)

▶ 서브 쿼리의 결과가 여러 행이므로 '=' (eqaul) 은 사용 불가합니다. 그래서 in 연산자로 대체! 첫 번째 사용된 서브 쿼리는 생략이 가능한데, 항상 참의 조건이기 때문입니다. 그리고 어차피 두 번째로 사용된 서브쿼리에서 deptno 기준으로 Grouping 해주기때문이죠.

 => 아래는 첫 번째 서브쿼리를 생략한 모습입니다. 하지만.. 가만보니 결과값은 어떨결에 똑같이 나왔지만,

      이 식은 SAL 컬럼만 비교하므로, 부서 별 비교도 필요합니다. 즉. DEPTNO 과 SAL 동시에 비교해야할 필요가 있죠

      이럴 때 동시에 컬럼을 비교하기 위한 비교식이 다중 컬럼 서브 쿼리라는 것입니다~!

▶ 아래와같이 부서번호, 급여를 세트로 비교해주는 것입니다! 이게 바로 다중 컬럼 서브 쿼리라는 것입니다~!

Q2. STUDENT 테이블에서 각 학년별로 몸무게가 가장 많이 나가는 학생의 이름, 학년, 몸무게 출력

1) Inline View (인라인 뷰)

▶ 서브 쿼리에서 학년별 가장 많이 나가는 몸무게를 구한 후, 테이블처럼 사용합니다. 서브 쿼리와 JOIN을 해주고 학년(GRADE), 무게(WEIGHT) 를 비교해주는 모습입니다.

2) Multi Column Sub Query (다중 컬럼 서브 쿼리)

▶ 서브 쿼리에서 학년별 가장 많이 나가는 몸무게를 구한 후, 학년(GRADE), 무게(WEIGHT) 를 세트로 비교해주는 것입니다! 인라인 뷰 보다 뭔가 더 간결해보이지만.. 뭔가 헷갈리고 어렵죠?ㅠㅠ

Q3. STUDENT 테이블에서 각 학년별로 평균 몸무게보다 많이 나가는 학생의 이름, 학년, 몸무게 출력

1) Inline View (인라인 뷰)  * 인라인 뷰는 그룹별 대소비교가 가능

▶ 서브 쿼리에서 학년별 평균 몸무게를 구한 후, 테이블처럼 사용합니다. 서브 쿼리와 JOIN을 해주고 학년(GRADE), 무게(WEIGHT) 를 비교해주는 모습입니다. 다만, 앞 예시에서는 equal 로 비교했다면 여기서는 대소비교를 하는데, 인라인 뷰에서는 그룹별 equal 비교와 대소비교가 모두 가능하다는 것을 알 수 있습니다.

2) Multi Column Sub Query (다중 컬럼 서브 쿼리) * 다중 컬럼 스브 쿼리는 그룹별 대소비교 불가능

▶ 서브 쿼리에서 학년별 평균 몸무게를 구한 후, 학년(GRADE), 무게(WEIGHT) 를 세트로 비교해주는 것입니다! 하지만 실행해보면 '연산자의 지정이 부적합합니다' 라는 Error 메시지가 뜨게 됩니다. 즉, 멀티 컬럼 서브 쿼리로는 그룹별 대소비교가 불가능하다는 뜻이죠! 이 해결 방안으로, 상호연관 서브쿼리라는 것이 있답니다.

3) 상호연관 서브쿼리  * 상호연관 서브쿼리는 그룹별 대소비교가 가능

▶ 메인 쿼리와 서브 쿼리가 계속 정보를 주고 받는다는 의미로 상호연관 서브쿼리라고 합니다. 다만.. 계속 모든 행마다 정보를 주고받고, 그룹 연산을 각 행마다 반복하므로 데이터의 양이 많아질수록 불리한 쿼리겠죠. 반대로 소수의 데이터에는 상당히 빠른 속도, 좋은 성능을 보여준다고 합니다. 초록색 줄이 쳐져있는 's1.grade = s2.grade' 이 부분에서 각 테이블의 모든 건수(행)마다 반복됩니다. 메인 쿼리의 s1.grade 값을 모든 행마다 요청하면서  s2.grade 값과 비교하는 것이죠. 그러면서 평균 몸무게보다 높은 정보가 발견되면 출력해주는 것이겠죠?

이 예시에서는 각 학년에 대한 정보를 구하므로(grade 를 계속해서 비교) 학년에 대한 그룹별 연산이 필요 없습니다. 그러므로 group by grade 문은 생략 가능합니다!

4) Scalar Sub Query (스칼라 서브쿼리)

스칼라 서브쿼리는 select 절에 사브쿼리를 사용하여 하나의 컬럼처럼 사용하기 위한 목적이 있습니다. 조인(Join)의 대체 표현식으로도 자주 사용됩니다. 하지만, 성능도 좋은 편이 아니고, 주 표현식이 아니므로 참고만 해주시면 되겠습니다!

Q1. EMP 테이블과 DEPT 테이블을 사용하여 각 직원의 이름, 부서번호, 부서명 출력

1) JOIN

▶ EMP 테이블과 DEPT 테이블을 조인(JOIN) 한 결과입니다. JOIN 이 이해가 안 가신다면 아래 링크를 참고해주세요!

2) Scalar Sub Query  

▶ 스칼라는 하나의 라는 의미를 가지고 있습니다. 그렇듯, 서브쿼리의 결과가 하나이길 기대하는 쿼리이죠. 결과는 당연히 조인(JOIN)과 똑같지만, FROM 절에 DEPT 테이블을 사용하지 않고 필요한 데이터만 추출해서 바로 SELET 절에 사용해 준 모습입니다.

 Q2. EMP 테이블과 DEPT 테이블을 사용하여 각 직원의 이름, 부서번호, 부서명 출력

1) Scalar Sub Query  

▶ 아우터 조인(Outer Join) 에서 사용했던 예시인데, 아우터 조인은 null 값이 생략되는 정보도 포함해서 표시하기 위한 조인이라고 했었죠?

그러나! 여기서는 아우터 조인을 사용하지 않았는데, 왜? 어떻게? 매니저(선배 직원)가 없는 직원도 출력되는지 의문이 들 것입니다. 아우터 조인을 사용하지 않았지만, 아우터 조인이 적용된 것 처럼 된 것은 바로바로~~ 메인 쿼리에 where 절이 없으므로 모든 행이 서브쿼리로 넘어갈 것입니다. 

그렇게 되면 서브쿼리는 null 값을 받게 되고 당연히 null 값을 null 로 출력해주게 되겠죠? 이렇게 마치 아우터 조인을 적용한 것처럼 보이는 것이랍니다!

출처 : https://data-make.tistory.com/25

이번 포스팅에서는 IN, EXISTS, NOT IN, NOT EXISTS 에 대해서 보다 상세하게 알아보려고 합니다.

해당 내용은 꼭 SQL Server 뿐만 아니라 MySQL 등에서도 포괄적으로 적용되는 내용입니다.

0. 데이터 세팅

먼저 각 구문에 대해서 비교를 할 때 보다 쉽게 확인할 수 있도록 가상 데이터를 세팅해보도록 하겠습니다. 총 2개의 테이블을 생성하며 각 테이블의 이름과 데이터는 아래와 같습니다.

SELECT * FROM TB_FOOD;

SELECT * FROM TB_FOOD;

SELECT * FROM TB_COLOR;

1. IN

SELECT * FROM TB_FOOD f
WHERE f.number IN (SELECT c.number FROM TB_COLOR c);

이는 우리가 어느정도 예상할 수 있는 결과입니다. 하지만 실제로 IN 을 포함한 쿼리가 어떻게, 어떤 식으로 작동되는지 알아야 이후에 EXISTS 또는 NOT IN / NOT EXISTS와 헷갈리지 않습니다.

위의 쿼리에서는 제일먼저 TB_COLOR 테이블에 접근하게 됩니다. 즉, IN 뒤에 있는 괄호의 서브쿼리를 먼저 실행해서 그에 대한 요소를 가져오는 것이죠. 따라서 사실 IN뒤에 괄호안에는 서브쿼리 이외에도 직접 요소값을 적어줄 수 있습니다.

이후에는 TB_FOOD에서 하나의 레코드를 가져오며 그 레코드의 number 값이 앞에서 가져온 IN 이하의 요소들에 포함되어 있는지를 체크합니다. 그리고 IN 이하의 요소들 중 하나라도 일치한다면 그 레코드를 출력하게 되는 것이죠.

여기서 중요한 것은, 쿼리에서 TB_COLOR에 먼저 접근하여, number 값들을 가져와 리스트로 IN 이하에 뿌려주고, 그 이후에 TB_FOOD에서 하나의 레코드씩 IN 이하의 요소들과 일치하는지 비교한다는 것 입니다.

2. EXISTS

그럼 EXISTS는 어떻게 동작하는지 쿼리와 그 결과를 보도록 합시다.

SELECT * FROM TB_FOOD f
WHERE EXISTS (SELECT c.number FROM TB_COLOR c);

무언가 이상합니다. 우리가 기대했던 결과와는 달리 TB_FOOD 테이블이 그대로 출력되었습니다. 왜 이럴까요? 이는 EXISTS 구문에 대해서 정확히 알지 못하고 잘못 사용하였기 때문에 나온 결과입니다.

위의 쿼리를 기준으로 DB가 어떻게 동작하는지 한번 알아보겠습니다.

IN구문에서는 IN 이후에 나오는 소괄호 내부의 서브쿼리에 대해서 먼저 접근하였습니다. 하지만 EXISTS 구문에서는 다릅니다. 먼저 TB_FOOD에 접근하여 하나의 레코드를 가져오고 그 레코드에 대해서 EXISTS 이하의 서브쿼리를 실행하고 서브쿼리에 대한 결과가 '존재하는지'를 확인합니다.

예시를 들어 생각해보면, 제일 처음에 [ 1 / 치킨 ] 이라는 레코드를 가져왔을 것이고, 해당 레코드에 대해서 SELECT c.number FROM TB_COLOR c 쿼리를 통해 결과가 나오는지 확인합니다. 이때 서브쿼리에 대해 어떠한 결과라도 존재하기만 한다면 참이 되어서 [ 1 / 치킨 ] 레코드가 출력됩니다.

그런데 SELECT c.number FROM TB_COLOR c 쿼리는 사실 TB_FOOD의 어떠한 레코드하고도 연관이 없이 항상 결과값을 가지는 쿼리입니다. 따라서 TB_FOOD의 모든 레코드가 출력되는 것이죠. 그럼 이를 우리가 기대하는 결과대로 출력하도록 하기 위해서는 다음과 같이 쿼리를 수정하면 됩니다.

SELECT * FROM TB_FOOD f
WHERE EXISTS (SELECT c.number FROM TB_COLOR c WHERE c.number = f.number);

이렇게 나온 결과는 사실 IN 구문과 같은 결과를 출력합니다. 하지만 내부적으로 쿼리가 동작하는 방식은 아예 다르다는 것에 주의하시길 바랍니다. 그러한 내부 로직에 따라서 성능차이도 크게 발생하기 때문입니다.

3. NOT IN

이번에는 NOT IN 구문입니다. 먼저 쿼리와 그 결과를 보고 함께 생각해보겠습니다.

SELECT * FROM TB_FOOD f
WHERE f.number NOT IN (SELECT c.number FROM TB_COLOR c);

위의 쿼리를 실행하니 위의 사진과 같이 아무런 결과도 출력되지 않았습니다. 왜 그럴까요?

우리가 처음에 알아본 IN의 방식에 대해서 알아봅시다. IN은 먼저 소괄호의 서브쿼리를 실행합니다. 그럼 SELECT c.number FROM TB_COLOR c 의 쿼리가 실행되고 그 결과로 다음의 리스트가 반환됩니다.

( 1, 2, 3, 4, 5, 6, NULL )

즉, 초기의 쿼리는 다음과 같은 쿼리인 것입니다.

SELECT * FROM TB_FOOD f
WHERE f.number NOT IN ( 1, 2, 3, 4, 5, 6, NULL );

그럼 이제 TB_FOOD에서 하나의 레코드씩 가져올 것이고 IN이 아니라 NOT IN 구문이기 때문에 소괄호의 요소들과 일치하지 않아야 결과로 반환됩니다.

TB_FOOD의 레코드들 중에서 [ 7 / 사탕 ] 레코드를 예로 들어서 생각해보면 해당 레코드의 number 값인 7이 NOT IN 이하의 소괄호에 있는지 확인하면 됩니다. 분명히 7이라는 요소는 존재하지 않습니다. 따라서 우리의 생각대로 라면 해당 레코드는 결과로 출력되어야 하는데 위에서 본 것 처럼 출력되지 않았습니다. 왜 일까요?

이는 DB 에서 해당 요소가 NOT IN 이하의 소괄호의 요소들에 대한 포함여부를 어떻게 판단하는지를 알면 쉽게 이해할수 있습니다. 사실 위의 쿼리는 아래의 쿼리와 같이 동작함으로써 NOT IN 이하의 소괄호에 대한 포함 여부를 판단하게 됩니다.

SELECT * FROM TB_FOOD f
WHERE f.number != 1
AND f.number != 2
AND f.number != 3
AND f.number != 4
AND f.number != 5
AND f.number != 6
AND f.number != NULL;

즉, NOT IN 구문은 TB_FOOD에서 가져온 레코드의 number 값이 소괄호의 모든 요소들과 일치하지 않는지를 체크하는 것입니다. 그런데 위에서는 number 값이 NULL과 연산을 진행하게 되는데, 이때 NULL과의 비교연산은 항상 UNKNOWN 값을 반환하게 됩니다. 따라서 WHERE 절 이하가 TRUE가 아니므로 해당 레코드가 출력되지 않게 되는 것이죠.

이렇게 NOT IN이 어떻게 동작하는지를 알고보니 결국 TB_COLOR에 존재하는 NULL 때문에 우리가 기대하던 결과가 나오지 않음을 알 수 있었습니다. 그럼 우리가 기대한 결과가 나오게 하려면 다음과 같이 쿼리를 수정하면 됩니다.

SELECT * FROM TB_FOOD f
WHERE f.number NOT IN (SELECT c.number 
		FROM TB_COLOR c WHERE c.number IS NOT NULL);

4. NOT EXISTS

그럼 마지막으로 NOT EXISTS에 대해서 알아보도록 하겠습니다.

오히려 NOT EXISTS는 위에서 EXISTS에 대해서 이해했다면 크게 어려운 점이 없습니다. 하지만 그 결과가 NOT IN과 약간 다르죠. 쿼리와 결과를 먼저 보도록 하겠습니다.

SELECT * FROM TB_FOOD f
WHERE NOT EXISTS (
		SELECT c.number FROM TB_COLOR c WHERE c.number = f.number);

위에서 NOT IN을 사용했을 때에는 number 값이 NULL인 레코드는 출력되지 않았습니다. 그 이유를 다시 생각해보자면, IN 구문은 요소간에 비교 연산으로 레코드가 출력되는데 NULL 값에 대한 비교연산은 항상 UNKNOWN을 반환하기 때문이었습니다.

하지만 앞에서 알아볼 때 EXISTS 구문은 다르게 동작했습니다. 위 쿼리를 기준으로 한다면 먼저 TB_FOOD에서 레코드를 가져오고 해당 레코드의 number를 NOT EXISTS 이하의 서브쿼리에 전달하여 해당 서브쿼리에서 값이 존재하는지를 확인합니다. EXISTS 구문이었다면 값이 존재할 때 해당 레코드를 출력하지만, NOT EXISTS 구문이기에 해당 서브쿼리의 값이 존재하지 않으면 해당 레코드를 출력합니다.

여기서 NULL이 출력하는 과정을 한번 더 자세하게 알아보자면, [ NULL / 타코 ] 레코드를 예로 들었을 떄, number = NULL 입니다. 따라서 NOT EXISTS 이하의 쿼리를 확인해보면 다음과 같을 것 입니다.

SELECT c.number FROM TB_COLOR c WHERE c.number = NULL;

이때 우리가 NOT IN에서 알아본 것과 같이 NULL에 대한 비교연산은 항상 UNKNOWN 값을 반환하므로 해당 쿼리의 결과가 존재하지 않게 되고, 이에 따라서 [ NULL / 타코 ] 레코드가 출력되는 것 입니다. 이렇게 IN, EXISTS, NOT IN, NOT EXISTS 에 대해서 알아보았습니다.

출처: https://doorbw.tistory.com/222 [Tigercow.Door]

유, 무선망을 이용하여 신호 전송 시 감쇄 및 손실등으로 인하여 신호의 왜곡 및 에러 발생합니다. 그러면 이번에는 이러한 신호 에러 제어 방식에 대해 알아보도록 하겠습니다.

- 에러 제어 방식에는 ARQ(에러검출), FEC 방식(에러정정), Hybrid-ARQ 방식이 있음

- FEC는 오류정정을 위한 여분의 비트를 추가하여 전송, 수신쪽에서는 이를 이용하여 오류를 검출, 정정하는 방식

- ARQ는 에러 검출 후 재전송 요청하는 방식으로 Stop and Wait ARQ, Go back N ARQ, Selective ARQ, Adaptive ARQ가 있음

- Hybrid-ARQ 방식은 ARQ와 FEC를 조합한 형태로 고속무선통신에 주로 사용

2. FEC

- 무선통신 에러정정

- 오류정정을 위한 여분의 비트를 추가하여 전송하므로 수신쪽에서는 이를 이용하여 오류를 검출하여 정정하는 방식

- 장점: 역채널이 필요없고 연속적인 데이터 전송 가능

- 단점: 코딩방식 복잡, 추가 bit 사용으로 인해 코딩 효율 저하 

3. ARQ

- 에러 검출 후 재전송 요청

가. Stop & Wait ARQ

1) 동작설명

- 송신기에서 데이터(1Frame) 송신 후 자체 타이머를 동작시킴

- 수신측에서는 데이터 수신 성공시 ACK, 실패시 NAK를 전송함

- 송신측이 ACK를 받으면 다음 데이터를 전송하고, NAK를 받거나 Timer 동작시간내에 응답이 없으면 데이터를 다시 송신함

2) 특징

- 신뢰성 있는 통신이 가능하나 고속전송이 불가함

- 저속 문자 방식에 사용됨

- 전송되는 Frame의 수가 한 개이므로 송신측이 기다리는 시간이 길어져 전송효율이 저하됨

나. Go ＆ Back ARQ

1) 동작 설명

- 송신측에서는 윈도우 크기만큼 데이터를 연속적으로 전송하고 수신측에서는 에러 검출 시 NAK 신호를 송신측으로 보냄

- NAK를 받은 송신측은 에러가 발생한 데이터 이후의 데이터를 재전송함

2) 특징

- 데이터 재조립을 위해 송신버퍼메모리가 필요함

- 정지 대기 ARQ보다 성능이 우수하나 채널환경에 따라 적당한 N값 설정이 필요함

다. Selective ARQ

1) 동작설명

- 송신측에서는 수신측으로 연속적으로 프레임을 전송하고, 수신측은 에러 검출 후 에러 발생 시 해당 프레임 정보를 NAK 신호로 송신측으로 전송함

- NAK 신호를 수신한 송신측은 에러발생한 프레임만 수신측으로 재전송함

2) 특징

- 에러가 발생한 프레임만 재전송하므로 효율이 우수함

- 재전송된 프레임 순서 재조립을 위해 큰용량의 송수신버퍼 메모리가 필요함

- 고가이며 LAN 카드에 적용

라. Adaptive ARQ

- BER↑, 블록의 길이↓

- BER↓, 블록의 길이↑ 즉, 에러 발생 확률에 따라 프레임 길이 조절

- 전송 효율은 좋으나 제어회로가 복잡하고 채널 대기시간 발생

4. H-ARQ

 - 무선의 열악한 채널환경에서 신뢰성을 보장하기 위해  FEC(Forward Error Correction) 와 ARQ(Automatic Repeat Request)를 조합한 형태임(3세대 이동통신, Wibro에서 적용됨) 

 - FEC와 비슷한 수준의 정보처리율과 ARQ와 비슷한 수준의 신뢰도를 얻을 수 있음

 - ARQ 방식은 FEC 방식에 비하여 구조가 간단하고 높은 신뢰성을 제공하지만 채널의 BER이 증가하면서 시스템 효율이 저하되며, FEC 방식은 채널의 BER에 상관없는 정보처리율을 유지하지만 신뢰도가 낮음

가. Hybrid-ARQ Type 1

   - 

 - 링크계층(2계층)에서 에러를 감지하고 재전송을 위한 기능을 함

 - 구조가 복잡하고 채널할당이 요구되지만, 빠른 에러정정이 가능하여 고속 Packet서비스에 적합한 에러정정 알고리즘임 

 - Hybrid ARQ 서비스 종류

5. 비교

http://www.ktword.co.kr/abbr_view.php?m_temp1=3150

http://blog.naver.com/PostView.nhn?blogId=golma2&logNo=120207824719

출처: https://ensxoddl.tistory.com/270 [지금 이 순간]

우리나라에서 가장 많이 발생하는 바이러스 피해 사례 1위가 무엇인지 여러분은 알고 계시나요? 

바로 USB 바이러스, 즉 오토런 바이러스라고 합니다. 

휴대가 간편하여 주요 저장매체로 활용되는 USB는 특정 파일을 다운로드 하거나 저장이 아닌 단순히 PC에 꽂는 것만으로도 자동으로 복제되어 감염시키는데요. 그 종류도 다양하게 급증하고 있다고 합니다. 

오토런 바이러스가 어떤 바이러스이고, 이 바이러스로부터 컴퓨터를 안전하게 보호할 수 있는 방법이 무엇인지 소개해드리려고 합니다. 

먼저, 오토런(Autorun, 자동실행)은 CD 또는 USB를 PC와 연결시켰을 때 안에 있는 특정 프로그램을 편리하게 사용할 수 있도록 자동으로

실행하는 기능인데요.

오토런 바이러스(Autorun Virus)는 'autorun.inf' 파일이나, 시스템의 레지스트리에 등록되어 자동 실행되도록 설정된 악성코드이며, 주로 USB같은 이동식 디스크에 복사되어 전파되는 바이러스입니다. 

PC에 설치된 바이러스 백신 프로그램들이 연결된 USB를 검사하기도 전에 악성코드가 실행되기 때문에 사용자들은 속수무책으로 당할 수밖에 없는데요. 사실, 오토런 기능 자체는 바이러스에 연관된 나쁜 기능이 아닌 사용자들의 편의를 위해 만들어진 기능이지만 이를 악용해 악성코드를 심는 사례들이 생겨나면서 오토런에 대한 인식이 바뀌게 되었다고 하네요.

일단 오토런 바이러스에 감염되면, PC 작동 자체에는 크게 영향을 미치진 않지만 PC 사용에 있어서 불편함을 초래하는 악성행위를 합니다. 

시스템이 감염되었을 때는 Windows Explorer에서 오른쪽 버튼을 눌렀을 때 메뉴에서 글씨가 깨져서 나오거나, 숨김 파일 및 폴더 표시, 보호된 운영 체제 파일 숨기기 설정이 변경되지 않으며, 내 컴퓨터에서 저장 장치를 눌렀을 때 새 창에서 열리는 증상을 볼 수 있습니다. 이동식 저장소(USB뿐만 아니라 외장하드, 핸드폰, 메모리카드 등)가 감염되었을 때는 Autorun.inf 파일과 정체를 알 수 없는 실행 파일(*.exe)들이 생기고, 폴더 중에 RECYCLER라는 폴더가 생기게 됩니다. 

오토런 바이러스는 삭제해도 계속 생성이 되는 끈질긴 바이러스이기 때문에 웬만한 백신 프로그램으로도 치료가 잘 되질 않는데요, 다음 단락에서 오토런 바이러스 예방법과 치료 방법에 대해 알아보도록 하겠습니다.

오토런 바이러스를 예방하는 일차적 방법은 위에서 언급된 이동식 저장소가 PC와 연결되면 자동 실행시키는 기능인 오토런이라는 기능을 사용하지 않는 것인데요. 

이동식 저장소의 오토런 기능을 미사용으로 설정해 오토런 바이러스가 실행될 틈을 주지 않으면 됩니다. 또한, USB가 오토런 바이러스에 감염된 상태라면 마우스 우클릭 후 ‘열기’ 를 통해 USB 드라이브에 접속하시기 바랍니다. 

Solution:

이동식 저장소가 오토런 바이러스에 걸렸을 때는 사실 포맷하는 방법이 가장 좋지만 저장해둔 많은 데이터를 다시 옮겨야 하는 번거로움을 겪어야 합니다. 그러나 차선책으로 V3 등의 일반 안티 바이러스 프로그램과 USB on 2.0 프로그램을 다운받아서 바이러스를 치료하고 자동 실행 기능을 막아 오토런 바이러스가 침투하지 못 하도록 한다면 좀 더 안전하게 USB를 사용하실 수 있을 겁니다.

출처: https://blog.skbroadband.com/2755 [SK브로드밴드 공식 블로그]

국가마다 서로 다른 정보 보호시스템 평가기준을 연동하고 평과결과를 상호인증하기 위해 제정된 국제표준 평가기준이다. 

ISO에서 국제표준(IEC 15408)으로 1999년 9월 승인되었다.

현존하는 평가기준과 조화를 통해 평가결과를 상호인정(CCRA)하는 구조로 정보보호시스템의 수출입에 소요되는 인증비용 절감으로 국제유통 촉진, 정보보호시스템 보안등급 평가에 신뢰성을 부여한다.

평가수행지침으로 CEM(Common Evaluation Methodology) 문서가 있으며, 인증서는 CCRA(CC Recognition Arrangement)에 가입되어야 효력을 발휘한다. 평가인증 결과를 국가 간 상호인증하도록 하는 협정(CCRA, Comon Criteria Recognition Arrangement)이 미국, 영국, 프랑스등을 중심으로 시작되었다.

TCSEC와 다르게 단일평가 기준으로 다양한 정보보호 제품을 평가한다.

소개 및 일반모델, 보안 기능 요구사항, 보증 요구사항 등으로 이루어지고 등급은 7개로 나뉜다.

Evaluation Assurance Level
EAL0등급(부적절-무등급 취급)

CC의 등급별 보안 수준- EAL1(기능시험) ~ EAL7급(정형적 보증) 7개

CC의 구성요소

출처: jjinfotech.tistory.com/79