From Surf Wiki (app.surf) — the open knowledge base
Bigtable
Cloud-based NoSQL database service
Cloud-based NoSQL database service
| Field | Value |
|---|---|
| name | Google Bigtable |
| title | Google Bigtable |
| developer | |
| logo caption | Logo of Google Bigtable |
| platform | Google Cloud Platform |
| programming language | |
| released | |
| genre | Cloud Storage |
| license | Proprietary |
| website |
Bigtable is a fully managed wide-column and key-value NoSQL database service for large analytical and operational workloads as part of the Google Cloud portfolio.
History
Bigtable development began in 2004. It is now used by a number of Google applications, such as Google Analytics, web indexing, MapReduce, which is often used for generating and modifying data stored in Bigtable, Google Maps, Google Books search, "My Search History", Google Earth, Blogger.com, Google Code hosting, YouTube, and Gmail. Google's reasons for developing its own database include scalability and better control of performance characteristics.
Apache HBase and Cassandra are some of the best known open source projects that were modeled after Bigtable. Bigtable offers HBase and Cassandra compatible APIs.
On May 6, 2015, a public version of Bigtable was made available as a part of Google Cloud under the name Cloud Bigtable.****
As of April 2024, Bigtable manages over 10 Exabytes of data and serves more than 7 billion requests per second. Since its launch, Google announced a number of updates to Bigtable, including SQL support, incremental materialized views, global secondary indexes and automated scalability.
Design
Bigtable is one of the prototypical examples of a wide-column store. It maps two arbitrary string values (row key and column key) and timestamp (hence three-dimensional mapping) into an associated arbitrary byte array. It is not a relational database and can be better defined as a sparse, distributed multi-dimensional sorted map. It is built on Colossus (Google File System), Chubby Lock Service, SSTable (log-structured storage like LevelDB) and a few other Google technologies. Bigtable is designed to scale into the petabyte range across "hundreds or thousands of machines, and to make it easy to add more machines [to] the system and automatically start taking advantage of those resources without any reconfiguration".. For example, Google's copy of the web can be stored in a bigtable where the row key is a domain-reversed URL, and columns describe various properties of a web page, with one particular column holding the page itself. The page column can have several timestamped versions describing different copies of the web page timestamped by when they were fetched. Each cell of a bigtable can have zero or more timestamped versions of the data. Another function of the timestamp is to allow for both versioning and garbage collection of expired data.
Tables are split into multiple tablets – segments of the table are split at certain row keys so that each tablet is a few hundred megabytes or a few gigabytes in size. A bigtable is somewhat like a mapreduce worker pool in that thousands to hundreds of thousands of tablet shards may be served by hundreds to thousands of BigTable servers. When Table size threaten to grow beyond a specified limit, the tablets may be compressed using the algorithm BMDiff and the Zippy compression algorithm publicly known and open-sourced as Snappy, which is a less space-optimal variation of LZ77 but more efficient in terms of computing time. The locations in the GFS of tablets are recorded as database entries in multiple special tablets, which are called "META1" tablets. META1 tablets are found by querying the single "META0" tablet, which typically resides on a server of its own since it is often queried by clients as to the location of the "META1" tablet which itself has the answer to the question of where the actual data is located. Like GFS's master server, the META0 server is not generally a bottleneck since the processor time and bandwidth necessary to discover and transmit META1 locations is minimal and clients aggressively cache locations to minimize queries.
References
Bibliography
References
- Hitchcock, Andrew. (2005). "Google's Bigtable".
- (May 6, 2015). "Announcing Google Cloud Bigtable: The same database that powers Google Search, Gmail and Analytics is now available on Google Cloud Platform". Google Blog.
- Hitchcock, Andrew. (2005). "Google's Bigtable".
- Cordes, Kyle. (2007-07-12). "YouTube Scalability Talk".
- "Google App Engine". Google Code.
- (2024-04-11). "Celebrating 20 years of Bigtable with exciting announcements at Next".
- Kerner, Sean Michael. (2022-01-27). "Google scales up Cloud Bigtable NoSQL database".
- (2008-10-12). "Google Bigtable, Compression, Zippy and BMDiff".
- (1999). "Data compression using long common strings". IEEE Computer Society.
- (2005-10-23). "Outer court".
- "snappy".
This article was imported from Wikipedia and is available under the Creative Commons Attribution-ShareAlike 4.0 License. Content has been adapted to SurfDoc format. Original contributors can be found on the article history page.
Ask Mako anything about Bigtable — get instant answers, deeper analysis, and related topics.
Research with MakoFree with your Surf account
Create a free account to save articles, ask Mako questions, and organize your research.
Sign up freeThis content may have been generated or modified by AI. CloudSurf Software LLC is not responsible for the accuracy, completeness, or reliability of AI-generated content. Always verify important information from primary sources.
Report