Evaluation of Bigtable
Understand Bigtable's architecture, including its use of tablets, SSTables, and memtables to balance read/write efficiency. Learn how Bigtable achieves high availability and fault tolerance through components like Chubby and GFS. Discover the trade-offs in system design that allow Bigtable to scale across servers while supporting diverse application needs, and gain insights into its centralized control and optimization techniques.
To meet our functional requirements, we employed a variety of strategies. However, we must determine if we have met the non-functional requirements. We’ll go through some of the techniques we’ve used to meet non-functional requirements.
Scalability
Bigtable divides a table into tablets, each of which holds related data with a continuous region of rows. At first, each table has only one tablet. As the table expands, it is divided into several tablets. The Bigtable manager is in charge of allocating tablets to tablet servers. Tablet servers are in charge of managing read and write requests to the tablets to which they have been allocated, as well as separating tablets that have become too big. It is really simple to add new tablet servers to a Bigtable cluster. The manager server allocates the tablets to any newly installed tablet server from the pool of unallocated tablets or from other tablet servers.
The manager checks the load (read/write requests) on the tablet servers periodically. If there is too much load on a tablet server for a specific tablet, the manager splits those busier tablets and merges tablets with lesser loads, and redistributes them between different tablet servers to balance the load.
Note: Since Bigtable is based on the GFS, it is also meant to be ...