2013 03 21_big_data_lecture_05
TRANSCRIPT
![Page 1: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/1.jpg)
Big Data’13Лекция V: NoSQL СУБД. Google Bigtable
Дмитрий Барашев[email protected]
Computer Science Center
21 марта 2013
1/54
![Page 2: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/2.jpg)
Этот материал распространяется под лицензией
Creative Commons ”Attribution - Share Alike” 3.0http://creativecommons.org/licenses/by-sa/3.0/us/deed.ru
2/54
![Page 3: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/3.jpg)
Сегодня в программе
Шаблоны доступа к данным
Реляционные СУБД и модные приложения
Таксономия NoSQL
Колоночные СУБД
Bigtable
3/54
![Page 4: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/4.jpg)
Анекдот для затравки
A DBA walks into a NOSQL bar, but turns and leavesbecause he couldn’t find a table
then he walks into Google bar and finds a big tablethere
4/54
![Page 5: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/5.jpg)
Анекдот для затравки
A DBA walks into a NOSQL bar, but turns and leavesbecause he couldn’t find a table
then he walks into Google bar and finds a big tablethere
4/54
![Page 6: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/6.jpg)
Сегодня в программе
Шаблоны доступа к данным
Реляционные СУБД и модные приложения
Таксономия NoSQL
Колоночные СУБД
Bigtable
5/54
![Page 7: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/7.jpg)
Последовательный доступ
I Map-Reduce, Pregel: последовательный доступ ипакетная обработка
I Читается много, записывается многоI Результат используется напрямую или подаетсяследующим звеньям, но не меняется
I Прекрасно для индексирования всего интернета
6/54
![Page 8: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/8.jpg)
Другие приложения
I Твиты, шаринги, лайки, котики, ботнетыI Много данных, постоянно добавляются именяются
I Случайный доступ к даннымI Зато данные достаточно локальны
7/54
![Page 9: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/9.jpg)
Варианты хранения
I Классическая реляционная СУБДI Oracle, SQL Server, MySQL, etc.
I Модная NoSQL СУБДI MongoDB, Cassandra, HBase, etc.
8/54
![Page 10: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/10.jpg)
Классическая реляционная СУБД
I Заранее известная структураI Данные хранятся построчноI Отношения нормализованы и связаны друг сдругом
I ACID транзакцииI SQL, позволяющий выразить очень сложныезапросы
I Архитектура, выжимающая на high-end машиневсё из сравнительно медленных дисков
Это прекрасно и зачастую ненужно
9/54
![Page 11: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/11.jpg)
Классическая реляционная СУБД
I Заранее известная структураI Данные хранятся построчноI Отношения нормализованы и связаны друг сдругом
I ACID транзакцииI SQL, позволяющий выразить очень сложныезапросы
I Архитектура, выжимающая на high-end машиневсё из сравнительно медленных дисков
Это прекрасно и зачастую ненужно
9/54
![Page 12: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/12.jpg)
WAT? Это ненужно?
I Если у вас банк или ERP система то вашиданные – это ваши деньги
I Конечно же вам нужны ACID транзакции инормализация
I Но никому не интересно, будет на светекотиком больше или лайком меньше
I Зато хочется чтобы сервис был доступен ифренд-лента не тупила
10/54
![Page 13: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/13.jpg)
WAT? Это ненужно?
I Если у вас банк или ERP система то вашиданные – это ваши деньги
I Конечно же вам нужны ACID транзакции инормализация
I Но никому не интересно, будет на светекотиком больше или лайком меньше
I Зато хочется чтобы сервис был доступен ифренд-лента не тупила
10/54
![Page 14: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/14.jpg)
Сегодня в программе
Шаблоны доступа к данным
Реляционные СУБД и модные приложения
Таксономия NoSQL
Колоночные СУБД
Bigtable
11/54
![Page 15: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/15.jpg)
Строгая схема и нормализация
I Не дублируй факты! Не допускай аномалий!НФБК! Ключи!
I Это все так – там где данные стоят денегI Но абстракции текут уже в РСУБД: клиентскиепрограммы объектно-ориентированы, ORM isPITA
I Модные приложения не хотят структуры инормализации, они хотят ключ-значение
12/54
![Page 16: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/16.jpg)
Заранее известная схема
I ALTER TABLE User ADD COLUMN friend_count INT
I ALTER command denied to user ’***’ fortable ’User’
I Модные приложения не знают заранее, что импонадобится в будущем
I или знают, что поле «номер паспорта» в соцсетизаполнит не так много пользователей какхотелось бы
13/54
![Page 17: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/17.jpg)
Заранее известная схема
I ALTER TABLE User ADD COLUMN friend_count INTI ALTER command denied to user ’***’ fortable ’User’
I Модные приложения не знают заранее, что импонадобится в будущем
I или знают, что поле «номер паспорта» в соцсетизаполнит не так много пользователей какхотелось бы
13/54
![Page 18: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/18.jpg)
Заранее известная схема
I ALTER TABLE User ADD COLUMN friend_count INTI ALTER command denied to user ’***’ fortable ’User’
I Модные приложения не знают заранее, что импонадобится в будущем
I или знают, что поле «номер паспорта» в соцсетизаполнит не так много пользователей какхотелось бы
13/54
![Page 19: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/19.jpg)
Сложные запросы
I 30 лет назад перед терминалом сидел оператори писал запросы на SQL или другом языке
I он мог написать любой запросI Сейчас пользователи смотрят френдленту,жмут лайки и посылают друг другу сообщения
I запросы модного приложения не отличаютсяразнообразием
I Значит и движок общего назначения не оченьнужен
14/54
![Page 20: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/20.jpg)
Одна high-end машина
I К сожалению на IBM System Z у модногоприложения нет денег
I Даже если бы они и были, модные приложенияне хотят
I зависеть от одного сервераI от одного датацентраI от одного континента
15/54
![Page 21: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/21.jpg)
Одна high-end машина
I К сожалению на IBM System Z у модногоприложения нет денег
I Даже если бы они и были, модные приложенияне хотят
I зависеть от одного сервераI от одного датацентраI от одного континента
15/54
![Page 22: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/22.jpg)
Масштабируемость
I Вторую high-end машину так быстро невключишь как минимум нужен банкет
I И вообще выгодней арендовать (виртуальные)машины в ДЦ чем держать свои
I Значит СУБД должна работать на low-endжелезе и считать отказ нормальным явлением
I а значит реплицироваться и шардироваться
16/54
![Page 23: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/23.jpg)
Транзакционная семантика
I Как только СУБД становится распределенной,сразу возникают проблемы с ACID транзакциямии доступностью системы
I Но модному приложению неважно, когда суммалайков увеличится на 1: в тот момент когдалайк добавлен, или через 5 минут.
I На смену ACID спешит BASE: Basic Availability,Soft state, Eventually consistent
17/54
![Page 24: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/24.jpg)
Железо вообще
I 30 лет назад оперативная память стоиладорого; процессоры были слабые
I Сейчас оперативная память измеряетсятерабайтами и у каждого в кармане по 4процессорных ядра
I Время позиционирования диска и времядоступа к RAM изменилось не сильно(20ms→ 4ms для диска и 200µs→ 100µs для RAM)
I Зато появилось три уровня кеша которыесущественно быстрее (≈ 1µs)
Есть место для других алгоритмов
18/54
![Page 25: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/25.jpg)
Железо вообще
I 30 лет назад оперативная память стоиладорого; процессоры были слабые
I Сейчас оперативная память измеряетсятерабайтами и у каждого в кармане по 4процессорных ядра
I Время позиционирования диска и времядоступа к RAM изменилось не сильно(20ms→ 4ms для диска и 200µs→ 100µs для RAM)
I Зато появилось три уровня кеша которыесущественно быстрее (≈ 1µs)
Есть место для других алгоритмов
18/54
![Page 26: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/26.jpg)
Ситуация не нова: OLAP vs OLTP
19/54
![Page 27: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/27.jpg)
OnLine Transaction Processing
I данные обновляются, часто параллельноI часто затрагивают одну таблицу и почти всеатрибуты
I запросы высокоселективныI ожидается низкое время отклика
20/54
![Page 28: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/28.jpg)
OnLine Analytical Processing
I read-only запросыI у сущностей много атрибутов но запросинтересуется небольшим подмножеством
I низкая селективностьI всякого рода агрегированиеI время выполнения запроса ожидаемо велико
21/54
![Page 29: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/29.jpg)
В середине 90-х появились специальные OLAPсистемы
22/54
![Page 30: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/30.jpg)
Сегодня в программе
Шаблоны доступа к данным
Реляционные СУБД и модные приложения
Таксономия NoSQL
Колоночные СУБД
Bigtable
23/54
![Page 31: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/31.jpg)
Классификация по модели данных
I «Ключ-значение»: мало чем отличается отхештаблицы, значением обычно являетсястрока
I тыщи их. Redis из самых популярныхI «Ключ-документ»: значением являетсядокумент, который может быть как BLOB’ом таки сложной структурой. СУБД можетподдерживать поиск по структуре документа
I яркий представитель MongoDBI «Ключ-расширяемая структура»: можно считатьразреженной таблицей с бесконечным числомстолбцов.
I Google Bigtable, HBase, Cassandra
24/54
![Page 32: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/32.jpg)
Классификация по организации храненияданных
I Построковое хранениеI Колоночное хранениеI Журнальное хранение
25/54
![Page 33: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/33.jpg)
Классическое построковое хранение
I все атрибуты кортежа плотно сидят рядом водном дисковом блоке
I атомарное чтение/запись одного кортежа
26/54
![Page 34: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/34.jpg)
Колоночное хранение
I в один блок упаковываются значения одного итого же атрибута разных кортежей
I кортеж разнесен по нескольким блокамI доступ к одному столбцу существенноэффективнее
27/54
![Page 35: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/35.jpg)
Журнальное хранение
I дисковые блоки для чтения read-onlyI данные для чтения сидят в RAMI обновления записываются в RAM и в журналI периодически журнал и основные данныеобъединяются
28/54
![Page 36: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/36.jpg)
Сегодня в программе
Шаблоны доступа к данным
Реляционные СУБД и модные приложения
Таксономия NoSQL
Колоночные СУБД
Bigtable
29/54
![Page 37: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/37.jpg)
Быстрое получение всех значений атрибута
I Пусть в кортеже в таблице Webtable 1000атрибутов.
I Атрибут site – адрес сайта страницы, атрибутvisits – число посещений сегодня Какая схемахранения выиграет при выполнении запроса?
1 SELECT site, SUM(visits) FROM Url GROUP BY site
30/54
![Page 38: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/38.jpg)
Построчное хранение
site …+ 500 … visits …+ 500 …a.example.com … 5 …a.example.com … 15 …a.example.com … 45 …b.example.com … 3 …b.example.com … 0 …b.example.com … 4 …b.example.com … 8 …
31/54
![Page 39: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/39.jpg)
Колоночное хранение
site …+ 500 … visits …+ 500 …a.example.com … 5 …a.example.com … 15 …a.example.com … 45 …b.example.com … 3 …b.example.com … 0 …b.example.com … 4 …b.example.com … 8 …
32/54
![Page 40: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/40.jpg)
Локальность данных в кеше
I Кеш процессора не такой уж большойI При построчном хранении будет использоватьсямалая часть
I При колоночном все нужные значения идут другза другом – кеш используется эффективнее
33/54
![Page 41: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/41.jpg)
Сжатие значений
I Пусть на каждом сайте от 10 до 1000 страниц, всреднем 500.
I Пусть всего миллион сайтовI Пусть средняя длина адреса 20 байтI Сколько понадобится места для храненияадресов в построчном хранении и сколько вколоночном?
34/54
![Page 42: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/42.jpg)
Сжатие значенийI Строковое хранение
site …+ 500 … visits …+ 500 …a.example.com … 5 …
и еще 400 страницa.example.com … 45 …b.example.com … 3 …
и еще 400 страницb.example.com … 8 …
I колоночное хранениеsitea.example.com+400a.example.comb.example.com+400b.example.com
35/54
![Page 43: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/43.jpg)
Сегодня в программе
Шаблоны доступа к данным
Реляционные СУБД и модные приложения
Таксономия NoSQL
Колоночные СУБД
Bigtable
36/54
![Page 44: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/44.jpg)
Bigtable
I Google, первая половина 2000-х годовI Разреженный распределенный многомерныйсортированный хранимый словарь
I или, ммм... большая таблица со строчками,колонками и версиями значений
I Значение – неинтерпретируемый BLOBI (row: string, column: string, time: int64)
→ byte[]
37/54
![Page 45: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/45.jpg)
Кортежи таблицы
I Ключ – произвольная последовательностьсимволов
I Кортежи отсортированы в порядкелексикографического возрастания ключей
I Все множество кортежей разбито на таблеты –непересекающиеся непрерывные диапазоны
I Таблет – единица распределения работы инагрузки
I Чтение и запись значений одного кортежаатомарны
38/54
![Page 46: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/46.jpg)
Столбцы таблицы
I Семейство: группа однотипных столбцовI В таблице обычно не очень много семейств новнутри семейства может быть много столбцов
I Группы хранения (locality groups) - наборсемейств, которые обычно используются вместе
39/54
![Page 47: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/47.jpg)
SSTable
I Сортированное отображение строк в значенияI Сортированный массив с разреженныминдексом поверх
I SSTable создается для каждой группы храненияI SSTable доступна только на чтениеI SSTable живет на GFS
40/54
![Page 48: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/48.jpg)
Жизнь системы
I Таблеты обслуживаются таблет-серверами N:1I В специальной таблице METADATA записанораспределение диапазонов ключей по таблетами таблетов по серверам
I Расположение таблетов METADATA записано вкорневом таблете
I Расположение корневого таблета системеизвестно
I Мастер следит за состоянием таблет-серверов изанимается назначением таблетов
41/54
![Page 49: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/49.jpg)
Жизнь клиента
I Клиент читает информацию о том где искатькорневой таблет
I Обращается к корневому таблету заинформацией о METADATA
I Обращается к METADATA за информацией о томгде прописаны таблеты нужной ему строки
I Звонит соответствующему таблет-серверуI Клиенты кешируют метаинформацию
42/54
![Page 50: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/50.jpg)
Жизнь записи в таблете
I Запись производится в redo-журнал,подтверждается и записывается в изменяемыйсловарь в памяти (memtable)
I Если кортеж удаляется то записывается«могильный камень»
I Minor compaction: когда memtable становитсядостаточно большим, его замораживают исоздают набор новых SSTable
43/54
![Page 51: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/51.jpg)
Жизнь чтения в таблете
I Запрос на чтение должен объединить данныеиз memtable и соответствующих SSTable
I Так как все отсортировано по ключу то этонедорогой процесс
44/54
![Page 52: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/52.jpg)
Важные события в жизни таблета
I Разделение (split)I Большое уплотнение (major compaction)
45/54
![Page 53: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/53.jpg)
Разделение таблета
46/54
![Page 54: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/54.jpg)
Равномерно распределенные ключи
47/54
![Page 55: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/55.jpg)
Неравномерно распределенные ключи
48/54
![Page 56: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/56.jpg)
Большое уплотнение
I В процессе записи постоянно создаются новыенебольшие SSTable
I Время от времени новые и старые SSTable надообъединять
I После уплотнения данные из одного диапазоналежат в одном SSTable и удалены всемогильные камни
49/54
![Page 57: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/57.jpg)
Реализации Bigtable
I Закрытая в Google (торчит наружу в App Enginedatastore)
I Apache HBase Cassandra (родом из Facebook)
50/54
![Page 58: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/58.jpg)
Занавес
I Не все большие данные обрабатываютсяконвейерно
I Не всем приложениям нужны возможности игарантии реляционных СУБД
I NoSQL СУБД осблуживают приложения сдругими требованиями
I Google Bigtable – одна из самых ранних NoSQLСУБД
I Реализаций NoSQL СУБД очень многоI Традиционные СУБД тоже начинаютподдерживать NoSQL фичи
I А NoSQL СУБД начинают поддерживать ACIDтранзакции
51/54
![Page 59: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/59.jpg)
Эта презентация сверстана в
Pa
peeria1LTEX в вашем браузере
alpha.papeeria.com
52/54
![Page 60: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/60.jpg)
Литература IFay Chang, Jeffrey Dean, Sanjay Ghemawat,Wilson C Hsieh, Deborah A Wallach, Mike Burrows,Tushar Chandra, Andrew Fikes, and Robert EGruber.Bigtable: A distributed storage system forstructured data.ACM Transactions on Computer Systems (TOCS),26(2):4, 2008.Ikai Lan.App engine datastore tip: monotonically increasingvalues are bad.http://ikaisays.com/2011/01/25/app-engine-datastore-tip-monotonically-increasing-values-are-bad/,2011.[Online; accessed 21-March-2013].
53/54
![Page 61: 2013 03 21_big_data_lecture_05](https://reader034.vdocuments.site/reader034/viewer/2022042715/557ebaf1d8b42a1e438b5321/html5/thumbnails/61.jpg)
Литература II
Christof Strauch, Ultra-Large Scale Sites, and WalterKriha.Nosql databases.Lecture Notes, Stuttgart Media University, 2011.
54/54