Das Google BigTable Konzept setzt auf horizontale Skalierung von Daten im Gegensatz zu relationalen Datenbanken um eine bessere Anpassungsfähigkeit der Datenarchitektur an die aktuellen Erfordernisse zu erreichen. Durch eine verteilte und horizontale  Datenbankarchitektur können Rechnerknoten lastabhängig und dynamisch angepasst werden. Google BigTable arbeitet also nicht im Relationenschema sondern dank dem NoSQL-Konzept schemafrei.  Die Folge ist die Aufweichung des ACID-Prinzips, welches für Web-Scale Datenbanken weder notwendig noch haltbar ist und das Umschwenken auf die Philosophie des BASE (Basically Available, Soft State und Eventual Consistent)  bzw. CAP-Theorems (bei verteilten Systemen werden nur 2 der 3 Bedingungen Consistency, Availability und Partition Tolerance erfüllt). 

MapReduce
Um die grossen Datenmengen effizienter verarbeiten zu können, hat Google das MapReduce-Verfahren entwickelt. Es handelt sich hierbei um 2 unabhängige Funktionen Map und Reduce die sich aus den funktionsorientierten Computer-Hochsprachen  ableiten, und jeweils in eigenen Prozessen ausgeführt werden. Das MapReduce-Framework bietet für den Anwender eine Möglichkeit der komplexen, gekapselten Datenverarbeitung: dabei werden hauptsächlich  Vergleichsoperationen ausgeführt welche Datensätze nach vom Anwender vorgegebenen Kriterien durchsuchen können. Der MapReduce-Prozess läuft dabei in zwei Schritten ab: zunächst werden die Ausgangsdaten eingelastet und auf  verschiedene Map-Prozesse verteilt. Mit Hilfe der vom Anwender erstellten Map-Kriterien ermittelt die Map-Funktion die Zwischenergebnisse. Diese werden in Zwischenspeicher abgelegt. Danach nimmt die Reduce-Funktion  diese auf und ermittelt parallel dazu die jeweiligen Suchergebnisse. Den ersten Schritt nennt man Map-Phase und den zweiten Reduce-Phase.

Google-File-System
Google BigTable verwendet das Google File System (GFS). Wie Google BigTable ist das  Google File System eine Google-proprietäre Softwaretechnologie. Das GFS ist Linux-basiert und dafür ausgelegt auf Clustern zu laufen welche mit einer großen Anzahl handelsüblicher Commodity-Server bestückt sind.  Das GFS ist für verteilte und fehlertolerante Systeme ausgelegt, was den Anforderungen der Googleware entspricht. Diese Merkmale zeigen sich bei der Behandlung des Wegfalls eines Netzwerkknotens,  ein Ereignis das im täglichen Google-Betrieb öfters stattfindet und zum Prinzip gehört um die dynamische Ein- und Anbindung von Daten bzw. Commodity-Servern zu ermöglichen: es wird nicht unterschieden  zwischen dem Ausfall eines Netzwerkknotens und dem Herunterfahren eines solchen. Dadurch ist auch das Hinzuschalten neuer Commodity-Server im RZ im laufenden Betrieb (Hot-Plugging) möglich.  Es finden weiterhin keine ReWrite-Vorgänge statt; stattdessen werden Daten einfach hinzugefügt so das keine Notwendigkeit ständiger Synchronisations-Prozesse besteht. GFS ist geclustert und teilt sich in viele Chunk-Server  auf, die über einen Master-Server verfügen. Die Chunk-Server verwalten ihre Daten in Chunks zu 64-MB. Die Speicherstruktur verfügt über eine mindestens dreifache Redundanz. Der Master-Server verwaltet hingegen nur  einen reduzierten Meta-Datensatz um Client-Anfragen effizienter verarbeiten zu können. Nach einem Client-Request an den Master-Server erhält der Client die Adresse des jeweiligen Chunk-Servers.

SSTable 
Zur internen Repräsentation der Daten setzt Google BigTable das SSTable -Format ein. SSTable (Sorted-String-Table) ist ein On-Disk File Format welches String-to-String-Mapping  einsetzt. SSTable setzt Maps ein, die, einmal geschrieben, unveränderbar sind. Es verwendet Key-Value Paare die nach Keys sortiert sind. Die Schreibvorgänge gehen sequentiell vonstatten und hängen einen Index am Ende der Datei an.  SSTable ist in Blöcke zu jeweils 64-KB organisiert. Diese werden in einem Blockindex registriert. Bei einer Anfrage wird der Blockindex in das RAM geladen um es mit Hilfe der Binärsuche zu durchsuchen. Durch  diesen vorbereitenden Vorgang können nachgelagerte HDD-Zugriffe effizienter gestaltet werden. Es besteht auch die Möglichkeit der In-Memory-Verarbeitung des ganzen SSTable.

Chubby-Lock-Service 
Zur Vermeidung von Deadlocks und zur Transaktionssteuerung setzt Goolge-BigTable den Chubby-Lock-Service ein. Der Cubby-Lock-Service ist eine Distributed Lock Manager für lose gekoppelte verteilte Systeme.  Er besteht aus 5 Replikationen inklusive einem Master und setzt den Paxos-Algorithmus ein. Paxos ist als eine Protokollfamilie zu verstehen, welche in verteilten Systemen versucht einen Ergebnis-Konsens herzustellen.  Paxos arbeitet mit Prinzipien der Fehlertoleranz und verteilten Implementierung und unterliegen den Prinzipien der State-Machine-Replication bzw. des State-Machine-Approach nach Leslie Lemport und Fred Schneider.  Paxos wird in Key-Value Umgebungen eingesetzt und ist geeignet, den Ausfall von Netwerkknoten eines Clusters zu managen. Der Chubby-Lock-Service unterstützt Google-BigTable bei der Suche nach neuen oder ausgefallenen  Tablet-Servern und der Ermittlung der Schemadaten für die Spaltenfamilie eines Tablets. Neben dem Master-Server verfügt Goolge-BigTable über eine Library und einen Tablet-Server.  Die Tabellen werden in einer dreifachen Struktur verwaltet: diese besteht aus einer Chubby-Datei welche die Adresse des Root-Tablets enthält. Im Root-Tablet sind  Referenzierungen auf die Metadaten-Tablets enthalten. Diese besitzen Informationen für die User-Tabellen. Die Maximale Anzahl der adressierbaren Tablets beträgt 2 ^ 34.  Der Chubby-Lock-Service wird Google intern heute auch als Nameserver eingesetzt.