main










Cluster : The Beginning - Hadoop 2.9.0 설치


이제 라즈베리파이의 구성은 모두 정리가 되었고 맥미니에 클러스터를 구성할 차례이다.
이 글을 쓰는 시점에는 이미 모든 클러스터 구성이 완료 되었으나 여전히 많은 작업이 남아있다.


하지만 모든 클러스터를 구성하는 것 까지는 초보 수준에서 가장 기초적인 설정만으로 진행하고 있으니
같은 맥락에서 진행을 하도록 하겠다.


맥미니에 설치할 Hadoop ecosystem은 3가지로 Hadoop과 HBase 그리고 Spark이다.
HBase는 Cassandra와 고민을 좀 했는데 아무래도 하둡과의 궁합을 생각해서 HBase를 설치하기로 했다.
Spark의 경우 Spark MLlib 때문에 설치해보기로 했는데 메모리를 이용한 시스템이다보니 가정용 PC의 뻔한
메모리 용량으로 제대로 써먹기나 할지 모르겠다(다른 시스템들도 마찬가지지만…).


하둡 배포판 선정


사실 예전에 하둡 1.4와 HBase를 설치했을 때 여러가지 설정과 배포본을 노드에 카피하는 등 많은 작업들이
매우 번거롭게 느껴져서 이번에는 아주 좋은 툴인 Apache Ambari를 사용하여 설치해볼까하고 시도를 해봤다.
그런데 시작부터 막힌 것이 Mac을 지원하지 않아 WMWare에 설치된 Ubuntu에 Ambari를 설치하게 되었다.



일단 설치는 간단하게 되었는데…정작 웹 콘솔을 시작하고 클러스터를 만드는 과정에서 각 노드에 연결을
하지 못하는 문제가 발생을 하였다. 아무래도 Mac에서 진행을 하다보니 지원이 안되는 부분이 있나보다 하고
과감하게 포기를 하고 다시 맨땅에 헤딩하면서 진행을 할 수밖에 없었다.


우선 설치할 시점에서의 최신 버전인 2.9.0 버전을 다운로드 받아 설치하기로 하였다. 그런데 오늘 가서 보니 그새
3.0.0이 새로 릴리즈가 되어있고 2.6.X, 2.7.X, 2.8.X, 2.9.X, 3.0.X가 각각 업데이트가 진행되는 것 같은데
어떤 기준으로 버전이 나누어지고 또 업데이트가 되는지 잘 모르겠다.


배포버전 참조 링크 : http://hadoop.apache.org/releases.html#Download


어쨌든 나는 2.9.0 버전을 선택하여 설치하였다.


설치 환경 및 모드


일단 앞선 몇 번의 포스팅에서 언급한 것과 같이 현재 내가 보유하고 있는 장비는 총 5대의 Mac mini이다.
즉 5대의 PC에 완전 분산모드로 설치를 진행하게 될 것이다. 5대의 host 이름은 각각 다음과 같다.
괄호 안은 떠있게 될 기본 프로세스다. 


  • NAMENODE.local (Active NameNode, JournalNode, ResourceManager, DFSZKFailoverController)
  • SECONDARY-NAMENODE.local (Standby NameNode, JournalNode, DFSZKFailoverController)
    (과거 1.4 설치 때 secondary namenode였음…)
  • DATANODE1.local (DataNode, JournalNode, NodeManager)
  • DATANODE2.local (DataNode , NodeManager)
  • DATANODE3.local (DataNode , NodeManager)


JournalNode 구성 때문에 1대를 더 영입하려다가 참았다…-.-
이후 작성하는 모든 글에서 각 노드는 위에 적은 호스트명을 사용하도록 하겠다.


설치


앞서 설치한 다른 시스템들과 마찬가지로 다운로드 받은 압축 패키지를 적당한 위치에 풀면 설치 끝이다…-.-
나는 현재 모든 시스템들을 /opt 아래에 설치 중이다. 따라서 hadoop의 경로는 /opt/hadoop이고 
버전 정보는 과감하게 빼버렸다.




사전 준비


