Java World

Java Korean

Author Archives: heewoo

kibana 설치 샷

Posted on by Posted in search engine

스크린샷 2016-06-13 오전 12.56.16

 

엘라스틱 서치  대시보드로 유명한 녀석이죠 ㅋ

키바나…

그냥.. local 서버에 설치한 기념으로…ㅋ

(키바나 설치후 첫화면ㅋ)

대시보드를 잘 활용하면..

데이터 분석, 로그분석 등등 유용하게…ㅋ

쓸수있겠죠잉…

다음엔 el, kibana 설치과정 정리해서 포스팅 예정.(오늘은 귀찮..)

 

검색엔진 카테고리 추가되었습니다.e

Posted on by Posted in search engine

tree

 

search engine 카테고리 추가했습니다.

search  ==  google…응?

검색 하면 역시 구글이죠.. ㅋ

검색엔진 약간(?) 흥미가 생겨서

기록하기위해 카테고리 만들었네요 ㅋ

HTTP 로 떠나는 시간여행…

하루에 생성되는 웹문서 수십억개..

내가 찾고 싶은 문서 단한개…

어떻게 찾아내느냐.. 어떻게 보여줄꺼냐..

정말 대단한 구글신입니다 ㅋㅋ

내가 쌓은 데이터를 얼마나 빨리..

얼마나 정확하게 도출해내는게

지상 최대 과제… ㅋ

시작해봅시다 ㅋ

Express vs Hapi 간단한 비교

Posted on by Posted in Hapi

Hapi(Http API Server)
Hapi(Http API Server)는 Express와 같은 Node.js 기반의 웹 프레임웍으로 월마트 연구실의 Eran Hammer와 그의 팀에 의해 개발되었다.

Express로 뭔가를 만들다가 Express에 실망하고 빡쳐서 ‘더 좋은걸 만들거야 하고!!’ 만들었다나 뭐라나 ^^;

Eran Hammer는 다음과 같은 생각으로 Hapi 개발을 결심했다고 한다.

– 설정이 코드보다 낫다.
(정말 설정을 많이 하는 것이 코드를 작성하는 것보다 나은지에 대한 의견이 분분하다고 한다)
– business logic과 transport layer는 분리되어야 한다.
– buffer, stream과 같은 native node 구성들은 첫번째 클래스 객체로 제공되어야 한다.

서버를 생성하는 간단한 샘플코드는 다음과 같다.

Express

var express = require('express');
var app = express();

var server = app.listen(3000, function(){
    console.log('Server start');
});

Hapi

var hapi = require('hapi');
var server = new hapi.Server(3000);

server.start(function () {
    console.log('Server start');
});

Json Array 데이터를 java ArrayList 데이터로 변환

Posted on by Posted in Java

json라이브러리중에 GSON 라이브러리를 사용해서
Array 형태의 JSON String을 ArrayList 형태로 자동 변환을 해보도록 하겠습니다.

1. JSON

 
[
    {
        title:'초보를 위한 Java'
        , author:'홍길동'
        , isbn : 'A000022200f'
    }
    , {
        title:'Java 개발자'
        , author:'이몽룡'
        , isbn : 'A1111100ff0'
    }
]

2, JAVA

class Book {
    private String title;
    private String author;
    private String isbn;
}

3, JSON To ArrayList

Gson gson = new Gson();
Type type = new TypeToken<list<book>>() {}.getType();


List<book> bookList = gson.fromJson(jsonString, type);
</book></list<book>

mysql 실행계획 Explain

Posted on by Posted in MySQL

Explain 정보보는법

 

인덱스가 적절히 사용되고 있는지 검토
나열된 순서는 MYSQL 이 쿼리처리에 사용하는 순서대로 출력

EXPLAIN 의 각 행 설명

1. id : SELECT 번호, 쿼리내의 SELECT 의 구분번호

2. select_type : SELECT 의 타입

  • SIMPLE: 단순 SELECT (UNION 이나 서브쿼리를 사용하지 않음)
  • PRIMARY: 가장 외곽의 SELECT
  • UNION: UNION 에서의 두번째 혹은 나중에 따라오는 SELECT
  • DEPENDENT UNION: UNION 에서의 두번째 혹은 나중에 따라오는 SELECT, 외곽쿼리에 의존적
  • UNION RESULT: UNION 의 결과물
  • SUBQUERY: 서브쿼리의 첫번째 SELECT
  • DEPENDENT SUBQUERY: 서브쿼리의 첫번째 SELECT, 외곽쿼리에 의존적
  • DERIVED: SELECT 로 추출된 테이블 (FROM 절 내부의 서브쿼리)

