В предыдущей части мы рассмотрели создание приложений для SharePoint Online при помощи встроенного инструмента NAPA. В данной статье мы дадим краткий обзор еще одного несложного способа — проекта O365 Cloud Business App (также известного в качестве LightSwitch для SharePoint).

В первой части мы кратко рассмотрели основные возможности SQL Server по in-memory обработке применительно к аналитическим и транзакционным и приложениям, сконцентрировавшись на последних, поскольку in-memory OLTP (Hekaton) является наиболее существенным нововведением в SQL Server 2014. В данной статье мы продолжим обзор функциональности Гекатона на примере ранее созданной БД.

Функциональность In-Memory OLTP (проект Hekaton) призвана ускорить обработку типовых OLTP-операций в SQL Server. Как известно, нагрузку, приходящуюся на сервер баз данных, будь то Microsoft SQL Server или Oracle/MySQL или SAP/Sybase или IBM DB2 и т.д., можно условно разбить на два класса: сбор данных и анализ того, что собрали, потому что зачем в противном случае было собирать? Первый класс задач называется OLTP (On-Line Transactional Processing). Для него характерны короткие обновляющие транзакции, затрагивающие относительно небольшое число таблиц в базе. Примеры таких приложений — операционный день в банке, биллинг в телекоме и т.д. Второй класс задач называется OLAP (On-Line Analytical Processing) и характеризуется массивным длительным чтением, охватывающим значительное количество таблиц и собирающим из них, как правило, по максимуму записей, изобилующим предикатами связывания, сортировки, группирования, агрегатными функциями и т.д. Как правило, структуры данных для разных классов задач разделяют, чтобы не мешали друг другу, и если первая структура базы строится с учетом многочисленных правил Кодда, то вторая, напротив, денормализована и выполняется по схеме «звезда (снежинка)».
Устремление СУБД в память проявилось в начале нового тысячелетия, когда выяснилось, что несмотря на закон Мура тактовая частота и быстродействие процессоров растут отнюдь не по экспоненте, а наоборот, выходят на плоскую прямую насыщения невзирая на ILP и прочие ухищрения. В то же время цены на оперативную память, когда-то неприлично дорогую, катастрофически снижаются и по сравнению с 90-ми упали в тысячи раз. Ага, сказали себе производители серверов баз данных. В 2005-м Oracle прикупил in-memory СУБД TimesTen, IBM в 2007-м — компанию Solid, а в Microsoft в данном случае ничего со стороны брать не стали, потому что решили воспитать в своем коллективе.

Прочитать в SQL Server табличку из Excel… В самом деле, что может быть проще? Для этого существует масса возможностей. Есть инструмент Integration Services, который бывшие DTS, есть мастер импорта/экспорта, который «за сценой» то же самое, можно по-быстрому сваять собственное ADO.NET-приложение, наконец, если неохота стрелять из пушек по воробьям, можно воспользоваться механизмом прилинкованных серверов, известным, как DTS, еще со времен семерки, который позволяет легко и элегантно увидеть теоретически любой ODBC/OLE DB-достижимый источник в виде таблицы (совокупности таблиц) или результата непосредственного (ad hoc) запроса. Так было до тех пор, пока 64-битная архитектура не перестала быть чем-то из области hi end и пришла на ноутбуки разработчиков и пользователей. Обычный пользователь, наверное, все-таки вряд ли будет ставить себе сервер баз данных, но для разработчика отнюдь не экзотична ситуация, когда на одной х64-машине уживаются 64-битный SQL Server с 32-битным MS Office. В этом случае создание прилинкованного сервера на Excel или Access вызывает проблему, потому что драйвера для них, понятно, 32-битные, которые SQL Server, будучи 64-битным, не понимает. Нет у него в списке известных ему провайдеров ничего похожего, хотя офис со всеми прибамбасами, включая connectivity, на компе стоит.


Рис.1

Соответственно, попытка использовать прилинкованный сервер на Excel, как описано в документации, приводит к ошибке Msg 7302, Level 16, State 1, Line 1
Cannot create an instance of OLE DB provider «Microsoft.ACE.OLEDB.12.0» for linked server…
Возникает извечный вопрос «что делать»?

