DataLake, Data Mart, Data Warehouse 이란.md

DataLake, Data Mart, Data Warehouse 이란

일반적으로 데이터베이스에 데이터를 저장하고 우리는 데이터를 가지고와서 활용합니다.


여기서 이 데이터베이스에 저장된 데이터를 목적에 맞게 저장하게되고 이 목적에 따라서 우리는 Data Lake, Mart, Warehouse라는 용어로 부를 수 있습니다.


꼭 데이터베이스가 아니더라도 데이터를 저장하는 공간 자체를 목적에 맞게 부르기때문에 데이터베이스가 절대적인 것 같지는 않습니다 ex) 저같은 경우 Apache Hadoop 을 Data Lake로 생각하고 활용했습니다


그렇다면 각각 어떤목적으로 나누는 걸까요?



1. Data Lake(DL, 데이터 레이크)

  • 데이터 레이크는 말 그대로 "데이터 호수" 즉 원본데이터가 포함되며 아무런 작업이 이루어지지않은 저장소 입니다. 쉽게말해 전처리작업도 데이터 형변환 작업 등 아무런 작업이 일어나지 않은 원시 데이터가 저장되어 있습니다.
  • 비유를 해서 설명해드리자면 우리가 과일을 먹기위해서는 우선 수확이라는 과정이 필요하고 이 과일을 수확해서 농장 창고에 담아두는데 이 창고를 데이터레이크 라고 부를 수 있습니다.



2. Data Warehouse(DW, 데이터 웨어하우스)

  • 데이터 웨어하우스는 데이터레이크에서 얻어진 데이터들을 데이터마트에 저장하기 전 주제별로 저장합니다. 여기서 다시한번 저장하는과정 중 버려지는 데이터가 발생할 수 있습니다.
  • 쉽게생각하면 위에서 수확했던 과일을 각 지역별로 분류해서 저장해두거나 과일의 등급에 맞게 다시한번 더 나누어서 저장해둔 형태 로 생각해볼 수 있습니다.



3. Data Mart(DM, 데이터 마트)

  • 데이터마트는 위 데이터하우스로부터 얻어와 바로 활용할 수 있는 형태로 저장된 방식입니다. 프로그램의 목적에 맞게끔 저장할 수도 있고 아니면 광고를위한 영상일 경우 광고 길이에 맞춰 화질과 길이가 이미 처리된 상태의 영상이 담길수도 있습니다.
  • 말 그대로 마트 라는 의미기에 우리가 쉽게 마트에서 물건을 골라 소비할 수 있다고 생각하시면 좋겠습니다.


오늘은 일반적으로 데이터를 저장하는 목적에 따라서 (실무에서나 토이프로젝트 등) 저장된 공간을 의미하는 개념을 알아보았습니다.



 

Reference

저작자표시 비영리 변경금지

REST API 란?

흔히 웹 개발자라면 REST API , REST ful 이란 말을 들어보셨을 겁니다.

 

 

이 REST API는 명확하게 무엇을 의미할까요?

 

 

REST를 한번 뜯어봅시다.

 

REST : Representational State Transfer API의 뜻으로 2000년대 웹의 장점을 최대한 활용할 수 있는 아키텍처입니다.

 

 

여기서 API는 Application Programming Interface로 애플리케이션에서 프로그래밍을 구축하고 통합하는 정의 및 프로토콜입니다. 흔히 API를 직접 프로젝트에서 활용할 때는 개발자(생산자)와 소비자(클라이언트)가 필요로 하는 호출(Request)과 응답(Response)을 구축합니다. 컴퓨터나 시스템에 사용자가 원하는 정보를 호출 및 응답받을 수 있도록 도와주는 조정자라고 생각하면 좋을 것 같습니다.

 

 

이어서 REST API를 설명하기 전 URI와 URL의 개념을 한번 짚고 넘어갑시다.

 

 

URL, URI 많이 들어봤는데 실제로 명확하게 어떤 차이점이 있을까요?

 

 

URN과 URL은 사실 URI에 포함되어있습니다.

 

 

