Colin Kang

Mysql의 InnoDB는 MVCC ( Multi Version Concurrency Control )을 사용하며, 이는 이전 버전으 데이터와 rollback을 지원하기 위해서 변경된 row의 이전 데이터를 commit/rollback이 완료될 때까지 보관하고 있어서 한다. rollback을 위해서 이러한 데이터는 undo log에 저장이 되며, linked list 형태로 관리되기 때문에 History List 이며, 이 list가 길어지는 혹은 증가하고 있다는 것은 undo 데이터가 많아지고 있으며 transaction이 여전히 commit/rollback 되지 않고 있다는 것을 의미한다. undo데이터가 삭제되는 순간은 undo데이터가 더이상 필요 없어지는 순간이며, 이 것이 삭제 되지 않는 것은 어떤  transaction에서 이 데이터가 계속 필요하다고 혹은 참고하고 있다고 판단되기 때문이다. 

History List Length, undo로그가 증가되는 원인은 다음과 같다.

- read나 write에 long transaction : 

mysql의 default isolation model은 REPEATED_READ이므로 다른 transaction이 해당 row를 변경하고 commit했더라고 그 transaction이전부터 select를하고 지금도 하고 있다면 undo는 보관을 하고 변경되기 이전의 데이터를 select에서 repeat read했을 때에도 제공해야한다. ( 참고로 대부분의 사람들이 착각하는데 select 등의 read는 transaction이 없는 걸로 오해하는데, select도 tranaction과 항상 같이 고민해야하며, transaction의 범위 내에 있다고 생각해야한다. ) 하여 read에 long transaction도 HLL을 증가시킬수 있다.

- heavy write

많이 기록하는 경우에는 당연히 HLL이 발생할낟.

- commit을 하지 않은 user session

이 경우는 흔지 않지만, 찾기가 어려우며, DB에 문제를 줄 수 있다. 예들 들어 auto-commit false로 데이터를 한건 넣고 기다린다고 하면, 

commit이 아직 안되었기 때문에 HLL이 purge되지 않고 이후의 HLL에 기록되는 transaction도 purge 되지 않는다. user sessino이기 때문에 timeout이 적용안되서 rollback이 되지않으면서, idle하고 그 이후에 DB에 영향을 주기 않고 있기 때문에 각종 monitoring 지표에서 찾아내기가 어렵다. 해당 user session을 종료하기 전까지는 HLL은 계속 증가한다. 만약 HLL이 계속 증가하면 언젠가는 DB shutdown 혹은 restart상황으로 갈수 있다.

조치

long running transaction을 찾아서 commit 혹은 rollback 해야한다.

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/proactive-insights.history-list.html

https://lefred.be/content/a-graph-a-day-keeps-the-doctor-away-mysql-history-list-length/

https://www.percona.com/blog/chasing-a-hung-transaction-in-mysql-innodb-history-length-strikes-back/

https://dev.mysql.com/doc/refman/8.0/en/innodb-multi-versioning.html

https://www.percona.com/blog/mysql-performance-implications-of-innodb-isolation-modes/

Mysql에 slow query log 를 남기게 되면 long_query_time 보다 지정 해놓은 시간 이상 소요되면  slow_query_log_file에 해당 query ( DML/DDL 모두 ) 남기게 된다.

이를 응용하여 long_query_time = 0 으로 지정해 놓으면 모든 쿼리가 파일로 저장되게 된다.

다만, 모든 쿼리가 파일로 저장되게 되므로 DB의 DDL/DML의 performance에 영향을 주게 되고 해당 파일을 써야하므로 io도 증가한다.

AWS aurora는 해당 파일을 parameter group에서 관리하므로 해당 option을 변경 후 DB Restart를 하면 적용된다.

적용전 

적용 후

slow low는 couwatch로 전송가능하다.

RDS > Modify > Additional Configuration > 

적용 후 RDS 상태 :

RDS Event

빌드 : 

프로그래밍한 소스 코드를 컴파일, 테스트, 배포, 문서화 등을 수행하는 일련의 작업

소스 코드 파일을 컴퓨터에서 실행할 수 있는 독립 소프트웨어 과정과 그 결과물

그레이들 빌드

초기화, 설정, 빌드 스크립트 + 속성파일 환경변수 프로젝트 디렉토리