Настройка разработческого окружения SharePoint всегда была нетривиальным процессом. Для его упрощения можно использовать Office 365 Developer Site, который является идеальной средой разработчика, чтобы освоить работу с SharePoint, сократить время настройки и приступить к созданию, отладке, тестированию и развертыванию своих приложений без необходимости установки у себя дополнительного ПО.

Как правило, в публичном Облаке хранится обезличенная информация, а персонализируюшая часть — в частном. В связи с чем возникает вопрос — как скомбинировать обе части, чтобы по запросу пользователя выдать единый результат? Предположим, имеется таблица клиентов, поделенная вертикально. Обезличенные колонки отнесены в таблицу, расположенную в Windows Azure SQL Database, а колонки с чувствительной информацией (напр., ФИО) остались в локальном SQL Server. Нужно связать обе таблицы по ключу CustomerID. Поскольку они лежат в разных базах на разных серверах, использование SQL-оператора с JOIN не проходит. В качестве возможного решения мы рассмотрели в предыдущем материале сценарий, при котором связывание происходило на локальном SQL Server. Он выступал в качестве своеобразной точки входа для приложений, и облачный SQL Server был заведен на нем как прилинкованный. В этом материале мы рассмотрим случай, когда и локальный, и облачный серверы с точки зрения приложения равноправны, а объединение данных происходит непосредственно в нем, т.е. на уровне бизнес-логики.

В данной заметке нас будут интересовать в первую очередь, что нового дает новая версия Windows 8.1 с точки зрения ее развертывания в корпоративном секторе. Основные новшества здесь можно сгруппировать по следующим основным категориям. Это дальнейшее развитие популярной концепции BYOD (Bring Your Own Device), улучшения в безопасности, мобильном доступе, печати и графическом интерфейсе. Эти изменения достаточно значительны, поэтому Windows 8.1 правильнее называть не обновлением, а именно новым релизом.

На этот раз мы поговорим еще об одном улучшении, которое SQL Server 2014 предоставляет в плане создания резервных копий, а именно — о возможности их полноценного шифрования. Возможность защитить резервную копию паролем, чтобы с нее не могли восстановиться неположенные люди, существовала с незапамятных времен, и те, кто достаточно долго имеет дело с SQL Server, должны помнить опцию WITH PASSWORD для команды BACKUP. Однако этот способ не обеспечивал стойкую защиту, и, как отмечалось на mssqltips, Although this does add a level of security if someone really wants to crack the passwords they will find a way, so look for additional ways to secure your data. На практике для защиты резервных копий применялось появившееся в SQL Server 2008 TDE, т.е. база данных прозрачно шифровалась, прежде чем сделать из нее бэкап. Поэтому начиная с SQL Server 2012, параметры PASSWORD и MEDIAPASSWORD не используются при создании резервных копий. Восстановление резервных копий, созданных с применением пароля, остается возможным.
Тем не менее шифрование данных и шифрование резервных копий — это два разных по своему назначению сценария. Очевидно, что при отчуждении резервной копии правилом хорошего тона является ее защитить. Например, если мы переносим базу в другой ЦОД, чтобы исключить утечку в процессе передачи по каналам связи или еще как-либо. Однако шифрование влечет накладные расходы, и если база данных надежно хранится в локальном датацентре, зачем ее шифровать только для того, чтобы сделать бэкап? К счастью, в SQL Server 2014 это стали два независимых процесса. Аналогично шифрованию данных резервную копию можно зашифровать на основе сертификата или асимметричного ключа. Поддерживаются алгоритмы шифрования AES 128, AES 192, AES 256 и Triple DES.

Собственно, идея резервировать базу в Облако не нова. Эта функциональность появилась в ныне здравствующем SQL Server 2012 с выходом 21.01.2013 кумулятивного обновления №2 к Service Pack 1 (Build 11.0.3339.0). Мы разбирали ее в посте Создание резервной копии БД в Azure Storage. Поэтому я не буду повторять, что это очень удобная возможность, которая обеспечивает миграцию данных из on-premise SQL Server в облачный (IaaS) и наоборот, а также облегчает перенос базы между двумя разнесенными on-premise SQL Serverами, когда Облако выполняет роль хаба. До сих пор это могло делаться только из скрипта T-SQL. В версии 2014 СТР в этот процесс добавились две новые возможности. Во-первых, выполнять резервное копирование в Windows Azure теперь можно непосредственно из интерфейса SQL Server Management Studio и включать его на регулярной основе в автоматизированный план поддержки базы, и во-вторых, что немаловажно, осуществлять шифрование резервных копий с использованием сертификатов или асимметричных ключей на основе криптостойких алгоритмов защиты. Впрочем, обо всем по порядку.