URI,URL

위 사진을 보면 조금은 감이 오실까요?

 

 

위치는 고정적이며 식별자라고는 말할 수 없기 때문에 URL이며 URL 속 식별자를 이용해 특정 데이터를 지정할 수 있습니다.

 

 

이처럼 REST API를 이용할 때 URI를 통해 특정 데이터를 호출하고 응답받을 수 있습니다.

 

 

REST API 구성요소

 

REST API는 3가지의 구성요소가 있습니다.

  • 자원(RESOURCE) - URI
  • 행위(Verb) - HTTP method
  • 표현(Representations) - Representation of Resource

여기서 자원은 위에서 설명드린 URI개념으로 서버에 특정 자원을 Identifier로 구별하고 호출할 수 있어야 합니다.

 

 

행위(Verb)는 기본적인 HTTP 요청 Method로 Get, Put, Delete, Post, Patch를 통해 서버에 요청을 보낼 수 있어야 합니다. 우리는 흔히 CRUD(Create, Read, Update, Delete 기능을 구현하는 것과 매칭 된다고 보시면 됩니다.) 기능을 구현하고 이를 앞에 메서드에 맞게 구현합니다.

 

 

표현은 위 자원을 나타내는데 이 자원을 주고받기 위한 형식이 일반적으로 JSON, XML 형식이라는 것입니다.

 

 

그래서 이 구성요소로 어떻게 한다는 건데~라고 생각할 수 있는데

 

 

위 구성요소를 활용해 REST API라고 불리는 아키텍처 규칙에 맞게 구현해야 합니다.

 

 

이 설계 규칙을 모두 적절하게 잘 지켰을 경우 우리는 RESTful API라고 말할 수 있습니다.

 

 

이 REST API의 설계 규칙은 다음과 같습니다.

 

 

1) Uniform (유니폼 인터페이스) - 일반성의 원칙을 적용하고 아키텍처를 단순화하고 상호 작용의 가시성을 향상할 수 있다. 즉 리소스(자원)를 간결하고 명확하게 그리고 고유한 표현을 통해 식별할 수 있어야 합니다 ( URI를 조금 더 명확하게 네이밍하고 이용해야 합니다.)


2) Stateless (무상 태성) - 서버는 작업에 따른 상태 데이터를 따로 저장하지 않습니다 그렇기에 구현이 단순합니다. 또 요청 응답 간의 데이터 역시나 저장하지 않으며 사용자에 대한 세션 상태는 완전히 유지해야 합니다.


3) Cacheable (캐시 가능) - REST API는 HTTP의 표준 형식을 이용하기 때문에 캐싱 기능이 존재합니다. 그중에서도 응답에 따라 캐싱 가능과 불가능으로 레이블을 분리하고 캐싱이 가능할 경우 일정 기간 동안 사용자에게 해당 응답 데이터를 재이용할 수 있는 권한을 부여할 수 있습니다. 여기서 사용되는 캐싱 기능 역시 HTTP에 존재하는 캐싱 기능입니다.


4) Self-descriptiveness (자체 표현 구조) - 위 리소스를 특정 고유 표현으로 표현했기 때문에 REST API의 메시지 만으로 어떤 의미에 요청인지를 인지할 수 있는 구조가 되어야 합니다.


5) Client - Server 구조 - 클라이언트와 서버를 명확하게 나누어 확장성을 개선해야 합니다. 클라이언트와 서버가 진화(? 업데이트할 동안) 이 클라이언트 - 서버 간의 인터페이스가 가 깨지지 않도록 합니다.


6) 계층형 구조 - 계층형 구조는 말 그대로 우리가 URI를 참조할 때 ( / ) 표현으로 리소스의 계층을 타고 갈 수 있으며 마지막에는 슬래쉬( / )를 포함하지 않아야 합니다. 또 이 API사이에 보안, 로드밸런싱, 암호화 등의 계층을 추가해 보안성을 강화하거나 Proxy, Gateway 등을 추가해 네트워크의 중간 매체를 사용할 수 있습니다.

 

