Cursor

JDBC ResultSet 기본기능

JDBC(Java Database Connectivity) 자바 프로그램에서 데이터베이스와의 연결을 관리하고 SQL 쿼리를 실행하기 위한 자바 API

ResultSet? JDBC에서 쿼리 결과를 나타내는 인터페이스 ResultSet 객체는 데이터베이스에서 실행된 SELECT 쿼리 집합을 나타냄 행과 열의 형태 -> 행 : 레코드 열 : 레코드의 필드

ResultSet이 open 될 때마다 database의 데이터 return DB 커넥션 후 데이터를 Streaming 해서 보냄. Cursor를 한칸씩 옮기며 데이터를 가져옴.

Cursor기반 ItemReader 구현체

• JdbcCursorItemReader
• HibeernateCursorItemReader
• StoredProcedureItemReader

MyBatisCursorItemReader

• .afterPropertiesSet() spring bean의 초기화를 위해 InitializingBean 상속 메서드 빈의 속성들이 설정된 후 이 메소드 호출되어 빈을 추가로 초기화할 수 있다. (객체 초기화) --> 의존관계가 끝나면 호출해주겠다는 의미

• .setSaveState(true) 빈의 상태를 저장할지 여부 지정. 빈의 상태를 저장하는것은 스프링 배치에서 일괄 처리 작업을 수행하는 동안 빈의 상태를 유지하고, 실패시 다시 시작하는데 도움. -> 작업이 중간에 중단되거나 실패한 경우 이전상태로부터 다시 시작

Paging

페이지라는 Chunk로 Database에서 데이터 검색 페이지 단위(PageSize = ChunkSize)로 한번에 데이터 조회 여러 쿼리를 실행해 각 쿼리가 지정한 PageSize만큼 한번에 가져옴 페이징은 offset(행번호), 페이지에서 반환할 행 수 (limit) 을 지정 -> Spring batch에서는 offset, limit을 pageSize에 맞게 자동 생성 --> 하지만 각 쿼리는 개별적으로 실행 ---> 각 페이지마다 새로운 쿼리를 실행하므로 order by가 중요하다.

Paging기반 ItemReader 구현체

• JdbcPagingItemReader
• HibernatePagingItemReader
• JpaPagingItemReader

Spring batch => Chunk 지향 처리. Chunk 단위로 트랜잭션 다룸. -> 롤백허용 읽고 처리해야할 아이템이 많을때, 트랜잭션을 한번에 이어가는 것 보다 일정 주기로 여러번 실행하는 것이 안정적. Cursor는 하나의 Connection으로 Batch가 끝날때까지 사용되어 Batch가 끝나기전에 Database와 application의 Connection이 먼저 끊어질 수 있어 위험

입사한지 벌써 4개월이라는 시간이 지나, 입사 후의 나를 되돌아볼까 한다.

내가 꿈꿔온 개발이란 뭘까? 아직까지는 잘 모르겠다.

입사 후에 나는 생각보다 다양한 개발건들, 여러가지 상황들을 겪었다. 가장 최근에 겪은 URLEncoding 이슈부터, 개발기와 운영기의 차이로 발생한 차이 등등, 사소하지만 사소하지 않은 것들을 겪고있다.

내가 혼자하던 프로젝트, 공부와 실전은 생각보다 많이 달랐다. 먼저 다른 사람이 쓴 코드의 의도부터 파악을 시작한 후, 내가 그 코드를 수정했을 때의 리턴값을 생각하면서 개발을 시작해야한다. 그리고 마주하게되는 예외처리, 리턴값 설정, 모듈화 방향성, 쿼리 작성 등 여러상황들을 직면하게된다. 이런 여러 상황들을 마주하게 되며 나는 오늘도 내가 아직 배울점이 많다는걸 깨닫고있다.

개발이 항상 재밌고 새로운점은, 오늘과 내일 그리고 일주일 후, 한달 후의 나의 코드의 방향성이 달라지는게 느껴진다는 것이다.

아직 나의 코드 스타일을 찾지 못했고, 갑자기 많은 지식들이 머릿속에 들어와 혼잡해진 탓에 많은 것을 놓치고있는 나의 모습이 많이 보인다. 내 코드에는 빈틈이 많고, 내가 생각했던 클린코드를 주입하기에는 시간이 턱없이 부족하다. 하지만 똑같은 코드를 나혼자 계속해서 보고있자니 너무 머리가 어지럽고 답답한 생각이든다. 그럴때마다 PR을 올리면 팀장님께서 나에게 수많은 피드백을 주신다. 너무 행복하다. 나도 답답했던 부분들을 팀장님께서 찾아서 말씀해주는데 머리가 정화되는 느낌이 든다.

나의 단점이 확연하게 들어난다. 머릿속에서 정리하지 않고 그대로 말을 뱉게되어 내가 생각해도 좀 어지럽게 답변할때가 많은 것 같다. 머릿속에서 정리하고 말을 하는 습관을 항상 들이자! 라고 생각은하지만, 얼른 답변해야하는데,,라는 마음에 나도 모르게 횡설수설 말을 내뱉는다. 나도 인지하고 있는 내 단점이니까 꼭 고쳐야지.

항상 개발은 새롭고 즐겁다. 나에게는 아직 모든 개발들이 새로운 도전이자 공부와 같아, 일하는게 일하는 것 같지 않게 느껴진다. (가끔 체력이 부족해서 지치고 힘들때가 있긴 하다) 하지만 걱정이 되는 부분도 있다. 항상 새로운 개발건들만 있는게 아니고, 내가 익숙한 개발건들만 있게 되는 시점이 나도 찾아올텐데, 그때 내가 받는 리턴값이 내 만족도와 같지않으면 나는 과연 개발을 즐거워할 수 있을까라는 걱정이 든다. 더 많이 공부하고 노력해서 남들보다 더 빨리 성장하고 싶고, 더 인정받고싶은데 만약 리턴값이 내가 맘에 안들때를 생각해야한다. 그렇기에 나는 언제나 공부하고 준비되어있어야한다. 일적인 개발뿐만이 아니라 나 자신을 위한 공부도 항상 함께해야한다. 그렇게 되려면 시간 배분을 항상 잘해야한다고 느낀다. 하지만 아직, 시간 배분을 하기엔 난 너무 부족한걸.. 마음같아서는 회사 컴퓨터를 끼고살고싶다!! (하지만 나도 힘들때는 얼른 집가고싶다.. 오늘처럼 안지치는날 한정)

아직 많이 부족하지만, 부족한만큼 더 열심히해야지.

파라미터가 null -> 문자열 null을 담음

(String) - Casting

대상이 null -> NullPointerException Object가 String이 아니면 ClassCastExceptiion

.toString()

대상 값이 Null이면 NullPointerException Object에 담긴 값이 String이 아니더라도 출력

Mybatis를 사용할 때 SqlSessionTemplate 라는걸 사용한다. 여기서 ExecutorType 모드가 있다는걸 알게 되었는데 지금 알게된 세가지 방식을 정리해보고자 한다.

