지금 현재 들어가면 선착순 3만대 까지 OTP 무료로 주네요
이기회에 바꿔 보시는 것도 좋을 것 같네요

느려터진 익스플로어에서 벗어나..
늦어지만 빠른 크롬이나 파폭으로 뱅킹하는 시대가
우리나라도 오는 것 같습니다. 

하지만 사용해보니 몇가지 불만 사항이 아직 있네요. 

1. 계좌비밀번호 조회에서 사용되는 
마우스로 입력하는 형식은 키보드로도 입력이 
가능하도록 선택이 가능했으면 좋겠습니다.  
일본 리소나 은행 같은 경우는 로그인과 패스워드를 마우스로 입력하는데
키보드로도 입력 가능하도록 선택이 가능하거든요..

2. 엑티브X
물론 공인인증서를 사용하기 위해서 필요하기는 하지만
크롬에서도 결국 인스톨이 필요하네요..
외국계 은행을 사용해보면 필요없는 데 말이죠..
이거 법적으로 공인인증서 확인이 필수 인가요???

3. 최근에 사용한 계좌번호도
자주쓰는 입금 계좌 옆에 추가 해줬으면 하네요..
타 은행에 있던데 의외로 편하더라구요...

익스플로우를 싫어하는 저로서는 
이거 때문에.. 주거래은행을 바꿀가라는 생각도 드네요. 

링크 : https://u.wooribank.com/

 

'날적이' 카테고리의 다른 글

크롬 유용한 확장 프로그램  (0) 2012.04.30
PDFmyURL  (0) 2011.11.17
Hadoop 0.20.205.0 , Hive-0.7.1, Hbase-0.90.4  (0) 2011.11.10
블로그 어렵다...  (0) 2010.10.20
첫 글...  (0) 2010.06.01