스크립트

init, setting, build

init.gradle setting.gradle build.gradle

객체

Gradle, Setting, Project

gradle.properties 

그레이들 빌드 수행

명령어 해석 > 그레이들 실행 > 스트립트 초기화 > 프로젝트 설정 > 테스트 실행 > 결과 출력

명령어 해석, 그레이들 실행

( 명령어 해석, 디렉터리 확인, 속성 파일 확인, 클래스 인스턴스 생성, 실행 모드 판단 )

스크립트 초기화

( script 파일 확인 읽기 > 멀티 / 싱글 프로젝트 판단 > project 객체 생성 > 명령어 옵션 및 인수 설정 )

프로젝트 설정

( 참조 중인 라이브러리 확인 > Task 객체 및 태스크 그래프 생성 )

태스크 실행

( 태스크 추출 > 태스크 실행 )

그레이들 주요 스크립트 블록

tasks.register("hello") {
    doLast {
        println("Hello world!")
    }
}

gradle -q hello

※ -q는 그레이들 실행시 log를 최소화해서 보여줌

UPDATE mysql.user SET Host='%' WHERE Host='localhost' AND User='username';
UPDATE mysql.db SET Host='%' WHERE Host='localhost' AND User='username';
UPDATE mysql.tables_priv SET Host='%' WHERE Host='localhost' AND User='username';
UPDATE mysql.columns_priv SET Host='%' WHERE Host='localhost' AND User='username';
UPDATE mysql.procs_priv SET Host='%' WHERE Host='localhost' AND User='username';
UPDATE mysql.proxies_priv SET Host='%' WHERE Host='localhost' AND User='username';
FLUSH PRIVILEGES;

CREATE USER 'myuser'@'%' IDENTIFIED BY 'mypass';

GRANT ALL ON *.* TO 'myuser'@'%';



