Вступление и DDL – Data Definition Language (язык описания данных)

Часть первая — habrahabr.ru/post/255361

DML – Data Manipulation Language (язык манипулирования данными)

В первой части мы уже немного затронули язык DML, применяя почти весь набор его команд, за исключением команды MERGE.

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

Т.к. учебник посвящается широкому кругу читателей (не только программистам), то и объяснение, порой будет соответствующее, т.е. долгое и нудное. Это мое видение материала, которое в основном получено на практике в результате профессиональной деятельности.

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

Т.к. DML в диалекте БД MS SQL очень сильно связан с синтаксисом конструкции SELECT, то я начну рассказывать о DML именно с нее. На мой взгляд конструкция SELECT является самой главной конструкцией языка DML, т.к. за счет нее или ее частей осуществляется выборка необходимых данных из БД.

О чем данный учебник

Данный учебник представляет собой что-то типа «штампа моей памяти» по языку SQL (DDL, DML), т.е. это информация, которая накопилась по ходу профессиональной деятельности и постоянно хранится в моей голове. Это для меня достаточный минимум, который применяется при работе с базами данных наиболее часто. Если встает необходимость применять более полные конструкции SQL, то я обычно обращаюсь за помощью в библиотеку MSDN расположенную в интернет. На мой взгляд, удержать все в голове очень сложно, да и нет особой необходимости в этом. Но знать основные конструкции очень полезно, т.к. они применимы практически в таком же виде во многих реляционных базах данных, таких как Oracle, MySQL, Firebird. Отличия в основном состоят в типах данных, которые могут отличаться в деталях. Основных конструкций языка SQL не так много, и при постоянной практике они быстро запоминаются. Например, для создания объектов (таблиц, ограничений, индексов и т.п.) достаточно иметь под рукой текстовый редактор среды (IDE) для работы с базой данных, и нет надобности изучать визуальный инструментарий заточенный для работы с конкретным типом баз данных (MS SQL, Oracle, MySQL, Firebird, …). Это удобно и тем, что весь текст находится перед глазами, и не нужно бегать по многочисленным вкладкам для того чтобы создать, например, индекс или ограничение. При постоянной работе с базой данных, создать, изменить, а особенно пересоздать объект при помощи скриптов получается в разы быстрее, чем если это делать в визуальном режиме. Так же в скриптовом режиме (соответственно, при должной аккуратности), проще задавать и контролировать правила наименования объектов (мое субъективное мнение). К тому же скрипты удобно использовать в случае, когда изменения, делаемые в одной базе данных (например, тестовой), необходимо перенести в таком же виде в другую базу (продуктивную).

Предыдущие части

• Часть первая — habrahabr.ru/post/255361
• Часть вторая — habrahabr.ru/post/255523
• Часть третья — habrahabr.ru/post/255825
• Часть четвертая — habrahabr.ru/post/256045

В данной части мы рассмотрим

Здесь мы в общих чертах рассмотрим работу с операторами модификации данных:

• INSERT – вставка новых данных
• UPDATE – обновление данных
• DELETE – удаление данных
• SELECT … INTO … – сохранить результат запроса в новой таблице
• MERGE – слияние данных
• Использование конструкции OUTPUT
• TRUNCATE TABLE – DDL-операция для быстрой очистки таблицы

В самом конце вас ждут «Приложение 1 – бонус по оператору SELECT» и «Приложение 2 – OVER и аналитические функции», в которых будут показаны некоторые расширенные конструкции:

• PIVOT
• UNPIVOT
• GROUP BY ROLLUP
• GROUP BY GROUPING SETS
• использование приложения OVER

Операции модификации данных очень сильно связаны с конструкциями оператора SELECT, т.к. по сути выборка модифицируемых данных идет при помощи них. Поэтому для понимания данного материала, важное место имеет уверенное владение конструкциями оператора SELECT.

Предыдущие части

• Часть первая — habrahabr.ru/post/255361
• Часть вторая — habrahabr.ru/post/255523
• Часть третья — habrahabr.ru/post/255825

В данной части мы рассмотрим

Многотабличные запросы:

• Операции горизонтального соединения таблиц – JOIN
• Связь таблиц при помощи WHERE-условия
• Операции вертикального объединения результатов запросов – UNION

Работу с подзапросами:

• Подзапросы в блоках FROM, SELECT
• Подзапрос в конструкции APPLY
• Использование предложения WITH
• Подзапросы в блоке WHERE:
  
  • Групповое сравнение — ALL, ANY
  • Условие EXISTS
  • Условие IN

Предыдущие части

• Часть первая — habrahabr.ru/post/255361
• Часть вторая — habrahabr.ru/post/255523

О чем будет рассказано в этой части

В этой части мы познакомимся:

