생각을 개발하자, 박진형

TIL - 0813

Stream API

  • Stream API : 콜렉션에 저장된 요소(데이터)에 대해 어떤 처리를 하기위해 만들어진 API
    • forEach로 하면 안되나? 코드 간결해지면서도 Lazy한 처리가 가능(최종 결과내는 메소드를 사용하지않으면 그때까지 처리를 하지않음), *기존 콜렉션에 대해서는 조작하지않으면서도 원하는 결과값을 얻어낼 수 있음, 병렬처리를 쉽게할 수 있음(API에 있음)
    • 데이터 변경보다는 데이터 처리가 주목적

IntSummaryStatistics

  • 최댓값, 최솟값, 평균 등 기본적으로 필요한 값에 대해 매번 구하려고 Stream API 쓰는게 아니라 하나의 객체만 리턴하도록 하면 됨
    • 어떤 값에 대해 최대, 최소, 평균 등을 구할 것인지 Stream API에서 람다식으로 정의하면 됨
public class ContactConsole {

    public static void main(String[] args) {
        Contact contact = new Contact();
        contact.addAll(Arrays.asList(
                new Person(1L, "jinbro", 27),
                new Person(2L, "imjinbro", 30))
        );
        
        IntSummaryStatistics statistics = contact.getStatics();
        System.out.println(statistics.getAverage());
        System.out.println(statistics.getMax());
        System.out.println(statistics.getMin());
    }
}

/******** Contact.java ********/
public IntSummaryStatistics getStatics() {
	return contact.stream()
					.mapToInt(Person::getAge)
					.summaryStatistics();
}

Database

계정 생성, 권한 설정

  • root 계정으로 접근, 사용하지말고 계정을 만들어서 사용하기
> use mysql;
> create user colin@localhost identified by password;
> grant select|insert|update|all privileges on db_name.table_name|*.*| to colin@'%' identified by password with grant option;
> flush privileges;
  • localhost를 입력할 경우 외부에서는 접근 불가
    • %로 변경하면 외부에서 해당 아이디로 접근 가능
  • 전체적으로 권한을 줄 수도 있고, 특정 권한만 줄 수도 있음 - 데이터베이스, 테이블 설정도 마찬가지
    • 설정 적용을 위해 flush
    • 권한 제거를 위해 revoke를 사용하면 됨

Trasaction Isolation Level

  • 트랜잭션의 isolation 정책을 위반하지않으면서도 성능을 지키기위해 최선인 레벨을 찾기 : 데이터의 성격에 따라 적절한 레벨 선택(기본 레벨은 보통 Repeatable Read)
    • 트랜잭션 간에 간섭(Read - Write)을 일으키지않으면서도 성능(Throughput : 처리량)까지 떨어뜨리지않도록
    • 기본 : 트랜잭션의 처리가 무시되어서 안됨 - Lost Data Problem
  • 격리레벨 종류와 발생할 수 있는 문제점
    1. Read Uncommitted : 커밋되지않은 변경까지도 다른 트랜잭션에서 읽어낼 수 있음 - Dirty Read 발생(변경 적용하지않은 데이터 읽기 - 항공사나 영화관 좌석 예약에서 사용자 경험 개선을 위해 해당 레벨을 사용하는 것으로 추정, 결제 과정까지 가서 이미 예약된 자리라고 하면 안되니깐?)
    2. Read Committed : 커밋된 내역만 다른 트랜잭션에서 읽을 수 있음 - Repeatable Read가 불가함, T1 트랜잭션에서 A 데이터에 대해 읽어놓은 상태에서 T2가 A 데이터에 대해 읽고 - 변경 - 커밋을 한다면 T1이 다시 읽었을 때 처음 읽은 상태가 아닌 변경된 상태를 읽게됨(반복된 읽기가 불가함), 트랜잭션 간 간섭해서는 안된다는 기본적인 정책은 위배하지만 트랜잭션 처리가 씹히지는 않으니 결과에는 상관없음(a=2에서 시작해서 T2가 a=3으로 변경하고 T1이 다시 처리를 할 때 a=3를 읽고 처리를 하게되므로 상관은 없음)
    3. Repeatable Read : 반복 읽기가 가능한 레벨, 해당 레벨을 사용하면 T1에서 SELECT 하는 데이터에 대해 Lock이 걸려 트랜잭션이 끝날 때까지 해당 데이터에 대해서는 변경 불가(SELECT - Shared Lock, Update 불가함 - UnShared Lock), 결국 변경할 수 없으니 반복적인 읽기가 가능함, 선택에 따라 반복적인 읽기까지 필요없겠다싶으면 Read Committed를 사용하면 됨(결과값은 예상할 수 있는 경우 안에 있음이 보장됨), Insert는 가능
    4. Serializable : SELECT를 사용한 영역에 대해 다른 트랜잭션에서 Insert까지 불가함, 완벽한 직렬 처리(쓰루풋 상 굉장히 좋지못함 - 사용하지않음)
  • 격리레벨이 1에 가까울 수록 동시 처리하지만 Read - Write 작업 처리 보정을 위해 복잡해지고, 4에 가까울 수록 단순하지만 성능 상 좋지 못함

Basic

  • CPU는 Read-Write 연산의 연속 : 메모리에 저장된 값을 읽어와서 연산 후 다시 메모리에 연산한 결과를 써줌
    • 멀티쓰레드 환경에서 공유 변수에 대해 처리를 할 떄 잘 해야하는 이유 : 동시에 읽고 쓰려고 할 때 한 쓰레드에서 쓴 결과가 프로그래밍에 따라 씹힐 수도 있음(동시 커밋)