GRANT ALL PRIVILEGES 
 ON *.* TO 'remote'@'%' 
 IDENTIFIED BY 'safe_password' 
 WITH GRANT OPTION;`
 
 

@Version은 Spring에서 Entity 사용시 optimistic lock 관리를 하기 위한 어노테이션

로그성이 아니고 update가 있다면 웬만하면 사용하기를 권장

OptimisticLockingException Mechanism은 다음과 같음

•https://vladmihalcea.com/jpa-entity-version-property-hibernate/

https://docs.oracle.com/javase/tutorial/java/data/numberformat.html

https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html

Java Persistent API

기술개요

- EJB 2.x에서 DB에 접근하기 위해 사용되었던 Entity Bean을 JSR-220(Enterprise JavaBeans 3.0)에서 대체하는 새로운 기술

- JSR-000338 JavaTM Persistence 2.1 ( stored procedure, converter, entity graph..)

http://download.oracle.com/otndocs/jcp/persistence-2_1-fr-eval-spec/index.html

- Entity Bean과는 아주 다른 POJO(Plain Old Java Object) 기반의 ORM(Object-Relational Mapping) 프로그래밍 모델을 제공하며 기존에 존재하던 Hibernate와 같은 ORM솔루션과 유사

- EJB3.0에 국한되지 않은 범용적인 기술로 만들어 졌기 때문에 JAVA EE 와 SE 환경에서 모두 사용 할 수 있으며 JAVA SE 5.0 Annotation을 사용하여 Java 객체에서 RDB로 Mapping하는 방법을 단순화

- SQL 매퍼 ( 마이바티스) 는 SQL 만들고 매핑만, ORM (하이버네이트) (SQL 생성, 매핑)

- 사실상, Spring + JPA + Hibernate (JPA의 implementation, ORM 프레임워크 )

- Hibernate (hibernate-entitymanager)

- entity 분석, SQL 생성, JDBC API 사용, resultset과 객체 매핑, 패러다임 (객체지향(상속, 다형성)과 RDBMS의 사상) 불일치 해결

용어

Entity : 엔터티 : 일반적인 엔터티는 비지니스 요구사항을 모델링한 객체를 일컷는데, JPA에서 entity는 table과 해당 table의 relation을 표현한 객체

JPA : entity operation

- 저장 

jpa.persist(entity)

- 조회

jpa.find(Entity.class, entityId);

- 수정

Entity entity = jpa.find(Entity.class, memberId);

entity.setId(1);

- 연관 객체 조회

entity.getAnotherEntity();

JPA는 같은 트랜잭션일 대 같은 객체가 조회되는 것을 보장한다.

String entityId = "100";

Entity entity1 = jpa.find(Entity.class, entityId);

Entity entity2 = jpa.find(Entity.class, entityId);

entity1 == entity2 ? "identical" : "not identical"

+ 추가 개인적인 의견

- hibernate + criteria는 sql이기 보다는 새로운 select query를 위한 문법을 배우는 새로운 장벽

- Insert, update, delete 는 이전부터 정형화 되었지만, select 부분은 정형화가 되기 어려운 부분이거너 query generate 하기위해서 추가적인 비용이 소요되었음

- 초기에 DAO (Data Access Object)를 만들어서 DB와 매핑하였고, 이를 확장되면 ORM (Object Relation Mapping) 프레임워크이란 영역의 세계로 진입하게 됨. 하지만 다들 사상이 다르고, 새로운 learning curve를 만들고, 현 DB의 SQL을 보완하지 못함.

http://www.javajigi.net/pages/viewpage.action?pageId=5924

jdbcTemplate 방법

public List<Actor> findAllActors() {

  return this.jdbcTemplate.query( "select first_name, last_name from t_actor", new ActorMapper());

}

private static final class ActorMapper implements RowMapper<Actor> {

  public Actor mapRow(ResultSet rs, int rowNum) throws SQLException {

    Actor actor = new Actor();

    actor.setFirstName(rs.getString("first_name"));

    actor.setLastName(rs.getString("last_name"));

    return actor;

  }

}

EXPLAIN : plan을 확인

ANALYZE : table의 통계 정보 제공

통계정보 생성 : ANALYZE

통계정보 확인 : DESCRIBE EXTENDED / FORMATTED

통계정보 설정 : SET hive.stats.autogather=true;

하이브 로그 

{HIVE_HOME}/conf/hive-log4j.properties

hive --hiveconf hive.root.logger=DEBUG,console

https://www.slideshare.net/oom65/file-format-benchmarks-avro-json-orc-parquet

ORC / snappy가 main stream?

http://tableau.coupang.com/t/review/views/EDDMissRate/MultiplePrioritytypes?iframeSizedToWindow=true&:embed=y&:showAppBanner=false&:display_count=no&:showVizHome=no

Kafka를 검토하게 된 계기 :

결론 : 

log데이터를 S3 에 저장하고, AWS EMR로 로그 데이터를 가공하며, 다시 이를 S3에 저장, 

이를 조회는 hive로, 가공은 MR, SPARK로 함. 

그럼 바로 instance에서 log data를 S3에 저장하면 되는데, KAFKA를 쓴 이유는 KAFKA가 이러한 데이터를 block size 단위로 S3에 저장할 수 있기 때문에 partition 내의 데이터 크기가 일정해지고, 

향후 해당 partition 의 데이터를 EMR에서 load시 한번 load로 데이터를 불러 오기 때문에 효율적으로 운영할 수 있다.  

현재 AS-IS의 RDBMS의 한계 :

1. 개별 도메인에서 사용하는 로그성의 데이터 (예를 들어 user activity, (로그인, 저장, 수정, action 들, comment, 등등)을 저장하기 위한 목적 

2. 이러한 데이터는 로그가 많지 않을 경우, RDB에 저장하게 된다. 이유는 도메인 데이터를 기존에 저장하고, 여기에서 확장해서 로그를 더 남기면 infra 관점에서 기존 코드를 그대로 이용할 수 있다. 

3. SQL로 쿼리가 가능하며, sorting이나 통계성 쿼리도 가능하므로, 분석도 가능

4. 이를 계속 사용하지 않는 이유 : 현재는 AWS의 Aurora를 사용하고 있으며, slave 에서 쿼리를 보내면 filter에 index가 있을 경우는 좀 나으나, 아니면 무척느림, group by등의 통계나, 조회는 기대 이상으로 느림

5. RDB는 여전히 매력적인 platform이지만 오라클을 오래사용해서인지, 다른 DB는 그냥 파일 저장소 + index이외에 다른 management기능이 많지 않으니 그냥 공유 데이터 저장소 용도 목적으로만 충실하게 사용하게 됨

6. RDB에 남기는 데이터는 대부분 최소화 하고 key로 mapping한다. 하여 많은 데이터가 누락되고,  msa에서는 빅뱅방식의 대규모 전환은 어려우니, 계속 적으로 기존 schema에 add를 하는 방식이라, null데이터도 많고 중복도 많으며, 정규화 되지 않았으니 데이터가 다 남지도 않으며, 의미가 생각된 데이터가 남아 이후 미래에 분석시점에서 원래의 의미를 추적할 수가 없음

7. RDB를 버려야하는 시점 : (10억건 이상이 넘어 갈 경우, 하지만 3V에 답할 수 있어야지... 하지만, 모든 데이터는 data Interface를 SQL로 operation할 수 있는 곳으로 모여야 데이터에 대한 진입장벽이 낮으므로 business user들이 분석이 가능함 )

RDBMS외 다른 platform검토 

5. MYsql의 한계를 느끼고, 다른 platform을 검토하였음, 

5-1. no-sql : 적합하지 않고, 도메인 업무상 document 분석할거 아니면,  no-sql사용할 일 없으며, api로 언제 복잡한 걸 짜서 데이터를 추출해내나. -> pass

5-2. redshift :  vertica등, 분산 rdb는 기존의 쿼리가 다 돌아간다는 장점이 있지만, computing도 전체 노드에서 수행할 수 있지만, results 가 다 취합이 될때까지는, wait이고,  전체 데이터 search시에는  느려지며, 결국, 저가 장비로 분산 computing이외에는 별다른 merit이 없음, 데이터가 늘어나고, 조회 조건에 데이터가 늘어날수록 더 많은 시간이 걸림. -> pass

5-3. mr : update가 없다는 가정하에서, 데이터를 partition 만 잘해서 넣어 놓으면, mr로 아후 row-level로 데이터를 manipulation할 수 있으며, hive 로도 웬만한 쿼리는 지원하니 많은 용량의 데이터를 관리하기에 적합, 하지만 node와 upgrade 유지보수를 어떻게 관리 -. pass

5-4. AWS EMR : AWS node 관리해주다 보니, 데이터만 넣어 주면 

5. 그럼 다른 곳에 저장해야하는데, 저장하는 것은 어렵지 않으나, 이렇게 저장된 데이터를 어떻게 조회하며, 이후에 내가 원하는 데이터만 찾아내거나 ( search), 통계 목적으로 이러한 데이터를 가공해야하는 것도 고려해야 함.

ElastiSearch를 검토했었어야 했음. 2024.05.31 added

Kafka 작동원리

Producer : 메세지를 메세지 set에 넣은 후  producer에게 send, 메세지 생성하여 broker에게 전달

Broker : 전달받은 메세지를 topic별로 분류하여 저장

Consumer : 특정 broker에 연결하여 topic을 pull로 가져옴.

topic은 하나 이상의 파티션으로 구성됨

Kafka single partition :

Simple storage : topic의 각 partition은 동일 크기의 segment file의 set으로로 구성됨

producer가 message를 publish하면 segment file의 맨 뒤에 append.

성능상의 이유로 설정된 메세지 개수가 채워지면 한번에 append함

memory에는 offset을 가지고 읽어야할 segmentfile의 읽어야할 첫번째 list point

Efficient transfer :

file system page cache. 

multi subscriber system

linux sendfile api (file channel to socket channel)

Stateless broker :

simple time based retention policy to delete a message

can rewind

KAFKA 장점

distributed, multiple message into a single request, 

queue 에 오래 대기해도 됨 ( mq는 consume하지 않으면 메세지로 인해 시스템 다운 가능)

메세지를 메모리가 아닌 파일 시스템에 저장

pull model : 상황에 따라 가능한 용량만큼 pull이 가능

topic 중심 메세지 관리

참조정보 :

http://epicdevs.com/17

Kafka: a Distributed Messaging System for Log Processing : http://notes.stephenholiday.com/Kafka.pdf

https://aws.amazon.com/ko/blogs/big-data/best-practices-for-running-apache-kafka-on-aws/

https://aws.amazon.com/ko/blogs/big-data/building-a-recommendation-engine-with-spark-ml-on-amazon-emr-using-zeppelin/