Sec.6 NoSQL & Hadoop

NoSQL

• 작은 데이터는 RDB로 충분하지만 큰 데이터라면 한계가 생긴다.
• 대용량 데이터를 아주 빠르게 처리한다.
• 데이터를 신속하게 분산 처리하면서 변형도 쉽다.
• RDB 스케일링 업(수직적 확장)
  • 비정규화
  • Caching layer
  • 마스터/슬레이브 → 어떤 건 write, 어떤 건 read만
  • Sharding

→ 서버가 자주 터질걸?

• API를 통해 원하는 정보만 필요하다.

→ key, value

HBase

• HDFS 위에 구축되고, 대용량 데이터를 HDFS에 저장하면 이를 활용해 데이터를 대규모로 외부로 내보낼 수 있다.
• 컬럼 기반 데이터베이스
• 구글 빅테이블을 기반으로 하고 있다.
• 쿼리가 아니라 API → CRUD
• 수 많은 클러스터 전체에 데이터를 자동으로 분배한다.
• 마스트 노드가 실제 데이터의 스키마를 관리하거나 저장하고 분할하는 작업을 한다.
• Zookeeper: 관리자의 관리자 → 마스터 서버의 헬스를 주기적으로 체크한다.
  • ROW
  • KEY
  • COLUMN FAMLIES: 행마다 고정된 열 대신 하나의 열집합 안에 수많은 열을 담는다.
  • COLUMN데이터 모델

• HBase 접근방법
  • shell, 자바 API, Spark, Hive, REST...

Cassandra

• 단일 장애 지점(그 지점에 장애가 발생하면 서비스를 제공할 수 없는 지점)이 없다는 점에서 독특한 분산 데이터베이스
• 마스터 노드가 없다.
• CQL
• 왜 카산드라를 사용?
  • CAP 중 2가지(partition-torleance는 무조건, consistency, availability 중 하나 선택 특히 카산드라는 availability 선택)만 선택하여 더 좋은 가용성을 낸다.
  • 밑의 그림에서 말하는 것은 아예 포기했다는 것이 아니라 일정부분 포기했다는 뜻이다.

CAP 이론에 대해 자세하게 알고있자!

• 카산드라 아키텍처
  • 마스터 노드가 없다
  • 가십 프로토콜을 통해 노드끼리 통신하여 스스로 관리한다.
  • 분석과 스파크 통합을 위해 복제 클러스터를 둘 수도 있다.
  • 노드와 클러스터는 다르다!
  • 키스페이스: 컬럼 패밀리를 묶어준다. 테이블들의 모임.
• CQL
  • SQL이지만 큰 제약이 있다.
    • 조인이 없다.
    • 모든 테이블에는 기본키가 있어야 한다.
  • API와 같다.
• 스파크와 궁합
  • DataStax를 사용하여 굉장히 쉽게 통합할 수 있다.
  • 카산드라 테이블을 데이터프레임으로 읽거나 쓸 수 있다.
• 카산드라 설치
  • 파이썬 2.7
  • datastax 저장소를 만든다.
  • [datastax] name = DataStax Repo for Apache Cassandra baseurl = <http://rpm.datastax.com/community> enabled = 1 gpgcheck = 0
• CQL 

  spark-submit --packages datastax:spark-cassandra-connector:2.0.0-M2-s_2.11 CassandraSpark.py
  

  • 스파크를 통해 데이터를 변환하고 카산드라에 저장
• # 카산드라 스파크 통합 코드 # wget <http://media.sundog-soft.com/hadoop/CassandraSpark.py> from pyspark.sql import SparkSession from pyspark.sql import Row from pyspark.sql import functions def parseInput(line): fields = line.split('|') return Row(user_id = int(fields[0]), age = int(fields[1]), gender = fields[2], occupation = fields[3], zip = fields[4]) if __name__ == "__main__": # Create a SparkSession spark = SparkSession.builder.appName("CassandraIntegration").config("spark.cassandra.connection.host", "127.0.0.1").getOrCreate() # Get the raw data lines = spark.sparkContext.textFile("hdfs:///user/maria_dev/ml-100k/u.user") # Convert it to a RDD of Row objects with (userID, age, gender, occupation, zip) users = lines.map(parseInput) # Convert that to a DataFrame usersDataset = spark.createDataFrame(users) # Write it into Cassandra usersDataset.write\\ .format("org.apache.spark.sql.cassandra")\\ .mode('append')\\ .options(table="users", keyspace="movielens")\\ .save() # Read it back from Cassandra into a new Dataframe readUsers = spark.read\\ .format("org.apache.spark.sql.cassandra")\\ .options(table="users", keyspace="movielens")\\ .load() readUsers.createOrReplaceTempView("users") sqlDF = spark.sql("SELECT * FROM users WHERE age < 20") sqlDF.show() # Stop the session spark.stop()
• CREATE KEYSPACE movielens WITH replication = {'class': 'SimpleStrategy','replication_factor':'1'} AND durable_writes=true; USE movielens; CREATE TABLE users (user_id int, age int, gender text, occupation text, zip text, PRIMARY KEY (user_id);

MongoDB

• 가용성을 일부 포기한 대신 마스터 노드를 통해 높은 일관성을 유지할 수 있다.
• 스키마를 사용하지 않을 수 있다.
• 각각의 문서마다 다른 필드를 가질 수 있다.
• 자동으로 ID 필드를 생성해서 키로 작동한다.
• 샤딩을 할 수 있다.
• 유연하게 데이터를 저장할 수 있지만 원하는 것이 무엇인지를 생각하며 스키마를 디자인해야 한다.
• Collection = Table, Documents = Row
• MongoDB 아키텍쳐
  • Replica Sets
    • 싱글 마스터
    → 마스터 노드와 프라이머리 노드는 다르다
    • 세컨더리: 복사본을 가지고 있다. 프라이머리가 다운되면 그 자리를 채운다.
  • Replica Sets 특이점
    • 서버는 홀수를 가져야 한다. → 과반수를 내야되기 때문에
    • arbiter node: 프라이머리 노드가 다운되었을 때 누가 그 역할을 할 지 투표할 때 쓰임
    • 레플리카는 몽고디비의 내구성 문제일 뿐이지, 빅데이터의 문제가 아니다. 레플리카가 없으면 작동을 하지 않는다.
  • Sharding
    • 빅데이터에 대한 내용
    • 특정 인덱스의 범위에 있는 데이터는 다른 레플리카 세트에 배정
    • mongos: 우리가 원하는 정보를 얻기 위해서 작업할 레플리카 세트가 어떤 것인지를 알아낸다.
  • Sharding 특이점
    • 오토 샤딩: 요소들을 시간에 따라서 재조정하는 것인데 가끔 실패한다. 특히 config 서버가 다운되면 아무것도 할 수 없다.
    • 아니면 프론트엔드에서 너무 자주 mongos가 재시작되면 오류가 생길 수도 있다.
  • 장점
    • 여러가지 포맷을 저장할 수 있다.
    • 자바스크립트를 사용할 수 있다.
    • 다양한 인덱스 방법을 사용할 수 있다.
    • 빅데이터 툴과 통합하기 좋다.

데이터베이스 기술 선택하기

• 시스템에 맞는 데이터베이스를 고르는 것이 중요하다.
• 고려사항
  • 다른 시스템과의 통합
  • 규모
    • 데이터가 커진다면 수평 확장 가능 데이터베이스 고려
    • 처리량을 고려할 때는 NoSQL
  • 지원여부
    • 보안 전문가의 여부가 중요하다
    • 작은 규모의 회사라면 전문적인 유료 지원을 받을 수 있는지 고려해야 한다.
  • 예산
    • 서버를 제외하고는 대부분 오픈 소스이기 때문에 크게 고려할 사항은 아니다.
  • CAP
    • 중요한 2개를 골라야 한다.
    • 카산드라 그림을 참고.
    • 하지만 이러한 장벽이 점점 희미해지고 있다.
    • 그림처럼 확실하게 구분되는 것은 아니다.
  • 간단함
    • 시스템이 꼭 필요한 최소 요건이 무엇인지 생각하여 복잡한 환경을 구성하지 마라
    • ex) 큰 규모가 아니라면 MySQL을 사용하면 된다.
• 사내 전화번호 구축
  • 규모: 적음
  • 일관성: 크게 신경쓰지 않아도 된다.
  • 가용성: 크리티컬하지는 않다.
  → MySQL을 사용하면 된다!
• 웹 서버 로그를 통해 패턴 발견
  • 높은 처리량이나 빠른 속도는 그리 중요하지 않다. → 외부 데이터베이스 필요없다(NoSQL)
  • HDFS에 데이터를 모으고 Spark로 처리하면 된다.
• 영화 추천
  • 사용자들이 추천 목록을 빠르게 보길 원한다.
  • 다운 되거나 느리면 안된다.
  • 가용성과 분단 허용성이 중요
  • 일관되지 않아도 상관없다.
  • 카산드라가 적합
• 대규모 주식 거래 시스템
  • 하둡과 스파크가 백그라운드로 돌아가면서 프론트엔드에는 주식 인터페이스를 갖추어야 한다.
  • 하나의 서버로는 감당X
  • 돈과 관련되어 있어 보안도 중요하다.
  • 대규모이기 때문에 분단 허용성 중요
  • 보안이 매우 중요하기 때문에 일관성이 중요
  • 가용성도 중요하지만 CP와 비교하면 상대적으로 덜 중요하다.
  • HBase, MongoDB가 적합
    • 보안과 같은 외부 전문가가 필요하기 때문에 MongoDB가 더 적합
• 너무 CAP이론에 치중하지 말고 여러 가지 조건을 고려하여 자신의 시스템에 가장 적합한 DB를 고르자