RDBMS kommen im distributed Cloud-Computing selten vor. Daher muss man auch die Datenhaltung überdenken. Ein Blog-Eintrag diskutiert die Änderungen sehr gut: http://highscalability.com/how-i-learned-stop-worrying-and-love-using-lot-disk-space-scale. Im Prinzip geht es darum, aus Joins zu verzichten, und Daten in den verschiedenen Entities zu duplizieren. Die Erfahrung habe ich bei meinen GWT und GAE/J Projekt ebenfalls gemacht. Es führt zu weniger Lesezugriffen insgesamt, wenn man die Daten lokal in der Entity hält und nicht erst aus verschiedenen Entities zusammensucht, wie man bei normalisierten relationalen Modellen tut. (Außerdem ist es bei vielen lese-Zugriffen auch billiger, die Daten an einer Stelle zu haben, anstatt sie von verschiedenen Stellen über Lesezugriffe, die jeweils Kosten nach sich ziehen, einzusammeln.)

In meinen GWT-GAE/J-Projekt habe ich noch einen anderen Ansatz, die Zugriffe auf die Big-Table zu minimieren. Grundsätzlich: Alle GWT-RPC Implementierungen sind Fassaden, die auf Services zurückgreifen (Googe Guice injiziert diese in die RPC-Fassaden). Für diese Endpoints gibt es dann noch einmal einen Caching-Dekorator als eine Art Caching-Aspekt, der sich wie ein Proxy um die eigentlichen RPC-Implementierungen legt. Diese speichert relevante Daten im MemCache zwischen und minimiert so (langsame) Zugriffe auf die Big-Table. Bei Schreibzugriffen löscht der Caching-Proxy die relevanten Daten aus dem Cache, sodass sie neu geladen werden müssen. Das ist einfach und fix.