1. с выражением CASE, которое позволяет включить условные выражения в запрос;
2. с агрегатными функциями, которые позволяют получить разного рода итоги (агрегированные значения) рассчитанные на основании детальных данных, полученных оператором «SELECT … WHERE …»;
3. с предложением GROUP BY, которое в скупе с агрегатными функциями позволяет получить итоги по детальным данным в разрезе групп;
4. с предложением HAVING, которое позволяет произвести фильтрацию по сгруппированным данным.

Статический маршрут — первое, с чем сталкивается любой человек при изучении понятия маршрутизации IP пакетов. Считается, что это — наиболее простая тема из всех, в ней всё просто и очевидно. Я же постараюсь показать, что даже настолько примитивная технология может содержать в себе множество нюансов.

В чем отличие маршрута пакета от его пути?
Стандартный механизм маршрутизации пакетов в интернете — per hop behavior — то есть каждый узел в сети принимает решение куда ему отправить пакет на основе информации, полученной от протоколов динамической маршрутизации и статически указанных администраторами маршрутов.

Маршрут — это интерфейс, в который нам надо послать пакет для достижения какого то узла назначения и адрес следующего маршрутизатора (next-hop):

R1#sh ip rou | i 40.  
	 40.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O        40.0.0.0/31 [110/3] via 20.0.0.0, 00:01:54, FastEthernet0/0
O        40.1.1.1/32 [110/4] via 20.0.0.0, 00:00:05, FastEthernet0/0

Что такое путь? Путь — это список узлов, через которые прошел (пройдет) пакет:

 1  10.0.0.1  16.616 ms  16.270 ms  15.929 ms
 2  20.0.0.0  15.678 ms  15.157 ms  15.071 ms
 3  30.0.0.1  26.423 ms  26.081 ms  26.744 ms
 4  40.0.0.0  48.979 ms  48.674 ms  48.384 ms
 5  100.0.0.2  58.707 ms  58.773 ms  58.536 ms

Путь пакета можно посмотреть с помощью утилит tracert в OC Windows и traceroute в GNU/Linux и Unix-подобных системах. (другие команды, типа tracepath мы не рассматриваем).
Многие считают что этих утилит один и тот же принцип работы, но это не так. Давайте разберемся.

СДСМ-15. Про QoS. Теперь с возможностью Pull Request'ов.

И вот мы дошли до темы QoS.

Знаете почему только сейчас и почему это будет закрывающая статья всего курса СДСМ? Потому что QoS необычайно сложен. Сложнее всего, что было прежде в цикле.

Это не какой-то магический архиватор, который ловко сожмёт трафик на лету и пропихнёт ваш гигабит в стомегабитный аплинк. QoS это про то как пожертвовать чем-то ненужным, впихивая невпихуемое в рамки дозволенного.

QoS настолько опутан аурой шаманизма и недоступности, что все молодые (и не только) инженеры стараются тщательно игнорировать его существование, считая, что достаточно закидать проблемы деньгами, и бесконечно расширяя линки. Правда пока они не осознают, что при таком подходе их неизбежно ждёт провал. Или бизнес начнёт задавать неудобные вопросы, или возникнет масса проблем, почти не связанных с шириной канала, зато прямо зависящих от эффективности его использования. Ага, VoIP активно машет ручкой из-за кулис, а мультикастовый трафик ехидно поглаживает вас по спинке.

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

Что это такое — 12.10.0.1.10.0.1.23. Нет, это не ссылка на ветку MIB протокола SNMP. Сегодня мы поговорим об Enhanced IP (далее EnIP).

Если трезво смотреть на мир, то транспортная сеть состоит из кучи «костылей», чего только стоят такие технологии как nat (во всех его видах) или virtual links в ospf. Прочитав драфт rfc , посвященный EnIP, я понял, что это очередной костыль. Но честно говоря идея мне понравилась. Ну, начнем.

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

Этот топик является продолжением топика опубликованного здесь.

Топик касается редистрибуции маршрутов в OSPF из других протоколов маршрутизации, и рассматривает особенности использования Е1 и Е2 типов маршрутов. В этой части разговор пойдёт о том, как маршрутизатор выбирает маршруты, если оба из них одинаковые по типу, но отличаются метрикой редистрибуции, и ценой пути до ASBR.
Напомню топологию

У практически любого сетевого инженера, рано или поздно наступает момент в жизни когда в его сети появляются домены маршрутизации отличные от любимого OSPF, EIGRP или IS-IS. Чаще всего это связано со слиянием двух сетей, но иногда может быть связано с модернизацией или редизайном. Одним словом, необходимость делать редистрибуцию маршрутов из одного протокола маршрутизации в другой возникает не так уж и редко. В случае с OSPF, эти маршруты появляются в таблице маршрутизации под меткой E1 (External Type 1) и E2 (Externel Type 2) маршрутов. Обычно учебные материалы Cisco говорят о том, что основное отличие этих двух маршрутов заключается в том, что при расчете метрики для Е1 маршрута используется общая метрика для всего пути, а для Е2 маршрута только стоимость редистрибуции. Попытаемся разобраться, что это значит и как это работает.

