프로세스와 스레드의 차이 

프로세스는 운영체제로부터 자원을 할당받아 실행되고, 스레드는 프로세스로부터 자원을 할당받아 실행된다.

하나의 프로세스 안에서 여러 스레드를 생성 가능하다. 각 스레드는 개별 스택을 가지고, 프로세스의 전역 메모리 공간을 공유하며, 프로그램을 실행한다.( 프로세스는 코드, 데이터, 스택, 힙 메모리 영역을 기반으로 실행하며, 스레드는 프로세스 안에서 개별적 스택을 가지고, 코드, 데이터, 힙 영역을 공유하며 실행된다.)

스크립트언어와 컴파일 언어의 차이점

스크립트 언어는 python, ruby, php 등 인터프리터 언어이며, 컴파일 언어는 java, c, c++ 등이 있다.

컴파일 언어는 컴파일러를 통해 컴파일되어, 기계어 상태로 실행된다. 속도가 빠르며 기계어 번역시 최적화를 통해 속도 향상이 가능하다. 스크립트 언어는 실행 단계에서 한줄씩 기계어로 변환 후 실행된다. 속도가 느리며 최적화가 어렵다.

동기비동기 차이점

동기식은 요청에 대한 응답을 기다린 후 응답이 오면 다음 요청을 하는 방식이고 비동기식 일처리는 요청에 대한 응답을 기다리지 않고 일처리를 진행하는것

동기비동기의 장단점

동기식 구성은 단순하고 순서가 보장되는 실행이 가능하다. 여러일 동시 수행 멀티태스킹이 불가능하다.

비동기식은 동시에 여러 일을 수행할 수 있지만, 일정 시간당 요청량이 많은 경우 부하가 발생할 수 있다.

DB인덱스 사용 이유와 장단점

데이터의 양이 많아 인덱스를 사용한다. 인덱스는 데이터를 논리적으로 정렬해서 검색과 정렬 속도를 높이기 위해 사용한다. 단, 데이터 삽입, 변경이 수시로 일어나면 매번 인덱스를 변경해야하는 단점이 존재한다. 성능 저하를 막기 위한 고려 필요.

Redis와 mongoDB

둘다 Nosql 방식을 사용하는 것으로 몽고디비가 document 형식으로 데이터를 저장하는데 반해, Redis는 key-value 형식으로 데이터를 저장한다. Redis는 인메모리 DB로 데이터를 메모리에 저장하고 관리하여 성능이 좋지만 데이터가 유한저장되어 캐시와 같이 저장 기한이 있고 성능위주 기기에 사용된다. 몽고디비는 mysql 처럼 서버-클라이언트 방식으로 가변데이터 구조를 다루는데 유용하다.

JVM과 JAVA 프로그램 실행과정

JVM은 자바가상머신의 약자로 자바프로그램을 자바 API를 기반으로 실행하는 역할을 한다. 프로그램이 실행되면 JVM이 OS로부터 메모리를 할당받고 자바 바이트코드로 변환된 class 파일을 class 로더를 통해 jvm으로 로딩시킨다. 로딩된 class 파일은 execution engine을 통해 해석되고, 실행된다. 필요시 garbage collection을 수행해서 불길한 메모리를 해제한다.

JVM은 OS로 부터 할당 받은 메모리를 세영역으로 분리

메소드 영역, JVM 스택, 힙 영역
힙 영역에 생성된 객체가 저장되고 힙영역은 Young, Old, Permanent generation으로 나뉘고 young영역에 eden, S0, S1로 세분화 된다. 이때 eden이 가득차면 Minor GC가 실행되고 Old가 가득차면 Major GC 가 작동한다. (큰 문제)

GC의 필요이유

메모리를 명시적으로 지정해서 해제하지 않기 때문에 필요하다. 경우에 따라 더이상 필요없는 객체를 찾아 지우는것이 필요하다.

Overwriting 과 Overloading

둘다 oop에서 중요한 다형성에 해당하는 내용으로 함수 재정의는 상속받은 경우 부모함수와 다른 작업을 위해 내용을 바꾸는 것이며 오버로딩은 파라미터의 자료형이나 개수가 다른 형태이다.

interface 와 abstract의 차이

두 경우 모두 new가 불가능하며 상속시 interface와 abstract 로 나뉜다.

abstract : 추상 클래스는 추상 메소드를 1개 이상 가지고 있는 클래스를 의미한다.

