Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных

Нажмите для полного просмотра!

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №2

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №3

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №4

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №5

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №6

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №7

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №8

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №9

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №10

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №11

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №12

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №13

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №14

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №15

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №16

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №17

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №18

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №19

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №20

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №21

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №22

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №23

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №24

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №25

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №26

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №27

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №28

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №29

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №30

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №31

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №32

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №33

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №34

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №35

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №36

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №37

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №38

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №39

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №40

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №41

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №42

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №43

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №44

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №45

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №46

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №47

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №48

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №49

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №50

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №51

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №52

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №53

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №54

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №55

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №56

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №57

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №58

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №59

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №60

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №61

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №62

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №63

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №64

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №65

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №66

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №67

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №68

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №69

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №70

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №71

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №72

Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №73

Содержание ▲

Вы можете ознакомиться и скачать презентацию на тему Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных. Доклад-сообщение содержит 73 слайдов. Презентации для любого класса можно скачать бесплатно. Если материал и наш сайт презентаций Mypresentation Вам понравились – поделитесь им с друзьями с помощью социальных кнопок и добавьте в закладки в своем браузере.

Слайды и текст этой презентации

Слайд 1

Описание слайда:

Введение в распределенные методы обработки информации Лекция №6 Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных New SQL базы данных

Слайд 2

Описание слайда:

Реляционная модель данных Обобщение Реляционная модель есть представление БД в виде совокупности упорядоченных нормализованных отношений Для реляционных отношений характерны следующие особенности. Любой тип записи (кортежа) содержит только простые (по структуре) элементы данных. Порядок записей в таблице несуществен. Упорядочение значащих атрибутов в кортеже должно соответствовать упорядочению атрибутов в реляционном отношении. Любое отношение должно содержать один атрибут или более, которые вместе составляют уникальный первичный ключ. Если между двумя реляционными отношениями существует зависимость, то одно отношение является исходным, второе - подчиненным. Чтобы между двумя реляционными отношениями существовала зависимость, атрибут, служащие первичным ключом в исходном отношении, должны также присутствовать в подчиненном отношении.

Слайд 3

Описание слайда:

Достоинства и недостатки РМД Достоинства РМД: простота представления и формирования базы данных универсальностью и удобством обработки данных, которая осуществляется с помощью декларативного языка запросов SQL (Structured Query Language) Достоинства обеспечили широкое распространение РМД Недостатки РМД: сложность моделирование предметной области нет специальных средств для отображения различных типов связей и агрегатов (приходится проводить нормализацию отношений) отсутствие специальных механизмов навигации, что приводит к увеличению времени поиска определенных данных

Слайд 4

Описание слайда:

Базовые операции SQL Изначально, SQL был основным способом работы пользователя с базой данных и позволял выполнять следующий набор операций: создание в базе данных новой таблицы; добавление в таблицу новых записей; изменение записей; удаление записей; выборка записей из одной или нескольких таблиц (в соответствии с заданным условием); изменение структур таблиц

Слайд 5

Описание слайда:

SQL - развитие обеспечиваются возможности описания и управления новыми хранимыми объектами (например, индексы, представления, триггеры и хранимые процедуры) стал приобретать черты, свойственные языкам программирования пользователю предоставляются развитые средства визуального построения запросов

Слайд 6

Описание слайда:

прямой (direct) SQL прямой (direct) SQL конструкции языка используются при "прямом" взаимодействии пользователя с СУБД является базовым уровнем встроенный (embedded) SQL содержит конструкции, позволяющие использовать возможности прямого SQL в программах, написанных на традиционных языках программирования динамический (dynamic) во встраиваемый SQL добавляются конструкции, позволяющие приложениям обращаться к СУБД с конструкциями прямого SQL, которые динамически образуются во время выполнения программы

Слайд 7

Описание слайда:

SQL и распределенные базы данных распределенные БД определяют сегодня развитие технологий реляционных баз данных и языка SQL задачи SQL в распределенных БД: удаленный запрос - отдельный SQL оператор обращается к одной удаленной базе данных, и каждый оператор – это отдельная транзакция. Таким образом, пользователь может выполнить несколько SQL операторов, обращающихся к разным базам данных, но каждый раз это будет отдельная транзакция; удаленная транзакция – транзакция уже из нескольких SQL операторов, обращающихся к одной удаленной базе данных распределенные транзакции – каждый оператор транзакции обращается к одной удаленной базе данных, но одна транзакция может обращаться к нескольким распределенные запросы – отдельный SQL оператор может обращаться к нескольким удаленным базам данных, причем транзакция из таких операторов может обращаться также к нескольким базам данных

Слайд 8

Описание слайда:

SQL и распределенные базы данных проблемы: план выполнения статического оператора SQL: встроенная статическая инструкция SQL компилируется и сохраняется в базе данных в виде плана выполнения когда запрос объединяет данные из двух или более баз данных, в какой из них следует хранить план выполнения? иметь два или более согласованных плана? если изменяется структура одной базы данных, то как можно изменить план выполнения в другой базе данных? Выход - применение динамического SQL в сетевой среде НО! снижается производительность приложений из-за повышения сетевого трафика и многочисленных задержек.

Слайд 9

Описание слайда:

SQL и распределенные базы данных Проблема оптимизации: в распределенных БД нельзя применять обычные правила оптимизации инструкций SQL например, полное сканирование локальной таблицы может оказаться оптимальнее, чем поиск по индексу в удаленной таблице программа оптимизации должна знать параметры сети и, в частности, ее быстродействие В распределенных БД роль оптимизации становится более важной, а ее осуществление более трудным.

Слайд 10

Описание слайда:

SQL и распределенные базы данных Проблема совместимости данных в различных вычислительных системах существуют разные типы данных данные одного и того же типа в разных системах могут иметь разные форматы В распределенной СУБД эти различия должны быть незаметны Оборудование от разных поставщиков различные СУБД => различные диалекты SQL

Слайд 11

Описание слайда:

SQL и облачные вычисления Задачи проекция традиционного SQL на облако: решить проблему масштабирования (произвольного увеличения количества серверов распределенных БД) предоставить возможность для работы с базой данных посредством интернет-сервисов построить в облаке проект реляционной базы данных со всеми преимуществами, предоставляемыми любой облачной технологией Одно из решений – новая технология Microsoft - SQL Azure

Слайд 12

Описание слайда:

NoSQL и SQL концепция NoSQL (англ. not only SQL, не только SQL): расширить возможности БД там, где SQL недостаточно гибок оставить SQL там, где он справляется со своими задачами проблемы реляционных БД: сложности при работе с данными очень большого объема проблема масштабируемости основа концепции NoSQL:

Слайд 13

Описание слайда:

NoSQL и SQL методологические обоснования – основа - теорема CAP: в распределённой системе невозможно одновременно обеспечить: согласованность данных, доступность (англ. availability, в смысле наличия отклика по любому запросу) устойчивость к расщеплению распределённой системы на изолированные части

Слайд 14

Описание слайда:

NoSQL и SQL предлагается: обеспечить высокую доступность и устойчивости к разделению не фокусироваться на средствах обеспечения согласованности данных, обеспечиваемых традиционными SQL-ориентированными СУБД с транзакционными механизмами на принципах ACID То есть предлагается пожертвовать согласованностью данных ради доступности и масштабируемости

Слайд 15

Описание слайда:

Что такое NoSQL? Предпосылки развития NoSQL технологий Появление в начале 2000-х Google - поисковые системы Facebook – социальные сети И.т.д. Этим системам свойственно Постоянно меняющаяся структура Непредсказуемый рост количества данных Огромное число пользователей Реляционные базы данных не справлялись

Слайд 16

Описание слайда:

Что такое NoSQL(not only SQL) СУБД? специализация БД для конкретной области применения (позволяет обеспечить более высокую скорость обработки данных); разделение БД на системы хранения, системы обработки потоков данных в режиме реального времени и гибридные системы; целевая направленность на обработку распределенных данных (многие базы NoSQL используют разные серверные продукты, осуществляют резервное хранение, поддерживают географическую распределенность, не испытывают зависимости от центрального узла) На данный момент существует очень много различных NoSQL СУБД (около 130)