하둡을 설치하기 전에 한 가지 준비할 것이 있는데 하둡은 마스터(NameNode)와 슬레이브(Datanode)간에
통신을 하는데 SSH를 이용하게 된다. 이 때 SSH 접근 시 비밀번호 인증을 거치게 되면 정상적으로 통신을 할 수
없기 때문에 먼저 비밀번호 인증 없이 접속을 하기 위해 다음과 같은 절차로 준비를 해야 한다.


일반적으로 사용자 계정의 홈 디렉토리에 있는 .ssh라는 디렉토리에 SSH 관련 인증키들이 들어있다. 만일 기존에
사용 중인 인증 키(보통 id_rsa, id_rsa.pub이라는 이름) 파일들이 보이면 그 파일들을 이용하면 될 것이고 파일이
없거나 .ssh 디렉토리 자체가 없다면 다음과 같이 SSH 키를 생성해준다. 이 작업은 Active NameNode 서버와
Standby NameNode 서버에서 각각 진행한다. 아래는 Active NameNode 기준으로 기록하였다.


'hadoop@NAMENODE.local$ ssh-keygen -t rasa -f  ~/.ssh/id_rsa

당연한 이야기이겠지만 Standby NameNode에서 할 때는 nn2_id_rsa와 같이 키 파일 이름을 다르게 해야
나중에 DataNode로 복사를 할 때 파일을 덮어쓰는 문제를 피할 수 있다.


이렇게 하면 인증키 파일이 생성이 된다. 이제 이 인증키 파일 중 공개키에 해당하는 id_rsa.pub 파일을 각 
DataNode들로 복사를 해준다.


'hadoop@NAMENODE.local$ scp ~/.ssh/id_rsa.pub hadoop@DATANODE1.local:/Users/hadoop/.ssh/id_rsa.pub 
'hadoop@NAMENODE.local$ scp ~/.ssh/id_rsa.pub hadoop@DATANODE2.local:/Users/hadoop/.ssh/id_rsa.pub 
'hadoop@NAMENODE.local$ scp ~/.ssh/id_rsa.pub hadoop@DATANODE3.local:/Users/hadoop/.ssh/id_rsa.pub 


다음 각각의 DataNode의 ~/.ssh 디렉토리로 이동하여 아래와 같이 인증 키 목록에 NameNode에서 받은
인증키의 내용을 추가해준다.


hadoop@DATANODE1.local$ cat  ~/.ssh/id_rsa.pub >> authorized_keys
hadoop@DATANODE2.local$ cat  ~/.ssh/id_rsa.pub >> authorized_keys
hadoop@DATANODE3.local$ cat  ~/.ssh/id_rsa.pub >> authorized_keys


이렇게 만들어진 authorized_keys 파일을 열어보면 대략 이렇게 생겼다.




마지막으로 ssh-agent를 실행하고 ssh-add를 해준다(예전에도 이런 것을 해줬는지 가물가물한데 해야 한다는
것을 보니 아무래도 예전에 내가 뭘 잘못했던게지…-.-)


hadoop@NAMENODE.local$ eval "$(ssh-agent -s)"  
Agent pid 59566  
hadoop@NAMENODE.local$ ssh-add ~/.ssh/id_rsa


가운데 줄은 첫 줄 실행의 결과다. 주의할 것은 콘솔창에서 이렇게만 실행하면 그 콘솔창의 세션 내에서만 반영이
된다. 즉, 콘솔창을 죽였다가 새로 실행하면 이 작업을 다시 해줘야 비밀번호 인증 없이 ssh 접속이 가능하게 된다.
또한 이 세션은 실행한 계정 내에서만 유효하다.


하둡 1.X vs 2.X


간단하게 예전에 설치했던 하둡 1.4와 비교를 하고 넘어가겠다. 생각외로 변경된 사항 때문에 설정해야 할 것들이
많아져서 가볍게라도 언급을 해두어야 할 것 같다. 우선 아래 그림을 먼저 보자.




중요한 변화를 2가지만 짚어보면


HA(High Availability) Cluster 구성