기존 메소드 이외에 추상 메소드를 상속시켜서 반드시 구현이 필요한 추성 메서드를 상속받은 클래스에서 구현시키는것이 주 목적이다.

interface : 상수와 메서드의 선언 집합으로 implements를 받은곳에서 구현을 강제시킨다. 인터페이스를 이용한 다중 상속이 가능하다.

디자인패턴 : 공통적인 소프트웨어 코드 작성 문제를 해결하는데 도움이 될 수 있는 패턴 소프트웨어 라이브러리를 쉽게 사용할 수 있게 해준다. 또한, 쉽게 이해하기 위한 공통 작업에 대해 간편한 메소드를 제공한다.

싱글톤패턴 : 전체 프로그램에서 단 1개의 객체만 생성하여 공유할 수 있는 코드 패턴

퍼사드패턴 : 클래스 라이브러리 같은 어떤 소프트웨어의 다른 커다란 코드 부분에 대한 간략화 된 인터페이스를 제공하는 객체를 만드는 코드 패턴 라이브러리 밖 코드가 라이브러리 안 코드에 의존을 줄여준다.

예) class Cpu, class Memory, class HardDrive 를 class Computer에서 구현해서 밖에서는  class Computer만 이용한다.
이때, class Computer가 facade가 되는것이다.

파이썬 generator란?

제너레이터는 Iterator를 생성해주는 함수로, 함수 안에 yield 키워드를 사용한다.

Iterator는 next() 메소드를 이용해 데이터를 순차적으로 접근할 수 있는 함수이다. Generator는 한번에 모든 데이터를 메모리에 적재할 필요가 없어서 메모리 효율이 높고 계산 결과가 필요할 때까지 계산을 늦출 수 있으므로 수행 시간이 긴 연산을 필요한 순간까지 늦출 수 있다는 장점을 가지고 있다.

파이썬 GIL

한번에 하나의 쓰레드만 수행할 수 있도록 인터프리터에 lock을 거는 기능

파이썬 객체는 GC를 위해 reference count를 가지고 있는데, 해당 객체를 참조할 때마다 이 count를 변경해야 한다. 멀티 쓰레드를 실행하게 되면, 각 스레드가 공유하는 객체들에 대해 각각 lock을 거는경우 성능상 이슈와 dead lock 발생 위험이 존재하기 때문에 인터프리터 레벨에서 한 시점에 실행되는 스레드는 1개로 제한한다.

이를 해결하기 위해 Multiprocessing 라이브러리를 사용하면 개별 프로세스가 생성되고 프로세스별 인터프리터 락이걸려 동시 실행이 가능해진다.

클래스와 객체의 차이점

클래스는 객체를 만들기 위한 하나의 틀이라고 생각할 수 있으며, 클래스를 구현화 하면 객체가 된다.

JAVA 접근제한자

public : 동일클래스, 동일패키지, 다른 패키지의 자식클래스, 다른패키지

protected : 동일클래스, 동일패키지, 다른 패키지의 자식클래스

default : 동일클래스, 동일패키지

private 동일 클래스

객체지향 5대 원칙

1. Single Responsiblity Principle (단일 책임 원칙)

 - 소프트웨어의 설계 부품(클래스, 함수 등)은 단 하나의 책임만을 가져야 한다. 여기서 책임이란, '기능' 정도의 의미로 해석하면 된다.

설계를 잘한 프로그램은 기본적으로 새로운 요구사항과 프로그램 변경에 영향을 받는 부분이 적다. 다시말해, 응집도는 높고 결합도는 낮은 프로그램을 뜻한다. 만약 한 클래스가 수행할 수 있는 기능, 즉 책임이 많아진다. 책임이 많아지면 클래스 내부의 함수끼리 강한 결합을 발생할 가능성이 높아진다. 이는 유지보수에 비용이 증가하게 되므로 따라서 책임을 분리시킬 필요가 있다.

2. Open-Closed Principle (개방-패쇄 원칙)

 - 기존의 코드를 변경하지 않고(Closed) 기능을 수정하거나 추가할 수 있도록(Open) 설계해야 한다.

OCP에 만족하는 설계를 할 때 변경되는 것이 무엇인지에 초점을 맞춘다. 자주 변경되는 내용은 수정하기 쉽게 설계 하고, 변경되지 않아야 하는 것은 수정되는 내용에 영향을 받지 않게 하는 것이 포인트다. 이를 위해 자주 사용되는 문법이 인터페이스(Interface)이다. 다음 예제를 함께 보자.