Слайд 17

Описание слайда:

Виды NoSQL Все NoSQL СУБД разделяются на несколько категорий: Key-value stores / Хранилища типа «ключ-значение» Column Family (Bigtable) stores / Масштабируемые распределенные хранилища Graph Stores / Графовые СУБД Document Stores / Документно-ориентированные СУБД

Слайд 18

Описание слайда:

На рисунке схематично обозначены объемы используемых данных и сложность этих данных в этих видах NoSQL

Слайд 19

Описание слайда:

Языки запросов баз NoSQL В качестве языка запросов баз NoSQL используется либо специализированные программные продукты (например, MapReduce, Sawzall), либо несколько расширенный SQL, позволяющий извлекать сложные объекты из одной таблицы без операций соединения.

Слайд 20

Описание слайда:

Слайд 21

Описание слайда:

Анализ таблицы: реляционные базы данных реляционные базы данных предназначены для хранения структурированной информации в виде двумерных таблиц, которая обрабатываются с помощь языка запросов SQL реляционные базы относятся к типу CP, т.е. они направлены на обеспечение согласованности данных и устойчивости системы к сбоям узлов именно их следует использовать для хранения бухгалтерской и финансовой информации, в частности для реализаций транзакций по банковским картам. использовать для этих целей базы NoSQL неразумно, поскольку в последних согласованность данных приносится в жертву доступности системы и ее устойчивости

Слайд 22

Описание слайда:

Анализ таблицы: категории NoSQL баз данных Первая категория — это базы данных (ключ значение). это очень большие хэш-таблицы[1], где каждому ключу поставлено в соответствие значение. могут очень быстро оперировать колоссальными объемами информации имеют серьезные ограничения в языке запросов. Примеры:Dynomite, Voldemort, Tokyo, Redis, BigTable. [1] Хеш-табли́ца — это структура данных, которая позволяет хранить пары (ключ, значение) и выполнять три операции: операцию добавления новой пары, операцию поиска и операцию удаления пары по ключу.

Слайд 23

Описание слайда:

Что такое key-value БД? Этот тип БД работает с данными типа ключ-значение. Здесь нет места ни структуре, ни связям. После подключения к серверу (например Redis) приложение может задать ключ и его значение, а в последствии получать эти данные по запросу. Такие СУБД обычно используются для быстрого сохранения базовых данных, а иногда не таких уж и базовых, если подсчитать затраты процессора и памяти. Они, обычно, очень быстры, работоспособны или легко масштабируемы (хорошо использовать такие БД для хранения сессий, кеша, счётчиков посещений или просмотров и т.д.).

Слайд 24

Описание слайда:

Зачем нужно такое решение, если есть MySQL, PostgreSQL, Oracle...? Решая такую простую задачу, как сохранение/чтение значений по ключу, система работает крайне эффективно, т.к. в ней отсутствуют тяжелые слои SQL обработчиков, систем индексации, профилирования, вакуумизации (для PostgreSQL) и т.д. Подобное решение дает наиболее эффективную производительность, минимальную стоимость внедрения и масштабирования.

Слайд 25

Описание слайда:

Пример на основе авторизации пользователя Сейчас все представили себе стандартное решение — таблица в MySQL на три колонки ID | login | password | Регистрация происходит следующим образом — мы проверяем, нет ли такого же логина в таблице и вставляем новую строку. Авторизация — делаем выборку по связке логин — пароль (или хеш пароля). А теперь вопрос — зачем мы использовали MySQL для решения такой задачи, если мы не использовали 99% возможностей этой РСУБД.

Слайд 26

Описание слайда:

Пример на основе авторизации пользователя Давайте ту же задачу рассмотрим в приближении БД ключ-значение: Регистрация. У нас есть логин (уникальная колонка) и пароль. Авторизация будет происходить следующим образом — делаем выборку по логину (это ключ) — получаем пароль, сравниваем с тем, что написал пользователь — готово. Как Вы успели заметить, у нас нет поля "user_id", без которого будет крайне трудно построить систему любой сложности. Как это решается? Ключом будет user_id, который будет увеличиваться при каждой регистрации на 1 (текущее значение autoincrement будем также хранить в паре ключ=значение) Т.к. во время авторизации нам нужно делать выборку по логину, то нужно хранить еще одну пару: логин-user_id

Слайд 27

Описание слайда:

Слайд 28

Описание слайда:

Слайд 29

Описание слайда:

Хранилища типа ключ-значение ориентированы на работу с записями Это значит, что вся информация, относящаяся к данной записи, хранится вместе с ней. Домен (о котором можно думать как о таблице) может содержать бессчетное количество различных записей. Например, домен может содержать информацию о клиентах и о заказах. Это означает, что данные, как правило, дублируются между разными доменами. Это приемлемый подход, поскольку дисковое пространство дешево. Главное, что он позволяет все связанные данные хранить в одном месте, что улучшает масштабируемость, поскольку исчезает необходимость соединять данные из различных таблиц. При использовании реляционной БД, потребовалось бы использовать соединения, чтобы сгруппировать в одном месте нужную информацию.

Слайд 30

Описание слайда:

Доступ к данным

Слайд 31

Описание слайда:

Доступ к данным

Слайд 32

Описание слайда:

Хранилища типа ключ-значение: преимущества РСУБД (RDBMS) слишком медленные, имеют тяжелую прослойку SQL движков, тяжело масштабируются РСУБД не достаточно хороши в плане показателя concurrency (обработка одновременных запросов) Слишком большая стоимость решения РСУБД для хранения мелких порций данных Нет необходимости в SQL запросах, индексах, триггерах, хранимых процедурах, временных таблицах, видах и т.д. БД ключ-значение легко масштабируемы и высокопроизводительны ввиду своей легкости

Слайд 33

Описание слайда:

Хранилища типа ключ-значение: недостатки Преимущество реляционных БД заключается в том, что они вынуждают вас пройти через процесс разработки модели данных. Ограничения в реляционных БД гарантируют целостность данных на самом низком уровне. Данные, которые не удовлетворяют ограничениям, физически не могут попасть в базу. Контроль целостности данных полностью лежит на приложениях. Однако в любом коде есть ошибки.

Слайд 34

Описание слайда:

Хранилища типа ключ-значение: недостатки Если ошибки в правильно спроектированной реляционной БД обычно не ведут к проблемам целостности данных, то ошибки в хранилищах типа ключ-значение обычно приводят к таким проблемам. Таким образом, в РСУБД данные становятся независимы от приложения. Это значит, что другое приложение сможет использовать те же самые данные и логика приложения может быть изменена без каких-либо изменений в модели базы.

Слайд 35

Описание слайда:

Выводы Экономя время на анализе во время разработки, вы теряете время и деньги, масштабируя решения, которые не предусмотрены для возложенных на них задач. Использовать РСУБД для хранения пар ключ-значение и чтений значений по ключу — это показатель того, что Вы действуете крайне не эффективно. Тем не менее, думайте заранее — если Вам необходимо делать выборки списков или строить графики статистики, Вам придется использовать реляционные СУБД (для чего они собственно и нужны)

Слайд 36

Описание слайда:

Документо-ориентированные базы данных Такие базы немного напоминают базы (ключ-значение), но в данном случае, база данных знает, что из себя представляют значения. Обычно, значением является некоторый документ или объект, к структуре которого можно делать запросы. Примерами таких баз являются CouchDB и MongoDB.

Слайд 37

Описание слайда:

Графовые базы данных В особую категорию относят базы, данных построенные на графах. Такие базы ориентированы на поддержку сложных взаимосвязей между объектами, и основываются на теории графов. Структура данных представляет собой набор узлов, связанных между собой ссылками. При этом и узлы и ссылки могут обладать некоторым количеством атрибутов. Примеры: Neo4j, AllegroGraph, Sones graphDB.

Слайд 38

Описание слайда:

Объектно-ориентированные базы данных Также существует еще одна категория, которую обычно не относят к NoSQL. Это - объектно-ориентированные базы данных Такие базы предназначены прежде всего для поддержки объектно-ориентированной парадигмы программирования. Их очень просто использовать в языках программирования, в которых поддерживается эта парадигма.

Слайд 39

Описание слайда:

Преимущества постреляционных БД Кроме отказа от нормализации, постреляционные СУБД позволяют хранить в полях отношений данные абстрактных, определяемых пользователями типов. Это дает возможность решать задачи нового уровня, хранить объекты и массивы данных, ориентированные на конкретные предметные области, а также роднит постреляционные СУБД с еще одним классом – объектно-ориентированными СУБД.

Слайд 40

Описание слайда:

Объектно-ориентированные базы данных (ООБД) ООБД - базы данных, в которых информация представлена в виде объектов, в ООБД любая сущность – объект и обрабатывается как объект; в ООБД используется понятие "объект" из объектно-ориентированного программирования

Слайд 41

Описание слайда:

Объектно-ориентированная парадигма Термин "объект" в программной индустрии впервые был введен в языке Simula (1967 г.) и означал какой-либо аспект моделируемой реальности. Сейчас под объектом понимается "нечто, имеющее четко определенные границы" (определение известного американского специалиста Г.Буча). В ООБД термин "объект" означает комбинацию "данных" и "программы", представляющих некоторую сущность реального мира.

Слайд 42

Описание слайда:

Объектно-ориентированная парадигма "Данные" состоят из компонентов произвольного типа, называемых "атрибутами". Характеристики объекта моделируются его атрибутами. Каждая программа в программной части называется "методом". Идентификаторы объектов – дескрипторы.

Слайд 43

Описание слайда:

Объекты, обладающие одинаковыми свойствами, составляют классы (например, курица, пингвин и чайка - объекты класса "птицы"). Объекты, обладающие одинаковыми свойствами, составляют классы (например, курица, пингвин и чайка - объекты класса "птицы"). Обычно класс описывается как новый тип данных, а объекты (экземпляры класса) - определенные на его основе переменные. Классы образуют иерархию наследования, заимствуя свойства друг друга; Каждый класс имеет определенную совокупность методов, Классы взаимодействуют друг с другом посредством механизма сообщений;

Слайд 44

Описание слайда:

Схема представления класса объектов

Слайд 45

Описание слайда:

Структура объектной модели Структура объектной модели описываются с помощью трех ключевых понятий: инкапсуляция – свойство объекта скрывать свою внутреннюю структуру наследование - возможность создавать из классов объектов новые классы объектов, которые наследуют структуру и методы своих предков, добавляя к ним черты, отражающие их собственную индивидуальность полиморфизм -различные объекты могут по разному реагировать на одинаковые внешние события в зависимости от того, как реализованы их методы

Слайд 46

Описание слайда:

Характеристики ООБД Объектно-ориентированные базы данных обычно рекомендованы для тех случаев, когда требуется высокопроизводительная обработка данных, имеющих сложную структуру. Выбор обязательных характеристик ООБД основан на 2 критериях: система должна быть объектно-ориентированной и представлять собой базу данных.

Слайд 47

Описание слайда:

Преимущества ООБД Объектно-ориентированный подход предоставляет мощные средства конструирования типов данных Эти средства устраняют три важных недостатка РБД: РБД вынуждают пользователей представлять иерархические данные (данные с большой вложенностью, составные данные и т.д.) в терминах кортежей многих отношений, что неудобно для выборки данных, разбросанных по многим отношениям, РБД должны выполнять трудоемкие операции соединения

Слайд 48

Описание слайда:

Преимущества ООБД РБД предлагают набор примитивных встроенных типов в качестве доменов столбцов отношений, без всяких средств добавления пользовательских типов. Встроенные типы - в основном, численные и символьные. Поэтому для того, чтобы добавить новый тип данных, часто приходится перекраивать архитектуру и код системы. Добавление же нового типа к системе баз данных означает возможность сохранения данных этого типа, запрашивания и обновления таких данных.

