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

Категория: Информатика
Нажмите для полного просмотра!
Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных. New SQL базы данных, слайд №1Распределенные реляционные базы данных. 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 базы данных
Описание слайда:
Введение в распределенные методы обработки информации Лекция №6 Распределенные реляционные базы данных. SQL и распределенные базы данных. NoSQL базы данных New SQL базы данных

Слайд 2





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

Слайд 3





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

Слайд 4





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

Слайд 5





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

Слайд 6





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

Слайд 7





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

Слайд 8





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

Слайд 9





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

Слайд 10





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

Слайд 11





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

Слайд 12





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

Слайд 13





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

Слайд 14





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

Слайд 15





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

Слайд 16





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

Слайд 17





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

Слайд 18





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

Слайд 19





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

Слайд 20


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

Слайд 21





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

Слайд 22





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

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

Слайд 23





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

Слайд 24





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

Слайд 25





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

Слайд 26





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

Слайд 27


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

Слайд 28


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

Слайд 29





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

Слайд 30





Доступ к данным
Описание слайда:
Доступ к данным

Слайд 31





Доступ к данным
Описание слайда:
Доступ к данным

Слайд 32





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

Слайд 33





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

Слайд 34





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

Слайд 35





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

Слайд 36





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

Слайд 37





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

Слайд 38





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

Слайд 39





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

Слайд 40





Объектно-ориентированные 
базы данных (ООБД) 

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

Слайд 41





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

Слайд 42





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

Слайд 43





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

Слайд 44





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

Слайд 45





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

Слайд 46





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

Слайд 47





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

Слайд 48





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

Слайд 49





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

Слайд 50





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

Слайд 51





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

Слайд 52





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

Слайд 53





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

Слайд 54





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

Слайд 55





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

Слайд 56





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

Слайд 57





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

Слайд 58





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

Слайд 59





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

Слайд 60





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

Слайд 61





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

Слайд 62





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

Слайд 63





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

Слайд 64





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

Слайд 65





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

Слайд 66





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

Слайд 67





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

Слайд 68





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

Слайд 69





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

Слайд 70





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

Слайд 71





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

Слайд 72





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

Слайд 73





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



Похожие презентации
Mypresentation.ru
Загрузить презентацию