• 2009년도 자료라 구릴 수 있다.

빅데이터란 무엇인가..

• 100GB면 현재 지구상에 있는 모든 인간의 정보들을 128비트에 담아낼 수 있다.

  age, sex, income, ethnicity, language, religion, housing status, and location

  • 이것은 Big Data인가?
  • 128GB짜리 메모리에 적재 다 된다.
  • 그래서 필자는 이것을 빅데이터라 부르기 모호하다고 표현

• 필자는 40GB이상 메모리 소모하면서 데이터베이스에서 3개의 field(age, sex, country)에 대해서 모두 불러오는 것을 성공 (PostgresDB에서)

  • 이후 쿼리를 테스트

SELECT country,age,sex,count(*) FROM people GROUP BY country,age,sex;

• 데이터 수가 늘어날수록 기하 급수적으로 쿼리 시간도 늘어나는 것을 확인
• 10억개의 데이터셋에 대해서는 거의 24시간이 걸림
• EXPLAIN을 통해 쿼리 실행 계획을 확인하니 문제가 보임
  • 적은 수의 데이터에 대해서는 합리적인 hash-table 집계 전략을 사용
  • 백만 개의 데이터에 대해서는 suboptimal한 전략을 사용
  • 10억개의 데이터에 대해서는 아주 비합리적인 결과값을 내놓았다.
• 여기서 이분은 빅데이터에 대해서 결론을 내리신듯.

결론

• 전통적인 DB에서는 Big Data를 다룰 때 집어 넣는 것은 쉽지만, 가져오는 것이 어렵다.
• 대부분의 DBMS는 transaction 처리에 대해 효율적으로 디자인되어있다.
  • add, update 및 큰 데이터베이스로부터 적은 수의 값을 가져올 때
• 데이터는 트랜잭셔널한 처리들에 의해 모인다.
  • 옷 판매 업체에서 로깅을 한다고 해보자.
  • 제품을 검색하고, 구매하는 등의 정보가 로그로 다 쌓인다.
  • 이런 것들이 모여서 빅데이터가 되는 것
  • 여기까지는 문제가 없다.
• 문제는 이 데이터들로부터 무언가를 얻으려 할때 생긴다.
  • 데이터를 집계하고 분석하는 순간 엄청난 시간이 걸린다.
• business application에서는 data warehousing이 문제를 해결하는 주 방안이라고 여긴다.
  • 데이터 웨어하우스는 "조회 및 분석을 위해 특별히 구성된 트랜잭션 데이터의 복사본"으로 분류.
  • 그리고 일반적인 접근법은 운영 데이터베이스로부터 데이터를 대량 추출하고 이어서 분석 쿼리(이른바 "추출, 변환, 로드" 또는 때로는 "추출, 로드, 변환" 프로세스)에 더 적합한 형태로 다른 데이터베이스에 재구성하는 것으로 이해됨(ETL, ELT)
  • 정말 거대한 데이터를 만나게되면 data warehousing만으로는 충분하지 않다.
• 그럼 데이터는 쿼리와 분류를 위해 어떻게 구성되어야 하고, 어떻게 분석을 위한 데이터베이스가 설계되어야 하는 것일까?
• Big data changes the answers to these questions, as traditional techniques such as RDBMS-based dimensional modeling and cube-based OLAP (online analytical processing) turn out to be either too slow or too limited to support asking the really interesting questions about warehoused data.
• 빅데이터는 이 질문에 대한 대답을 바꿔놓았음.
  • warehoused data에 질문을 하고 대한 결과값을 받기 위해 지원해야하는 cube-based OLAP나 RDBMS-based dimensional modeling이 데이터가 많아짐에 따라 너무 느려지고, 한계가 있었기에