executorType.simple

• 이 모드에서는 각 SQL 문이 실행될 때마다 DB 연결을 열고 실행.
• 각 SQL 문이 개별적 실행되어 하나의 트랜잭션 내에서 여러 SQL 문을 실행할 때에도 각각의 SQL 문은 독립적인 트랜잭션으로 실행
• 이 모드는 간단한 작업이나 간단한 쿼리를 처리할 때 사용될 수 있고, 트랜잭션 관리나 롤백에 있어 SQL 문 간에 영향을 주지 않음

executorType.batch

• 이 모드에서는 Mybatis가 가능한 모든 SQL문을 배치(batch)로 묶어 데이터베이스에 한번에 전송. -> 네트워크 오버헤드가 감소하고 성능 향상 가능
• 모든 SQL 문은 동일한 트랜잭션 내에서 실행 -> 롤백이나 커밋도 한꺼번에 처리.

executorType.reuse

• 미리 컴파일된 SQL 문과 캐시된 세션을 재사용해 성능 향상시키는 방법
• 성능이 중요한 시나리오에 사용

출처

<%@ include file ="/WEB-INF/ ... / a.jsp" %> 

-> 지정된 jsp 파일이 현재 jsp 페이지 처리 과정 중에 그대로 복사되어 들어가며, 
   다른 jsp 파일의 내용을 현재 페이지에 포함시킴. 
   컴파일 시에 처리.

를 사용해 jsp파일에 또 다른 jsp 파일을 불러올 때 하나의 js파일이 여러번 호출되는 현상이 발생했다.

해결책은 클라이언트 측에서 중복로딩을 방지해줬는데, script가 이미 로드가 되어있는지 확인하고, 중복 로딩을 방지하는 코드를 집어넣었다.

<script type="text/javascript">
    if (typeof aJsLoaded === "undefined") {
        var script = document.createElement('script');
        script.type = 'text/javascript';
        script.src = '${pageContext.request.contextPath}/a.js?v=' + ${System.currentTimeMillis()};
        document.head.appendChild(script);
        aJsLoaded = true; 
    }
</script>

이 코드를 사용하면, 중복 스크립트 로딩을 방지할 수 있다.

code interpretation

* if (typeof aJsLoaded === "undefined") 
-> aJsLoaded - 중복 로딩 방지를 위한 플래그 변수. 
aJsLoaded 라는 변수가 이미 정의되어있는지 확인. 
이 변수가 정의되어 있다면, 중복 로딩을 방지하기 위해 아무것도 수행되지 않음. 

* var script = document.createElement('script');
-> 새로운 <script> 요소를 동적으로 생성. 
    script 파일을 동적으로 로드하는 역할 

* script.type = 'text/javascript';
 -> 생성된 script 요소 type 속성을 javascript로 설정 

* script.src = '${pageContext.request.contextPath}/a.js?v=' + ${System.currentTimeMillis()};
 -> script 요소의 src 속성 설정 

* document.head.appendChild(script);
 -> 동적으로 생성된 script 요소를 문서의 <head> 에 추가 
 -> 이렇게 하면 script 파일이 현재 페이지에 로드 

* aJsLoaded = true; 
 -> 중복 로딩 방지용 변수를 true로 설정해 다음에 스크립트가 중복으로 로드되지 않도록 제어 

Spring Batch 어노테이션 배치의 인프라스트럭처를 부트스트랩하는데 사용

• 인프라스트럭처 레이어 : ItemReader, ItemWriter 를 비롯해,

                재시작과 관련된 문제를 해결할 수 있는 클래스와 인터페이스 제공. 

제공되는 컴포넌트 목록

• JobRepository : 실행중인 Job 상태 기록시 사용
• JobLauncher : Job 구동 시 사용
• JobExplorer : JobRepository를 사용해 읽기 전용 작업을 수행하는 데 사용
• JobRegistry : 특정한 런처 구현체를 사용할 때 Job을 찾는 용도로 사용
• PlaformTransactionManager : Job 진행 과정에서 트랜잭션을 다루는데 사용
• JobBuilderFactory : Job을 생성하는 빌더
• StepBuilderFactory : Step을 생성하는 빌더

Spring Batch 설정하고 사용하는 방법을 정의한 인터페이스

JobRepository

Job 관련 정보와 실행 내역을 저장 및 관리하는 요소 Job의 실행 상태, 파라미터, 실행 이력 등 JobRepository에 저장 및 Job 실행 중에 발생하는 데이터 관리

PlatformTransactionManager

Spring batch에서 트랜잭션 관리를 담당하는 요소

JobLauncher

Spring Batch에서 Job을 실행하는 역할. Job의 실행은 JobRepository와 함께 동작 후 실행 내역 저장하고 관리.

JobLauncher를 사용하여 특정 시간 간격 or 스케줄에 따라 Job을 주기적으로 실행하기 위해 크론 표현식(Cron Expression) 사용

초(0-59) 분(0-59) 시(0-23) 일(1-31) 월(1-12) 요일(0-7, 0과 7은 일요일)

JobExplorer

Spring batch 실행 이력을 조회하는데 사용 실행 중인 Job의 상태 및 실행 내역 검색가능

Retrofit interface. API method는 본래의 응답을 여러 번 사용하기 위해 복제(cloned)를 함.

Call

Retrofit에서 비동기 HTTP 요청을 나타내는 객체 -> Call.enqueue() Retrofit 으로 생성한 API 인터페이스의 메서드를 호출하면 해당 요청이 call 객체로 래핑 후 반환 Call 객체는 요청을 비동기적으로 실행, 성공 or 실패 시 콜백함수 호출

Response

Retrofit에서 서버로부터 받은 HTTP 응답을 나타내는 클래스. Call의 enqueue 메서드로 비동기 요청을 보내면 서버에서의 응답이 Response 객체로 포장되어 콜백함수로 전달 Response 객체를 통해 서버로부터의 응답을 검사 및 해당 응답 사용 가능. -> 데이터 파싱 및 오류 처리 가능

네트워크 요청과 응답을 로깅하고 디버깅하는데 사용되는 interceptor OkHttp library에서 제공 네트워크 통신을 추적 및 디버깅하는데 도움

앱이 서버로 보내는 HTTP 요청과 서버에서 받는 HTTP 응답을 자세하게 로깅하고 기록 가능.

1. 요청과 응답의 본문 내용 확인 HTTP 요청과 응답에 포함된 데이터를 볼 수 있어 디버깅 쉽다

2. 요청 및 응답 헤더 확인 HTTP 요청 및 응답 헤더를 확인해 요청과 응답의 메타데이터를 살필 수 있다.

3. 요청과 응답의 타이밍 정보 확인 요청과 응답의 시작 및 종료 시간을 측정해 성능 문제 분석가능

4. 로깅 레벨 조절 로깅 레벨을 조절해 필요한 정보만 로깅 가능.