위 6가지 규칙 중 가장 중요한 것만 기억하자면

URI는 고유명사로 데이터를 명확하게 의미할 수 있어야 하며, 해당 데이터를 활용한 행동은 꼭 HTTP method를 이용해야 한다는 걸 기억하면 좋겠습니다.

 

 

그 밖에도 주의할 점으로는

 

 

( _ ) 표시보다는 ( - ) 하이픈을 사용해야 하고, 파일의 확장자(. jpg )등을 표시하지 않아야 하며, 소문자만을 사용해야 합니다

 

 

저도 역시나 프로젝트를 진행할 때 REST API 아키텍처를 지향하며 설계하고 구성했지만 결과적으로 로컬의 일부 리소스를 끌어다 쓰는 방식의 프로젝트를 종종 사용하곤 했습니다. (동영상, 이미지와 같이 데이터베이스에 담기 껄끄러운 데이터들..) 이럴 때마다 REST API의 설계 규칙에 위배되었다는 것을 오늘 개념을 정리해보며 다시 한번 느끼는 시간이 되었다고 생각합니다.

 

 

Reference

저작자표시 비영리 변경금지

'지식 창고' 카테고리의 다른 글

MSA란 무엇일까?  (0) 2023.01.10
HLS protocol 이란 무엇일까?  (2) 2022.09.11
프레임워크랑 라이브러리는 뭐가 다를까??  (0) 2022.09.03

HLS란 무엇인가?

HLS (HTTP Live Streaming) 이며 주문형 스트리밍 이자 라이브 스트리밍 입니다. 일반적으로 우리는 웹상에서 동영상을 볼 때 한 동영상파일의 전체크기를 다운받고 시청을 하지 않습니다. 한 동영상파일을 잘게 분리한다음 한 조각조각씩 사용자가 순서대로 다운받아와서 동영상을 시청할 수 있는 방식입니다.

실제로 일상생활에서도 동영상을 보다가 HTTP통신환경이 좋지않아 동영상이 끊길 경우가 종종 생깁니다. 저는 이 경우를 버퍼링이 걸리는 경우로 기억하고있습니다. 항상 한 가지 개념을 기억하기 가장 좋은 예시는 본인의 경험의 한 상황으로 연결짓는다면 기억에 오래남는 것 같습니다. 실제로 버퍼링의 의미는 말 그대로 버퍼에 데이터를 담는다는 뜻으로 쓰이고 버퍼링이 걸린다 라는 것은 네트워크 통신이 약해져서 우리가 보고있는 (동영상 데이터)가 버퍼에 담기지않아 지금까지 버퍼에 담아두었던 영상의 부분까지만 시청하고 대기상태에 이르는 상황인 것입니다.

다시 HLS의 얘기로 돌아와서 HLS는 비디오 스트리밍 프로토콜로 Apple사가 개발했고 현재는 다양한 장치에서 이 프로토콜이 활용되고 있습니다.

다양한 장치에서까지 이 프로토콜을 사용하는 이유는 무엇일까요?

HLS의 장점으로는 모든 인터넷 연결 장치가 HTTP를 지원하기 때문에 전용 서버가 필요한 스트리밍 프로토콜보다 간단하게 실행할 수 있다는 것입니다.

또 다른 장점은 HLS스트리밍은 재생에 지장을 주지 않으며 네트워크 상태에 따라 비디오품질을 높이거나 낮출 수 있다는 것입니다. 여기까지 읽었을 때 가끔 영상을 보다가 화질이 안좋아지는 경험을 해보신 분이라면 공감을 하실 수 있을 것 같습니다.

이 때문에 사용자는 시청중 품질이 나빠지거나 좋아질 수 있고(네트워크 상황에 따라) 이 기능은 "적응 비트 전송률 비디오 전송", "적응비트 전송률 스트리밍" 이라고 알려져 있으며 이 기능이 없으면 네트워크가 느려진 경우 비디오 재생이 완전히 멈출 수 있습니다.

