Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 1386 сообщений
Cообщения с меткой

базы данных - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Как искать в DataGrip

Четверг, 20 Апреля 2017 г. 15:53 (ссылка)





В работе с любым инструментом важно легко находить то, что нужно. В DataGrip ищут:



Объекты базы данных: таблицы, представления, функции, колонки и т. д.

— Сами данные.

Код, например кусок кода в скрипте или исходнике объекта.

Другое: настройки, действия, файлы.



Разберемся, как не потеряться в IDE и своих базах данных.



Объекты базы данных



Любое дерево в DataGrip, как и в остальных наших IDE, поддерживает быстрый поиск: просто печатайте имя того, что вам нужно. Помните, что объект будет найден, только если его узел в дереве раскрыт.



Поддерживаются аббревиатуры: ‘fa’ найдет ‘film_actor’.







Навигируйтесь к объекту базы по Ctrl+N (Alt+O для OSX). Наберите в поле имя или аббревиатуру базы, схемы, таблицы, представления, процедуры.



Если вы ищете таблицу или представление, Enter откроет редактор данных (с вкладкой DDL, если нужен код), а F4 покажет объект в дереве.



То же для функций и процедур: Enter откроет исходник в редакторе, F4 покажет объект в дереве.



image



Маленький трюк для поиска столбцов в таблице или результате запроса: откройте Structure view (Ctrl/Cmd+F12) и начните печатать. Быстрый поиск отфильтрует нужные колонки. Enter перенесет фокус на нужный столбец.







Данные



Текстовый поиск (Ctrl/Cmd+F) работает в таблицах и результатах запроса. Подойдет, если вы не знаете, в каком конкретно столбце нужные вам данные.







Искаться данные будут только на текущей странице. Количество строк на странице задается в Settings -> Database -> Data views -> Result page size. Если ввести -1, будут отображаться все строки сразу. Но это может повлиять на скорость выполнения запросов.







При просмотре данных в таблице, условия фильтрации выписывайте в текстовое поле сверху, как будто пишете SQL в предложении WHERE.







В это поле можно вставлять значения автоматически, из контекстного меню.







Код



Поиск работает в любом редакторе. Но даже не все в JetBrains знают, что здесь есть автодополнение :) Вызывается по Ctrl+Space и предлагает варианты из открытого файла.

В настройках укажите, где искать: включать или исключать строки, комментарии. На все результаты поиска можно поставить мультикурсор: Ctrl+Alt+Shift+J (Ctrl+Cmd+G для OSX).







Поиск по пути ищет код в других консолях, файлах и в исходниках представлений, процедур и функций.



В нашем примере, если выбрать 'In Project', код будет найден только в дамп-файле, прикрепленном к проекту. Но если выбрать 'All scopes,' этот же кусок отыщется и в процедуре нашей базы.







Find usages в контекстном меню объекта (или по Alt+F7) покажет его использования в запросах, скриптах или исходниках других объектов. Например, таблица actor найдена в дамп-файлах, консолях и нескольких исходниках: она используется в правилах и представлениях.







Остальное



Ctrl+Shift+N (Shift+Cmd+O for OSX) откроет файл по имени.







В настройках тоже работает быстрый поиск. Чтобы найти Result page size, напечатайте это.







Когда не знаете, как что-то сделать, поможет Find action (Ctrl+Shift+A). Тут и настройки можно искать, но главное, ищите здесь любое действие в IDE. Не знаете, как открыть новую консоль? Напишите Open new console.







А когда совсем уж непонятно, где искать, попробуйте 'Search everywhere'. Объекты баз, действия, файлы, настройки — все можно найти здесь. Например, 'actor' показал не только объекты из базы, но и действие 'Refactor', которое можно выполнить прямо отсюда.







Иконка ввиде шестеренки поможет определить, где искать.







Если ваши поиски так и не увенчались успехом, пишите нам в комментарии или в Твиттер. Мы найдем!



Команда DataGrip
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/327006/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как понять и подружиться с транзакциями и JPA

Понедельник, 03 Апреля 2017 г. 12:16 (ссылка)