주로 암호화(cryptography)와 관련된 작업에서 발생. 이 예외는 key가 잘못된 경우 throw

일반적으로 암호화 작업에서 사용되는 key는 특정한 형식과 길이를 가짐. 만약 암호화 or 복호화 작업 중 제공된 키가 기대한 형식이나 길이와 일치하지 않을 시 InvaalidKeyException 발생

상위 클래스로 KeyException을 가짐

NoSuchAlgorithmException

특정한 알고리즘을 찾을 수 없을 때 발생하는 예외. 이 예외는 주로 암호화, 해시, 서명 등과 같은 보안 관련 작업에서 사용되는 알고리즘을 찾을 수 없을 때 발생

ValidationException

일반적으로 데이터나 입력값의 유효성 검사에서 실패한 경우 나타내는 예외

안드로이드 및 Java 기반 애플리케이션에서 RESTful 웹 서비스를 쉽게 호출하고 통신하기 위해 만들어진 라이브러리. TypeSafe해 네트워크로부터 전달된 데이터를 필요한 형태의 객체로 받을 수 있음. HTTP Client library인 OkHttp 와 함께 사용.

OkHttp?

안드로이드 및 Java 애플리케이션에서 네트워크 통신을 처리하기 위한 오픈소스 HTTP Client Library HTTP 요청을 생성하고 응답을 처리하는 것을 쉽게 만들어줌.

특징

1. 간단하고 일관된 API
   • 쉽게 사용할 수 있는 API 제공하여 HTTP 요청을 생성하고 응답을 처리하기 용이하게 함
2. HTTP/2 지원
   • OkHttp는 HTTP/2 protocol을 지원. 성능향상을 위해 다중 스트림과 헤더 압축을 활용
3. 자동 리디렉션 처리
   • HTTP 리디렉션을 자동으로 처리, 리디렉션된 URL에 대한 요청을 수행

• HTTP Redirection? 클라이언트의 웹 브라우저나 HTTP 클라이언트가 요청한 웹 페이지 또는 리소스가 다른 위치로 이동하거나 다른 URL로 변경되었음을 나타내는 HTTP protocol 기능. 주로 웹 서버나 웹 애플리케이션에서 특정 조건을 처리하거나 사용자를 다른 페이지로 안내하는데 사용.

4. 캐싱 HTTP 캐시를 지원해 서버 응답을 로컬 캐시에 저장, Redirection된 URL에 대한 요청 수행
5. Interceptor 요청과 응답의 중간에 작업을 수행하기 위한 인터셉터 지원 이를 통해 요청 및 응답 수정하거나 로깅, 인증 등 작업 수행 가능
6. 인증 지원 Basic 인증, Digest 인증, Bearer token 등 다양한 인증 지원
7. 비동기요청 비동기 요청 처리 가능해, UI thread blocking 없이 네트워크 요청 수행 가능 또한, 콜백 기반의 응답처리 지원
8. 연결 풀링 HTTP 연결을 관리하고 재사용해 네트워크 연결 오버헤드 최소화

Java에서 속성(property) 데이터를 다루는 데 사용되는 클래스 주로 설정파일이나 구성 정보를 관리. Key-Value 쌍의 데이터를 저장, 로드하는 기능 제공

// 1. Properties 객체 생성 
Properties properties = new Properties(); 

// 2. 속성 추가 및 검색
properties.setProperty("name", "yujin");
properties.setProperty("age", "25");

String name = properties.getProperty("name");
String age = properties.getProperty("age");

// 3. 속성 파일에서 로드 및 저장 
// Properties 객체는 속성 파일로부터 데이터를 로드하거나 데이터를 속성 파일에 저장가능. 
// load / store method 

// * 데이터를 파일에서 로드 
FileInputStream fileInputStream = new FileInputStream("config.properties");
properties.load(fileInputStream);
fileInputStream.close();

// * 데이터를 파일에 저장 
FileOutputStream fileOutputStream = new FileOutputStream("config.properties");
properties.store(fileOutputStream, "My Configuration");
fileOutputStream.close();

// 4. 기본 값 설정 
// Properties 객체는 기본 값 설정 가능. 
// 원하는 속성 찾을 수 없을 때 기본값 반환 
String country = properties.getProperty("country", "KOREA");
// -> country 라는 속성이 없을 시, 기본값 KOREA 반환 

큰 단위의 작업을 일괄처리

대부분 처리량이 많고 비 실시간성 처리에 사용 -> 대용량 데이터 계산, 정산, 통계, 데이터베이스, 변환...

컴퓨터 자원 최대로 활용 -> 컴퓨터 자원 사용이 낮은 시간대 배치 처리 or 배치만 처리 위해 사용자가 사용하지 않는 또 다른 컴퓨터 자원 사용

스케줄러와 같은 시스템에 의해 실행되는 대상 -> ex) 오전 10시에 배치 실행... / crontab, jenkins...

Spring Batch는 배치를 처리하기 위해 Spring Framework 기반 기술 Spring에서 지원하는 기술 적용 가능. 비교적 간단한 작업(Tasklet) 단위 처리 or 대량 묶음(Chunk) 단위 처리

실행 단위 -> Job / Step

@Bean
public Job helloJob(){
    return jobBuilderFactory.get("helloJob") // 잡 이름 설정 - name은 스프링 배치를 실행할 수 있는 key 
        .incrementer(new RunIdIncrementer()) // Job이 실행될 때 마다, 파라미터 아이디 자동생성 
        .start() // job 실행시 최초로 실행할 지점 설정 
        .build();

Job은 실행단위를 구분할 수 있는 incrementer와 job의 이름, step을 설정.

    @Bean
    public Step helloStep(){ // step -> job 의 실행단위. 1개의 Job 은 1개 이상의 step 을  가질 수 있다.
        return stepBuilderFactory.get("helloStep") //
                .tasklet((contribution, chunkContext) -> { // step의 실행단위. step의 실행단위는 tasklet / chunk 기반 두개가 존재.
                    log.info("hello spring batch");
                    return RepeatStatus.FINISHED;
                }).build();
    }

• Spring batch는 Job type의 bean이 생성되면, JobLauncher 객체에 의해 Job 실행. Job은 Step에 실행

• JobRepository -> DB or Memory에 Spring batch가 실행할 수 있도록 배치의 메타데이터를 관리.

Job

• Job = JobLauncher에 의해 실행
• Job = 배치의 실행단위
• Job = N개의 Step 실행, 흐름(Flow) 관리. ex) A Step 실행 후 조건에 따라 B Step or C Step 실행 설정.

Step

• Step = Job의 세부 실행 단위. N개가 등록되어 실행됨.

Step의 실행단위

Chunk 기반 - 하나의 큰 덩어리를 n개씩 나눠 실행

-> ItemReader, ItemProcessor, ItemWriter ** 여기서 Item은 배치 처리 대상 객체 의미.

ItemReader?