여기서 스트리밍에 대한 개념을 한번 짚고 넘어가겠습니다.

스트리밍은 무엇이냐?

  • 스트리밍은 인터넷을 통해 비디오, 오디오 미디어를 전달하는 방식으로 미디어파일을 한 번에 모두 보내는 대신 한 번에 조금씩 지속적으로 사용자 장치에 보냅니다. 원 미디어 파일은 멀리 떨어진 곳에 저장되어 있거나 라이브 스트리밍의 경우 원격 카메라나 마이크를 이용하여 실시간으로 제작됩니다.
  • 위 특징을 읽어보면 HLS의 이야기와 같게 느껴질 수 있습니다. 결론적으로 맞습니다 스트리밍의 방식을 그대로 적용하기 때문입니다.
  • 그리고 이 작은 데이터조각들을 지속적으로 사용자가 다운로드받는 것을 버퍼링 이라고 합니다.

그래서 이 HLS는 적응 비트레이트 스트리밍 방식의 스트리밍을 제공합니다.

그렇다면 이제 HLS 중 H에 대한 이야기가 남아있습니다.

H는 HTTP입니다.

HTTP(Hyper Text Transfer Protocol)는 무엇이냐?

  • HTTP는 네트워크에 연결된 장치사이 정보를 전송하기 위한 어플리케이션 계층 프로토콜입니다. 일반적인 사용자가 액세스할 수 있는 모든 웹사이트와 어플리케이션은 HTTP에서 실행됩니다. HTTP를 통한 데이터 전송은 일반적으로 용청과 응답에 따라 이루어지며 이 HTTP의 통신방식은 추후 다른 게시글을 통해 자세하게 설명해드리겠습니다. 현재는 이 HTTP는 목적지와 편지를 주고 받는 개념이라고 생각하시면 좋을 것 같습니다.
  • 그리고 이 HTTP를 스트리밍의 경우 표준 요청 응답 패턴이 적용되지 않습니다. 클라이언트와 서버 사잉의 연결은 스트리밍 기간 동안 열려 있고 서버는 비디오 데이터를 클라이언트는 비디오 데이터 세그먼트마다 요청하지 않아도 됩니다.
  • 또한 HTTP통신 중 데이터를 주고 받을 때 흔히 발생하는 CORS, CORB 에러가 있습니다. 이 에러는 HTTP의 구조를 조금 더 명확하게 알고 있다면 수월하게 해결할 수 있으며 이 문제역시나 다른 게시글에서 조금 더 깊게 다루어 보겠습니다.

이 HLS의 또 다른 특징으로는 스트리밍 데이터를 .m3u8 확장자와 .ts확장자를 가진 파일로 분리한다는 특징이 있습니다.

저는 이것을 직접 구현하기위해 우선 ffmpeg 프로그램을 이용해 동영상 파일은 분리하는 작업을 진행했습니다.

코드는 다음과 같고 ffmpeg파일은 HLS관련 코드를 검색하시면 쉽게 구하실 수 있습니다.

const ffmpeg = require('fluent-ffmpeg');

const ffmpegInstaller = require('@ffmpeg-installer/ffmpeg');

//ffmpegInstaller는 ffmpeg만 사용했을 때 생겼던 오류를 해결하기 위해 사용.
ffmpeg.setFfmpegPath(ffmpegInstaller.path);

ffmpeg('videos/고등어조림.mp4', {timeout : 432000}).addOptions([
    '-profile:v baseline',
    '-level 3.0',
    '-start_number 0',
    '-hls_time 10', // hls_time : 몇 초 단위로 동영상을 분할할 것인지 설정
    '-hls_list_size 0',
    '-f hls' // 포맷을 설정 -> HLS사용.
]).output('videos/output.m3u8').on('end',() =>{
    console.log('end');
}).run();

소스를 보시면 fluent-ffmpeg라는 것을 처음 불러오고 이 ffmpeg를 통해 "videos/고등어조림.mp4" 라는 동영상 파일을 옵션에 맞게 분할하는 것을 생각해볼 수 있습니다. 그리고 output부분을 확인해보시면 m3u8의 확장자로 뽑아내는 것을 확인할 수 있습니다.