В прошлый раз мы не оставили камня на камне при разборе MPLS. И это, пожалуй, хорошо.

Но до сих пор только призрачно прорисовывается применение его в реальной жизни. И это плохо.

Этой статьёй начнём исправлять ситуацию. Вообще же читателя ждёт череда из трёх статей: L3VPN, L2VPN, Traffic Engineering, где мы постараемся в полной мере рассказать, для чего нужен MPLS на практике.

Итак, linkmeup — уже больше не аутсорсинг по поддержке хоть и крупной, но единственной компании, мы — провайдер. Можно даже сказать федеральный провайдер, потому что наша оптика ведёт во все концы страны. И наши многочисленные клиенты хотят уже не только высокоскоростной доступ в Интернет, они хотят VPN.
Сегодня разберёмся, что придётся сделать на нашей сети (на которой уже меж тем настроен MPLS), чтобы удовлетворить эти необузданные аппетиты.

В этой короткой заметке я хочу рассказать о том, как подготовить тестовый стенд для работы с мультикастом.
Для меня самого эта задача была очень актуальной при подготовке девятого выпуска Сетей Для Самых Маленьких.
Хочется ведь не просто увидеть циферки в консоли, а посмотреть видео.

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

Поясняющее наглядное видео.



Для примера мы возьмём вот такую сеть:



Здесь R1 олицетворяет собой IP-сеть, редуцированную до одного узла — это в общем-то не имеет значения.
Главный вопрос: что будет на месте мультикастового сервера и клиента.

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

Однако сеть linkmeup выросла до размеров федерального оператора. Возможность управления трафиком и быстрого восстановления сервисов стали очень важным требованием в MPLS-сети.
Пора внедрять Traffic Engineering.

---

Зачем вообще может понадобиться инжиниринг трафика?

Долго ли коротко ли, но шестерни в очередной раз провернулись и linkmeup встал на ступень Tier 2. И несколько достаточной платёжоспособности энтерпрайзов проявили заинтересованность в организации связи между своими филиалами через сети linkmeup.

L3VPN, который мы рассмотрели в прошлом выпуске, покрывает собой огромное количество сценариев, необходимых большинству заказчиков. Огромное, но не все. Он позволяет осуществлять связь только на сетевом уровне и только для одного протокола — IP. Как быть с данными телеметрии, например, или трафиком от базовых станций, работающих через интерфейс E1? Существуют также сервисы, которые используют Ethernet, но тоже требуют связи на канальном уровне. Опять же ЦОДы между собой любят на языке L2 общаться.

Вот и нашим клиентам вынь да положь L2.

Традиционно раньше всё было просто: L2TP, PPTP да и всё по большому счёту. Ну в GRE ещё можно было спрятать Ethernet. Для всего прочего строили отдельные сети, вели выделенные линии ценою в танк (ежемесячно).

Однако в наш век конвергентных сетей, распределённых ЦОДов и международных компаний это не выход, и на рынок выплеснулось некоторое количество масштабируемых технологий випиэнирования на канальном уровне.

Мы же в этот раз сосредоточимся на MPLS L2VPN.

A forwarding entity always forwards packets in per-flow order to
zero, one or more of the forwarding entity’s own transmit interfaces
and never forwards a packet to the packet’s own receive interface.
Brian Petersen. Hardware Designed Network

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

А через 10 минут он закажет такси через приложение на телефоне, и ему не придётся даже брать с собой в дорогу наличку.

В аэропорту он купит кофе, расплатившись часами, сделает видеозвонок дочери в Берлин, а потом запустит кинцо онлайн, чтобы скоротать час до посадки.

За это время тысячи MPLS-меток будут навешаны и сняты, миллионы обращений к различным таблицам произойдут, базовые станции сотовых сетей передадут гигабайты данных, миллиарды пакетов больших и малых в виде электронов и фотонов со скоростью света понесутся в ЦОДы по всему миру.

Это ли не электрическая магия?

В своём вояже к QoS, теме обещанной многократно, мы сделаем ещё один съезд. На этот раз обратимся к жизни пакета в оборудовании связи. Вскроем этот синий ящик и распотрошим его.


Кликабельно и увеличабельно.

Сегодня:

1. Коротко о судьбе и пути пакета
2. Плоскости (они же плейны): Forwarding/Data, Control, Management
3. Кто как и зачем обрабатывает трафик
4. Типы чипов: от CPU до ASIC'ов
5. Аппаратная архитектура сетевого устройства
6. Путешествие длиною в жизнь