Гибридное Облако является достаточно привлекательной моделью при внедрении облачных вычислений в информационные системы предприятий, поскольку этот подход сочетает преимущества публичного и частного облака. С одной стороны, достигаются возможности гибкого привлечения внешних ресурсов по мере надобности и сокращения инфраструктурных издержек, с другой — сохраняется полный контроль за данными и приложениями, которые предприятие не хочет отдавать наружу. Однако в подобном сценарии мы неизбежно сталкиваемся с задачей интеграции данных из различных источников. Предположим, имеется таблица клиентов, которую мы вертикально разбили на две части. Обезличенная часть была отнесена в публичное облако, а персонифицирующая клиентов информация осталась в локальной базе. Для целостной обработки внутри приложения необходимо снова соединить обе части по CustomerID. Возможны различные способы это сделать. Условно их можно разбить на две большие категории: объединение данных на уровне on-premise сервера БД, который в этом случае будет выступать единой точкой входа для доступа к локальным и удаленным данным, и внутри бизнес-логики. В этой статье будет рассмотрен первый подход.

На конференции PASS 2013 вице-президент Microsoft Квентин Кларк объявил о доступности 2-го предварительного выпуска Customer Technology Preview (СТР2) следующей версии сервера баз данных Microsoft SQL Server 2014.

Вещь, о которой я расскажу, ни в коем случае не используйте в рабочем окружении. Чтобы солнышко, как в анекдоте про программиста, всякий раз восходило на востоке, а садилось на западе, лучше вообще от греха подальше пропустить этот материал. В многообразном программном мире автор относится к той категории экстремальщиков, которым во чтобы то ни стало не терпится заглянуть в будущее и попробовать на себе предварительные версии программных продуктов, которые когда-нибудь — кто-то раньше, кто-то позже — станут нашим самым настоящим настоящим. Более того, я бы сказал, нашим всем :) Итак, сегодня в гостях Windows 8.1 Enterprise Preview, Visual Studio 2013 Ultimate Preview, Team Foundation Server 2013 Release Candidate и SQL Server 2014 Evaluation Edition CTP1. Сейчас это все предварительные версии, и, как все предварительные версии, они бесплатны.

В начале июня 2013 на конференции TechEd (Северная Америка) член технического совета Microsoft и ведущий специалист компании по разработке направления ALM Брайан Харри анонсировал Visual Studio 2013 и Team Foundation Server 2013 совместно с .Net Framework 4.5.1. Несколько недель спустя на конференции Build 2013 в Сан-Франциско было объявлено о доступности предварительных версий этих продуктов. Помимо многочисленных улучшений среды разработки, возможностей создания приложений для любых устройств на базе Windows, в том числе в системе Windows 8.1, веб-приложений и служб для локальных и облачных сред с использованием новых дополнений к Visual Studio и ASP.NET, которые упрощают веб-разработку для различных браузеров и устройств, гибкого управления портфелями проектов, взаимодействия в режиме реального времени, а также упрощения доступа к нужной информации прямо из редактора кода, Visual Studio 2013 является законченным инструментом для разработки, диагностики и отладки приложений в Облаке.

SQL Saturday – это бесплатный однодневный тренинг по технологиям Microsoft SQL Server, который проводится в различных странах силами международного сообщества профессиональных DBA и разработчиков под эгидой Professional Association for SQL Server (PASS). Участие в мероприятии — хорошая возможность не только познакомиться с технологическими новшествами, но и пообщаться с коллегами и экспертами в этой области. Традиционно в России докладчиками выступают активные участники Russian SQL Server User Group.
Список докладов пока верстается, однако предварительная регистрация уже открыта на странице мероприятия.

Под этой общей тематикой состоится очередной семинар Russian SQL Server User Group 9 октября в Microsoft Technology Center, Россия, Москва, ул. Лесная д.5, 6-й этаж.

В программе прозвучат доклады:

В данном примере мы разберем создание и выполнение типового задания MapReduce в облачной реализации Hadoop от Microsoft, которая носит название HDInsight.
В предыдущем примере мы создали 3-узловой кластер Hadoop и загрузили абстрактный журнал слабоструктурированного формата, который сейчас предстоит обработать. Журнал представляет собой в общем случае большой (в нашем конкретном примере маленький, но на принципиальную демонстрацию идеи это не влияет) текстовый файл, содержащий строки с признаками TRACE, DEBUG, INFO, WARN, ERROR, FATAL. Наша элементарная задача будет состоять в том, чтобы подсчитать количество строк с каждым признаком, т.е. сколько раз возникала ситуация WARN, сколько ERROR и т.д.

В предыдущих статьях по миграции в «облачный» SQL Server мы рассмотрели различные возможности передачи резервной копии базы в Облако. На всякий случай следует сразу напомнить, что речь идет о IaaS-подходе, т.е. развертывании SQL Server на виртуальной машине Windows Azure. Альтернативный PaaS-подход принципиально отличен, т.к. Windows Azure SQL Database (SQL Azure) не поддерживает функциональности в виде штатных команд T-SQL backup/restore. Также нет возможности отсоединять и присоединять файлы БД (detach/attach). Там следует применять другие методы, такие, как DAC, BCP, SSIS, SQL Azure Sync и т.д. В данной статье мы продолжаем обзор способов, относящихся к IaaS, и, коль скоро в нем нет проблемы сделать/поднять бэкап, основной рабочий момент состоит в том, чтобы оптимально передать резервную копию базы в Облако и обратно. В этом плане он ничем не отличается от загрузки или скачивания любого блоба в/из Azure Storage. Нами были рассмотрены использование Blob Service REST API (http://msdn.microsoft.com/en-us/library/dd135733.aspx), который является очень простым по своей идее, но достаточно кропотливым в реализации, поскольку требует аккуратно сформировать тело PUT-запроса. Упростить процесс позволяет обертка, предоставляемая Azure SDK (http://msdn.microsoft.com/en-us/library/dd179380.aspx), который имеет в своем составе готовые классы, инкапсулирующие подготовительную работу, которую требуется выполнять вручную в случае использования «сырого» REST API. Наконец, мы рассмотрели процесс передачи резервной копии на отдельном vhd-диске, который присоединяется к облачной виртуалке. С выходом Cumulative Update 2 к SQL Server 2012 SP1 этот процесс еще более упростился, т.к. теперь стало возможным создавать резервные копии базы непосредственно в Azure Storage с помощью штатных команд T-SQL и, соответственно, восстанавливаться с них. Вся не относящаяся к функциональности SQL Server служебная работа по передаче резервной копии в Облако встроена внутрь T-SQLных команд. От нас потребуется только иметь учетную запись хранения (Windows Azure Storage Account), которая будет использоваться для промежуточного хранения резервной копии.

HDInsight Services for Windows Azure — это сервис, позволяющий работать с кластером Apache Hadoop в Облаке, предоставляющий программную среду для операций управления, анализа и отчетности по Большим Данным.

Предыдущий способ переноса резервной копии базы с локального компьютера на виртуальную машину с SQL Server в Облаке использовал Azure Storage, который не является NTFS-видимым. Таким образом, перед восстановлением бэкап базы нужно было скопировать из Azure Storage на виртуальный диск, чтобы установленный на виртуалке SQL Server его увидел. В случае БД значительного объема это ведет к неоправданному расходу пространства в Azure Storage и, как следствие, к дополнительным затратам: сначала бэкап загружается в облачное хранилище, а затем копируется в vhd, который хранится там же. Чтобы избежать этих затрат, в этой статье мы рассмотрим иной способ. Локально будет создан отдельный vhd, на котором будет размещен бэкап базы. Затем vhd будет загружен в Azure Storage и приаттачен в качестве дополнительного диска облачной виртуалки. С него будет произведено восстановление резервной копии.

В предыдущем примере мы тренировались загружать файлы в Azure Storage при помощи REST API и залили туда бэкап базы данных AdventureWorks2012.
Остается скачать его в облачную виртуальную машину и восстановить на установленном в ней SQL Server. В этом плане работа с Azure Storage совершенно симметрична что со стороны on-premise клиента, что со стороны облачной виртуалки — они передают друг другу файлы через Azure Storage. Один туда закачивает, второй считывает.