Наверное, все знают о транзакциях в реляционных базах данных, все слышали про ACID. Но тем не менее есть разница между знать и прочувствовать, сам с этим столкнулся, когда пришлось переквалифицироваться в бэкэнд разработчика. Думаю, в тот момент подобная статья здорово бы мне помогла, надеюсь она окажется полезна и вам.



При разработке энтерпрайз приложений зачастую с базами данных взаимодействуют посредством ORM технологии, в мире джавы наиболее известна технология JPA (Java Persistence API) и её реализации — Hibernate и EclipseLink. JPA позволяет взаимодействовать с базой данных в терминах объектов предметной области, предоставляет кэш, репликацию кэша при наличии кластера в middle tier-е.



Как это обычно происходит:




  1. На бэкэнд приходит REST запрос обновить документ, в теле запроса — новое состояние.

  2. Начинаем транзакцию.

  3. Бэкэнд запрашивает существующее состояние документа у EntityManager-а, который может вычитать его из базы, а может достать из кэша.

  4. Далее мы берём объект прибывший в теле запроса смотрим на него, сравниваем с состоянием объекта представляющего запись в базе данных.

  5. На основе этого сравнения вносим необходимые изменения.

  6. Коммитим транзакцию.

  7. Возвращаем ответ клиенту.



Где здесь порылась собака? Смотрите, мы взяли данные, скорее всего из кэша, возможно уже протухшие, возможно сервер прямо сейчас обрабатывает конкурентный запрос на изменение того же документа, и данные протухают ровно в момент когда мы делаем все эти сравнения. На основе этих данных сомнительной достоверности и тела REST запроса мы принимаем решения о внесении изменений в базу и коммитим их. Тут встаёт вопрос, что за лажу мы только что записали в базу данных?



Здесь нам и помогут транзакции. Ключ к их пониманию — это при каких условиях транзакция не пройдёт, или, иначе говоря, когда случится её откат. А откат транзакции случится если вносимые изменения нарушат констрейнты базы данных. Наиболее важные из них:




  • Нарушение констрейнтов уникальности.

  • Нарушение ссылочной целостности.



И так, если наша транзакция прошла, то «лажа», которую мы закоммитили чуть выше, удовлетворяет констрейнтам. Осталось настроить констрейнты так, чтобы удовлетворяющие им данные представляли собой валидные бизнес-сущности.



Вот максимально примитивный и искусственный пример:



@Entity
public class Document {
@Id
private String name;

@Lob
private String content;

// getters and setters пропущены
}


@ApplicationScoped
@Transactional // транзакции начнаются перед вызовом безнес-метода и завершаются по его окончанию
public class DocumentService {

@PersistenceContext
private EntityManager entityManager;

public void createDocument(String name, String content) {
// скорее всего никакого запроса к базе данных здесь не будет,
// с большой долей вероятности мы получим закэшированный объект
Document documentEntity = entityManager.find(Document.class, name);

if (documentEntity != null) {
throw new WebApplicationException(Response.Status.CONFLICT); // конфликт имен!
}

// возможно прямо сейчас другой тред конкурентно создает документ с таким же именем
documentEntity = new Document();
documentEntity.setName(name);
documentEntity.setContent(content);

entityManager.persist(documentEntity);
}
}


Здесь в случае кункурентного создания документа с тем же именем или если данные полученные из каша оказались устаревшими, в момент коммита случится ConstraintViolationException и бэкэнд вернет клиенту 500 ошибку. Пользователь повторит операцию чуть позже и получит вразумительное сообщение об ошибке или таки создаст документ.



На самом деле, 500 ошибки не очень желательны, фокус в том, что они почти никогда не будут случаться, ну а если специфика использования вашего приложения такова, что они случаются слишком часто, вот тогда стоит подумать о чём-нибудь более изощренном.



Попробуем что-нибудь посложнее. Допустим мы хотим иметь возможность защитить документ от удаления. Заводим новую таблицу:



@Entity
public class DocumentLock {
@Id
@GeneratedValue
private Long id;

@OneToOne
private Document document;

@Basic
private String lockedBy;

// getters, setters
}