Слайд 49

Описание слайда:

Преимущества ООБД Инкапсуляция объектов в ООБД не накладывает никаких ограничений на типы. В объектно-ориентированных языках тип атрибута объекта может быть как примитивным, так и произвольно определенным пользователем типом (классом). Иерархические данные естественным образом представляются благодаря тому, что значение атрибута объекта, в свою очередь, может быть объектом.

Слайд 50

Описание слайда:

Преимущества ООБД Инкапсуляция объектов - основа для хранения и управления программами как объектами, средствами баз данных. Современные РБД поддерживают "хранение процедуры", т.е. позволяют писать программы на некотором процедурном языке и сохранять в базе данных, а затем их загружать и выполнять. Однако хранимые процедуры не инкапсулируют данные, поэтому их нельзя соотнести с любым отношением или с любым кортежем. Кроме того, поскольку РБД не поддерживают наследования, хранимые процедуры не допускают автоматического переиспользования.

Слайд 51

Описание слайда:

Преимущества ООБД Сила объектно-ориентированных концепций проистекает из объединения инкапсуляции и наследования. Поскольку наследование делает возможным совместное использование различными классами одного набора атрибутов и методов, одна и та же программа может работать с объектами, принадлежащими ко всем этим классам.

Слайд 52

Описание слайда:

Преимущества ООБД На этом основывается объектно-ориентированный интерфейс пользователя современных оконных систем. Один и тот же набор программ (открыть, закрыть, создать, выбросить, переместить и т.д.) применим к различным типам данных (изображение, текст, аудио-данные, каталог и т.д.). Если пользователи определяют много классов, и каждый имеет много атрибутов и методов, выгода от разделения не только данных, но и программ может быть впечатляющей. Их не надо определять каждый раз заново. Новые классы могут создаваться добавлением атрибутов и методов к существующим классам, а не модифицируя их атрибуты и методы, что уменьшает вероятность появления новых ошибок.

Слайд 53

Описание слайда:

Недостатки ООБД Отсутствуют мощные непроцедурные средства извлечения объектов из базы. Все запросы приходится писать на процедурных языках, проблема их оптимизации возлагается на программиста Вместо чисто декларативных ограничений целостности (типа явного объявления первичных и внешних ключей реляционных таблиц с помощью ключевых слов PRIMARY KEY и REFERENCES) или полудекларативных триггеров для обеспечения внутренней целостности приходится писать процедурный код

Слайд 54

Описание слайда:

Недостатки ООБД Оба эти недостатка связаны с отсутствием развитых средств манипулирования данными. Эта задача решается двумя способами – расширение ОО-языков в сторону управления данными (стандарт ODMG), либо добавление объектных свойств в реляционные СУБД (SQL-3, а также так называемые объектно-реляционных СУБД).

Слайд 55

Описание слайда:

Подход Стоунбрейкера Стоунбрейкер — главный архитектор Ingres и Postgres, активный участник разработки многих других систем. Он также является сооснователем компании Vertica, создателя одноименной столбцовой СУБД, которая феврале нынешнего года была приобретена Hewlett-Packard. Сейчас Стоунбрейкер — директор по технологиям новой компании VoltDB, предлагающей программную систему распределенной обработки данных. По убеждению патриарха СУБД, широко известный язык запросов SQL можно было бы после небольшого усовершенствования использовать с новыми горизонтально масштабируемыми NoSQL-системами, благодаря чему они могли бы обрести полноценную гибкость. Этот новый подход Стоунбрейкер называет NewSQL.

Слайд 56

Описание слайда:

Подход Стоунбрейкера: реабилитация SQL баз данных Реляционные СУБД — действительно «вымирающий вид»,. Однако виноваты в этом поставщики СУБД, а не SQL как таковой. Реляционные СУБД, медлительны вовсе не из-за того, что поддерживают SQL. Большинство коммерческих реляционных систем управления базами данных, доступных на рынке, появились 30 лет назад или больше, Они не были рассчитаны на применение в условиях нынешних транзакционных сред, обрабатывающих гигантские объемы данных. Десятилетиями реляционные СУБД обрастали новыми возможностями сомнительной ценности, в результате превратившись в неимоверных размеров программные «пузыри».

