일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- JavaScript
- 김성박
- vmin
- 가상클래스 선택자
- 다시보자
- 서블릿
- HTML Templating
- 깃헙
- 소스트리
- 속성 선택자
- 보충필요
- EDWITH
- optgroup
- jsp
- 부스트코스
- ES6
- vmax
- 가상요소 선택자
- 웹개발
- 자바
- spring
- datalist
- 부정 선택자
- 즐거운자바
- 상속
- 즐거운 자바
- nth-of-type()
- nth-child()
- 다시볼 것
- 복합 선택자
Archives
- Today
- Total
기억의 DataBase
Computing 환경에 대한 이해 본문
- DataBase를 공부하기 위해서 OS를 이해해야 하는 이유는?
DBMS의 경우 Performance를 위해 OS의 기능을 일부 담당(Disk 관련)하기 때문이기도 하고(No Device)
>> 전체 OS 기능을 하는 경우 DB Machine이라고 부른다.
OS뿐 아니라 전반적인 Computing 환경을 이해해야,
문제발생 시 원인을 진단할 수 있기 때문에 OS에 대한 이해는 필수!
문제발생 시 원인을 진단할 수 있기 때문에 OS에 대한 이해는 필수!
위의 모습을 개략적인 Computing 환경이라고 보았을 때 OS(Operating System)는
모든 Application과 DBMS의 기반이 된다.
모든 Application과 DBMS의 기반이 된다.
이러한 기반이 되는 Program을 이해하지 못하고 Application 차원의 이해에만 그친다면
Senior 개발자가 되어 설계를 할때 한계에 부딫치거나, Application Debugging에만 매달리며
엉뚱한 해결책을 내놓을 수 있다.
엉뚱한 해결책을 내놓을 수 있다.
DBMS도 일종의 Application이라고 할 수 있으나 다른 Application에 필요한 Data를 제공하는 경우
OS와 Application 사이에 존재한다고 할 수 있다.
- H/W에 대한 이해
CPU : 실제 작업수행이 이루어지고 있는 장치 - TimeSharing을 통해 스케쥴링 하여, 수행을 나눠 실행
MainMemory : 당장 수행하는 Application을 올려두는 Memory 장치
HardDisk : 당장 실행하는 Application이 아닌 것을 저장해두는 Memory 장치(Application 보관)
Controller? : HD, I/O Device, Network 등과 MainMemory간에 연결규칙으로 공통규약을 가지고 있음
- Application 실행과정
H/D > M/M > CPU
- MainMemory내 Application의 구조
Header : OS가 관리하는 부분으로, Process의 Pointer를 가지고 있음
Method : Application의 연산을 가지고 있는 부분으로 같은 프로그램이 여러개 올라올 경우,
Method 부분은 다른 실행과 공유! (중복된 Method로 인한 Memory 낭비를 방지)
Data : Application의 변수와 결과값 등의 내용을 담는 부분
※ 메모리 상주 프로그램 - MainMemory내에 항상 실려있는 프로그램으로
OS가 시작되어야 실리는 시작프로그램과는 다른 의미
※ MainMemory가 모자라면 HardDiskMemory를 끌어다가 사용(Memory Extension)
>> 영구저장이 아니라 임시보관하는 것
- Memory Swapping
MainMemory와 HD 간에 당장 사용하는 프로그램과
아닌 프로그램(INSTANCE)을 교환하며 Memory활용을 극대화하는 것
(Paging의 경우 사용하는 Method만을 교환)
- Swapping은 가급적 피해야함
CPU와 OS간 속도 >>>>> OS와 HD간 속도
(MainMemory 증설을 통해 Memory 부족을 극복하는 것이 가장 바람직 )
- BUS
CPU - OS - DEVICE 간의 Communicater
HW가 좋아도 BUS 구성이 안좋으면 성능이 HW만큼 못나옴(컴퓨터의 혈관)
- FileSystem == DBMS(OS)
- Physical
같은 Sector 내에서 한줄에 들어가는 데이터의 양은 같다
>> 바깥쪽이 길다고 해서 더 많은 데이터가 저장되는 것은 아니다!
외부충격이 있을 경우 바깥쪽 디스크가 더 안전한 것은
Data가 오밀조밀 모여있지 않기 때문(안정성 측면에서 Index를 바깥쪽에 저장하는 것이 좋다)
- Logical
- Index
windows : FAT / UNIX : I-Node
데이터의 위치에 관한 정보를 담고 있는 부분
0번은 시작할때 OS를 정하는 BOOT 정보
1번은 C,D,E 등의 ROOT 정보(드라이브의 위치)
2. DataBlock(Sector의 배수로 Block수를 잡는 것이 정석)
실제 Data의 내용을 담고 있는 부분으로 파일 1개에 한글자라도 쓰면 크기에 관계없이
1 block을 할당받음(비효율적)
1 block을 할당받음(비효율적)
>> Block을 더 쪼개서 효율을 추구하는 Fragment도 존재
※ Index 부분에 할당한 용량이 부족하면 DataBlock쪽의 Block을 Index로 사용가능(Extension)
이 Block도 다차면 다른 Block을 이어지는 Index로 사용가능하나 성능면에서 비추천
- FORMAT
FileSystem 내에서 Index와 Block을 할당하여 가르는 것
- PARTITION
FileSystem 자체를 가르는 것 (C, D, E)
- COMPRESS
디스크 정리의 개념으로 산재한 Data를 찾기 쉽게 정리하여 성능을 향상
정확하지 않은 정보가 많을 수 있습니다.
사용에 유의하시고 피드백 주신다면 더욱 감사하겠습니다 :)
Comments