И добавляем в класс Document:



    @OneToOne(mappedBy = "document")
private DocumentLock lock;


Теперь чтобы защитить документ от удаления достаточно создать DocumentLock ссылающийся на документ. Логика удаляющая документ:



    public void deleteDocument(String name) {
Document documentEntity = entityManager.find(Document.class, name);

if (documentEntity == null) {
throw new NotFoundException();
}

DocumentLock lock = documentEntity.getLock();

if (lock != null) {
throw new WebApplicationException(
"Document is locked by " + lock.getLockedBy(),
Response.Status.BAD_REQUEST);
}

entityManager.remove(documentEntity);
}


Смотрите, мы проверили, что лока нет, но использовали для это закэшированные данные возможно уже устаревшие, а возможно устаревающие прямо во время проверки. В этом случае наш код удаляя документ попытается нарушить ссылочную целостность данных и значит наша транзакция не пройдёт. Пара замечаний:




  1. Убедитесь, что каскадное удаление отключено, в случае каскадных удалений, удаление документа приведет к удалению всех записей, которые на него ссылаются. Т.е. наличие записи о бизнес-локе ничему не помешает.

  2. На самом деле код выше позволяет повесить несколько локов на один документ, т.е. требуется настроить ещё констрейнт уникальности.

  3. Пример сугубо синтетический, скорее всего имеет смысл поместить данные о владельце бизнес-лока прямо в документ, а не заводить отдельную таблицу. И затем использовать явный пессимистичный лок для проверки отсутствия этого бизнес-лока при удалении документа.



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



Подводя итоги: даже используя устаревшие и сомнительные данные (что вполне может иметь место при работе с БД посредством JPA) при принятии решения о внесении изменений в базу данных, и даже если конкурентно вносятся конфликтующие изменения, механизм транзакций не позволит нам сделать ничего, что нарушит ссылочную целостность либо не будет соответствовать наложенным констрейнтам, все действия объединённые данной транзакцией и приводящие к данному плачевному итогу будут отменены в соответствии с принципом атомарности. Просто имейте это ввиду моделируя данные и аккуратно расставляйте констрейнты.
Original source: habrahabr.ru.

https://habrahabr.ru/post/325470/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Релиз DataGrip 2017.1

Вторник, 28 Марта 2017 г. 17:06 (ссылка)

Привет! Обсуждение DataGrip началось уже в комментариях к анонсу новой IntelliJ IDEA, давайте продолжим здесь. Расскажу, что нового в DataGrip 2017.1.



image



Будет много текста и картинок. Вкратце, вот что мы добавили:





Дерево базы данных

— Новое управление схемами

— Привязка файлов к источникам данных

— Интерфейс для создания баз и схем

— Настройки цветов для редактора и результатов запроса



Импорт и экспорт данных

— Экспорт таблиц из одной базы в другую

— Сопоставление колонок файла и таблицы



Консоль запросов

— Сохранение пути поиска по умолчанию в PostgreSQL

— Шаблон для генерации триггеров

— Настройки для отключения автоматической конкатенации многострочных литералов и для автоматической квалификации объектов



Остальное

— Время выполнения запроса и номера колонки и строки выделенного поля в панели статуса

— Поиск имени таблиц и остальных объектов в комментариях и строках

— Windows-аутентификация в SQL Server для jTDS-драйвера

— Предупреждение об изменении исходного кода представления, процедуры и т.д.



Дерево баз данных



Управление схемами



Мы ещё раз переработали интерфейс для выбора схем в дереве баз данных. Надеемся, теперь это надолго :)



Дерево выбора открывается по двойному щелчку на Schemas…. Выбирайте сразу все схемы, текущую, или только те, что вы хотите видеть.







Вкладку Schemas мы вернули в свойства источника данных — там теперь такое же дерево выбора. Можно указать отображаемые схемы в текстовом шаблоне, язык которого описан в окне информации (Ctrl+Q или F1 для OSX).







Соответствия файлов и источников данных