이렇게 m3u8파일만 뽑는 것처럼 읽을 수 있으나 m3u8뿐만 아니라 ts파일 역시 같이 만들어지게되고 이 m3u8은 ts파일들의 순서를 기록하는 설명서역할을 합니다.

즉 웹 브라우저는 HTTP통신을 통해 처음 m3u8파일을 최초로 가져오게되고 이 m3u8의 내용을 읽어 0번째의 ts(동영상 분할 파일)을 가지고와서 영상데이터를 제공하는 방식입니다.

저는 이 HLS protocol을 이용하는 방식을 React X Spring Boot에서 이용해 보았습니다. 처음 설계를 진행할 때는 이 Spring Boot가 스트리밍 서버의 목적에 맞지 않고 조금더 범용적인 여러 기능을 핸들링할 수 있는 백엔드서버의 역할성 때문에 또 다른 백엔드서버인 Nodejs를 활용해 스트리밍서버를 구성하려고 했으나 해당 프로젝트를 진행할 때 강사님의 조언으로는 백엔드서버가 여러개 있는 것보단 현재 프로젝트 기준으로써는 하나의 백엔드 서버가 맞다는 이야기에 Spring Boot 백엔드 API서버와 React의 react-hls-player를 통해 이 프로토콜을 활용하게 되었습니다.

해당 프로젝트의 소스코드가 궁금하신 분들을 위해 아래 깃허브 링크를 남겨두겠습니다.

이상으로 HLS Protocol에 대한 간단한 개념 정리글을 마치겠습니다.

https://github.com/ukjinlee66/metanet_internship_project

HLS에 대한 기초적인 소스코드를 확인하고싶다면 root위치에 streaming_server/HLSTest 를 확인해주시면 감사하겠습니다.

Reference

저작자표시 비영리 변경금지

'지식 창고' 카테고리의 다른 글

MSA란 무엇일까?  (0) 2023.01.10
REST API란?  (0) 2022.09.12
프레임워크랑 라이브러리는 뭐가 다를까??  (0) 2022.09.03

[JAVA]JAVA 언어의 특징

자바언어를 이용한 자바 프로그래밍을 생각해보면 객체지향 프로그래밍 OOP(Object Oriented Programming)이라 해도 상관없습니다. 그 이유는 자바언어의 특징을 소개하며 설명을 이어나가겠습니다.

자바 언어는 크게 5가지 특징을 가지는데 아래와 같습니다

  • 객체 지향 프로그래밍(OOP)
  • 자동 메모리 관리(GC)(가비지 컬렉터)
  • 운영체제에 독립적
  • 멀티쓰레드 지원
  • 동적 로딩 지원

첫번째로 객체 지향 프로그래밍의 대표적인 특징은 아래 4가지가 존재합니다.

  • 상속 (Inheritance) : 부모클래스의 속성과 기능을 그대로 이어받아 사용할 수 있게 하고 기능의 일 부분을 변경해야 할 경우 상속받은 자식클래스에서 해당기능을 재정의(수정)해 사용할 수 있는 것입니다.

  • 다형성 (Polymorphism) : 다형성은 상속을 통해 기능을 확장하거나 변경하는 것을 가능하게 해줍니다. 이를 통해 코드의 재사용, 코드길이 감소, 유지보수가 용이해지는 특징이 있습니다. 여기서 크게 두가지 개념으로 오버라이딩(Overriding)과 오버로딩(Overloading)이 있습니다.

    • /*
**오버라이딩 (Overriding)
** - 상위 클래스가 가지고 있는 메소드를 하위 클래스가 재정의해서 사용합니다.
*/