class SoundPlayer{
	void play(){
    sysout("play wav");
    }
}

public class Client {
	public static void main(String[] args) {
    	SoundPlayer sp = new SoundPlayer();
        sp.play();
        }
    }
}

SoundPlayer 클래스는 음악을 재생해주는 클래스이다. 이 클래스는 기본적으로 wav파일을 재생할 수 있다. 그러나 SoundPlayer가 다른 포맷의 파일, 예를 들어 Mp3 파일을 재생하도록 요구사항이 변경 되었다고 하자. 요구사항을 만족 시키기 위해서는 SoundPlayer의 play() 메소드를 수정하여야 한다. 그러나 이러한 소스코드 변경은 OCP 원칙에 위배된다. 

그렇다면 어떻게 해야 OCP 원칙을 만족시킬 수 있을까? 다양한 방법이 있지만 여기선 앞에서 언급한 인터페이스를 이용하여 OCP를 만족시켜 보자. 먼저 변해야 하는것은 무엇인지 정의한다. 위 클래스에서는 play() 메소드가 변해야 하는 것이다. 따라서 play() 메소드를 인터페이스로 분리한다.

interface playAlgorithm{
	public void play();
}

class Wav implements playAlgorithm{
	@override
    public void play() {
    	sysout("play Wav");
	}
}

class Mp3 implements playAlgorithm{
	@Override
    public void play() {
    	sysout("play Mp3");
	}
 }

 

일단 재생하고자 하는 파일 클래스(Wav, Mp3)를 만들어 PlayAlgorithm 인터페이스의 play() 메소드를 재정의하도록 설계한다.

class SoundPlayer{
	private playAlgorithm file;
    
    public void setFile(playAlgorithm file) {
    	this.file = file;
	}
    
    public void play(){
    	file.play();
    }
}

public class Client {