Раньше, особенно в других IDE со встроенной поддержкой баз, возникала путаница с тем, к какому источнику данных привязан файл. Если запросы, скажем, из java-класса, использовали неквалифицированные объекты, IntelliJ IDEA сама пыталась догадаться, в какой базе они выполняются. Среде можно было помочь во вкладке Resolve Unqualified References. Но если в источнике данных были объекты с одинаковыми именами в разных схемах, эту проблему решить было нельзя.







Стало проще: любой файл или папку можно явно привязать к одному или нескольким источникам данных или даже к отдельным схемам. Делается это в Settings -> Database -> SQL resolution scopes. В результате, неквалифицированные объекты базы данных из ваших запросов будут восприниматься, как объекты из указанного источника. То есть, будут работать, автодополнение и навигация.



UI для создания баз и схем



В прошлый раз нас просили это сделать — готово! В новом окне генерируется простой SQL.







Укажите, хотите ли вы видеть созданные схемы и базы в дереве немедленно. Эта опция также работает для создания схем и баз прямо из консоли.







NB! DataGrip до сих пор не поддерживает нескольких баз в PostgreSQL для одного источника данных. Поэтому созданные новые базы в дереве не появятся — для работы с ними создайте отдельный источник данных. Но мы начали работу над этим.



Настройки цвета



Color settings в контекстном меню источника данных были и раньше (знали о них? :), но теперь цвет можно применить и к фону консоли, и к таблице результатов запроса. Надеюсь, это поможет не запускать тестовые скрипты на живой базе.







Импорт и экспорт данных



Экспорт таблиц и результатов



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







Создать новую таблицу в другой базе можно и из результатов запроса: добавили кнопку Export to database.







Улучшения в диалог импорта



Было много предложений по тому, как сделать импорт более гибким.



Укажите, в какую таблицу импортируете данные и отредактируйте скрипт её создания. Сопоставление колонок поможет понять, какие данные куда попадут. Для имён колонок работает автодополнение.







Консоль запросов



Путь поиска в PostgreSQL



Самое важное для пользователей PostgreSQL: теперь мы не забываем о пути поиска по умолчанию. Как и раньше, он настраивается в верхнем правом углу.







Триггеры



Добавили шаблон для генерации триггеров по Ctrl+N (Cmd+O для OSX).







Поддержали NEW/OLD и INSERTED/UPDATED для исходников триггеров.







Написание кода



Знакомая по другим IDE опция Settings -> Editor -> Appearance -> Show parameter name hints работает и в DataGrip: показывает имена колонок для предложений INSERT.







Новые настройки появились в Settings -> Editor -> Smart Keys.







Insert string concatenation on Enter отвечает за то, будут ли строки при переносе автоматически конкатенироваться. Раньше это работало по умолчанию и выглядело так:







В некоторых базах используются многострочные литералы и такое поведение было неудобным. Если снять галочку, перенос строк не будет ничего вставлять:







Опцию Qualify object in completion тоже просили. Кому-то удобно, чтобы объекты квалифицировались всегда, кого-то это раздражает даже при коллизиях — одни и те же скрипты будут запущены на разных базах, и люди не хотят в них ничего менять. Скажем, у нас есть две схемы — max и public, с такими таблицами:







Вот как будет вести себя IDE при параметре Qualify on collisions:







Именованные параметры дополняются второму нажатию Ctrl+Space. Вообще, во всех наших IDE это приводит к интересным результатам, попробуйте.







Дополнение по Ctrl+Space после простого SELECT вставляет алиас. В Settings -> Editor -> Code style -> SQL теперь можно настроить — использовать для него прописные или строчные буквы.







Ещё одна настройка из платформы работает для DataGrip. Settings -> Editor -> Appearance -> Show method separator будет рисовать линии между запросами.







В MySQL есть баги в грамматике при использовании UNION. Мы добавили забавную инспекцию, которая об этом предупредит.







Навигация к настройкам цветов и шрифтов



А это понадобится пользователям любой IDE на платформе IntelliJ — не ищите, где в дебрях настроек изменить цвет или шрифт. Действие Jump to colors and fonts в вездесущем меню по Ctrl+Shift+A (Cmd+Shift+A для OSX) отправит вас в настройку цвета того контекста, в котором стоит курсор.