배치대상의 리더를 만들거나 읽을 수 있다. 배치 처리 대상 객체를 읽어 ItemProcessor or ItemWriter에 전달 ex) 파일 or DB에서 데이터를 읽음

ItemProcessor?

ItemReader에서 읽은 것들을 가공하거나 필터링 할 수 있다. 필수값은 아님. 하지만 명확한 책임을 나눌 수 있어 사용. input 객체를 output 객체로 filtering or processing 해 ItemWriter에 전달. ex) ItemReader에서 읽은 데이터 수정 or ItemWriter 대상인지 filtering. ItemProcessor -> Optional함 ItemProcessor가 하는 일을 ItemReader or ItemWriter가 대신 할 수 있다.

ItemWriter?

배치 처리 데이터 최종 처리. 정상 데이터를 만들어 DB에 insert나 update.. 아니면 알림을 보낼수도 있다. 배치 처리 대상 객체 처리 ex) DB update or 처리 대상 사용자에게 알림

Task 기반 - 하나의 작업 기반으로 실행

Spring batch 테이블 구조와 이해

배치 실행을 위한 메타 데이터가 저장되는 테이블

BATCH_JOB_INSTANCE

• Job이 실행되며 생성되는 최상위 계층 테이블
• job_name과 job_key를 기준으로 하나의 row가 생성, 같은 job_name, job_key가 저장될 수 X
• job_key는 BATCH_JOB_EXECUTION_PARAMS에 저장되는 Parameter를 나열해 암호화해 저장
• JobInstance와 매핑

BATCH_JOB_EXECUTION

• Job이 실행되는 동안 시작/종료 시간, job 상태 관리
• JobExecution과 매핑

BATCH_JOB_EXECUTION_PARAMS

• Job을 실행하기 위해 주입된 parameter 정보 저장
• JobParameters와 매핑

BATCH_JOB_EXECUTION_CONTEXT

• Job이 실행되며 공유해야할 데이터를 직렬화해 저장
• ExecutionContext와 매핑

BATCH_STEP_EXECUTION

• Step이 실행되는 동안 필요한 데이터 or 실행된 결과 저장
• StepExecution과 매핑

BATCH_STEP_EXECUTION_CONTEXT

• Step이 실행되며 공유해야할 데이터를 직렬화해 저장
• ExecutionContext와 매핑

ExecutionContext? -> Job과 Step의 context를 모두 매핑