Слайд 57

Описание слайда:

Подход Стоунбрейкера: реабилитация SQL баз данных Медлительность баз данных можно отнести на счет нескольких факторов: реляционные системы обслуживают буферный пул, ведут журналы операций для нужд восстановления, управляют блокировками полей данных, предотвращающими их перезапись конкурирующими операциями. Согласно результатам испытаний все эти задачи отнимают до 96% системных ресурсов.

Слайд 58

Описание слайда:

Причины перехода к NoSQL базам данным Реляционные базы данных не обладают необходимой гибкостью. Их архитектура, разработанная еще в эпоху перфокарт, реализует фиксированный подход к моделированию данных. Если организации нужно добавить новый столбец к таблице, приходится изменять схему базы, что может вызвать определенные трудности. При этом сама схема не всегда точно отражает исходную модель данных Существует множество видов данных, которые нельзя разместить в таблице. Табличный формат накладывает слишком много ограничений.

Слайд 59

Описание слайда:

Причины перехода к NoSQL базам данным Реляционные базы данных плохо масштабируются за пределами одиночного сервера. Когда объем данных превышает возможности одного сервера, их приходится делить между несколькими системами, а с этим могут быть определенные сложности. При исполнении СУБД на группе серверов могут возникнуть трудности с выполнением некоторых операций, например внешних соединений, при которых консолидируются данные из нескольких таблиц.

Слайд 60

Описание слайда:

Недостатки NoSQL баз данных Ввиду отсутствия поддержки SQL такие системы лишены способности выполнять структурированные запросы с математической точностью. Созданный на основе алгебры отношений и реляционного исчисления, SQL дает гарантию того, что хорошо структурированный запрос, даже очень сложный, захватит из базы все необходимые данные. NoSQL-системы не обеспечивают соответствия операций требованиям ACID (atomicity, consistency, isolation, durability — «атомарность, непротиворечивость, изолированность, долговечность») — стандарта, который гарантирует точность выполнения оперативных транзакций средствами СУБД, даже если работа системы прерывалась.

Слайд 61

Описание слайда:

Недостатки NoSQL баз данных Средства обеспечения соответствия ACID можно реализовать на уровне приложения, однако написание соответствующего кода, по словам Стоунбрейкера, это «хуже смерти». Наконец, у каждой NoSQL-системы есть свой собственный язык запросов, в связи с чем затруднена стандартизация интерфейсов приложений.

Слайд 62

Описание слайда:

Выход – NewSQL базы данных NewSQL обеспечивает гарантии качества выполнения транзакций, свойственные SQL-системам, и при этом обладает масштабируемостью на уровне NoSQL-систем. Подход NewSQL основан на ряде инновационных архитектурных решений: В NewSQL не используется ресурсоемкий буферный пул, поскольку база данных целиком находится в основной памяти. Новый метод также устраняет потребность в краткосрочных блокировках данных, поскольку система исполняется на сервере строго в виде одиночного потока (хотя иные типы блокировки все же будут создавать определенную нагрузку) А «дорогостоящие» операции восстановления исключаются за счет применения дополнительных серверов для тиражирования и переключения нагрузки при отказе.

Слайд 63

Описание слайда:

NewSQL базы должны удовлетворять следующим критериям: поддержка реляционной модели и транзакционности SQL как основной интерфейс доступа к данным горизонтальная масштабируемость совершенно новый движок, не унаследованный от классических СУБД появились в последние 3-5 лет

Слайд 64

Описание слайда:

Технические характеристики решений NewSQL SQL как основной механизм для взаимодействия. ACID поддержка транзакций. Механизм управления без применения блокировок, таким образом считывающие данные в реальном времени не будут находится в противоречии с записывающими, что исключает конфликт. Архитектура, обеспечивающая намного выше производительность узла, чем доступный из традиционных решений RDBMS. Удобное масштабирование, способное управлять большим количеством узлов, не перенося узкие места.

Слайд 65

Описание слайда:

Классификация NewSQL Новые базы данных Новый движок базы данных MySQL Прозрачное объединение в кластеры Данная Классификация основана на различных подходах, разработанных для того, чтобы сохранить SQL интерфейс, а также решить масштабируемость и производительность, являющиеся проблемами традиционных решений OLTP.

Слайд 66

Описание слайда:

Новые базы данных NewSQL система разрабатывается полностью с нуля с целью достижения масштабируемости и производительности. Одним из ключевых факторов в повышении производительности является использование оперативной памяти или новых видов дисков (флэш-память/SSD), которые являются хранилищем первичных данных. Данное решение может осуществляться программно (VoltDB, NuoDB) либо на уровне железа (Clustrix, Translattice) Примеры разработок являются Clustrix, NuoDB и Translattice (коммерческие) и VoltDB, (Open Source).

Слайд 67

Описание слайда:

Новые базы данных Многие NewSQL БД — это in-memory БД. Они хранят все данные в оперативной памяти. Создатели этих БД считают фатальным недостатком существующих БД стремление все хранить на диске. Если вам нужно обрабатывать данные быстро, вам нужно хранить их в ОЗУ. А относительно небольшой объем ОЗУ на одной машине можно легко компенсировать, собрав кластер из сотен узлов. Хранение в ОЗУ не означает, что данные будут потеряны при выключении питания. Все эти БД ведут журнал операций и периодически скидывают снимки данных на диск.

Слайд 68

Описание слайда:

Новый движок базы данных MySQL Чтобы преодолеть проблемы масштабируемости MySQL, было создано ряд движков основанных на MySQL. Положительная сторона — использование интерфейса MySQL, но есть плохая сторона — не поддерживается миграция данных из других баз данных (включая старый MySQL). Примеры реализации — Xeround, GenieDB (коммерческие) TokuTek; и Akiban, MySQL Группа NDB и др. (opensource).

Слайд 69

Описание слайда:

Новый движок базы данных MySQL Самый популярный — TokuDB — движок для MySQL. Он использует индексы на так называемых фрактальных деревьях. Эти индексы значительно быстрее B-деревьев в случаях, когда индексы не помещаются в оперативной памяти и их приходится читать с диска.

Слайд 70

Описание слайда:

Прозрачное объединение в кластеры Обычные SQL базы объединяются в кластере из нескольких физических узлов для хранения и обработки больших объемов данных. Тут может быть два подхода: Базы данных OLTP сохраняются в своем оригинальном виде, но обеспечивают масштабируемость за счет особенностей группировки данных. Другой подход должен обеспечить прозрачность фрагментации, чтобы улучшить масштабируемость.

Слайд 71

Описание слайда:

Прозрачное объединение в кластеры БД Schooner MySQL, Continuent Tungsten и ScalArc следуют первому подходу, тогда как ScaleBase и dbShards следуют второму подходу. Оба подхода позволяют повторное использование существующих наборов и экосистемы, и избегают потребности переписать код или выполнить любые миграции данных. Примеры реализаций — ScalArc, Schooner MySQL, dbShards (коммерческий) ScaleBase; и Continuent Tungsten (opensource).

Слайд 72

Описание слайда:

Прозрачное объединение в кластеры Сюда можно отнести также MySQL Cluster, Postgres-XC, Oracle RAC и прочие. Все промышленные СУБД пытаются собраться в кластер. Все эти решения представляют собой промежуточный слой (middleware), который распределяет запросы между узлами, хранящими данные (обычными БД) и объединяет результаты, собственно, осуществляя фрагментацию. Как правило, на запросы накладываются сильные ограничения на использование внешних ключей и джойнов.

Слайд 73

Описание слайда:

NewSQL подходит для фирм, которые планируют: миграцию существующих приложений для адаптации к работе с данными большого объема разработку новых приложений на хорошо масштабируемых системах OLTP использовать на имеющиеся системы, основанные на традиционной системе обработки данных OLTP