하둡 1.X에서는 NameNode는 1대만 설치가 가능하였으나 하둡 2.X에서는 2대 이상의 
NameNode를 설치할 수 있는데 이 모든 NameNode가 동시에 작동하는 것이 아니라
이 중 1대만이 Active NameNode로 활성화 되고 다른 NameNode들은 Standby
NameNode로, 말 그대로 대기를 하고 있다가 Active NameNode가 다운되었을 경우 
Active 상태가 되어 NameNode로서의 임무를 수행하게 된다. 

이런 운영이 가능하려면 NameNode들 간에 항상 데이터가 공유되어야 하며 그 방법에는
NFS(NAS와 같은 공유 저장소)를 이용하는 방법과 zookeeper와 JournalNode를 이용하는
방법이 있는데 보통 zookeeper와 JournalNode를 이용하는 방법을 많이 쓴다고 한다.
JournalNode는 3개 이상 홀수로 구성을 해야 한다.


YARN의 등장

기존에 MapReduce의 작동이 JobTracker와 TaskTracker를 통해 이루어지던 것이
YARN의 ResourceManager와 NodeManager를 통해 자원 관리 및 모니터링이
이루어지도록 바뀌었다.


하둡 1.X에서는 Secondary NameNode라는 개념이 있었는데 2.X에서도 여전히 사용 가능하며
다만 HA 클러스터를 구성하는 경우에는 Secondary NameNode를 사용할 수 없다.


이런 변화로 인해 하둡 2.X에서는 zookeeper에 대한 설정을 해야 하며 JournalNode 프로세스를
띄워야 하고 YARN을 구동시켜야 하는 등 1.X에 비해 해야 할 일이 늘었다. 


참고로 zookeeper는 이전에 Kafka 설치 시 라즈베리파이에 함께 설치한 zookeeper를 함께 사용한다. 


아래 이미지는 2.X의 구조를 나타낸 그림이다.




설정


설치는 언급할 것도 없이 매우 간단하였고…이제는 설정이다. 역시나 설정도 필수적인 몇몇 항목만 제대로 
설정을 하면 나머지는 기본값으로 그냥 사용하면 된다. 그리고 경로도 좀 독특해서 아래와 같은 경로에 설정 파일들이 
존재한다.


/opt/hadoop/etc/hadoop


그런데!
다른 시스템들과는 달리 하둡은 설정 파일에 기본 값들이 들어있지 않다! 즉, 파일에 최상위 엘리먼트 태그만
덩그러니 있고 내용은 비어있다. 따라서 일단 잘 설명되어있는 블로그나 사이트로 가서 기본적인 내용을 
복사해와야 한다…ㅠ.ㅠ 내가 설정한 내용은 다음과 같다.


  • core-site.xml
<!-- 필수 설정 -->
<property>
      <name>fs.defaultFS</name>
      <value>hdfs://NAMENODE.local:9090</value>
</property>
<!-- 아래 2개의 설정은 옵션~
<property> 
      <name>io.file.buffer.size</name>
      <value>131072</value>
</property>
<property> 
      <name>hadoop.tmp.dir</name>
      <value>/opt/hadoop/temp</value>
</property>
-->
<!--
HA Cluster를 구성할 때 JournalNode를 관리하기 위한 zookeeper 서버를 설정 
이 서버들은 이전에 포스팅한 Kafka 설치 관련 내용에서 이미 설치해둔 라즈베리파이들이다. 
-->
<property> 
      <name>ha.zookeeper.quorum</name>
      <value>rpi1,rpi2,rpi3</value>
</property>



  • hdfs-site.xml
<!-- 
아래 내용 중 데이터 복제 계수를 의미하는 dfs.replication가 설정되지 않았는데 기본값으로
3이 적용 된다.
-->
<!-- NameNode가 namespace와 transaction 로그를 저장하기 위한 경로 -->
<property>
          <name>dfs.namenode.name.dir</name>
          <value>/Users/hadoop/data/dfs/namenode</value>
</property>
<!-- DataNode 자체 및 클러스터와의 관계에 대한 메타데이터를 저장하기 위한 경로 -->
<property>
          <name>dfs.datanode.data.dir</name>
          <value>/Users/hadoop/data/dfs/datanode</value>