3. table : table명

4. type : 조인타입, 우수한 순서대로… 뒤로갈수록 나쁜 조인형태

  • system
    테이블에 단 하나의 행만 존재(시스템 테이블). const join 의 특수한 경우
  • const
    많아야 하나의 매치되는 행만 존재할 때
    PRIMARY KEY 나 UNIQUE index 를 상수와 비교할 때
    각 컬럼값은 나머지 연산에서 상수로 간주, 처음 한번만 읽어들이면 되므로 매우 빠름
  • eq_ref
    조인수행을 위해 각 테이블에서 하나씩의 행만이 읽히는 경우
    조인연산에 PRIMARY KEY 나 UNIQUE index 인덱스가 사용되는 경우
    인덱스된 컬럼이 = 연산에 사용되는 경우
  • ref
    이전 테이블과의 조인에 사용될 매치되는 인덱스의 모든행이 이 테이블에서 읽혀질 때
    leftmost prefix 키만을 사용하거나 사용된 키가 PRIMARY KEY 나 UNIQUE 가 아닐때
    (즉 키값으로 단일행을 추출할수 없을때)
    사용된 키가 적은수의 행과 매치되면 이것은 적절한 조인 타입
    ref 는 인덱스된 컬럼과 = 연산에서 사용됨
  • ref_or_null
    ref 와 같지만 NULL 값을 포함하는 행에대한 검색이 수반될 때
    서브쿼리 처리에서 대개 사용됨
  • index_merge
    인덱스 병합 최적화가 적용되는 조인 타입
    이 경우, key 컬럼은 사용된 인덱스의 리스트를 나타내며
    key_len 컬럼은 사용된 인덱스중 가장 긴 key 명을 나타냄
  • unique_subquery
    몇몇 IN 서브쿼리 처리에서 ref 타입대신 사용됨
    unique_subquery 는 성능향상을 위해 서브쿼리를 단순 index 검색 함수로 대체함
  • index_subquery
    unique_subquery 와 마찬가지로 IN 서브쿼리를 대체
    단, 서브쿼리에서 non-unique 인덱스가 사용될때 동작 함
  • range
    인덱스를 사용하여 주어진 범위 내의 행들만 추출
    key 컬럼: 사용된 인덱스
    key_len: 사용된 가장 긴 key 부분
    ref 컬럼: 이 타입의 조인에서 NULL
    키 컬럼이 상수와 =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN 또는 IN 연산에 사용될때 적용됨
  • index
    인덱스가 스캔된다는걸 제외하면 ALL 과 같음
    일반적으로 인덱스 파일이 데이타파일보다 작기 때문에 ALL 보다는 빠름
    MySQL 은 쿼리에서 단일 인덱스의 일부분인 컬럼을 사용할때 이 조인타입을 적용함
  • ALL
    이전 테이블과의 조인을 위해 풀스캔
    (조인에 쓰인) 첫번째 테이블이 고정이 아니라면 비효율적
    대부분의 경우에 아주 느린 성능
정리:
system – const – eq_ref – ref – ref_or_null – index_mergy – unique_subquery – index_subquery – range – index – ALL

5. possible_keys : MySQL 이 해당 테이블의 검색에 사용할수 있는 인덱스들
possible_keys 에 나타난 인덱스들이 결과에 나타난 테이블 순서에서 실제 사용할 수 없을수도 있음

6. key :  MySQL 이 실제 사용한 key(index)

7. key_len : MySQL 이 사용한 인덱스의 길이, key 컬럼값이 NULL 이면 이값도 NULL
key_len 값으로 MySQL 이 실제 복수컬럼 키중 얼마나 많은 부분을 사용할 것인지 알 수 있음

8. ref : 행을 추출하는데 키와 함께 사용된 컬럼이나 상수값

9. rows : 쿼리 수행에서 MySQL 이 예상하는 검색해야할 행수