Если контекстов несколько, выберите нужный. Здесь нам предлагают настроить цвет и отображение для запускаемого запроса (фиолетовая рамка) и цвет строчного литерала (зелёный). Предположим, нас волнует строчный литерал.







Готово! Можно менять цвет.







Разное



В панель статуса результатов запросы мы добавили время выполнения запроса и номера колонки и строки выделенной записи.







В окне Modify table детали колонки открываются по двойному клику, а не по одинарному.







Редактор исходников отлавливает, что объект изменился из DataGrip, и предупреждает об этом.







В окно информации для системных таблиц в PostgreSQL добавлена ссылка на документацию.







В поиске использований объектов можно исключить текстовые вхождения — комментарии, динамический SQL.







А ещё в новой версии:



— Предпросмотр для больших файлов в режиме «только для чтения».

— Windows-аутентификация в SQL Server для jTDS-драйвера.

— Поддержка CREATE/ALTER запроса в SQL Server 2016.

— TNS имена корректно считываются из файла tnsnames.ora в Oracle.

— Коммит запускает синхронизацию в PostgreSQL.

— Интроспектируется больше объектов в SQLite.

— Предупреждения появляются во вкладке Output сразу.

Zero-latency typing включена по умолчанию.

— Настройки цвета для регулярных выражений.



Вероятно, вы про это всё знаете, но тем не менее:



— Скачать бесплатную пробную версию здесь.

— У нас есть Твиттер и форум.

— О багах сообщайте трекер.



Вот и всё. Как всегда, продолжим в комментариях.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/325066/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] SQL или NoSQL — вот в чём вопрос

Понедельник, 27 Марта 2017 г. 14:15 (ссылка)

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



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



Нереляционные БД устроены иначе. Например, документо-ориентированные базы хранят информацию в виде иерархических структур данных. Речь может идти об объектах с произвольным набором атрибутов. То, что в реляционной БД будет разбито на несколько взаимосвязанных таблиц, в нереляционной может храниться в виде целостной сущности.



Внутреннее устройство различных систем управления базами данных влияет на особенности работы с ними. Например, нереляционные базы лучше поддаются масштабированию.







Какую технологию выбрать? Ответ на этот вопрос зависит от особенностей проекта, о котором идёт речь.



О выборе SQL-баз данных



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




  1. Необходимость соответствия базы данных требованиям ACID (Atomicity, Consistency, Isolation, Durability — атомарность, непротиворечивость, изолированность, долговечность). Это позволяет уменьшить вероятность неожиданного поведения системы и обеспечить целостность базы данных. Достигается подобное путём жёсткого определения того, как именно транзакции взаимодействуют с базой данных. Это отличается от подхода, используемого в NoSQL-базах, которые ставят во главу угла гибкость и скорость, а не 100% целостность данных.




  2. Данные, с которыми вы работаете, структурированы, при этом структура не подвержена частым изменением. Если ваша организация не находится в стадии экспоненциального роста, вероятно, не найдётся убедительных причин использовать БД, которая позволяет достаточно вольно обращаться с типами данных и нацелена на обработку огромных объёмов информации.




О выборе NoSQL-баз данных



Если есть подозрения, что база данных может стать узким местом некоего проекта, основанного на работе с большими объёмами информации, стоит посмотреть в сторону NoSQL-баз, которые позволяют то, чего не умеют реляционные БД.



Вот возможности, которые стали причиной популярности таких NoSQL баз данных, как MongoDB, CouchDB, Cassandra, HBase:




  1. Хранение больших объёмов неструктурированной информации. База данных NoSQL не накладывает ограничений на типы хранимых данных. Более того, при необходимости в процессе работы можно добавлять новые типы данных.




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




  3. Быстрая разработка. Если вы разрабатываете систему, используя agile-методы, применение реляционной БД способно замедлить работу. NoSQL базы данных не нуждаются в том же объёме подготовительных действий, которые обычно нужны для реляционных баз.




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



SQL и NoSQL