</property>
<!-- JournalNode의 메타데이터를 저장하기 위한 경로 -->
<property>
          <name>dfs.journalnode.edits.dir</name>
          <value>/Users/hadoop/data/dfs/journalnode</value>
</property>
<!-- 이하는 HA Cluster 구성을 위해 필요한 내용 -->
<!-- 클러스터 내의 nameservice를 대표하는 논리적인 이름 -->
<property>
	<name>dfs.nameservices</name>
         <value>mazberrycluster</value>
</property>
<!-- 위에서 설정한 nameservice 내에서 사용될 NameNode들의 논리적 이름 -->
<property>
	<name>dfs.ha.namenodes.mazberrycluster</name>
	<value>nn1,nn2</value>
</property>
<!-- 첫 번째 NameNode(nn1)에서 사용할 RPC 호스트:포트 -->
<property>
	<name>dfs.namenode.rpc-address.mazberrycluster.nn1</name>
	<value>NAMENODE.local:8020</value>
</property>
<!-- 두 번째 NameNode(nn2)에서 사용할 RPC 호스트:포트 -->
<property>
	<name>dfs.namenode.rpc-address.mazberrycluster.nn2</name>
	<value>SECONDARY-NAMENODE.local:8020</value>
</property>
<!-- 첫 번째 NameNode(nn1)에서 사용할 Web UI 호스트:포트 -->
<property>
	<name>dfs.namenode.http-address.mazberrycluster.nn1</name>
	<value>NAMENODE.local:50070</value>
</property>
<!-- 두 번째 NameNode(nn2)에서 사용할 Web UI 호스트:포트 -->
<property>
	<name>dfs.namenode.http-address.mazberrycluster.nn2</name>
	<value>SECONDARY-NAMENODE.local:50070</value>
</property>
<!-- 각 JournalNode에서 공유할 데이터를 저장할 URI -->
<property>
	<name>dfs.namenode.shared.edits.dir</name>
	<value>qjournal://NAMENODE.local:8485;SECONDARY-NAMENODE.local:8485;DATANODE1.local:8485/mazberrycluster</value>
</property>
<!-- 클라이언트가 Active NameNode에 접근할 때 사용할 JAVA 클래스 -->
<property>
	<name>dfs.client.failover.proxy.provider.mazberrycluster</name>
	<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
<!-- Failover가 발생했을 때 Active NameNode로의 접근을 차단할 방법 -->
<property>
        <name>dfs.ha.fencing.methods</name>
        <value>sshfence</value>
</property>
<!-- 위에서 ssh를 사용하기로 했기 때문에 ssh 인증키 경로를 설정해준다. -->
<property>
        <name>dfs.ha.fencing.ssh.private-key-files</name>
        <value>/Users/hadoop/.ssh/id_rsa</value>
</property>
<!-- 자동으로 Failover 처리를 할 것인지 -->
<property>
        <name>dfs.ha.automatic-failover.enabled</name>
        <value>true</value>
</property>



  • slaves
## Slave. 즉, DataNode로 사용할 서버의 호스트명을 적어준다.
DATANODE1.local
DATANODE2.local
DATANODE3.local



  • mapred-site.xml
<!-- Map-Reduce 실행 시 관리 프레임워크로 YARN을 지정 -->
<property>
      <name>mapreduce.framework.name</name>
      <value>yarn</value>
</property>



  • yarn-site.xml
<!-- Map-Reduce 실행시 사용할 셔플 서비스 설정 -->
<property>
      <name>yarn.nodemanager.aux-services</name>
      <value>mapreduce_shuffle</value>
</property>
<!-- 위에 설정한 셔플 수행을 위한 JAVA 클래스 -->
<property>
      <name>yarn.nodemanager.auxservices.mapreduce.shuffle.class</name>
      <value>org.apache.hadoop.mapred.ShuffleHandler</value>
</property>
<!-- 위에 설정한 셔플 수행을 위한 JAVA 클래스 -->
<property>
          <name>yarn.nodemanager.local-dirs</name>
          <value>/opt/hadoop/data/yarn/nm-local-dir</value>