Java에서 XML없이 SQL개발하기

 요약하면, Java의 여러 프레임웍은  Xml안에 SQL을 넣는 방식을 지원하는데, 줄바꿈이 있는 문자열을 편하게 쓰게 해주는 따옴표 세 개문법 (""")만 Java에 추가된다면 XML을 사용하는 목적을 충족시키면서도 XML로 인한 여러 단점들을 겪지 않아도 된다는 것입니다. 따옴표 세개는 Java에서 추가될 예정이지만, Groovy등에서는 이미 지원합니다. 지금이라도 SQL관리에만 Groovy를 쓰면 쿼리편집이 조금 더 편리해질만도 합니다.

 

XML로 SQL을 관리할 수 있는 Java framework

  많은 Java 프레임웍들이 SQL구문들을 XML파일 안에서 코딩하게 되어 있습니다.

  가장 대표적인 것이 iBatis입니다. 아래와 같이 SQL 구문, 파라미터를 운반하는 클래스,  쿼리의 결과가 담길 클래스를 XML안에 선언합니다.

 

    <select id="findByIsbn13" parameterClass="string" resultClass="book">
    SELECT  title,    author,     isbn13,     isbn10,     pages, content, imageUrl
    FROM book
    WHERE isbn13 = #isbn13#
    </select>
    <select id="findByTitle" parameterClass="string" resultClass="book">
    SELECT  title,    author,     isbn13,     isbn10,     pages, content, imageUrl
    FROM book
    WHERE title = #title#
    </select>

 

그리고 Hibernate와 JPA에서도 "named query"라는 개념으로, SQL을 따로 XML파일로 빼도 됩니다. 아래는 Hibernate에서 SQL을 XML 파일안에 설정한 예입니다.

 

<sql-query name="findBookByIsbn13">
    <return alias="book" class="tdd.edu.domain.Book"/>
   SELECT  title,    author,     isbn13,     isbn10,     pages, content,  imageUrl
   FROM book
    WHERE isbn13 = :isbn13
 </sql-query>

 Navie SQL과 Hibernate가 쓰는 HQL을 모두 .xml파일 안에 선언하는 것이 가능합니다. JPA를 사용해도 마찬가지로 JPA-QL, Native SQL을 모두 XML에 넣어도됩니다.

 

 Spring JDBC에서는 jdbctemplate.execute 등의 메소드에서 SQL내용을 직접 문자열로 넘기게 되어있지만, Applicaton context 안에 쿼리를 저장해두고, 이를 사용하는 쪽에서 java.util.Properties 같은 객체를 Dependency Injection 받아서 사용하면 iBatis처럼 XML로 쿼리가 관리됩니다.

 

<util:properties id="bookSqls">
    <prop key="findByIsbn13">
   SELECT  title,    author,     isbn13,     isbn10,     pages, content,  imageUrl
   FROM book
    WHERE isbn13 = :isbn13
    </prop>
</util:properties>

 

 그런데, Spring-jdbc나 Hibernate, JPA에서는 XML에 SQL을 저장하는 방식이 선택일 뿐이지만, iBatis 2.x에서는 반드시 XML안에 쿼리를 넣어야합니다.  myBatis라고 이제 이름이 갈라진 iBatis 3.x에서는 Annotation으로 쿼리를 지정할 수 있어서, .java파일 안에 문자열로 SQL에 넣어도 되기는 합니다.

 

final String PERSIST_INFO =
“INSERT INTO simple_information(info_id, info_content) VALUES (#{infoId}, #{infoContent})”;

@Insert(PERSIST_INFO)
public int persistInformation(SimpleInformationEntity simpleInfo) throws Exception;

(예제는 http://java.dzone.com/articles/mybatis-formerly-called-ibatis 에서)

 그런데, 이런식으로 쿼리까지 Annotation으로 지정하는 것에 대해서는 의견이 분분할 것 같고, 개인적인 생각으로는 Spring jdbc나 Hibernate처럼 필요하면 직접 메소드 시그니처에 직접 SQL을 문자열로 넘기는 방식이 훨씬 더 자연스럽다고 보여집니다.

 

문제점은?

 iBatis에서는 파라미터에 따라서 SQL이 다르게 구성되는 다이나믹 쿼리를 아래와 같이 선언합니다.

<isEqual property="writerSelected" compareValue="false">
  <isNotNull property="writerList">
    <iterate prepend=" AND writer in" property="writerList"
       open="(" close=")" conjunction=",">#writerList[]#
    </iterate>
  </isNotNull>
</isEqual>

if, for문 처럼 조건,반복문들이 XML로 표현되어 있습니다. 이는 절차적 프로그래밍을 SQL로 하게 되어서 아래와 같은 단점이 있습니다.

  1. 조건, 반복문에 해당하는 태그 문법을 별도로 배워야함
  2. 괄호"{}"대신 열고 닫는 태그가 단락을 구분하기 때문에, 같은 조건,만복문을 코딩해도 Java 같은 범용언어에서보다 긴 코드가 나오게됨
  3. Compile time의 validation범위가 더 줄어들게 됨.  getter, setter로 참조하게 될 속성명에 오타가 있어도 직접 실행해봐야지 오타를 알 수 있음.
  4. Java파일 밖이므로, Emma와 같은 Coverage 확인 툴로 실제 해당 절이 실행되었는지 확인할 수도 없음.

 

왜 SQL이 XML에 들어가게 되었을까?

   직접 JDBC를 쓰면 Connection 관리와 Exception처리 등이 불편합니다. 그리고 JDBC의 Prepared Statement에서는 파라미터를 "?"를 표시하기 때문에 거기에 넘어가는 변수를 위치의 순서로 파악을 해야 합니다.  ":id"와 같이 named parameter를 넣을 수 있다면 훨씬 쿼리의 가독성이 높아집니다. 그래서 그러한 Jdbc의 미흡한 점들을 보완해주는 프레임웍들이 각광을 받았습니다.

  그런데, Connection이나 Excpetion처리의 편의성, named parameter의 활용하고 싶다고 해서 반드시 XML로 SQL를 관리해야 하는 것은 아닙니다. XML을 안 써도 되는 Spring의 jdbcTemplate에서도 그런 기능은 다 제공을 합니다.

  SQL이 한 파일에 모여있지 않으면  DBA한테 쿼리 검수를 맡기거나, 여러 SQL을 한번에 수정할 일이 있을 때 불편해 지기도 합니다. 그러나 그런 점도 SQL 내용을 상수로 선언하는  .Java 파일을 따로 분리하면 해결할 수 잇습니다. SQL을 보관하는 .java파일에 *SqlMap.java와 같은 명명규칙을 부여하고,  SQL 검수를 맡길 때 그 파일만 넘기면 됩니다. 다만, XML에 있을 때보다 줄바꿈 문자등이 불편하게 들어가는데, 그 점은 아래에서 더 자세히 이야기하고자 합니다.

  또, 과거에는  .java파일 밖에 SQL이 있으면 SQL만을 수정을 했을 때는 다시 컴파일을 안 해도 된다는 장점이 강조되었습니다. 그러나, 요즘은 개발 PC에서는 Eclipse로, 서버에 배포할 때는 Ant나 Maven으로 빌드과정이 간편해졌고, 설정파일을 수정해도 파일의 복사를 위해 그런 배포과정을 똑같이 거쳐야 하므로, 컴파일이 필요없다는 것도 더이상 장점이 되지 못합니다.

   XML에 SQL을 썼던 가장 핵심적인 이유는 .java파일에서는 줄 바꿈이 들어간 문자열을 편집을 하는 것이 불편했기 때문입니다.   Java 파일에서는 문자열이 한 줄이 넘어가면 아래와 같이 + 기호를 이용해서 이를 연결해주는 방법 밖에 없습니다.

 

public static final String SELECT_BY_ISBN13 = "SELECT name , id " +

                                                                                      "FROM user " +

                                                                                      "WHERE isbn13 = :isbn13 ";

 

 보통 Toad와 같은 DB client 도구에서 SQL을 작성해서 프로그램에 붙여넣기도 하고, 디버깅 중에는 프로그램 내에 있는 SQL을 반대로 DB client 툴에 붙여넣어서 실행해보기도 하는데, 그 때마다 저렇게 줄바꿈마다 "+"가 있다면 쿼리 편집이 많이 번거로워집니다. 그래서 XML파일 안에 SQL이 있으면 줄바꿈이 있는 긴 문자열도 똑같이 붙여넣을 수 있기 때문에, SQL을 개발하는 작업이 훨씬 편해집니다.  이렇게 SQL이 XML안에 들어가다보니 동적쿼리를 만들기 위한 조건,반복문과 각종 파라미터 매핑 클래스등까지 다 XML에 포함되어 버렸고, 앞에서 말한 부작용들이 점점 드러나기시작했습니다.

  물론 Eclipse의 설정으로 .java 파일에 붙여넣기를 할 때는 "+"를 넣는 것과 같이 줄을 바꿀 때 필요한 작업들을 자동으로 할 수도 있습니다.

 Windows-Preference-Java-Editor-Typing란의 "Escape text When pasting into a string literal"을 선택하고, 큰 따옴표 하나를 연 채 여러줄을 붙여넣으면, 알아서 줄이 바뀔 때는 " + " 기호를 넣어줍니다.

 

typing(1).png

 그리고 반대로 이런 여러줄의 String을 DB 접속 툴에 붙여 넣을 때도 Toad 같은 툴에서는 그런 "+"와 같은 기호를 제거해 주는 기능이 있기도 합니다. 그러나 이런 기능을 활용할 수 있다고 해도, XML에 바로 붙여 넣을 때보다는 불편합니다.

 

 그런데  Python, Groovy, Scala, Ruby, PHP에서 이미 지원하고 있는 '따옴표  3개짜리 문자열 선언'이 Java에도 포함된다면 그런 편집의 불편함을 겪지 않아도 됩니다. 아래와 같이 중간에 줄바꿈이 있어도 전체 SQL 내용이 끊어지지않고 들어갑니다.

 public static final String SELECT_BY_ISBN13 =    """

  SELECT  title,    author,     isbn13,     isbn10,     pages, content,  imageUrl
   FROM book
   WHERE isbn13 = :isbn13

""";

  이 따옴표 3개는 이미 JDK7에 포함되는 것이 제안된 상태인데, JDK에 포함될 실험적인 내용을 구현해보는 "Kijaro"라는 프로젝트에서는 Enhanced String Handling for Java 이름으로 이 명세를 다루고 있습니다. 그러나, 내년 중반기 쯤에 JDK7에 포함되어 발표될 예정인, java의 문법 개선내용을 주로 담고 있는 project coin에서는 아직 이를 찾아볼 수 없어서, 언제 Java에 반영될지는 아직 미지수입니다.

 그렇다면 Java에서 따옴표 3개를 지원해주기 전까지는 계속 XML의 불편함을 감수해야 할까요? 저는 이미 이 문법을 지원하는 Groovy를 SQL관리 용도로 사용해볼만 하다고 생각합니다.

 

Groovy로 따옴표 3개 문법을 이용해서 SQL 관리하기

  Groovy를 사용하기 위해서는 Eclipse와 Maven에 아래 설정만 해주면 됩니다.

 

  1. Eclipse에서 Groovy plugin 설치

     ( update site는 http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/ )

  2.  pom.xml에 아래와 같이 Groovy를 compile할 수 있는 plugin과 dependency 추가

 

Dependencies에 선언 추가

<dependency>

         <groupId>org.codehaus.groovy.maven.runtime</groupId>

         <artifactId>gmaven-runtime-1.6</artifactId>

        <version>1.0</version>

</dependency>

 

 build-plugins 에 아래 내용 추가

   <plugin>
                <groupId>org.codehaus.groovy.maven</groupId>
                <artifactId>gmaven-plugin</artifactId>
                <version>1.0</version>
                <executions>

                    <execution>

                      <goals> <goal>compile</goal></goals>
                      <configuration>
                      <sources><fileset>
                                    <directory>${pom.basedir}/src/main/java</directory>
                                    <includes>
                                        <include>*-/-.groovy</include>
                                    </includes>
                       </fileset> </sources>
                       </configuration>
                   </execution>
               </executions>
            </plugin>

 

 Gmaven plugin에 대한 자세한 내용은 http://docs.codehaus.org/display/GMAVEN/Building+Groovy+Projects 참조

 

 그리고 New-> groovy class를 선택하여서 java 파일 작성하듯이 클래스를 만듭니다.

 new_groovy_class.png

java 문법을 그대로 쓸 수 있으니 따옴표 3개를 쓸 수 있다는 점만 다르다고 생각해도 됩니다. 아래와 같이 .groovy 파일 안에 들어간 SQL이 색깔도 다르게 표시되어 비교적 가독성이 높게 표시되는 것을 확인할 수 있습니다.

groovy_sqls.png

   그런 다음 DAO 등 SQL을 호출하는 쪽에서는 이 상수 문자열을 바로 참조합니다. 상수 선언이 되어 있으니 아래와 같이 오타를 쳐도 미리 알려주고, Ctrl + Space를 치면 자동완성도 됩니다.

 typing_error.png

 

  Dynamic SQL의 경우에도 직접 Java안에서 if문으로 써서 적어주면 됩니다. 아래와 같이 EclEmma 같은 도구로 coverage를 측정하면, 실제 실행되지 않은 조건분기도 눈으로 보입니다.

 

coverage.png

   위의 코드를 Spring-JDBC를 사용했는데, 필요하다면 Hibernate나 apache commons DBUtils에서도 적용 가능한 방법입니다. 다만 Hibernate에서는 Criteria 같은 것을 이용하면 문자열로 길게 쓰는 쿼리가 많이 나오지는 않을 것으로 예상합니다. 그리고 myBatis(iBatis 3.0)의 Annotation으로 지정하는 쿼리 문자열에서도 똑같이 참조할  수 있습니다. static final String으로 선언된 문자열 상수만 쓰는 것이기 때문에 Groovy의 성능문제도 걱정할 필요가 없습니다.

 

 단점은 별도의 Eclipse plugin을 설치해야 하기 때문에, 이미 많은 수의 Plugin을 설치해서 Eclipse가 무겁다고 느껴지는 개발환경에서는 다소 부담이 될지 모른다는 점입니다. 그리고 거의 java와 같은 문법을 지원하기는하지만, SQL 때문에 Groovy라는 새로운 언어를 도입하는 것이 적합하지 않다고 느끼시는 분들도 계실 것입니다. 그런 분들은 언제가 될지는 몰라도 Java에서 따옴표 3개를 지원하는 때까지 기다려야 하겠죠.

 

출처 : http://benelog.egloos.com/2708621


웹이 점점 커지고 다양한 요구가 생겨나는 가운데 NoSQL이 커다란 이슈중에 하나로 떠오르고 있습니다. 제가 NoSQL에 대해서 처음 들은 것은 올 초정도로 기억하고 있습니다.

Google Trends에서 NoSQL로 검색한 결과

구글 트랜즈   에서 확인해보아도 NoSQL이라는 단어가 이슈화되기 시작한 것은 2009년 중순정도로 나타나고 있습니다.  위키피디아   에서 확인해 보면 NoSQL이라는 단어는 1998년 Carlo Strozzi이 SQL을 드러내지 않는 경량 데이터베이스로 이름지었고 2009년 초에 Last.fm   의 Johan Oskarsson이 오픈소스 분산데이터베이스에 대한 논의를 위한 이벤트를 원했을 때 Rackspace   의 직원인 Eric Evans가 NoSQL이라는 단어를 다시 소개했다고 합니다. 아틀란타에서 열린 no:sql conference 2009가 NoSQL논의에 큰 영향을 미쳤다고 합니다. (이 컨퍼런스의 모토인 "select fun, profit from real_world where relational=false;"가 상당히 센스넘치는군요)

올해 중에 NoSQL중 하나는 경험해 보자는 생각이었는데 마침 좀 만져볼 기회가 생겨서 좀 만져보고 있습니다. 개념자체가 개발자에게 기존에 익숙한 RDBMS와는 너무 달라서 튜토리얼 보고 단순한 사용정도는 할 수 있겠지만 관련해서 고민해 보려면 NoSQL에 대해서 좀 자세히 알아야 할 필요가 있게 느껴졌습니다. 사실 NoSQL에 대한 지식이 많다보니 고민 자체가 해결책이나 진도나 나가지 않고 계속 빙글빙글 도는 느낌이라 여기저기 자료를 좀 찾아서 정리해 보았습니다.





CAP Theorem
NoSQL에 대해서 이해하려면 먼저 CAP 이론에 대해서 알 필요가 있습니다. CAP이론은 Brewer's CAP Theorem   으로 알려져 있는데 분산 컴퓨팅 시스템에서 보장해야 하는 특징으로 아래 3가지를 정의하고 있습니다.

  • Consistency (일관성) : 모든 노드들은 동시에 같은 데이터를 보아야 합니다.
  • Availability (유효성) : 모든 노드는 항상 읽기와 쓰기를 할 수 있어야 합니다.
  • Partition Tolerance (파티션 허용차) : 시스템은 물리적인 네트워크 파티션을 넘어서도 잘 동작하여야 합니다

CAP 이론에 따르면 위 3가지 중에 동시에 2가지만 보장할수 있고 3개를 모두 보장하는 것이 불가능하다고 나와있습니다. 그래서 데이터를 관리할때 이 3가지 중에 어느 2가지에 중점을 두냐는 것은 아주 중요한 부분입니다. 이 부분을 이해하는데 Nathan Hurst   이 만든 아래의  Visual Guide to NoSQL Systems   는 큰 도움이 됩니다.

사용자 삽입 이미지

기존에 많이 사용하던 RDBMS는 3가지 중 CA에 집중하고 있습니다. 웹이 발전하면서 다양한 요구사항이 생겨나고 엄청난 양의 데이터를 처리해야 하게 되면서 RDBMS가 갖지 못한 P의 특성이 필요해졌고 그러면서 등장한 것이 NoSQL입니다. 좀더 풀어쓰면 데이터베이스에 대한 수평적 확장(Horizontal Scalability 즉 옆에 서버한대 더 배치해서 데이터베이스를 늘리고 싶다는 의미입니다.)에 대한 이슈가 발생했고 확장성이슈를 해결하기 위해서 P를 선택하다 보니 기존에 가지고 있던 C나 A의 특성중 하나를 포기해야 했습니다. 그래서 NoSQL에는 다양한 시도들이 있지만 가장 중요한 이슈는 확장성을 해결하려는 것으로 생각됩니다.

관계형 데이터베이스는 기본적으로 분산형을 고려해서 디자인 되지 않았습니다. 그래서 ACID(원자성, 일관성, 독립성, 지속성) 트랜잭션 같은 추상화와 고레벨 쿼리모델을 풍부하게 제공할 수 있지만 확장성이 좋지 못하기 때문에 모든 NoSQL 데이터베이스는 다양한 방법으로 확장성 이슈를 해결하기 위해 초점을 맞추고 있습니다. 각 NoSQL에는 여러가지 차이점들이 있지만 CAP의 범주에서만 보면 CP를 선택하거나 AP를 선택하게 됩니다.




왜 비관계형이어야 하는가?
NoSQL이 확장성 이슈를 해결하려고 CP나 AP의 특성을 선택했지만 구체적으로 어떤 특징을 선택하고 왜 그래야 했는지 이해할 필요가 있습니다. NoSQL은 많은 제품군들이 있는데 모두 같은 전략으로 접근하고 있지는 않고 각각에 제품에 따라 다양한 접근을 하고 있는데 아래 적힌 내용들은 비관계형으로 가기 위한 여러가지 특성들에 대한 이야기이고 제품군에 따라 아래의 특성들을 선택한 여부는 다른 것으로 보입니다.아래의 내용은 상당부분 VINEET GUPTA가 작성한 NoSql Databases - Part 1 - Landscape   를 참고하였습니다. 잘 정리된 문서라서 참고하시면 도움이 될 것입니다.



관계형 데이터 베이스는 확장하기가 어렵습니다.

Replication - 복제에 의한 확장
Master-Slave 구조에서는 결과를 슬레이브의 갯수만큼 복제해야 하는데 N개의 슬레이브에서 읽을 수 있기 때문에 Read는 빠르지만 Write에서는 병목현상이 발생하게 기 때문에 확장성에 대한 제한을 가지게 됩니다.
다중 마스터구조에서는 마스터를 추가함으로써 쓰기의 성능을 향상시킬 수 있는데 대신에 충돌이 발생할 가능성이 생기게 됩니다.

Partitioning(Sharding) - 분할에 의한 확장
Read만큼 Write도 확장할 수 있지만 애플리케이션레이어에서 파티션된 것을 인지하고 있어야 합니다.RDBMS의 가치는 관계에 있다고 할 수 있는데 파티션을 하면 이 관계가 깨져버리고 각 파티션된 조각간에 조인을 할 수 없기 때문에 관계에 대한 부분은 애플리케이션 레이어에서 책임져야 합니다. 일반적으로  RDBMS에서 수동  Sharding 은 쉽지 않습니다.



필요없는 특성들

UPDATE와 DELETE
Update와 Delete는 전통적으로 정보의 손실이 발생하기 때문에 잘 사용되지 않으며 후에 데이터 검사 및 재활성화를 위해서 기록해둘 필요가 있습니다. 그리고 사용자가 커뮤니티를 탈퇴한다고 그들의 글을 지우지 않듯이 도메인 관점에서는 실제로 삭제되지 않습니다.  이런 접근을 하게 되면 Update / Delete를 모두 Insert로 모델할수 있고 과거 데이터는 버전을 붙혀서 기록할 수 있으며 이 데이터들은 비활성데이터들이 됩니다. 이 INSET-only 시스템에서는 2개의 문제가 있는데 데이터베이스에서 종속(cascade)에 대한 트리거를 이용할 수 없으며 Query가 비활성 데이터를 걸러내야 할 필요가 있습니다.

JOIN
데이터가 많을 때 JOIN은 많은 양의 데이터에 복잡한 연산을 수행해야 하기 때문에 비용이 많이 들며 파티션을 넘어서는 동작되지 않기 때문에 피해야 합니다. 정규화는 일관된 데이터를 가지기 쉽게 하고 스토리지의 양을 줄이기 위해서 하는건데 반정규화(De-normalization)를 하면 JOIN문제를 피할 수 있습니다. 반정규화로 일관성에 대한 책임을 디비에서 애플리케이션으로 이동시킬수 있는데 이는 INSERT-only라면 어렵지 않습니다.

ACID 트랜젝션
Atomic (원자성) : 여러 레코드를 수정할 때 원자성은 필요없으며 단일키 원자성이면 충분합니다.
Consistency (일관성) : 대부분의 시스템은 C보다는 P나 A를 필요로 하기 때문에 엄격한 일관성을 가질 필요는 없고 대신 결과의 일관성(Eventually Consistent   )을 가질 수 있습니다.
Isolation (격리성) : 읽기에 최선을 다하는(Read-Committe) 것 이상의 격리성은 필요하지 않으며 단일키 원자성이 더 쉽습니다.
Durability (지속성) : 각 노드가 실패했을때도 이용되기 위해서는 메모리가 데이터를 충분히 보관할 수 있을정도로 저렴해지는 시점까지는 지속성이 필요합니다.

고정된 스키마
RDBMS에서는 데이터를 사용하기 전에 스키마를 정의해야하고 Index등을 정의해야 하는데 현재의 웹환경에서는 빠르게 새로운 피쳐를 추가하고 이미 존재하는 피쳐를 조정하기 위해서는 스키마 수정이 필수적으로 요구됩니다. 하지만 컬럼의 추가/수정/삭제는 row에 lock을 걸고 index의 수정은 테이블에 락을 걸기 때문에 스키마 수정이 어렵습니다.



어떤 특성들은 갖지 않습니다.
계층화 데이터나 그래프를 모델하는 것은 어렵습니다. 또한 빠른 응답을 위해서 디스크를 피하고 메인 메모리에서 데이터를 제공하는 것이 바람직한데 대부분의 관계형 데이터베이스는 디스크기반이기 때문에 쿼리들이 디스크에서 수행됩니다.





기대하는 특성들
NoSQL이 바라는 환경은 서버들이 다른 용량들을 가지고 수업이 퍼져나가는 것으로 이를 노드라고 부릅니다. 

높은 확장성
점진적으로 노드를 추가할 수 있어야 하고 이는 파티셔닝을 통해서 가능합니다. 

높은 Availability
실패의 단일포인트가 없으며 데이터는 복제되기 때문에 어떤 노드가 죽었을때도 데이터는 이용이 가능합니다.

높은 성능
디스크대신 메모리 기반으로 결과는 빠르게 리턴되어야 하며 이는 논블락킹 Write와 낮은 복잡성을 가진 알고리즘을 통해서 이룰수 있습니다.

원자성
각각의 쓰기는 원자성을 가질 필요가 있다.

일관성
강한 일관정은 필요없고 결과적인 일관성만 가지면 된다.(Read-Your-Writes1 일관성)

지속성
데이터는 휘말성 메모리만이 아닌 디스크에서 유지되어야 합니다.

배포의 유연함(Flexibility)
노드의 추가/삭제는 데이터를 분산하고 수동으로 중재할 필요없이 자동적으로 로드되어야 하며 분산 파일 시스템이나 공유스토리지 요구같은 제약이나 특수한 하드웨어같은 것이 필요없어야 합니다. 이기종간의 하드웨어에서 동작가능해야 합니다.

모델링의 유연함(Flexibility)
Key-Value쌍, 계층형 데이터, 그래프등 여러가지 타입의 데이터를 간단하게 모델할 수 있어야 합니다.

쿼리의 유연함(Flexibility)
하나의 호출에서 제공된 키에 대한 값이 묶음을 얻는 다중 GET과 키의 특정 범위에 기반한 데이터를 얻는 범위 쿼리가 필요합니다.

출처 : 
http://blog.outsider.ne.kr/519 
SELECT A.*
FROM A LEFT OUTER JOIN B
ON A.ID=B.ID
WHERE B.ID IS NULL

'Oracle/Mysql/Sql' 카테고리의 다른 글

Group by 알파벳 순으로 정렬 후 최종 1개만  (0) 2011.10.06
CAP Theorem  (0) 2011.06.28
계층구조- SYS_CONNECT_BY_PATH 함수  (0) 2011.04.06
Mysql Table 메모리화  (0) 2011.03.15
GRANT  (0) 2010.08.27
오라클를 이용한 계층구조

계층구조- SYS_CONNECT_BY_PATH 함수 db 

2006/03/28 14:59

http://blog.naver.com/peterppan/50002894715

계층구조를 가지는 테이블에서 Navigation Path 를 만들기 위하여
SYS_CONNECT_BY_PATH 함수를 사용할 수 있습니다.

순방향으로 전개할 때에는 이 path 가 root 에서 leaf 쪽으로 계층적으로
구성되어 반환되므로 상관이 없습니다.

예1) 순방향 전개시

SELECT EMPNO, LPAD(' ', 2*LEVEL-1)||SYS_CONNECT_BY_PATH(ENAME,'/') PATH
  FROM EMP
 START WITH JOB='PRESIDENT'
CONNECT BY PRIOR EMPNO = MGR

EMPNO    PATH
-----    ------------------------------
7839     /KING
7566       /KING/JONES
7788         /KING/JONES/SCOTT
7876           /KING/JONES/SCOTT/ADAMS
7902         /KING/JONES/FORD
7369           /KING/JONES/FORD/SMITH
7698       /KING/BLAKE
7499         /KING/BLAKE/ALLEN
7521         /KING/BLAKE/WARD
7654         /KING/BLAKE/MARTIN
7844         /KING/BLAKE/TURNER
7900         /KING/BLAKE/JAMES
7782       /KING/CLARK
7934         /KING/CLARK/MILLER

역방향으로 전개할 때에는 이 path가 leaf 에서 root 쪽으로 구성됩니다.
더 정확하게 말하자면 start with 절에 해당하는 node 의 level 이 1부터 시작하여
순방향이던 역방향이던 전개하면서 level 이 1씩 증가므로 level 순으로
path를 만들어 내는 것입니다.

예2) 역방향 전개

SELECT EMPNO, LPAD(' ', 2*LEVEL-1)||SYS_CONNECT_BY_PATH(ENAME,'/') PATH
  FROM EMP
 START WITH EMPNO = 7876
CONNECT BY  EMPNO = PRIOR MGR

EMPNO    PATH
-----    ------------------------------
7876     /ADAMS
7788       /ADAMS/SCOTT
7566         /ADAMS/SCOTT/JONES
7839           /ADAMS/SCOTT/JONES/KING

따라서 역방향으로 전개할 때에는 path가 거꾸로 나오므로
개발자들은 다음과 같이 2번에 걸친 전개를 하여 값을 구하곤 합니다.
1) 역방향 전개로 원하는 결과집합 생성하여 inline view로 묶고
2) 해당 집합에서 순방향 전개를 하여 sys_connect_by_path 함수로 올바른 path 생성

위의 제약사항을 reverse 함수를 2번 사용하는 것으로 해결해 보았습니다.

*********************************************************************************
* 주의 : reverse 함수는 내부적으로만 사용되는 undocumented 함수입니다.
*        support 되지 않으므로 사용에 대한 책임은 전적으로 사용자에게 있습니다.
*********************************************************************************

reverse 함수는 byte 단위로 앞뒤를 변경하므로 character 값들만 변경의 의미가 있습니다.

예3) reverse 함수 예제

SQL> select reverse('123'), reverse('한글'), reverse(sysdate), reverse(12) from dual;

REV REVE REVERSE(S REVERSE(12)
--- ---- --------- -----------
321 旁饑 14-AUG-50  -(.000E+98

하지만 reverse를 한번 더 적용하면 ~(~T) = T 와 같이 원래 값으로 변경됩니다.

예4) reverse 함수 2번 적용 예제

SQL> select reverse(reverse('123')), reverse(reverse('한글')), reverse(reverse(sysdate)), reverse(reverse(12)) from dual;

REV REVE REVERSE(R REVERSE(REVERSE(12))
--- ---- --------- --------------------
123 한글 11-AUG-05                   12

따라서 reverse를 먼저 적용하여 path를 만들고 전체적으로 한번 더 뒤집은 후 '/' 등의 
delimeter 처리만 약간 해주면 우리가 원하는 path를 만들어 낼 수 있습니다.

예5) 역방향 전개시 reverse 1회 적용

SELECT EMPNO, 
       SYS_CONNECT_BY_PATH(REVERSE(ENAME),'/') PATH
  FROM EMP
 START WITH EMPNO = 7876
CONNECT BY  EMPNO = PRIOR MGR

EMPNO    PATH
-----    ------------------------------
7876    /SMADA
7788    /SMADA/TTOCS
7566    /SMADA/TTOCS/SENOJ
7839    /SMADA/TTOCS/SENOJ/GNIK

예6) 역방향 전개 및 reverse 2회 적용

SELECT EMPNO, 
       LPAD(' ', 2*LEVEL-1)||'/'||
       RTRIM(REVERSE(SYS_CONNECT_BY_PATH(REVERSE(ENAME),'/')),'/') PATH
  FROM EMP
 START WITH EMPNO = 7876
CONNECT BY  EMPNO = PRIOR MGR

EMPNO    PATH
-----    ------------------------------
7876     /ADAMS
7788       /SCOTT/ADAMS
7566         /JONES/SCOTT/ADAMS
7839           /KING/JONES/SCOTT/ADAMS

 

============================================

 

EX) SELECT MENU_ID, SEQ, PRT_MENU_ID,
LEVEL, LPAD(' ', LEVEL*7) || MENU_NM, SYS_CONNECT_BY_PATH(MENU_NM, '')
FROM TABLE

CONNECT BY PRIOR MENU_ID = PRT_MENU_ID
START WITH PRT_MENU_ID = ''
ORDER SIBLINGS BY SEQ
 
ORDER SIBLINGS BY 컬럼  <-- CONNECT BY에서 정렬을 시켜준다.
 
SYS_CONNECT_BY_PATH(MENU_NM, '') <--  상위메뉴에서 부터 구분자가 인 값을 가져올수 있다.
 
메뉴1
메뉴1하위1
메뉴1하위2
이런식으로 나올수 있다.

'Oracle/Mysql/Sql' 카테고리의 다른 글

CAP Theorem  (0) 2011.06.28
두테이블을 비교해서 같지않은 값만 출력하기  (0) 2011.05.23
Mysql Table 메모리화  (0) 2011.03.15
GRANT  (0) 2010.08.27
hr계정 Lock풀기  (0) 2010.08.27
하둡 종료를 한번 잘못시켰더니........
하둡로그에 아래와 같은 로그가 발생.

구글검색결과 비정상적으로 종료 되었을경우에 안전모드로 들어간다. 
이경우에는 풀어 줄필요가 있음. 


2011-04-04 15:27:51,144 INFO org.apache.hadoop.mapred.JobTracker: problem cleaning system directory: hdfs://tedgelog1:9000/home/hadoop/hdfs/mapreduce/system
org.apache.hadoop.ipc.RemoteException: org.apache.hadoop.hdfs.server.namenode.SafeModeException: Cannot delete /home/hadoop/hdfs/mapreduce/system. Name node is in safe mode.


# 再起動に失敗するとsafemodeになってしまい,HDFSのファイル操作ができなくなってしまいます.
# もし以下のようなメッセージが出た場合はsafemodeになってしまっています
put: org.apache.hadoop.hdfs.server.namenode.SafeModeException: Cannot create file/user/training/test.txt. Name node is in safe mode.

# safemodoを解除するには-safemode leaveを実行します
training@training-vm:~/tmp$ hadoop dfsadmin -safemode leave
Safe mode is OFF


참조: http://code.google.com/p/jatextmining/source/browse/wiki/Tutorial_with_cloudera.wiki?spec=svn23&r=23 

참조: http://omake.accense.com/wiki/Hadoop 

'Hadoop' 카테고리의 다른 글

HBase 데이터 Scan 및 Delete  (0) 2011.12.30
Hive Error  (0) 2011.12.26
Hadoop 인스톨 ②  (0) 2011.07.20
Hadoop 인스톨 ①  (0) 2011.07.19
Apache Hadoop이란?  (0) 2011.07.18
사용해본 확장프로그램 중에서 가장 좋은 듯. 

IE Tab Multi

https://chrome.google.com/extensions/detail/fnfnbeppfinmnjnjhedifcfllpcfgeea?hl=ko 


Request Headers:
Host: www.neopets.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://www.neopets.com/hi.phtml
Cookie: np_uniq=2006-09-11; xt6Yr4e33D=29268402315566579497; _tz=300; npuid=e70000000000000000000000000000ly00000000000000000000003e70000000; np_uniq_=2006-09-11; np_randseed=74589-14695679166655
Content-Type: application/x-www-form-urlencoded
Content-Length: 48

Request Body:
username=aerss&password=ce1&destination=


Request Headers는 별의미 없다. 하지만 없으면 값이 제대로 들어가지 않는다.
Body부분에서 값을 제대로 세팅해주자 .
 


1. 테이블을 메모리화 시킨후 

2. 해당 DB의 Heap 사이즈도 변경시킨다.

3. Heap사이즈 변경 후

4. 해당 테이블에도 적용시킨다 .



select @@max_heap_table_size;    //사이즈 확인

set @@max_heap_table_size=536870912;  //512MB로 수정

SHOW TABLE STATUS LIKE '테이블 명'   //현재 테이블의 상태 확인 

ALTER TABLE '테이블명'ENGINE MEMORY  //수정한 메모리 적용


참고: http://ronaldbradford.com/blog/the-size-of-memory-tables-2008-12-12/ 
        http://dicortazar.wordpress.com/2010/07/09/changing-your-max_heap_table_size-variable/ 
        http://variable.jp/?tag=global-max_heap_table_size  

'Oracle/Mysql/Sql' 카테고리의 다른 글

두테이블을 비교해서 같지않은 값만 출력하기  (0) 2011.05.23
계층구조- SYS_CONNECT_BY_PATH 함수  (0) 2011.04.06
GRANT  (0) 2010.08.27
hr계정 Lock풀기  (0) 2010.08.27
DataBase 파일들의 위치보기  (0) 2010.08.27


2011-03-04 16:28:20.0 형식으로 되어 있는 데이터를 
Jsp에서 Excel형식으로 바꾸어 다운로드 시킬때
자동형변환이 일어나는 경우가 있다 있다. 

이때 아래 와 같이 해주면 된다. 
 <td style="mso-number-format:\@">${couponInfo.registerDate}</td>

'Jsp-Servlets' 카테고리의 다른 글

서블렛 + JDBC 연동시 코딩 고려사항  (0) 2010.08.27

+ Recent posts