Тип | Хмарне сховище |
---|---|
Розробник | Google Inc. |
Перший випуск | лютий 2005 |
Платформа | Google Cloud Platform |
Мова програмування | |
Ліцензія | Пропрієтарне |
Вебсайт | cloud.google.com/bigtable/ |
Bigtable — це система зі стисненням, високою продуктивністю та власницькою системою збереження даних, побудована на файловій системі Google, розподіленому менеджері блокувань Chubby, SSTable (лог-структуроване сховище, подібне до LevelDB[en]) та кілька інших технологій Google. 6 травня 2015 року загальнодоступна версія Bigtable почала працювати як сервіс. Bigtable також використовується в Google Cloud Datastore, який доступний як частина Google Cloud Platform.[1][2]
Розробка Bigtable розпочалась у 2004 році[3] й зараз використовується рядом додатків Google, таких як вебіндексація,[4] MapReduce, яка часто використовується для створення та модифікації даних, що зберігаються в Bigtable,[5] Google Maps,[6] пошуку у Google Книги, «Моя історія пошуку» (англ. My Search History), Google Earth, Blogger.com, хостинг Google Code, YouTube[7] та Gmail[8]. Причини, які спонукали Google для розробки власної бази включають масштабованість та кращий контроль за характеристиками продуктивності.[9]
Реляційна база даних Google Spanner є реалізацією Bigtable разом з групою протоколів Paxos для двофазної транзакції для кожної таблиці. Google F1 є надбудовою над Spanner для заміни реалізації заснованої на MySQL.[10]
Bigtable є одним із прототипів сховищ з широким стовпчиком. Він відображає два довільних текстових значення (ключ рядка і ключ стовпця) та відмітку часу (отже, тривимірне відображення) у пов'язаний довільний масив байтів.[4] Це не реляційна база даних і її краще визначити як розріджену, розподілену багатовимірну відсортовану карту. Bigtable призначений для масштабування в діапазоні петабайту через «сотні або тисячі машин, а також для спрощення додавання нових машин до системи і автоматичного використання цих ресурсів без будь-якої переконфігурації».[11]
Кожна таблиця має багато розмірностей (одна з яких є полем для відміток часу, що дозволяє використовувати системи керування версіями та збирання сміття). Таблиці оптимізовані для файлової системи Google (GFS) шляхом розбиття на кілька таблиць або таблетів (англ. tablet) — сегменти таблиці діляться по рядкам, таким чином, щоб їх розмір складав ~200 мегабайт. Коли розміри загрожують вийти за встановлену межу, таблиці стискуються за допомогою алгоритмів BMDiff[12][13] та Zippy[14] — останній алгоритм широко відомий за відкритою бібліотекою Snappy,[15] яка є варіацією LZ77 не дуже ефективною за об'ємом стиснення, але більш ефективною за часом обчислень. Розташування складових таблиці (таблети) в GFS вносяться як записи бази даних у кількох спеціальних таблетах, які називаються «META1»-таблетами. META1 таблети знаходяться за запитом єдиного таблета «META0», який звичайно розміщується на власному сервері, оскільки до нього часто йдуть запити від клієнтів щодо розташування таблета «META1», який сам містить відповідь на питання про те, де знаходяться фактичні дані. Як і головний сервер GFS, сервер META0 взагалі не є вузьким місцем[en], оскільки час і пропускна спроможність процесора, необхідні для пошуку та передачі адреси META1, є мінімальними, а клієнти активно кешують координати для мінімізації запитів.
((cite web))
: Обслуговування CS1: Сторінки з текстом «archived copy» як значення параметру title (посилання)
First an overview. Bigtable has been in development since early 2004 and has been in active use for about eight months (about February 2005)..
There are currently around 100 cells for services such as Print, Search History, Maps, and Orkut.
Their new solution for thumbnails is to use Google’s Bigtable, which provides high performance for a large number of rows, fault tolerance, caching, etc. This is a nice (and rare?) example of actual synergy in an acquisition..
We've moved a large and critical application suite from MySQL to F1.
|