10. Extra : MySQL 이 쿼리를 해석한 추가적인 정보를 나타냄

  • Distinct: MySQL 이 매치되는 첫행을 찾는 즉시 검색을 중단한다는 의미
  • Not exists: MySQL 이 LEFT JOIN 을 수행함에 매치되는 한 행을 찾으면 더이상 매치되는 행을 검색x
  • range checked for each record (index map: #): MySQL 이 사용할 좋은 인덱스가 없음 의미
  • Using filesort: MySQL 이 정렬을 위해 추가적인 과정을 필요로 함
  • Using index: 컬럼정보가 실제 테이블이 아닌 인덱스트리에서 추출, 쿼리에서 단일 인덱스된 컬럼들만을 사용하는 경우
  • Using temporary: MySQL 이 결과의 재사용을 위해 임시테이블을 사용, 쿼리 내에 GROUP BY 와 ORDER BY 절이 각기 다른 컬럼을 사용할때 발생
  • Using where: WHERE 절이 다음 조인에 사용될 행이나 클라이언트에게 돌려질 행을 제한하는 경우 테이블의 모든 행을 검사할 의도가 아니면 ALL 이나 index 라면 쿼리사용이 잘못된 것임
  • Using sort_union(…) , Using union(…) , Using intersect(…)
  • Using index for group-by: Using index 와 접근방식이 같으며, 추가적인 디스크 접근 없이 GROUP BY 나 DICTINCT 쿼리에 사용된 모든 컬럼에 대한 인덱스를 찾았음을 의미

SQL 옵티마이져

Posted on by Posted in Databases

OPTIMIZER_MODE 의 개념#

초기화 파라미터인 OPTIMIZER_MODE는 오라클 인스턴스가 최적의 Access 경로를 선택하는 기본 설정이 된다. 즉 옵티마이저가 어떠한 기준으로 최적화된 Access 경로를 추출 하는지 결정하는 방법에 대해 제시 한다고 볼 수 있다.

옵티마이저(Optimizer) : #

  1. Rule-based – SQL에 대한 Execution Plan이 여러 개 있다고 할 때, 가장 낮은 순위의 실행계획을 항상 사용
  2. Cost-based – 가장 cost가 적은 실행계획을 선택

실행환경#

  1. CHOOSE : Optimizer가 CBO와 RBO 두 가지가 모두 선택 가능할 경우에 사용
  2. ALL_ROWS : CBO 환경경에서 전체적인 처리, 즉 Batch 환경에서 주로 사용
  3. FIRST_ROWS : CBO 환경에서 빠른 응답시간을 얻고자 할 때, 즉 ON-LINE 환경에서 주로 사용
  4. RULE : RBO 환경에서 사용
MODE 장점 단점
RULE Analyze작업이 불필요,
일정한 응답속도를 기대		 전문가에게 의존도가 매우 높음,
옵티마이저 대부분의 기능을 사용 못함
CHOOSE 옵티마이저 기능을 최대한 활용 주기적인 Analyze작업이 필요,
비효율적인 실행계획수립 발생
FIRST_ROWS Nested Loop 위주의 실행계획수립 일부 Hash Join으로 바꾸는 작업 필요
ALL_ROWS Hash Join 위주의 실행계획 수립 일부를 Nested Loop로 바꾸는 작업 필요

Rule-Based Optimizer (규칙기반 최적화)#

  1. RBO는 규칙에 의해서 실행되므로 예측가능하고 통제 가능하므로 대부분의 DBA, 프로그래머들이 선호
  2. RBO는 구문 중심으로, SQL 구문을 변경할 경우 성능이 향상될 수 있음(통계정보, 비용계산 비사용). 오직 규칙에 의해서만 실행계획을 결정
  3. 테이블의 row수가 작거나 query가 일반적으로 row의 대부분을 반활할 때에도 가능하면, 항상 인덱스를 사용함으로써 비효율적이 될 수도 있음. 테이블명에 대한 파싱은 우에서 좌로 진행되기 때문에 최후 기술된 테이블이 먼저 처리

RBO 순위표(규칙)#

  1. 문장의 WHERE절에 ROWID나 Oracle Precompiler에 지원되는 확장된 SQL 구문 구조의 CURRENT OF CURSOR에 의해 지정된 ROW들이 식별될 수 있을 경우에만 사용이 가능
  2. 문장의 WHERE 절에 join이 단지 하나의 row를 return하는 것을 보증하는 조건절을 가지고 있어야 함. 이러한 조건절은 unique하거나 primary key인 칼럼의 ‘=’ 조건절과 유사함. 이러한 조건들은 반드시 AND 연산자를 통해 합쳐져야 하고, 이러한 문장을 수행하기 위해 Oracle은 nested loops 연산을 수행
  3. WHERE 절이 ‘=’조건절에 HASH CLUSTER KEY의 모든 칼럼을 사용하여야 하며, 합성된 CLUSTER KEYS인 경우에는 ‘=’ 조건절이 반드시 AND 연산자에 의해 연결되어야 함. 문장은 칼럼이 HASH CLUSTER KEY를 만들어 내듯이 UNIQUE나 PRIMARY KEY를 만들어내기 때문에 단지 하나의 ROW만을 RETURN해야 함
  4. WHERE절이 ‘=’ 조건절에서 칼럼들의 unique나 primary key를 사용할 경우에 사용
  5. 이 접근 경로는 두 Join 테이블이 같은 cluster에 저장되고, 문장의 Where절에 한 테이블의 각 칼럼에 대해 대응하는 테이블의 칼럼을 같게 하는 조건절을 포함하는 경우 사용함.
  6. WHERE절에 hash cluster key인 칼럼의 ‘=’조건절이 있을 경우에 사용
  7. WHERE절에 Index cluster key인 칼럼의 ‘=’조건절이 있을 경우에 사용
  8. WHERE절에 결합 INDEX의 칼럼이 있을 경우에 사용
  9. WHERE절에 single row index의 칼럼이 있을 경우에 사용
  10. index column이 bound range 된 것을 Where 조건에서 있을 경우에 사용
  11. index column이 unbound range 된 것을 Where조건에서 있을 경우에 사용
  12. where조건에 있는 칼럼들이 각각의 index로 구성되었을 경우에 사용
  13. MAX와 MIN함수의 argument는 칼럼, 상수, +연산자, ||연산자나 CONCAT함수 등을 포함하는 어떠한 수식도 올 수 있음. 단, select 절에 다른 수식이 오지 않아야 하며 문장은 WHERE절이나 GROUP BY절이 없어야 함.
  14. index의 칼럼이 order by절에서 이용할 경우에 사용
  15. 마지막으로 테이블 전체를 읽게 됨

Cost-Based Optimizer (비용기반 최적화)#

  1. 이론적으로 RBO에 비해 진보됨, 전문지식이 없어도 악성계획의 회피 가능
  2. 논리적인 한계성이 존재, 원하는 경로로 유도하기 어려운 단점

CBO 환경 설정 Parameter#

  1. Optimizer Mode = CHOOSE : 비용 기반 옵티마이저 환경을 의미
  2. ALL_ROWS : 비용 기반 옵티마이저 환경을 의미하며, SQL문의 WHERE 조건을 만족하는 모든 행을 가장 빠르게 검색하는 실행 계획을 결정함
  3. FIRST_ROWS : SQL문의 WHERE 조건을 만족하는 첫 번째 행을 가장 빠르게 검색하는 실행계획을 결정함
  4. FIRST_ROWS_10 : ~~ 10개 행을
  5. FIRST_ROWS_100 : ~~ 100개 행을
  6. FIRST_ROWS_1000 : ~~ 1000개 행을

CBO 특징#

  1. 좌에서 우로 파싱되므로 최초 기술된 테이블이 먼저 처리됨
  2. ANALYZE 명령은 과부하를 초래하기 때문에 항상 최선은 아님
  3. CHOOSE Mode에서 SQL문에 포함된 테이블 중 어느 하나라도 이미 분석된 상태라면, 그 SQL문은 기본적으로 CBO(비용기반 최적화)에 맞춰지게 됨

Optimizer Modes 설정 방법#

  1. Optimizer Mode = ( CHOOSE, ALL_ROWS, FIRST_ROWS, RULE
  2. 시스템 전체에 지정하기 (instance level) SQL> SET AUTOTRACE TRACE EXPLAIN
  3. 세션에서 지정 (Seesion level) ALTER SESSION SET OPTIMIZE_MODE = ( CHOOSEM ALL_ROWS, FIRST_ROWS, RULE )
  4. SQL문장에서 지정 (Statement level)
  • SELECT /*+ (ALL_ROWS, FIRST_ROWS, RULE) * /
/*+ CHOOSE */
/*+ RULE */
/*+ ALL_ROWS */
/*+ FIRST_ROWS[(n)] */
  • Hint를 사용하지 않는 경우 Session 혹은 System 전체에 정해진 Rule로 실행계획을 생성한 상태

옵티마이저를 이용한 SQL 튜닝#

인덱스 정보 이용법#

SELECT DISTINCT B.CLASS, COUNT(B.CLASS)   // DISTINCT는 아래의 GROUP BY에 의해 의미가 없음
FROM COL A, COM B
WHERE A.YEAR = B.YEAR
AND A.HOUSE = B. HOUSE
A.SERIAL_NO = B.SERIAL_NO
A.AMT >=100
B.DATE < '950501'
B.CLASS IN('C', 'Y', 'I' ,'P')
GROUP BY B.CLASS;

CHOOSE Mode와 CBO#

  1. 조합된 테이블 중 어느 하나라도 이미 분석된 상태라면, 기본적으로 CBO로 작동함
  2. SELECT /** RULE **/ ROUND (NUV(SUM(C.REQR_QTY Z.MIN_COMP_QTY * …

비용 기반 옵티마이저를 이용한 sql튜닝#

  1. 아무런 인덱스가 없는 테이블 EMP의 znalyze 되기 전의 실행계획
SELECT ename
FROM emp
WHERE deptno = 20
AND empno BETWEEN 100 TO 200
ORDER BY ename;

Execution Plan
-----------------------------------------------------------------------
0          SELECT STATEMENT Optimizer = CHOOSE
1     0      SORT (ORDER BY)
2     1         TABLE ACCESS (FULL) of 'EMP'

현재는 아무런 인덱스가 없으며 분석되지 않았으며, 비용기반이 아님

  1. 테이블 emp만 analyze 되었을 경우의 실행계획
SQL> ANALYZE TABLE emp COMPUTE STATISTICS;

분석 이후 Cost, Card, Byte등이 출력됨. (Cost가 큰 수일수록 비효율적임)

  1. 테이블 emp의 칼럼 deptno에 대해서 인덱스 생성시의 실행계획
SQL> CREATE INDEX EMP_DEMPTNO_IDX ON EMP(DEPTNO);

초기의 COST보다 18이 줄은 값이 나옴 인덱스 사용이 미사용보다 COST가 높았다면 인덱스를 사용하지 않았을 것임

예제#

SQL>conn / as sysdba
SQL> show parameter optimizer_mode

NAME                                 TYPE        VALUE
------------------------------------ ----------- -------------------------
optimizer_mode                       string      CHOOSE
SQL> alter session set optimizer_mode = first_rows_1;

세션이 변경되었습니다.

SQL> show parameter optimizer_mode

NAME                                 TYPE        VALUE
------------------------------------ ----------- -------------------------
optimizer_mode                       string      FIRST_ROWS_1

사용된 optimizer mode 알아내기#

select sql_text, optimizer_mode, optimizer_cost, parsing_schema_name 
from v$sql
where lower(sql_text) like 쿼리

not found in class java.io.PrintStream

Posted on by Posted in Java

ERROR Method printIn(java.lang.String)(메소드명) not found in class java.io.PrintStream(클래스명)

발생되는 경우 자신이 사용한 클래스의 메소드가 맞지 않는(=없는)경우

조 언 자신이 사용한 클래스의 메소드가 맞지 않는(=없는) 경우에 발생하는 에러이므로

API를 통해서 사용하고자 하는 클래스와 메소드를 다시 한번 확인해 봅니다.

보통 이경우 메소드의 철자나 대소문자를 잘못 쓴 경우가 많으니 그점을 유심히 살표봅니다.

마지막으로 철자와 대소문자도 맞는다면 메소드의 인자의 객체형을 맞게 주었는지 확인해보면 됩니다.

java.lang.ClassNotFoundException: org.gjt.mm.mysql.Driver

Posted on by Posted in Java

ERROR java.lang.ClassNotFoundException: org.gjt.mm.mysql.Driver(드라이버명)

발생되는 경우 JDBC로 데이터 베이스에 연결하는 중 드라이버를 찾지 못할 경우

조 언 JDBC를 연결하는 중에 드라이버를 찾지 못할 경우에 발생하는 에러이므로

각 데이터 베이스에 맞는 드라이버가 제대로 다운로드 되었는지 확인해 보시고

드라이버의 위치가 클래스 패스에 잡혀 있는지 확인해주시면 됩니다.

Error opening registry key ‘Software\JavaSoft\Java Runtime Environment’

Posted on by Posted in Java

ERROR Error opening registry key ‘Software\JavaSoft\Java Runtime Environment’

Error: could not find java.dll

Error: could not find Java 2 Runtime Environment

발생되는 경우 중복설치 등으로 인해 레지스트리 키값이 잘못되어 있는 경우

조 언 중복설치 등으로 인해 레지스트리 키값이 잘못되어 있는 경우에 발생하는 에러이므로

레지스트리 편집기를 열어서 HKEY_LOCAL_MACHINE -> SOFTWARE -> JavaSoft에

보시면 3개의 키가 있을 겁니다. 그중에서 첫번째 키인 Java 런타임 환경 을 마우스

오른쪽 버튼으로 클릭하여 Java Runtime Environment로 이름을 바꿔주시면 됩니다.