빅데이터는 대부분의 경우 확장성이 높은 **분산 스토리지(Distributed Storage)**에 저장된다. 기본적으로 대량으로 파일을 저장하기 위한 **객체 스토리지(Object Storage)**이다. Hadoop이라면 HDFS, AWS에는 S3 등이 있다.
폴더와 파일로 이루어진 스토리지 입니다. 계층 구조를 따르며 보통 일반적인 컴퓨터 유저에게 익숙한 구조입니다. 원하는 파일을 찾으려면 어느 폴더 위치에 있는지 정확히 알아야 합니다. 파일들이 많지 않다면 분류하고 정리하는데 큰 문제가 없지만, 파일들이 많아지고 폴더 구조가 깊어지면 분류하고 정리하기 힘들어지고 파일을 찾는데도 어렵습니다.
블록 스토리지는 정해진 블록안에 데이터를 저장합니다. 우리가 SQL에서 테이블을 만들때 각 칼럼별로 저장할 데이터를 설정해주고 이후의 데이터 삽입도 맨처음 설정한 값 범위안에서 저장해주는것과 유사합니다. 낮은 IO 레이턴시를 보이기때문에 RDB와 같은 데이터베이스에 아주 적합합니다.
S3나 Cloud Sotrage에서 폴더를 만들거나 다른 버킷으로 파일을 옮긴다고하여도 실제로 블록을 이동하거나 폴더에 종속된게 아닌 단지 사용자에게 그렇게 보이게 해주기만 해줍니다. 즉 논리적인 스토리지라고 볼 수 있습니다. 위의 이미지에서 보듯이 오브젝트 스토리지는 물리적 제약이 없기때문에 원하는 만큼 공간을 확장시킬 수 있습니다.
블록 스토리지는 주차장과 같습니다. 주차장이 꽉차면 더이상 주차할 수 없습니다. 그렇다면 필요한만큼 주차장을 늘려놓아야합니다. 파일 스토리지는 주차타워와 같습니다. 문제는 내 차를 타기 위해서는 주차타워가 한번 돌아가야합니다. 즉 주차가 많아지면 많아질수록 폴더가 깊어지고 많아질수록 차를 찾기가 힘듭니다. 오브젝트 스토리지는 발렛아저씨들이 알아서 주차를 해줍니다. 강남이나 판교에서 발렛 맡겨보시면 아시겠지만 이 아저씨들은 정말 공간의 예술을 보여줍니다. 어떠한 공간도 정말 효율적이고 예술적으로 사용하고 공간의 낭비가 하나도 없도록 주차를 해줍니다.
오브젝트 스토리지는 오로지 2가지 키값과 데이터만 저장합니다. 발렛을 맡길때도 자동차(데이터) 세워두고 번호표만 줍니다. 어디에 주차되어있는지 알필요는 없습니다. 마찬가지로 오브젝트 스토리지는 RESTFul Protocol(HTTP)를 이용하여 Get 혹은 Post로 요청을하면 파일을 내려줍니다. 그 이상은 알 필요가 없습니다. 또한 파일에 대해 가지고 있는 정보가 적기때문에 파일이 아무리 많아져도 블록스토리지나 파일스토리지에 비해서 빠르게 작동합니다. 마지막으로 공간을 아주 효율적으로 사용할 수 있기때문에 저렴합니다.
물론 단점도 존재합니다. 파일의 수정이 불가능합니다. 파일이 수정될때 트랜잭션을 통해 일관성을 유지하기가 힘들기때문에 덮어쓰는 방법을 이용합니다. 이렇기 때문에 이미지나 동영상같이 수정이 잘 일어나지 않는 정적인 데이터를 호스팅할때 좋습니다. 또한 내구성이 블록스토리지에 비해 떨어지기때문에 내구성을 상당히 요구하는 데이터를 처리하기 힘듭니다.
객체 스토리지에서의 파일 읽고 쓰기는 네트워크를 거쳐서 실행한다. 이때 내부 처리에는 다수의 물리적인 서버와 하드 디스크가 있다. 데이터는 항상 여러 디스크에 복사되기 때문에 일부 하드웨어가 고장 나더라도 데이터가 손실되진 않는다. 데이터의 읽고 쓰기를 다수의 하드웨어에 분산함으로써 데이터의 양이 늘어나도 성능이 떨어지는 일이 없도록 고안되어 있다.
분산 스토리지에는 필요에 따라 얼마든지 확장할 수 있는 확장성과 데이터를 구조화하지 않고도 저장할 수 있는 유연성이 요구된다. 그중에서도 기본이 되는 객체 스토리지는 임의의 파일을 저장할 수 있다는 점이 장점이지만, 다른 한편으로는 단점도 많다.
먼저 객체 스토리지 상의 파일은 교체하기 어렵다. 일단 파일을 써넣으면 그것을 통째로 교체하는 방법밖에 없다. 로그 파일처럼 나중에 변경할 일이 없는 것은 그래도 상관없지만, 데이터베이스처럼 수시로 변경하는 용도로는 적합하지 않다. 쓰기 빈도가 높은 데이터는 별도 RDB에 저장하고 정기적으로 스냅샷을 하거나 다른 **분산 데이터베이스(Distributed database)**에 저장하도록 한다.