//부모클래스
class Parent{
  public String name;
  public int age;
  public void Speak(){
    System.out.println("일어나 ~ 학교 가야지 ~");
  }
}
//자식클래스
class Child extends Parent{
  public String name;
  public int age;
  public void Speak(){
    System.out.println("10분만 더 잘게요 ~ ");
  }
}
public class Test{
  public static void main(String[] args){
    //자식 클래스의 객체 생성
    Child ch = new Child();

    //자식 객체의 변수 설정
    ch.name = "아무개";
    ch.age = 10;

    //오버라이딩 함수 호출
    ch.Speak();
  }
}
      /*
**오버로딩 (Overloading)
** - 같은 이름의 메서드 여러개를 가지면서 매개변수의 유형과 개수가 다르도록 하는 기술
*/

class marine
{
  public void attack(){
    System.out.println("일어나 ~ 학교 가야지 ~");
  }
  public void attack(int damage){
    System.out.println(damage + "만큼의 피해를 입힙니다.");
  }
  public void attack(String class_name, int damage){
    System.out.println(class_name+"이"+damage"만큼의 피해를 입힙니다.");
  }
}
public class Test{
  public static void main(String[] args){
    //marine 클래스의 객체 생성
    marine m = new marine();

    //매개변수가 없는 attack 메소드 호출
    m.attack();

    //매개변수가 1개 있는 attack 메소드 호출
    m.attack(10);

    //매개변수가 2개 있는 attack 메소드 호출
    m.attack("warrior", 30);
  }
}

  • 캡슐화 (Encapsulation, information Hiding) : 캡슐화는 한 객체에 대해 그 객체가 특정 목적을 위해 필요한 변수나 메소드를 하나로 묶는것을 의미합니다. 즉 접근제한자로 변수를 설정해 함부로 변수의 값을 변경할 수 없게 만들고 대신 getter, setter와 같은 메소드를 통해서 접근할 수 있도록 구현할 수 있습니다.

  • 추상화 (Abstraction) : 공통의 속성, 기능들을 묶어 클래스로구성해 확장성을 넓히는 것을 의미합니다. 추상클래스(추상 메소드를 하나이상 포함한 클래스)를 구성하고 추후의 이 class 또는 interface를 상속받아 구현하여 사용하는 것입니다. 공통 기능으로 묶어서 처음 클래스 또는 인터페이스를 구성했기 때문에 설계에 따라서 확장성이 크게 올라갈 수 있습니다. ex)동물이라는 추상 클래스는 행동 이라는 추상 메소드를 가지고 있고 추후에 양서류 등등으로 나뉘어지더라도 이 행동이라는 추상메소드는 계속 상속받아 각 종류에따라서 다르게 구현될 수 있습니다.

그렇다면 이러한 객체지향 프로그래밍을 쓰는 이유는 무엇인가요? 라는 궁금증이 생길 수 있습니다.

객체지향 프로그래밍은 프로그래밍에서 필요한 데이터를 추상화시켜 상태와 행위를 가진 객체를 만들고 그 객체들 간의 유기적인 상호작용을 통해 로직을 구성하는 프로그래밍 방법입니다.

장단점은 무엇이 있을까? 생각해볼 수 있습니다.

  • 장점
    • 코드 재사용성 증가 - 상속을 통한 확장성 증가
    • 유지보수가 쉬워짐 - 절차 지향 프로그래밍 에서는 코드를 수정해야할 때 하나하나 수정해야하지만 객체지향프로그래밍은 상속받은 부모 클래스의 내용만 수정하면 하위 상속받은 자식클래스의 코드수정을 하지 않아도 됩니다.
    • 대형 프로젝트에 적합 - 클래스 단위로 모듈화시켜 개발할 수 있기 때문에 업무분담하기 쉬워집니다.
  • 단점
    • 처리속도가 상대적으로 느려집니다.
    • 객체가 많으면 용량이 커질 수 있습니다.
    • 설계시 많은 시간과 노력이 필요합니다.

두번째로 자동메모리관리(GC) 가비지 컬렉션을 설명하겠습니다.

Garbage collection(GC)는 메모리관리 기법 중 하나로 프로그램이 동적으로 할당했던 메모리 영역 중 필요없게 된 영역을 해제하는 기능입니다.