Как вы помните из прошлого выпуска провайдер linkmeup встал на ступень Tier 2. Но просто предоставлять услуги доступа в Интернет или L2/3VPN-ы (быть по сути трубой для трафика) Linkmeup не устраивает. Сейчас большим спросом пользуются услуги облачного хранения данных, поэтому linkmeup обзавелся несколькими собственными датацентрами, расположенные по экономическим соображениям в Рязани. В связи с этим перед нами встала новая задача — как связать датацентры между собой и предоставить клиентам доступ к корпоративным СХД, расположенные в наших автозалах? Ввиду того, что в core-network уже запущен MPLS, то наш выбор пал на EVPN/MPLS. Его и рассмотрим.

Статья про L3VPN получилась большой — ни много ни мало 130 000 символов.
Учитывая, что и её ещё не все дочитали, эту часть про доступ в Интернет мы вынесли в отдельную публикацию.
Это особенно важно, потому что в рунете, да и вообще в интернетах, нет доступного разбора этой темы.
Вполне вероятно, что вы сейчас читаете эксклюзивный материал.

Итак, есть оператор связи, который предоставляет своему клиенту L3VPN. Ни с того ни с сего, с бухты да барахты понадобился ему ещё и Интернет.
Самое очевидное решение — прокинуть ещё один кабель — в одном VPN, в другом Интернет.
Допустим, это сложно. Тогда можно поднять сабинтерфейс и передавать фотки вконтактике в отдельном VLAN'е.
Допустим, там сложный арендованный канал, где можно прокинуть только 1 VLAN или оборудование клиента не умеет VLAN (стоит обычный компьютер), что тогда?

Об этом следующие 36 000 букв вашей жизни.

Содержание выпуска

• NAT на CE
• VRF Aware NAT
• Common Services

Сеть нашей воображаемой компании linkmeup растёт. У неё есть уже магистральные линии в различных городах, клиентская база и отличный штат инженеров, выросших на цикле СДСМ.
Но всё им мало. Услуги ШПД — это хорошо и нужно, но есть ещё огромный потенциальный рынок корпоративных клиентов, которым нужен VPN.
Думали ребята над этим, ломали голову и пришли к выводу, что никак тут не обойтись без MPLS.

Если мультикаст был первой темой, которая требовала некоторого перестроения понимания IP-сетей, то, изучая MPLS, вам точно придётся забыть почти всё, что вы знали раньше — это особенный мир со своими правилами.



Сегодня в выпуске:

• Что такое MPLS
• Передача трафика в сети MPLS
• Терминология
• Распространение меток
• — Методы распространение меток
• — — — DU против DoD
• — — — Ordered Control против Independent Control
• — — — Liberal Label Retention Mode против Conservative Label Retention Mode
• — — — PHP
• — Протоколы распространения меток
• — — — LDP
• — — — — Практика
• — — — Применение чистого MPLS в связке с BGP
• — — — RSVP-TE
• — — — — Практика
• — ВиО
• — Полезные ссылки

А начнём мы с вопроса: «Что не так с IP?»

Долго ли коротко ли длилась история linkmeup, но компания росла, развивалась. Счёт маршрутизаторов уже на десятки, свои опто-волоконные линии, развитая сеть по городу. И было принято решение оформлять компанию, как провайдера и предоставлять услуги доступа в Интернет для сторонних в том числе организаций.
Сама по себе задача административная — лицензии там, поиск клиентской базы, реклама, поставить СОРМ.
Разумеется, с технической стороны тоже нужны приготовления — просчитать ресурсы, мощности, порты, подготовить политику QoS. Но всё это (за исключением QoS) — рутина.

Мы же хотим поговорить о другом — IBGP. Возможно, тема покажется вам несколько притянутой за уши, мол, внутренний BGP — прерогатива достаточно крупных провайдеров.
Однако это не так, сейчас iBGP задействуется в ентерпрайзах чуть ли не чаще, чем в провайдерах. С целью исключительно внутренней маршрутизации. Например, ради VPN — очень популярное приложение на базе BGP в корпоративной среде. К примеру, возможность организовать периметры, изолированные на L3, на уже используемой инфраструктуре очень ценна. А префиксов-то может быть каких-то полсотни, а то и десяток. Вовсе никакой не Full View, однако все равно удобно.

Возможно, к нашей сети Linkmeup это не имеет по-прежнему отношения, но обойти стороной такую концепцию будет совершенно непростительно. Поэтому предположим, что сеть достаточно велика, и у нас есть необходимость в BGP в ядре.

Сегодня обсудим

• Когда нужен IBGP
• В чём отличия от EBGP
• Route Reflector’ы
• Конфедерации
• Нерассмотренные в основной статье атрибуты BGP

Традиционное видео


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