Начнём с некоторых ключевых концепций реляционных и нереляционных баз данных. Ниже показана база данных, содержащая сведения о взаимоотношениях людей. Вариант a — это бессхемная структура, построенная в виде графа, характерная для NoSQL-решений. Вариант b показывает, как те же данные можно представить в структурированном виде, типичном для SQL.



Два варианта представления данных



Бессхемность означает, что два документа в структуре данных NoSQL не должны иметь одинаковые поля и могут хранить данные разных типов. Вот, например, массив объектов, набор полей которых не совпадает.



var cars = [
{ Model: "BMW", Color: "Red", Manufactured: 2016 },
{ Model: "Mercedes", Type: "Coupe", Color: "Black", Manufactured: "1-1-2017" }
];


При реляционном подходе данные надо хранить в заранее спроектированной структуре, из которой эти данные потом можно извлекать. Например, используя оператор JOINпри выборке из двух таблиц:



SELECT Orders.OrderID, Customers.Name, Orders.Date
FROM Orders
INNER JOIN Customers
ON Orders.CustID = Customers.CustID


Как более продвинутый пример, для демонстрации того, когда SQL предпочтительнее NoSQL, рассмотрим особенности применения в NoSQL-базах алгоритмов уплотнения. Проблема заключается в том, что в некоторых NoSQL-базах (например, в CouchDB и HBase) постоянно приходится формировать так называемые sstables — строковые таблицы в формате ключ-значение, отсортированные по ключу. В такие таблицы, которые сохраняются на диск, данные попадают из таблиц, хранящихся в памяти, при их переполнении и в других ситуациях. При интенсивной работе с базой создание таблиц, со временем, приводит к тому, что подсистема ввода-вывода устройства хранения данных становится узким местом для операций чтения данных. Как результат, чтение в NoSQL-базе происходит медленнее, чем запись, что сводит на нет одно из главных преимуществ нереляционных баз данных. Именно для того, чтобы уменьшить этот эффект, системы NoSQL используют, в фоновом режиме, алгоритмы уплотнения данных, пытаясь объединить множество таблиц в одну. Но и сама по себе эта операция весьма ресурсоёмка, система работает под повышенной нагрузкой.



Масштабируемость



Одно из основных различий рассматриваемых технологий заключается в том, что NoSQL-базы лучше поддаются масштабированию. Например, в MongoDB имеется встроенная поддержка репликации и шардинга (горизонтального разделения данных) для обеспечения масштабируемости. Хотя масштабирование поддерживается и в SQL-базах, это требует гораздо больших затрат человеческих и аппаратных ресурсов.
































Тип хранилища данных

Сценарий использования

Пример

Рекомендации

Хранилище типа ключ-значение

Подходит для простых приложений, с одним типом объектов, в ситуациях, когда поиск объектов выполняют лишь по одному атрибуту.

Интерактивное обновление домашней страницы пользователя в Facebook.

Рекомендовано знакомство с технологией memcached.

Если приходится искать объекты по нескольким атрибутам, рассмотрите вариант перехода к хранилищу, ориентированному на документы.

Хранилище, ориентированное на документы

Подходит для хранения объектов различных типов.

Транспортное приложение, оперирующее данными о водителях и автомобилях, работая с которым надо искать объекты по разным полям, например — имя или дата рождения водителя, номер прав, транспортное средство, которым он владеет.

Подходит для приложений, в ходе работы с которыми допускается реализация принципа «согласованность в конечном счёте» с ограниченными атомарностью и изоляцией. Рекомендуется применять механизм кворумного чтения для обеспечения своевременной атомарной непротиворечивости.

Система хранения данных с расширяемыми записями

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

Приложения, похожие на eBay. Вертикальное и горизонтальное разделение данных для хранения информации клиентов.

Для упрощения разделения данных используются HBase или Hypertable.

Масштабируемая RDBMS

Использование семантики ACID освобождает программистов от необходимости работать на достаточно низком уровне, а именно, отвечать за блокировки и непротиворечивость данных, обрабатывать устаревшие данные, коллизии.

Приложения, которым не требуются обновления или слияния данных, охватывающие множество узлов.