C,C++언어같은 경우 동적할당을 받아 배열또는 객체를 생성하게 될 경우 힙메모리 영역에 저장되고 이 부분의 메모리가 할당된 걸 해제하기위해 개발자가 직접 free해주어야합니다. 그러나 자바언어의 경우에는 모든 객체가 클래스기반이며 참조변수 같은경우에는 기본으로 힙에 저장되기때문에 애초에 힙에 저장되는 값들이 많습니다. 이러한 값들을 주기적으로 관리해주기위해 GC가 존재하기도하며 직접 개발자가 System.gc() 를 호출해서 해제할 수 있으나 권장되지 않는것으로 알고있습니다.

세번째로는 운영체제에 독립적입니다.

이말의 의미를 명확하게 이해하려면 JVM(Java Virtual Machine)을 이해하고 있어야 합니다. 자바의 개발 환경과 배포환경이 다를 경우 프로그램을 다시 컴파일 할 필요 없이 실행가능합니다. 그 이유는 JVM은 별도의 Java Compiler를 통해 사용자의 코드를 Byte코드로 변환하고 모든 자바 프로그램은 이론적으로 CPU나 운영체제의 종류와 무관하게 동일하게 동작합니다.

마지막으로 동적로딩, 멀티쓰레드 지원 입니다.

자바는 한 프로그램 내에서 여러 쓰레드가 동작할 수 있는 환경을 제공합니다. C,C++은 운영체제의 도움을 받아 멀티쓰레드를 지원하지만 자바는 이런 운영체제의 지원없이 멀티쓰레드를 이용한 프로그래밍이 가능합니다.

멀티쓰레드를 구현하는 방식음 다음과 같이 두가지가 있습니다.

1) Thread Class (화이트박스 방식)

  • 자바에서 쓰레드를 만들기위해 Thread Class 를 상속받아 쓰레드를 생성합니다.
    2) Runnable Interface (블랙박스 방식)
  • 위 화이트박스 방식과 비슷하게 Thread class와 같이 자바에서 스레드를 실행시키는 인터페이스 이며 다중상속이 지원되기 때문에 Thread class보다 많이 사용됩니다.

추가로 저는 C,C++에서 철학자 문제를 가지고 멀티쓰레드와 멀티 프로세스개념을 이해하며 학습한 적이 있는데 이러한 멀티쓰레드와 멀티프로세싱은 교착상태(데드락)문제를 중요하게 다루고있습니다. 여러개의 쓰레드 또는 프로세스가 공유자원을 이용할 때의 문제점을 다루는 것인데 그당시는 뮤텍스, 세마포어를 활용해 이러한 공유자원문제를 해결하는 방식을 학습했던 적이 있었습니다. 중요한 개념인 만큼 밑에 깃허브 링크를 남겨두겠습니다.

지금은 이런게 있구나 기억하고 넘어가시는게 좋을 것 같습니다.

철학자 문제 - https://github.com/ukjinlee66/42_Philosophers

동적로딩(Dynamic Loading)은 어플리케이션이 실행될 때 모든 객체가 처음부터 생성되지 않고 필요한 시점에서 동적로딩을 통해 생성되는 개념입니다. 이러한 동적 로딩은 클래스를 일부 변경하더라도 재 컴파일을 하지 않아도 되는 장점이 있고 적은 작업으로 처리할 수 있는 유연성을 동적로딩이 제공합니다. 그러나 말 그대로 시점에 따라서 그때그때마다 생성이된다면 당연히 그 시점에 메모리에서 불러오기에 속도가 정적로딩에 비해 느린 편이고 이런 느린 속도를 해결하기위해 Static 키워드를 사용합니다.

Reference

저작자표시 비영리 변경금지

'JAVA' 카테고리의 다른 글

[JAVA & Database] JDBC, MyBatis, JPA 의 차이점  (1) 2022.09.26
[JAVA]직렬화 - Serializable란?  (0) 2022.05.16
[JAVA]DAO, DTO, VO 정리.  (0) 2021.12.25

+ Recent posts

티스토리툴바