	public static void main(String[] args) {
    	
        SoundPlayer sp = new SoundPlayer();
        sp.setFile(new Wav()); // 또는
        sp.setFile(new Mp3()); // 선택
        
        sp.play();

 

SoundPlayer 클래스에서는 playAlgorithm 인터페이스를 멤버 변수로 만든다. 그 후 SoundPlyaer의 play() 함수는 인터페이스를 상속받아 구현된 클래스의 play()함수를 실행시키게 한다. 마지막으로 메인함수에서 setter를 이용하여 우리가 플레이하고자 하는 파일의 객체를 지정해주면 된다.

앞에서 언급하진 않았지만 이와 같은 설계를 디자인 패턴에서는 Strategy Pattern(전략 패턴)이라고 한다.

결과적으로 우리는 SoundPlayer 클래스의 변경 없이 재생되는 파일을 바꿀 수 있으므로 위 코드는 OCP를 만족한다. 앞서 말했듯이 OCP를 만족한 설계는 변경에 유연하므로 유지보수 비용을 줄여주고 코드의 가독성 또한 높아지는 효과를 얻을 수 있다.

3. Liskov Substitution Principle (리스코프 치환 원칙)

 - 자식 클래스는 부모클래스에서 가능한 행위를 수행할 수 있어야 한다.

리스코프 치환 원칙은 MIT 컴퓨터 사이언스 교수인 리스코프가 제안한 설계 원칙이다. 부모 클래스와 자식 클래스 사이의 행위에는 일관성이 있어야 한다는 원칙이며, 이는 객체 지향 프로그래밍에서 부모 클래스의 인스턴스 대신 자식 클래스의 인스터스를 사용해도 문제가 없어야 한다는 것을 의미한다.

상속 관계에서는 일반화 관계(IS-A)가 성립해야 한다. 일반화 관계에 있다는 것은 일관성이 있다는 것이다. 따라서 리스코프 치환 원칙은 일반화 관계에 대해 묻는 것이라 할 수 있다.

이해를 돕기위해 도형을 예시를 들어보자. 도형 클래스와 사각형 클래스가 있고, 사각형 클래스는 도형 클래스의 상속을 받는다고 가정하자. 

(1) 도형은 둘레를 가지고 있다. 
(2) 도형은 넓이를 가지고 있다. 
(3) 도형은 각을 가지고 있다. 

일반화 관계(일관성인지 확인하는 방법은 단어를 교체해 보면 알 수 있다.  (1) ~ (3)의 도형이란 단어 대신 사각형을 넣어보자. 

(1) 사각형은 둘레를 가지고 있다. 
(2) 사각형은 넓이를 가지고 있다. 
(3) 사각형은 각을 가지고 있다. 

(1) ~ (3) 모두 딱히 이상한 부분이 보이지 않는다. 따라서 도형과 사각형 사이에는 일관성이 있다고 할 수 있다. 

여기서 원(Circle) 이라는 도형에 대해 생각해보자. 원 클래스 역시 도형 클래스의 상속을 받는다고 가정하자. 앞에서 언급한 (1) ~ (3)의 도형 단어 대신 원을 대입해보자. 

(1) 원은 둘레를 가지고 있다. 
(2) 원은 넓이를 가지고 있다. 
(3) 원은 각을 가지고 있다. 

문장을 읽어보면 (3)번 문장이 어색하다는 것을 알 수 있다. 따라서 도형 클래스는 LSP을 만족하지 않은 설계라 할 수 있다. 따라서 (3)문장에 대해서는 일반화 관계가 성립하도록 수정되어야 한다. 

4. Dependency Inversion Principle (의존 역전 원칙)

- 의존 관계를 맺을 때, 변화하기 쉬운것 보단 변화하기 어려운 것에 의존해야 한다는 원칙이다.

여기서 말하는 변화하기 쉬운것이란 구체적인 것을 말하고, 변화하기 어려운 것이란 추상적인 것을 말한다. 객체지향적인 관점에서 보자면 변화하기 쉬운것이란 구체화 된 클래스를 의미하고, 변화하기 어려운 것은 추상클래스나 인터페이스를 의미한다. 따라서 DIP를 만족한다는 것은 의존관계를 맺을 때, 구체적인 클래스보다 인터페이스나 추상 클래스와 관계를 맺는다는 것을 의미한다.

DIP를 만족하면 '의존성 주입' 이라는 기술로 변화에 유연한 설계를 할 수 있다.  앞에 언급한 SoundPlayer 클래스 다시 보자.

우리는 setFile 클래스를 이용하여 실행하고자 하는 파일을 쉽게 바꿀 수 있다. 마찬가지로 새로운 오디오 파일 포맷(예를들면 FLAC)을 실행시키고자 한다면, 새로운 클래스(FLAC)를 만든 후 play 인터페이스를 상속받아 구현한 후 setFile 메소드를 이용하여 file 멤버 변수에 주입시키면 된다. 이와같은 기술을 '의존성 주입' 이라 한다.

5. Interface Segregation Principle (인터페이스 분리 원칙)

- 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다. 하나의 일반적인 인터페이스보다는, 여러 개의 구체적인 인터페이스가 낫다. 이는 다시 말해서, 자신이 사용하지 않는 기능(인터페이스)에는 영향을 받지 말아야 한다는 의미이다.

한가지 예를 들어보자. 우리는 스마트폰으로 전화, 웹서핑, 사진 촬영 등 다양한 기능을 사용할 수 있다. 그런데 전화를 할 때에는 웹서핑, 사진촬영 등 다른 기능은 사용하지 않는다. 따라서 전화기능과 웹서핑 기능 사진 촬영 기능은 각각 독립된 인터페이스로 구현하여, 서로에게 영향을 받지 않도록 설계해야 한다. 이렇게 설계된 소프트웨어는 인터페이스 분리 원칙을 통해 시스템의 내부 의존성을 약화시켜 리팩토링, 수정, 재배포를 쉽게 할 수 있다. 

MVC 패턴

Model View Controller의 약자로 에플리케이션을 세가지의 역할로 구분한 개발 방법론이다. 아래의 그림처럼 사용자가 Controller를 조작하면 Controller는 Model을 통해서 데이터를 가져오고 그 정보를 바탕으로 시각적인 표현을 담당하는 View를 제어해서 사용자에게 전달하게 된다.

위의 모델을 웹에 적용하면

1. 사용자가 웹사이트에 접속한다. (Uses)

2. Controller는 사용자가 요청한 웹페이지를 서비스 하기 위해서 모델을 호출한다. (Manipulates)

3. 모델은 데이터베이스나 파일과 같은 데이터 소스를 제어한 후에 그 결과를 리턴한다.

4. Controller는 Model이 리턴한 결과를 View에 반영한다. (Updates)

5. 데이터가 반영된 VIew는 사용자에게 보여진다. (Sees)

Controller
사용자가 접근 한 URL에 따라서 사용자의 요청사항을 파악한 후에 그 요청에 맞는 데이터를 Model에 의뢰하고, 데이터를 View에 반영해서 사용자에게 알려준다. 

Model
일반적으로 CI의 모델은 데이터베이스 테이블에 대응된다. 이를테면 Topic이라는 테이블은 topic_model이라는 Model을 만든다. 그런데 이 관계가 강제적이지 않기 때문에 규칙을 일관성 있게 정의하는 것이 필요하다.

View
View는 클라이언트 측 기술인 html/css/javascript들을 모아둔 컨테이너이다. 

브라우저는 어떻게 렌더링 되는가? https://d2.naver.com/helloworld/59361

가상DOM과 DOM의 차이점

하나의 큰 HTML 문서를 DOM으로 가지는 상태에서 부품 컴포넌트를 조립하는 듯 다루는 개념이다.

부품들이 Virtual DOM에 해당한다. 리액트에서 뜯어서 모듈화로 불러오듯 말이다.

const VirtualDOM = () => {
	return
    	<div>
        	<p>Virtual DOM</p>
        </div>
};

위의 코드와 같이 함수를 불러 HTML 내용을 가져다 쓰는것을 말한다. 여기서 함수 VirtualDOM 가상돔 역할을 한다.

HTML에서 부분만 수정하는것을 가능하게 해준 방법이다.

컨텍스트 스위칭

프로세스 p0과 p1이 존재할때, p0이 cpu를 점유중이었고, p1이 대기중 상태에서 잠시후 p1이 실행되고 p0가 대기가 되는 상태가 찾아온다. 이때, p0이 실행중에 대기로 변하게 될 때는 작업해오던 내용을 PCB라는 곳에 저장하게 된다.

p0은 PCB에 저장해야하고 p1은 PCB에서 데이터를 가져와야한다. 이러한 과정을 컨텍스트 스위칭이라 한다.

컨텍스트 스위칭을 통해 멀티 프로세싱과 멀티 스레딩의 운영이 가능해진다.

PCB는 프로세스 생성시 메모리에 할당되는 공간이다.

컨텍스트 스위칭의 단점

위의 그림처럼 p0의 실행 상태에서 대기 상태가 될 때 바로 p1이 실행 상태가 되는것이 아니다. 그 사이에 cpu가 아무 작업을 하지 않는 공백상태가 존재하는데 이러한 문제로 컨텍스트 스위칭이 잦으면 오버헤드가 쌓여 성능이 떨어지게 되는 단점이 있다.

컨텍스트 스위칭 인터럽트

I/O interrupt, cpu 사용시간, 만료 자식 프로세스 fork 가 일어날때 인터럽트가 발생한다. 이러한것은 프로세스 스케줄러가 결정한다.

스레드가 프로세스보다 빠른 이유도 이것이 작용한다. 스레드는 스택을 제외한 영역을 프로세스에서 공유하고, PCB 스레드 고유의 것인 스택 영역만 저장하기 때문에 빠르다.

가상 메모리

RAM을 관리하는 방법의 하나로, 각 프로그램에 실제 메모리 주소가 아닌 가상의 메모리 주소를 주는 방식을 말한다.

멀티태스킹 운영 체제에서 흔히 사용되며, 실제 주기억장치보다 큰 메모리 영역을 제공하는 방법으로도 사용된다.

가상 주소 공간은 메모리 관리 장치(MMU)에 의해서 물리 주소로 변환된다. 이 덕분에 프로그래머는 가상 주소 공간상에서 프로그램을 짜게 되어 프로그램이나 데이터가 주메모리상에 어떻게 존재하는지를 의식할 필요가 없어진다. 대부분의 현대적 아키텍처와 운영 체제는 가상 메모리 기능을 제공한다.

가상 메모리는 크게 나누어 세그먼트(segment) 방식과 페이징 방식의 2종류가 있다. 

페이징 기법은 컴퓨터가 메인 메모리에서 사용하기 위해 2차 기억 장치로부터 데이터를 저장하고 검색하는 메모리 관리 기법이다. 즉, 가상기억장치를 모두 같은 크기의 블록으로 편성하여 운용하는 기법이다. 이때의 일정한 크기를 가진 블록을 페이지라고 한다. 주소공간을 페이지 단위로 나누고 실제기억공간은 페이지 크기와 같은 프레임으로 나누어 사용한다.

페이징 기법이 적용된 시스템에서 가상주소는 순서쌍 (p,d)로 나타낼 수 있다. p는 가상기억장치 내에서 참조될 항목이 속해 있는 페이지 번호이고, d는 페이지 p 내에서 참조될 항목이 위치하고 있는 곳의 변위이다.

어떤 프로세스가 현재 참조하고 있는 페이지가 주기억장치 내에 있다면 그 프로세스는 수행될 수 있다. 반대로 주기억장치 내에 없다면 그 해당 페이지를 보조기억장치로부터 읽어와서 페이지 프레임의 한 블록에 저장한다.

메모리 세그먼트 방식은 메모리 보호를 수행하는 가장 일반적인 방법 가운데 하나이다. 세그먼트를 사용하는 컴퓨터 시스템에서 메모리 위치를 참조하는 명령어 피연산자는 세그먼트와 그 세그먼트 안의 오프셋을 증명하는 값을 포함하고 있다.

트랜젝션

데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위 또는 한꺼번에 모두 수행되어야 할 일련의 연산들을 의미한다.

1. 트랜잭션은 데이터베이스 시스템에서 병행 제어 및 회복 작업 시 처리되는 작업의 논리적 단위이다.

2. 사용자가 시스템에 대한 서비스 요구 시 시스템이 응답하기 위한 상태 변환 과정의 작업단위이다.

3. 하나의 트랜잭션은 Commit되거나 Rollback된다.

Atomicity(원자성)

1. 트랜잭션의 연산은 데이터베이스에 모두 반영되든지 아니면 전혀 반영되지 않아야 한다.

2. 트랜잭션 내의 모든 명령은 반드시 완벽히 수행되어야 하며, 모두가 완벽히 수행되지 않고 어느하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 한다.

Consistency(일관성)

1. 트랜잭션이 그 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 변환한다.

2. 시스템이 가지고 있는 고정요소는 트랜잭션 수행 전과 트랜잭션 수행 완료 후의 상태가 같아야 한다.

Isolation(독립성,격리성)

1. 둘 이상의 트랜잭션이 동시에 병행 실행되는 경우 어느 하나의 트랜잭션 실행중에 다른 트랜잭션의 연산이 끼어들 수 없다.

2. 수행중인 트랜잭션은 완전히 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조할 수 없다.

Durablility(영속성,지속성)

1. 성공적으로 완료된 트랜잭션의 결과는 시스템이 고장나더라도 영구적으로 반영되어야 한다.

RDBMS 와 NoSQL 차이점

RDBMS

관계형 데이터베이스 관리 시스템입니다. RDBMS는 정해져있는 데이터 스키마에 따라 데이터베이스 테이블에 저장되며, 관계를 통한 테이블간 연결을 통해 사용됩니다. 이 때문에 RDBMS는 데이터 관리를 효율적으로 하기위해 구조화가 굉장히 중요 
장점으로는 정해진 스키마에 따라 데이터를 저장하여야 하기 때문에 명확한 데이터 구조를 보장. 각 데이터에 맞게 테이블을 나누어 데이터 중복을 피해 데이터 공간을 절약 단점으로 RDBMS 관계로 인한 시스템 복잡도를 고려 복잡 할수록 성능 저하

스키마

스키마는 데이터베이스의 구조와 제약 조건에 관한 전반적인 명세를 기술한 메타데이터의 집합이다.
스키마는 데이터베이스를 구성하는 데이터 개체, 속성, 관계 및 데이터 조작 시 데이터 값들이 갖는 제약 조건 등에 관해 전반적으로 정의한다.

NoSQL

스키마와 관계라는 개념이 없다.

장점으로 자유롭게 데이터를 추가가 가능하다. 이는 복잡한 테이블간의 관계를 형성하는 형태의 구조를 신경쓰지 않는다. RDBMS는 조인 등 복잡한 SQL구문으로 인한 문제가 있는데 NOSQL에서는 필요한 데이터가 보통 하나의 컬렉션에 있으며, 이는 자주 변경되지 않는 데이터에 큰 장점이 있다. 그리고 수평적 확장이 쉽다. 분산처리 목적 단점으로 컬렉션에 중복된 데이터가 저장이 가능

해시테이블, 해시 맵, 해시 표

컴퓨팅에서 키를 값에 매핑할 수 있는 구조인, 연관 배열 추가에 사용되는 자료 구조로 해시 테이블은 해시 함수를 사용하여 색인을 버킷이나 슬롯의 배열로 계산한다.

해시 함수 임의의 길이의 데이터를 고정된 길이의 데이터로 매핑하는 함수이다.

 

반응형

+ Recent posts