Стоит обратить внимание на такие системы, как MySQL Cluster, VoltDB, Clustrix, ориентированные на улучшенное масштабирование.



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



Используя данные, полученные в ходе испытаний, авторы делают выводы о том, что SQL-базы с возможностью кластеризации показали многообещающие результаты производительности в расчёте на один узел, и, кроме того, обладают способностью масштабируемости, что даёт системам RDBMS преимущество перед NoSQL за счёт полного соответствия принципам ACID.



Индексация



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



И в SQL, и в NoSQL-базах индексы служат одной и той же цели — ускорить и оптимизировать извлечение данных. Но то, как именно они работают — различается из-за разных архитектур баз данных и особенностей хранения информации в базе. В то время, как SQL-индексы представлены в виде B-деревьев, которые отражают иерархическую структуру реляционных данных, в NoSQL базах данных они указывают на документы, или на части документов, между которыми, в основном, нет никаких отношений. Вот подробный материал на эту тему.



CRM-системы



CRM-приложения — это один из лучших примеров систем, для которых характерны огромные объёмы ежедневно обрабатываемых данных и очень большое количество транзакций. Все разработчики таких приложений используют и SQL, и NoSQL базы данных. И, хотя большая часть данных транзакций всё ещё хранится в SQL-базах, применение находят общедоступные системы класса DBaaS (data-base-as-a-service, база данных как сервис), наподобие AWS DynamoDB и Azure DocumentDB, в результате, серьёзная нагрузка по обработке данных может быть перенесена в облачные NoSQL-базы.



В то время, как использование подобных служб освобождает разработчика от решения задач по обслуживанию хранилищ, это, кроме того, область, где NoSQL базы применяются для того, для чего они, в основном, и были созданы, например, для глубинного анализа данных. Объёмы информации, хранимой в огромных CRM-системах финансовых и телекоммуникационных компаний, было бы практически невозможно проанализировать, используя инструменты вроде SAS или R. Это потребовало бы огромных аппаратных ресурсов.



Главное преимущество таких систем — использование неструктурированных данных, похожих на документы. Такие данные могут подаваться на вход статистических моделей, которые дают компаниям возможность выполнять различные виды анализа. CRM-приложения, кроме того, являются весьма удачным примером, в котором две системы баз данных выступают не конкурентами, а существуют в гармонии, играя каждая свою роль в большой архитектуре управления данными.



Итоги



Занимаясь поиском системы управления базами данных, можно выбрать одну технологию, а позже, уточнив требования, переключиться на что-то другое. Однако, разумное планирование позволит сэкономить немало времени и средств.



Вот признаки проектов, для которых идеально подойдут SQL-базы:




  • Имеются логические требования к данным, которые могут быть определены заранее.

  • Очень важна целостность данных.

  • Нужна основанная на устоявшихся стандартах, хорошо зарекомендовавшая себя технология, используя которую можно рассчитывать на большой опыт разработчиков и техническую поддержку.



А вот свойства проектов, для которых подойдёт что-то из сферы NoSQL:




  • Требования к данным нечёткие, неопределённые, или развивающиеся с развитием проекта.

  • Цель проекта может корректироваться со временем, при этом важна возможность немедленного начала разработки.

  • Одни из основных требований к базе данных — скорость обработки данных и масштабируемость.



В итоге хочется сказать, что в современном мире нет противостояния между реляционными и нереляционными базами данных. Вместо этого стоит говорить об их совместном использовании для решения задач, на которых та или иная технология показывает себя лучше всего. Кроме того, всё сильнее наблюдается интеграция этих технологий друг в друга. Например, Microsoft, Oracle и Teradata сейчас предлагают некоторые формы интеграции с Hadoop для подключения аналитических инструментов, основанных на SQL, к миру неструктурированных больших данных.



Уважаемые читатели, а вам приходилось выбирать системы управления базами данных для собственных проектов? Если да — поделитесь пожалуйста опытом, расскажите, что и почему вы в итоге выбрали.
Original source: habrahabr.ru.

https://habrahabr.ru/post/324936/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<базы данных - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda