Datastore limitations:

1. Datastore was built on Megastore, which used Paxos [28] to synchronously replicate entity groups for high availability; each replica was hosted in Bigtable [8]. Megastore, and hence Datastore, provided full ACID semantics within each entity group but no consistency guarantees across them
2. Furthermore, each entity group had a limited maximum write rate (on the order of a few writes per second), forcing application developers to split their data across many entity groups, and then have to resort to eventually consistent queries to access this data. These consistency limitations significantly complicated application—and in particular, data model—development. As a mitigation, Datastore also supported transactions that straddle up to 25 entity groups [16].

The Spanner client communicates with one or more Spanner Server tasks that manage the complexity associated with distributed storage, e.g. coordinating replication via Paxos. Conversely, the Megastore library accesses the underlying Bigtables directly, in addition to communicating with two support services: the Replication Server, which handles per-replica aspects of Megastore’s Paxos implementation, and the Coordinator, which is an in-memory per-replica cache of the Paxos replication state.

The MegaMover Orchestrator updates Firestore’s metadata to shepherd databases through the various migration states. The migration state of a given database determines how traffic for that database is routed among the Megastore, Spanner, or migrationspecific implementations. Before migration, traffic goes via the (original) Megastore-backed implementation. Once migration for a database starts, traffic is handled by a second, migration-specific implementation

Depending on migration state, some reads may go to Megastore while the others for the same database go to Spanner. Similarly, writes may go to one of Megastore or Spanner, or during some states of migration writes may be attempted on Megastore but retried on Spanner. Once a database has completed migration, all its traffic goes to only Spanner. Section 4 and Table 1 provide further detail on routing of reads and writes

1. Sharding for Scalability and Load Balancing:

• What is sharding?: Sharding is a technique used to split or merge rows of an instance into smaller chunks called tablets.
• Why sharding?: Tablets are assigned to individual servers, enabling the system to distribute the load evenly across multiple servers. This ensures scalability and avoids overloading any single server.

2. Keyed Rows and Tablets:

• Each tablet contains consecutive ranges of keyed rows (rows organized by unique keys).