</property>
<!-- ResourceManager 상태가 저장될 경로 -->
<property>
          <name>yarn.resourcemanager.fs.state-store.uri</name>
          <value>/opt/hadoop/data/yarn/system/rmstore</value>
</property>
<!-- ResourceManager가 수행될 노드의 호스트명 -->
<property>
          <name>yarn.resourcemanager.hostname</name>
          <value>NAMENODE.local</value>
</property>
<!-- YARN의 web proxy 주소:포트 -->
<property>
          <name>yarn.web-proxy.address</name>
          <value>0.0.0.0:8089</value>
</property>


휴…이제 설정이 끝난 것 같다.
이렇게 설정이 끝났으면 설치한 하둡 배포판을 모든 노드의 같은 경로에 복사해준다.



마지막으로 데몬 실행 파일들에 보면 실제로 데몬을 실행하는 코드가 모두 nohup으로 시작하는데 Mac에서는
nohup 명령어가 없다. 따라서 파일을 열어 nohup으로 시작하는 명령 코드에서 nohup을 모두 제거해주어야 한다.


실행


상당히 많은 분량의 설정이 있었던 만큼 실행 역시 순탄치 않다.
일단 기본적으로 위에 언급된 것만 해도 NameNode, DataNode, JournalNode, YARN 등이 있다.
게다가 Active와 Standby NameNode를 지정해주기 위한 단계와 Failover 처리를 위한 프로세스도
띄워주어야 한다.


이제부터 차근차근 순서를 밟아 실행을 해보자. 우선 $HADOOP_HOME으로 이동하자.


$ cd /opt/hadoop



  • Failover 컨트롤러 실행을 위해 먼저 zookeeper를 초기화 해주어야 한다.
hadoop@NAMENODE.local$ bin/hdfs zkfc -formatZK



  • JournalNode로 사용할 서버에서 각각 JournalNode 프로세스를 실행한다.
    나의 경우 NAMENODE.local, SECONDARY-NAMENODE.local, DATANODE1.loca의 3대이다.
hadoop@NAMENODE.local$ sbin/hadoop-daemon.sh start journalnode
hadoop@SECONDARY-NAMENODE.local$ sbin/hadoop-daemon.sh start journalnode
hadoop@DATANODE1.local$ sbin/hadoop-daemon.sh start journalnode



  • NameNode를 포맷한다.
hadoop@NAMENODE.local$ bin/hdfs namenode -format



  • Active NameNode를 실행한다.
hadoop@NAMENODE.local$ sbin/hadoop-daemon.sh start namenode



  • zookeeper Failover 컨트롤러를 실행한다.
hadoop@NAMENODE.local$ sbin/hadoop-daemon.sh start zkfc



  • 전체 DataNode를 실행한다 (각각의 DataNode에서 hadoop-daemon.sh로 실행해도 된다.)
hadoop@NAMENODE.local$ sbin/hadoop-daemons.sh start datanode



  • Standby NameNode로 이동하여 Active NameNode의 메타 데이터를 Standby NameNode로 
    복사한다.
hadoop@SECONDARY-NAMENODE.local$ bin/hdfs namenode -bootstrapStandby



  • Standby NameNode를 실행한다.
hadoop@SECONDARY-NAMENODE.local$ sbin/hadoop-daemon.sh start namenode



  • Standby NameNode용 zookeeper Failover 컨트롤러를 실행한다.
hadoop@SECONDARY-NAMENODE.local$ sbin/hadoop-daemon.sh start zkfc



  • 다시 Active NameNode로 돌아와 YARN을 실행한다.
hadoop@NAMENODE.local$ sbin/start-yarn.sh



  • 마지막으로 Map-Reduce를 위한 history 서버를 실행한다.
hadoop@NAMENODE.local$ sbin/mr-jobhistory-daemon.sh start historyserver


이렇게 해서 하둡으로의 긴 여정이 끝이났다…ㅠ.ㅠ


모니터링


하둡을 설치하고 나면 아래와 같이 Active NameNode와 Standby NameNode에서 각각 관리 사이트로
접속을 할 수 있다. 기본 포트는 50070이다.




정리


전체적으로 상당히 긴 과정이었다. 이 것이 그저 꼴랑 5대의 노드로 구성된 클러스터이니 망정이지 수 백, 수 천 대의
노드로 구성된 클러스터라면 정말 관리 시스템의 도움이 없이는 제대로 운영할 수 없을 것이다.


일단 전체 에코시스템 구성에서 가장 큰 고비를 넘긴 것 같다. 이제 정리할 것은 HBase와 Spark만 남겨두고 있다.
하지만 이미 모든 시스템을 설치한 후 각 시스템들을 어떻게 연동하여 데이터를 다룰 것인지에 대해 고민을 하다보니
이후가 더 어려울 것 같다는 생각이 든다.


그래도 차근차근 끝까지 가봐야겠다.






최초 작성일 : 2013/01/31 14:58 


Big Data : 

기존 데이터베이스 관리도구의 데이터 수집·저장·관리·분석의 역량을 넘어서는 대량의 정형 또는 비정형 데이터 세트 및 이러한 데이터로부터 가치를 추출하고 결과를 분석하는 기술...

데이터 양(Volume),
데이터 속도(Velocity),
그리고 데이터 다양성(Variety) 등
세 가지 요소의 복합적인 변화를 그 특징으로 한다.

Big Data 분석 기법 :

  • Text Mining(Text mining) : 텍스트 마이닝은 비/반정형 텍스트 데이터에서 자연 언어 처리 기술에 기반하여 유용한 정보를 추출, 가공하는 것을 목적으로 하는 기술이다.
  • 평판 분석 (Opinion mining) : 오피니언 마이닝은 소셜미디어 등의 정형/비정형 텍스트의 긍정, 부정, 중립의 선호도를 판별하는 기술이다.
  • 소셜 네트워크 분석 (Social network analysis) : 소셜 네트워크 분석은 소셜 네트워크 연결구조 및 연결강도 등을 바탕으로 사용자의 명성 및 영향력을 측정하는 기술이다.
  • 군집 분석 (Cluster Analysis) : 군집 분석은 비슷한 특성을 가진 개체를 합쳐가면서 최종적으로 유사 특성의 군을 발굴하는데 사용된다.

  • R (프로그래밍 언어) : 

    통계 계산과 그래픽을 위한 프로그래밍 언어이자 소프트웨어 환경이다.
    ...
    R은 통계 소프트웨어 개발과 자료 분석에 널리 사용되고 있으며, 패키지 개발이 용이하여 통계학자들 사이에서 통계 소프트웨어 개발에 많이 쓰이고 있다.

    Hadoop (하둡) :

    대량의 자료를 처리할 수 있는 큰 컴퓨터 클러스터에서 동작하는 분산 응용 프로그램을 지원하는 자유 자바 소프트웨어 프레임워크이다. 원래 너치의 분산처리를 지원하기 위해 개발된 것으로, 아파치 루씬의 하부 프로젝트이다. 분산처리 시스템인 구글 파일 시스템을 대체할 수 있는 하둡 분산 파일 시스템(HDFS: Hadoop Distributed File System)과맵리듀스를 구현한 것이다.

    MapReduce :

    구글에서 분산 컴퓨팅을 지원하기 위한 목적으로 제작하여 2004년 발표한 소프트웨어 프레임워크다. 이 프레임워크는 페타바이트 이상의 대용량 데이터를 신뢰할 수 없는 컴퓨터로 구성된 클러스터 환경에서 병렬 처리를 지원하기 위해서 개발되었다. 이 프레임워크는 함수형 프로그래밍에서 일반적으로 사용되는 Map과 Reduce라는 함수 기반으로 주로 구성된다.

    현재 MapReduce는 Java와 C++, 그리고 기타 언어에서 적용이 가능하도록 작성되었다.






    YARN :

    MapReduce 2.0의 다른 이름

    Google file system (GFS) :

    Google 에서 개발 한 독점적인 분산 파일 시스템. 이것은 상품화된 하드웨어의 대형 클러스터를 사용하여 데이터에 효율적이고 안정적으로 액세스엑세스 할 수 있도록 설계되었다. 구글 파일 시스템의 새 버전의 코드명은 Colouss이다.

    분산 파일 시스템 (Distributed file system, DFS)
    네트워크 파일 시스템 (Network file system) :

    컴퓨터 네트워크를 통해 공유하는 여러 호스트 컴퓨터의 파일에 접근할 수 있게 하는 파일 시스템이다.

    NoSQL (Not only SQL) :

    NoSQL은 널리 사용되는 관계형 데이터베이스 관리 시스템(RDBMS) 모델을 따르지 않는 데이터베이스

    관리 시스템의 광범위한 클래스이다. NoSQL은 테이블을 생성하지 않으며 데이터 조작을 위해 SQL을 사용하지

    않는다.


    NoSQL 시스템은 대체로 데이터의 검색과 추가에 매우 최적화 되어 있으며 흔히 다음 세대의 저장 장치

    (예를 들면 key-value 저장)에 대한 몇가지 기능을 제공한다.


    full SQL 시스템에 비히 감소된 실행타임의 유연성은 특정 데이터 모델에 대한 확장성과 성능으로

    확실한 보상이 될 수 있다.


    요컨대 NoSQL 데이터베이스 시스템은 데이터의 성격상 데이터간의 관계를 필요로 하지 않는

    방대한 양의 데이터를 처리할 때 유용하다.


    데이터는 구조화 될 수 있겠지만 진짜 NoSQL이 필요한 경우는 요소들 사이에 관계가 없는 방대한

    양의 데이터를 저장하고 검색하는 능력이 요구되는 때이다. 예를 들면 수백만 건의 key-value 쌍을

    하나 혹은 연관된 여러개의 배열에 저장하거나 혹은  수백만 건의 데이터 레코드를 저장하는 경우를

    들 수 있겠다.


    최근의 기업들의 입장에서 보자면 특히 점점 증가하는 요소들의 통계핵적인 분석이나 혹은 실시간 분석에

    유용할 것이다.(예를 들면 커다란 그룹의 사용자들이 올리는 트위터의 글들이라든가 서버상의 로그들이 그런 것이다.)


    일반적으로 NoSQL 데이터베이스는 데이터를 저장하는 방식에 따라 Key-Value Store,

    BigTable 이행, 문서 저장 데이터베이스(Document store database), 그리고

    graph 데이터 베이스의 하위 영역으로 카테고리가 나누어진다.


    - (영문판 위키피디아 발번역...-.-)


    Graph :

    이 형태의 데이터베이스는 데이터들간의 관계를 그래프로 잘 표현 할 수 있도록
    디자인 되었다. (각 요소들은 상호간에 불확실한 수의 관계로 연결되어있다)

    이런 류의 데이터에는 사회적 관계(Social Relations), 대중 교통 시설의 연결,
    도로 지도나 네트워크 topology 등을 예로 들 수 있다.

    Key-Value Store :

    스키마없는 방식으로 데이터를 저장 할 수 있다.
    데이터는 프로그래밍 언어의 데이터 타입이나 객체 형태로 저장될 수 있다.
    이 때문에 고정 된 데이터 모델이 필요 없다.

    Key-Value Stoer의 종류

    Eventually‐consistent key‐value store

    Hierarchical key–value store

    Hosted services

    Key–value cache in RAM

    Key–value stores on solid state or rotating disk

    Ordered key–value stores

    Multivalue databases

    Object database

    RDF database

    Tabular

    Tuple store


     [출처 : 위키백과]

    1. iamdanlee 2015.03.23 22:55 신고

      요즘 빅데이터에 큰 관심을 갖고있는 한 경영학도입니다. 귀중한 정보덕분에 빅데이터에 대해 조금이나마 개념을 잡은것같네요. 감사합니다 :)

    2. 2015.03.24 11:27

      비밀댓글입니다

      • 마즈다 2015.04.16 21:24 신고

        글을 이제야 봤네요^^;; 경영이 전공이시라니 컴공보다는 응용통계쪽이 더 적절하지않나 생각됩니다. 빅데이터가 물론 큰 데이터를 처리하는 기술도 중요하지만 역시 무엇을 위해 어떻게 분석할 것인지를 아는 것이 더 중요하다고 생각되네요.

    + Recent posts

    티스토리 툴바