Google은 제품별 데이터베이스 대신 하나의 Bigtable에서 60개 이상의 제품을 운영했다

2004년까지 Google의 제품들은 모두 같은 문제에 직면해 있었다. 웹 크롤링부터 위성 이미지, 금융 피드에 이르기까지 방대한 양의 구조화된 데이터를 저장해야 했던 것이다. 제품마다 맞춤형 저장 시스템을 구축하는 것은 비용이 많이 들었고, 기성 데이터베이스로는 필요한 규모에 도달할 수 없었기에 회사는 하나의 공유 시스템을 설계했다.

Bigtable은 단순한 모델을 제시한다. 행, 열, 타임스탬프를 키로 하는 희소 정렬 맵이며, 값은 해석되지 않은 바이트로 저장된다. 애플리케이션은 자체 레이아웃을 결정하고, 데이터 지역성을 제어하며, 데이터를 메모리에서 제공할지 디스크에서 제공할지까지 선택할 수 있는 반면, 플랫폼은 수천 대의 상용 서버에서 파티셔닝, 복제, 장애 조치를 처리한다.

2006년 논문이 나올 무렵, Google Analytics, Google Finance, Personalized Search, Google Earth를 포함한 60개 이상의 Google 제품이 Bigtable을 사용하고 있었다. 클러스터는 소수에서 수천 대의 서버에 이르기까지 다양했으며, 각각 최대 수백 테라바이트를 저장했다.

하나의 공유 저장소; 각 제품이 자체 스키마를 조정

하나의 플랫폼이 엔지니어링 및 운영 비용을 여러 제품에 분산시킨다

애플리케이션이 레이아웃을 제어하므로 모델은 단순하게 유지되면서도 용도는 다양해진다

상용 서버와 자동 파티셔닝이 페타바이트 규모로 확장된다

공유 시스템이므로 한 팀이 모두를 위해 시스템을 견고하게 만들 수 있다

제품을 확장하기 전에 공유 기반을 한 번 구축하라. 여러 팀이 조정하는 하나의 시스템이 아무도 함께 개선할 수 없는 여러 맞춤형 시스템보다 낫다.

Bigtable은 Google 자체 서비스의 중추로 남았고, 이후 Google Cloud의 제품인 'NoSQL 선구자'가 되었다. 지연 시간에 민감한 개인화, 클릭스트림, IoT 워크로드를 위한 관리형 키-값 및 와이드 컬럼 저장소로, HBase 및 Cassandra 호환 API를 갖추고 있다. 그 아이디어는 HBase와 같은 오픈소스 클론에도 영향을 주었다.