meta table의 script 위치? spring-batch-core/org.springframework/batch/core/* 에 위치 -> spring batch를 실행하고 관리하기 위한 테이블

JobInstance

생성기준? JobParameters 중복 여부에 따라 생성 다른 parameter로 Job 실행 -> JobInstance 생성 같은 parameter로 Job 실행 -> 이미 생성된 JobInstance 실행 JobExecution은 항상 새롭게 생성

ex) * 처음 Job 실행 시 date parameter가 1월 1일로 실행 -> 1번 JobInstance 생성 * 다음 Job 실행 시 date parameter가 1월 2일로 실행 -> 2번 JobInstance 생성
* 다음 Job 실행 시 date parameter가 1월 2일로 실행 -> 2번 JobInstance 재실행 -> 이때 Job이 재실행 대상이 아닌 경우 에러 발생

Job을 항상 새로운 JobInstance가 실행될 수 있도록 RunIdIncrementer 제공 -> RunIdIncrementer는 항상 다른 run.id를 Parameter로 설정

데이터 공유 ExecutionContext 이해

JobExecutionContext 는 Job 내에서만 데이터 공유 StepExecutionContext 는 Step 내에서만 데이터 공유

Batch를 처리할 수 있는 방법

Tasklet을 사용한 Task 기반 처리

• 배치 처리 과정이 비교적 쉬운 경우 쉽게 사용

• 대량 처리를 하는 경우 더 복잡

• 하나의 큰 덩어리를 여러 덩어리로 나누어 처리하기 부적합

  Chunk를 사용한 chunk(덩어리) 기반 처리

  • ItemReader, ItemProcessor, ItemWriter 의 관계 이해 필요

  • 대량 처리를 하는 경우 Tasklet보다 비교적 쉽게 구현

  • ex) 10000개 데이터 중 1000개씩 10개의 덩어리로 수행 -> 이걸 Tasklet으로 처리 시 10000개를 한번에 처리 or 수동으로 1000개씩 분할

    chunk 기반의 Step 종료 시점은 reader에서 null을 return 할 때 까지 Step 반복

    <INPUT,OUTPUT>chunk(int)

       *    reder에서 INPUT을 return
       *     processor에서 INPUT을 받아 processing 후 OUTPUT을 return 
           > INPUT, OUTPUT은 같은 타입일 수 있다. 
       *     writer에서 List<OUTPUT>을 받아 write 

JobParameters의 이해

JobParameters의 객체를 직접 사용하는 방법 / Spring에서 제공하는 EL 이용하는 방법

• 배치를 실행에 필요한 값을 parameter를 통해 외부에서 주입
• JobParameters는 외부에서 주입된 parameter를 관리하는 객체
• parameter를 JobParameters와 Spring EL(Expression Language)로 접근
  • String parameter = jobParameters.getstring(key, defaultValue);
  • @Value("#{jobParameters[key]}")

@JobScope / @StepScope 이해

spring의 scope는 bean의 lifecycle을 설정. spring의 기본 scope는 싱글톤 애플리케이션이 실행되는 시점에 생성, 종료되는 시점에 소멸

• @Scope - 어떤 시점에 bean을 생성/소멸 시킬 지 bean의 lifecycle 설정
• @JobScope - job 실행 시점에 생성/소멸 -> Step에 선언
• @StepScope - step 실행 시점에 생성/소멸

            -> Tasklet, Chunk(ItemReader, ItemProcessor, ItemWriter) 에 선언

• @Scope("job") == @JobScope
• @Scope("step") == @StepScope
• Job과 Step 라이프사이클에 의해 생성되어 Thread safe하게 작동
• @Value("#{jobParameters[key]}")를 사용하기 위해 @JobScope / @StepScope 는 필수

Apache POI 라이브러리 일부인 클래스. Excel workbook을 생성하고 편집하기 위한 기능을 제공. 워크북은 Excel 문서의 가장 높은 수준의 컨테이너, 시트(Sheet) 및 data 포함. Apache POI를 사용해 HSSFWorkbook 객체를 생성하고 액셀 워크북 만들 수 있고, 워크북에 시트를 추가하거나 시트에서 데이터를 읽고 쓸 수 있음.

Apache POI?

Java로 Microsoft Office 파일 포맷(ex. excel, word, powerpoint)을 생성, 읽기 및 수정하기 위한 라이브러리.

HSSFWorkbook 클래스는 특히 Microsoft Excel 파일을 다루기 위한 클래스 중 하나, 이 클래스는 구체적으로 Excel 97-2003 파일 형식(.xls)을 다루는데 사용.

Asynchronous JavaScript and XML AJAX를 사용 시 웹 페이지에서 비동기적으로 데이터를 가져오고 업데이트할 수 있다.

AJAX의 구성요소

1. Asynchronous(비동기적) AJAX는 비동기적인 방식으로 동작. 브라우저가 웹페이지를 계속 실행하며 서버로 요청을 보내고 응답을 기다리지 않아도 된다는 것을 의미. 데이터를 요청하고 응답이 올 때 까지 다른 작업을 계속할 수 있다.

2. JavaScript AJAX는 JavaScript를 사용해 클라이언트 측에서 동작. JavaScript는 브라우저에서 실행, 사용자와 상호작용하고 웹 페이지를 동적으로 제어

3. XML or JSON AJAX의 요청은 주로 XML, JSON 형식 데이터 사용. 이 데이터 형식은 서버와 클라이언트 간에 구조화된 정보를 주고받기 위해 사용

4. XMLHttpRequest 객체 or Fetch API AJAX 요청 생성하고 통신하기 위해 2가지 사용. 이 객체를 사용해 서버로 데이터를 보내고, 받을 수 있음

AJAX 작동

1. 사용자가 웹 페이지에서 어떤 작업 수행 -> JavaScript 코드 실행
2. JavaScript 코드 -> XMLHttpRequest객체나 Fetch API를 사용해 서버에 요청 -> 비동기적 작업이라 다른 작업 가능
3. 서버 요청 받은 작업 수행 후 응답을 클라이언트에 전송
4. 클라이언트에서는 응답을 받고, 웹페이지 일부 업데이트 or 새로운 데이터 표시 등 작업 수행

=> 웹 페이지를 새로고침하지 않아도 동적으로 데이터를 로드하고 업데이트 가능.

AJAX 설정

async(default: true)

기본이 비동기 처리. 동기 처리를 하려면 변경하면됨

complete: function(jqXHR jqXHR, String textStatus)

success, error에 관계없이 실행하고 싶은 로직 추가. finally와 같은 기능 수행

beforeSend: function(jqXHR jqXHR, PlainObject settings)

ajax가 서버로 요청하기 전에 실행되는 로직 실행 가능

참고문헌 https://milenote.tistory.com/46

DOM 페이지 로딩에 관해서 추가 스터디를 하고자 한다.

브라우저?

사용자가 선택한 자원을 서버에 요청하고 브라우저에 표시하는 것 자원은 HTML 문서, PDF, 이미지 등 다양한 형태를 띌 수 있다. 자원의 주소는 URL(Uniform Resource Identifier)에 의해 정해짐.

렌더링?

서버로부터 HTML, CSS, JavaScript등 작성한 파일을 받아 브라우저에 뿌림

렌더링 순서

1. 불러오기

• Loader가 서버로부터 전달받은 리소스 스트림 읽음

2. DOM, CSSOM 생성

• 웹 엔진의 HTML/XML 파서가 문서 파싱해 DOM Tree, CSS 파서가 CSSOM Tree 생성

3. 생성된 DOM과 CSSOM으로 렌더링 트리 생성 DOM Tree + CSSOM Tree, 렌더링에 필요한 노드만 선택해 페이지 렌더링에 사용

4. CSS, 레이아웃 렌더트리를 토대로 그릴 노드, 스타일, 크기 계산 렌더링 트리에서 위치, 크기를 알 수 없어 객체에 정해주는 과정.

5. 그리기 렌더트리의 각 노드를 실제 픽셀로 변환해 실제로 그리는 작업 실행

DOM 브라우저 로딩 순서

1. 사용자가 웹 페이지 방문 -> 웹브라우저 시작
2. 브라우저가 웹문서를 읽기 시작 -> 웹문서 읽기
3. DOM 생성 -> DOM이 생성시, ready method 실행. -> $(document).ready(function(){

        alert("태그 등의 셋팅이 완료되었을 시점에 이벤트 발생");
   }); 

   -> = 브라우저에서 DOM이 완성된 시점.

     DOM 트리 생성 직후이므로, window.onload보다 빠르다. 

4. 이미지를 포함한 요소들 로드
5. 페이지 로딩 완료 -> 모든 요소들이 로드 완료되면 load method실행 -> $(window).load(function() {

        alert("실행할 내용 ");
   });

   -> window.onload = function(){

        alert("할 것");

   } -> = 외부호출(src)등의 로딩이 완료된 시점(외부 호출까지 끝난 시점) -> 동일 페이지 내에서 onload함수는 하나만 존재해야함

쉽게 해석해 Ready가 load보다 빠름.

참고문헌 https://blog.naver.com/dssh87/222023739537 https://carpet-part1.tistory.com/730 https://velog.io/@zaman17/%EA%B8%B0%EC%88%A0%EB%A9%B4%EC%A0%91%EB%8C%80%EB%B9%84-%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EB%A0%8C%EB%8D%94%EB%A7%81-%EC%88%9C%EC%84%9C%EC%99%80-%EC%9B%90%EB%A6%AC

클라이언트가 서버에 요청을 보낼 때 그 요청의 결과가 어떻게 되었는지 알려주는 것

Informational responses(100 - 199)

100 Continue

클라이언트가 요청을 계속해야 하거나 요청이 이미 완료된 경우 응답을 무시해야함

101 Switchcing Protocols

클라이언트의 요청 헤더에 대한 응답으로 전송, 서버가 전환하는 프로토콜

102 Processing

서버가 요청을 수신해 처리 중 이지만, 아직 응답X

103 Early Hints

주로 헤더와 함께 사용, 서버가 응답을 준비하는 동안 Link사용자가 리소스를 미리 로드하기 시작할 수 있게함

Successful responses(200 - 299)

200 OK

요청 성공.

201 Created

요청 성공, 결과적으로 새 리소스 생성.

202 Accepted

요청이 수신되었지만 아직 실행X. HTTP에서는 나중에 요청결과를 나타내는 비동기 응답을 보낼 수 없어, 아직 비커밋. 다른 프로세스나 서버가 요청을 처리하는 경우나 일괄처리를 위한 것.

203 Non-Authoritative Information

반환된 메타데이터가 원본 서버에서 사용할 수 있는 것과 정확히 동일하지 않지만, 로컬 또는 타사 복사본에서 수집되었음을 의미. -> 주로 다른 리소스의 미러나 백업에 사용.

204 No Content

요청에 보낼 콘텐츠는 없지만, 헤더에 유용. 사용자는 이 리소스에 대해 캐시된 헤더를 새 헤더로 업뎃 가능

205 Reset Content

요청을 보낸 문서를 재설정하도록 사용자에 지시

206 Partial Content

리소스의 일부만 요청하기 위해 클라이언트에서 헤더를 보낼 때 사용

207 Multi-Status

여러 상태 코드가 적절할 수 있는 상황에 대해 여러 리소스에 대한 정보 전달

208 Already Reported

동일한 컬렉션에 대해 여러 바인딩의 내부 멤버를 반복적으로 열거하지 않기 위해 응답 요소 내부에서 사용

226 IM Used

서버는 GET 리소스에 대한 요청 이행, 응답은 현재 인스턴스에 적용된 하나 이상의 인스턴스 조작 결과 나타냄.

Redirection messages(300 - 399)

300 Multiple Choices

요청에 가능한 응답 2개 이상 존재. 사용자는 둘 중 하나를 선택.

301 Moved Permanently

요청한 리소스 URL 영구변경. 새 URL이 응답에 제공

302 Found

요청한 리소스의 URI가 일시적으로 변경됨 의미 URI가 추가로 변경될 수 있다. 따라서 클라이언트는 향후 요청에서도 동일한 URI 사용해야함

303 See Other

서버는 클라이언트가 GET 요청을 통해 다른 URI에서 요청한 리소스를 가져오도록 지시

304 Not Modified

캐싱 목적. 응답이 수정되지 않음을 클라이언트에 알리므로 클라이언트는 캐시된 동일한 버전의 응답 사용

305 Use Proxy

요청된 응답이 프록시에 의해 액세스함을 나타내기 위해 이전 버전의 HTTP 사양에서 정의. 프록시의 대역 내 구성과 관련된 보안 문제로 인해 더이상 사용X

306 unused

HTTP/1.1 사양에서 사용됨

307 Temporary Redirect

서버는 이전 요청에 사용된 것과 동일한 방법으로 다른 URI에서 요청된 리소스를 가져오도록 클라이언트에 지시.

308 Permanent Redirect

리소스가 Location: HTTP 응답 헤더에 지정된 다른 URI에 영구적으로 위치함을 의미.

Client error responses(400 - 499)

400 Bad Request

서버는 클라이언트 오류로 인식되는 사항으로 인해 요청을 처리할 수 없거나 처리하지 않음

401 Unauthorized

인증되지 않음 -> 클라이언트는 요청된 응답을 얻으려면 인증필요

402 Payment Required

응답코드는 향후 사용을 위해 존재. 이 코드를 생성하는 초기 목표는 디지털 결제 시스템에 사용되는 것. 하지만 지금 현재 거의 사용하지않음.

403 Forbidden

클라이언트는 콘텐츠에 대한 액세스 권한 없음.

404 Not Found

서버가 요청한 리소스 찾을 수 없음. 브라우저에서 URL이 인식되지 않음을 의미. API에서 엔드포인트가 유효하지만 리소스 자체가 존재하지 않음을 의미할 수도 있다.

405 Method Not Allowed

요청방법은 서버에 알려졌지만, 대상 리소스에서는 지원하지 않음. ex. delete 호출 허용하지 않음

406 Not Acceptable

웹 서버가 서버 기반 콘텐츠 협상을 수행 후 사용자 에이전트가 제공한 기준을 준수하는 컨텐츠를 찾지 못함

407 Proxy Authentication Required

프록시를 통해 인증을 수행해야함

408 Request Timeout

클라이언트의 이전요청 없이도 일부 서버의 연결에서 전송. 서버가 사용되지 않는 연결 종료함을 의미.

409 Conflict

요청이 서버의 현재 상태와 충돌할 때 전송

410 Gone

요청한 콘텐츠가 전달 주소 없이 서버에서 영구적으로 삭제되었을 때 전송. 클라이언트는 캐시와 리소스 제거 필요.

411 Length Required

Content-Length 헤더 필드가 정의되지 않고, 서버에서 요구하기 때문에 서버가 요청 거부.

412 Precondition Failed

클라이언트는 서버가 충족하지 않는 전제조건을 헤더에 표시

413 Payload Too Large

요청 엔티티가 서버에서 정의한 제한보다 큼. 서버는 연결을 닫거나, Retry-After 헤더 필드를 반환.

414 URI Too Long

클라이언트가 요청한 URI가 서버가 해석할 수 있는 것보다 길다.

415 Unsupported Media Type

요청한 데이터의 미디어 형식이 서버에서 지원하지 않아 서버 요청 거부

416 Range Not Satisfiable

Range 요청의 헤더 필드에 지정된 범위 이행 불가. 범위가 대상 URI의 데이터 크기를 벗어난 가능성 존재

417 Expectation Failed

요청 헤더 필드에 표시된 기대 사항을 Expect 서버에서 충족할 수 없음 의미.

418 I'm a teapot

?? 서버는 찻주전자로 커피를 끓이려는 시도 거부.. ?? HTCPCP Hyper Text Coffee Pot Control Protocol

421 Misdirected Request

요청이 응답을 생성할 수 없는 서버로 전달.

422 Unpocessable Content

요청의 형식은 올바르지만 의미 오류로 인해 따를 수 없다.

423 Locked

액세스 중인 리소스가 잠김

424 Failed Dependency

이전 요청의 실패로 인해 요청 실패

425 Too Early

서버가 재생될 수 있는 요청을 처리하는 위험을 감수할 의사가 없음 의미

426 Upgrade Required

서버는 현재 프로토콜을 사용한 요청 수행을 거부하지만 클라이언트가 다른 프로토콜로 업그레이드한 후 사용 가능.

428 Precondition Required

원본 서버에서는 조건부 요청 요구. 업데이트 손실 문제 방지하기 위해.

429 Too Many Requests

사용자가 주어진 시간 동안 너무 많은 요청 보냄 -> 속도 제한

431 Request Header Fields Too Large

헤더 필드가 너무 커서 서버가 요청 처리 불가. 요청 헤더 필드의 크기를 줄인 후 요청 다시 제출 가능

451 Unavailable For Legal Reasons

사용자 에이전트가 합법적으로 제공할 수 없는 리소스 요청

Server error responses(500 - 599)

500 Internal Server Error

서버에 처리 방법을 알 수 없는 상황 발생

501 Not Implemented

요청 방법이 서버에서 지원되지 않아 처리 불가.

502 Bad Gateway

서버가 요청을 처리하는데 필요한 응답을 얻기 위해 게이트웨이로 작동하는 동안 잘못된 응답을 받았음을 의미

503 Service Unvailable

서버가 요청을 처리할 준비가 되지 않음. 일반적인 원인 -> 서버가 다운되었거나 과부하 발생.

504 Gateway Timeout

서버가 게이트웨이 역할을 함. 시간 내에 응답을 받을 수 없음

505 HTTP Version Not Supported

요청에 사용된 HTTP 버전 서버 지원 안함

506 Variant Also Negotiates

서버에 내부 구성 오류가 있음.

507 Insufficient Storage

서버가 요청을 성공적으로 완료하는 데 필요한 표현을 저장할 수 없어 리소스에서 메서드 수행 불가

508 Loop Detected

서버가 요청을 처리하는 동안 무한 루프 감지

510 Not Extended

서버가 요청을 이행하려면 요청에 대한 추가 확장 필요

511 Network Authentication Required

클라이언트가 네트워크 액세스를 얻으려면 인증해야함

참조문헌

웹 브라우저가 원본 HTML을 읽어들인 후, style을 입힌 후 대화형 페이지로 만들어 뷰 포트에 표시하기까지 과정을 "Critical Rendering Path"라고함. 이 과정은 대략 두 단계로 나눌 수 있다.

1. 브라우저는 읽어들인 문서를 파싱해 최종적으로 어떤 내용을 페이지에 랜더링할지 결정.
2. 브라우저는 해당 랜더링 수행.

첫번째 과정을 거치면 "랜더 트리" 생성 랜더 트리? 웹 페이지에 표시될 HTML 요소들과 이와 관련된 스타일 요소로 구성. 브라우저는 랜더 트리를 생성하기 위해 다음과 같이 두 모델 필요.

• DOM - HTML 요소들의 구조화된 표현
• CSSOM(Cascading Style Sheets Object Model) - 요소들과 관련된 스타일 정보와 구조화된 표현

DOM(문서 객체 모델)

웹 페이지(HTML이나 XML 문서)의 콘텐츠 및 구조, 스타일 요소를 구조화 시켜 표현하여 프로그래밍 언어가 해당 문서에 접근하여 읽고 조작할 수 있도록 API를 제공하는 일종의 인터페이스. -> JS같은 스크립트 언어가 쉽게 웹 페이지에 접근해 조작할 수 있게 연결시켜주는 역할. -> 어떤 프로그래밍 언어에 의존하지 않는 독립적인 인터페이스.

DOM은 문서의 구조화된 표현(structured representation)을 제공하여 프로그래밍 언어가 DOM 구조에 접근할 수 있는 방법 제공. 문서 구조, 스타일, 내용 등 변경할 수 있다.

DOM은 nodes와 objects로 문서를 표현. -> 웹 페이지를 스크립트 or 프로그래밍 언어들에서 사용될 수 있게 연결시켜주는 역할담당. -> 웹 페이지를 수정하거나 생성하는데 사용되는 모든 property, method, event들은 objects로 구성.

DOM은 동일한 문서를 표현, 저장, 조작하는 방법 제공. 웹 페이지의 객체지향표현이며, 자바스크립트와 같은 스크립팅 언어를 통해 DOM 수정 가능.

DOM은 HTML 문서를 계층적 구조와 정보로 표현, 이를 제어할 수 있는 프로퍼티와 메서드를 제공하는 트리 자료구조. HTML DOM / HTML DOM Tree 트리 자료구조로 구축이 되어, HTML 문서는 최종적으로 하나의 최상위 노드(root 노드)에서 자식 노드를 가지며, 아래로만 뻗어나감.

Document node(문서 노드)

DOM Tree에서 최상위 루트 노드를 나타냄. document 객체를 가리킴. HTML 문서 전체를 나타내는 노드.

window 객체의 document property로 연결되어 window.document, doocument로 참조해 사용가능. HTML 문서에 문서노드는 오직 1개만 존재 가능.

element node(요소 노드)

모든 HTML요소(body, h1, div...) 속성 노드를 가질 수 있는 유일한 노드 부모-자식 관계를 가지게 되어 계층적 구조 이룸.

attribute node(속성 노드)

HTML 요소의 속성. 요소 노드에 대한 정보를 가짐(ex. color....) 요소 노드와 연결

text node(텍스트 노드)

정보를 표현, 가장 마지막에 위치하는 자식노드. 리프노드라고 불리기도함.

JavaScript DOM

자바스크립트는 DOM을 조작할 수 있는 프로그래밍 언어 중 가장 유명한 언어. 자바스크립트는 가장 빠르고 간편하게 DOM으로 구조화된 웹 문서에 접근해 노드(웹 컨텐츠를 이루는 모든 기본 요소)들을 조작 가능.

자바스크립트를 이용해 HTML 문서에 없는 노드를 만들어 이어 붙여 웹 페이지에 렌더링되게 만드는 모든 과정이 동적으로 구현하는 것. 또한, 자바스크립트를 이용해 노드에 없는 노드를 만들어 이어 붙이는 것도 동적으로 구현 가능.

정적으로 생성되는 과정은 오로지 이미 HTML 파일에 적혀 있는 코드를 위에서부터 아래로 읽어내려가며 생성되는 과정만을 뜻함. -> HTML 문서에 직접 태그로 작성하는 것 = 정적

DOM의 Datatype

DOM 객체의 구성 요소

property

DOM 객체의 멤버 변수. HTML 태그의 속성 반영

method

DOM 객체의 멤버 함수. HTML 태그 제어

collection

정보를 집합적으로 표현하는 일종의 배열.

event listener

HTML 태그에 작성된 이벤트 리스너(onclick, onchange...)들을 그대로 가짐.

style

style property를 통해 css style 시트에 접근 가능

DOM의 Datatype은 객체이기 때문에, property와 method를 가짐

document

member가 document type의 object를 리턴할 때, 이 object는 root document object 자체.

element

element는 DOM API의 member에 의해 return된 element 또는 element type의 node 의미

nodeList

element의 배열 nodeList의 Items은 index를 통해 접근 가능,

• list.item(1)
• list[1]

• 두 가지 방식 존재.

attribute

attribute가 member에 의해 리턴되는 것은 attribute에 대한 특별한 인터페이스를 노출하는 object reference.

namedNodeMap

array와 유사하지만, items은 name 또는 index에 의해 접근 가능.

DOM의 완전한 이해

DOM은 HTML이 아니다.

DOM은 HTML 문서로부터 생성되지만 항상 동일하지 않음. DOM이 원본 HTML 소스와 다를 수 있는 두가지 케이스 존재.

1. 작성된 HTML 문서가 유효하지 않을 때. DOM은 유효한 HTML 문서의 인터페이스. DOM을 생성하는 동안, 브라우저는 유효하지 않은 HTML 코드를 올바르게 교정.

2. 자바스크립트에 의해 DOM이 수정될 때. DOM은 HTML 문서의 내용을 볼 수 있는 인터페이스 역할을 하는 동시에 동적 자원이 되어 수정할 수 있다.

DOM은 브라우저에 보이지 않음

브라우저 뷰 포트에 보이는 것은 랜더 트리로 DOM과 CSSOM의 조합. 랜더 트리는 오직 스크린에 그려지는 것으로 구성되어 DOM과 다름. 랜더 트리는 display:none은 포함하지 않음!!

DOM은 개발도구에서 보이지 않음

개발도구의 요소검사기는 DOM과 가까운 근사치 제공. 그러나 개발도구의 요소검사기는 DOM에 없는 추가적인 정보 포함. Ex. css의 가사요소 -> ::before, ::after 선택자를 사용해 생성된 가상요소는 CSSOM과 렌더트리의 일부 구성. DOM은 오직 원본 html 문서로부터 빌드, 요소에 적용되는 스타일을 포함하지 않음.

요약

DOM은 HTML 문서에 대한 인터페이스.

1. 뷰 포트에 무엇을 렌더링할지 결정하기 위해 사용
2. 페이지의 콘텐츠 및 구조, 그리고 스타일이 자바스크립트 프로그램에 의해 수정되기 위해 사용
3. DOM은 원본 HTML 문서 형태와 비슷하지만
   • 항상 유효한 HTML 형식
   • 자바스크립트에 수정될 수 있는 동적모델
   • 가상 요소를 포함 x
   • 보이지않는 요소 포함 한다는 차이점 존재..

참고문헌 https://www.codestates.com/blog/content/dom-javascript https://wit.nts-corp.com/2019/02/14/5522

B-tree와 비슷한데, 다차원의 공간 데이터를 저장하는 색인 '현재 위치에서 200km 이내의 모든 도시를 찾아라'와 같은 질의에 대해 빠르게 응답.

R-tree는 공간을 최소 경계 사각형(MBR, Minimum Bounding Rectangle) 들로 분할해 저장. MBR 끼리 겹칠 수도 있고, 상위 레벨의 MBR은 하위 레벨의 MBR들을 포함하는 계층적인 트리 구조. 각 노드는 미리 정의된 범위 내에서 유동적인 개수의 자식 노드들의 정보(MBR과 포인터)를 가짐.

R-tree의 저장과 삭제 알고리즘 - 가까운 데이터들은 되도록 같은 단말 노드(leaf)에 형성 -> MBR 유지 가능, 검색 성능 향상.

검색 알고리즘

교차 질의(intersection)

최소 경계 사각형 MBR을 질의 입력으로 받지만, 검색은 B-tree와 유사. 검색은 루트 노드로부터 시작. 단말 노드를 제외한 모든 중간의 비단말 노드들은 자식 노드의 MBR을 포함하는 MBR을 가짐 단말 노드들의 MBR? 단말 노드가 가리키는 공간 데이터들을 둘러쌈. -> 모든 노트들은 질의 입력 MBR과 자식 노드들의 MBR을 비교해 교차되는 영역이 있는 자식 노드들에게만 질의 전달. -> 재귀함수로 구현 가능

포함 질의(Containment)

교차 질의와 유사, 교차되는 영역이 있는 자식노드가 아닌, 질의를 포함하는 자식노드들만 검색

근접 이웃 질의(Nearest Neighbor)

점 좌표와 거리를 입력으로 받음. 특정 점 좌표로부터 가장 가까운 거리에 위치한 데이터를 찾는 알고리즘 필요

삽입 알고리즘(insertion)

부적절한 상태에 있는 노드 -> 적절한 범위에서 벗어난 수의 항목을 가지고 있다는 것 의미

1. 노드가 어느 위치로 삽입될지 찾은 후 삽입
2. 부적절한 상태의 노드가 없으면 삽입 종료
3. 만약, 어떤 노드가 너무 많은 항목 보유시, 두 노드로 분류 -> 반복적으로 트리를 타며 진행. -> 루트 노드를 분리했을 시는 새로운 루트 노드 생성
4. B-tree와 달리, 노드 분리 시, 공간의 특성 고려. 분리된 MBR들의 겹침정도를 고려해 분리할 차원을 결정, 선형(linear), 사각형(quadratic), 소모적(exhaustive) 분리 알고리즘 있다.

삭제 알고리즘

1. 자율 값의 위치를 찾은 후 그 값을 가진 노드 삭제
2. 부적절한 상태의 노드가 없다면, 삭제 과정 종료
3. 부적절한 상태의 노드 존재시, B-tree와 유사하게 해결.

회사에서 현재 사용하는 PostgreSQL과, 내가 사용했던 MySQL의 차이점을 알아보고자한다.

PostgreSQL vs MySQL

PostgreSQL은 복잡한 쿼리와 대규모 데이터베이스를 다룸

MySQL은 설치와 관리가 비교적 쉽고, 빠르고, 신뢰할 수 있고, 쉽게 파악 가능한 간단한 DB

PostgreSQL은 테이블 상속, 함수 오버로딩 등의 기능을 갖춘 객체 관계형 데이터베이스(ORDBMS) MySQL은 순수 관계형 데이터베이스(RDBMS)

MySQL의 경우 웹사이트와 온라인 트랜잭션에 적합, 기능이 많지 않아 속도와 안정성에 중점 PostgreSQL은 복잡한 대규모 분석 프로세스에 적합, 많은 기능 보유, ACID 호환, 높은 동시성

둘 다 NoSQL 제공

속도? 대량의 데이터 집합, 복잡한 쿼리, 읽기=쓰기 작업을 처리할 때 -> PostgreSQL이 빠름 읽기 전용 명령 -> MySQL이 더빠름

MySQL의 인덱스 유형

• INDEX, FULLTEXT, PRIMARY KEY, UNIQUE 등 B-tree에 저장된 인덱스
• 공간 데이터 형식에서 찾을 수 있는 인덱스 등 R-tree에 저장된 인덱스
• FULLTEXT 인덱스 사용 시 해시 인덱스 및 역 리스트

PostgreSQL 인덱스 유형

• 해시 인덱스 및 B-tree 인덱스
• 테이블 일부의 정보만 정리하는 부분 인덱스
• 열 값과 반대로 수식 함수의 결과로 인덱스를 만드는 수식 인덱스

코딩 차이점

대소문자 구분

MySQL은 대소문자 구분 안함. PostgreSQL은 대소문자 구분.

기본 문자 집합 및 문자열

특정 MySQL 버전의 경우 문자 집합과 문자열을 UTF-8로 변환. PostgreSQL - 문자 집합과 문자열을 UTF-8 변환 필요 X, UTF-8 구문은 PostgreSQL에서 허용X

결론

복잡한 쿼리와 대규모 데이터베이스를 다룰 수 있는 기능이 풍부한 데이터베이스가 필요 -> PostgreSQL

설치와 관리가 비교적 쉽고, 빠르고 안정적이며, 파악이 어렵지 않은 간단한 데이터베이스 -> MySQL

객체관계 데이터베이스 - ORDBMS?

object-relational database; ORD, ORDB) or 객체관계형 데이터베이스 관리 시스템(object-relational database management system; ORDBBMS)

ORDBMS는 오브젝트 지향 모델(OODBMS)과 관계형 모델(RDBMS) 사이의 하이브리드 인 데이터베이스 관리 시스템. 객체 지향의 사고방식을 채용. 소프트웨어 개발자가 스스로 데이터 형식과 방법을 자유롭게 정의해 데이터베이스 개발

ORDBMS의 기술의 목표? 소프트웨어 개발자에게 문제 영역을 생각하는 수준까지 데이터베이스 설계의 추상화 수준 높임.

특징?

• 사용자 정의 타입 지원
• 참조 타입 지원
• 중첩된 테이블 - 테이블을 구성하는 레코드 상의 하나의 항목이 또 다른 레코드의 집합(테이블)으로 구성되는 복합 구조를 모델링 하는 것 가능.
• 대단위 객체 지원 - LOB(Large OBject; 대단위 객체)타입이 기본 타입으로 지원