Одним пятничным вечером несколько лет назад я получил задание от руководителя подготовить за выходные ТЗ на конкурс. Видимо, я слишком уж излучал радость от предстоящих выходных, и боссу просто было приятно занять их чем-то новым и интересным, как он считал – ведь до этого с техническими документами мне работать не доводилось. Сейчас уже не смогу припомнить, какая там была система, но точно какой-то мониторинг. Субботнее утро принесло разочарование. Миллионы ссылок, сотни статей одна другой информативнее. От одной аббревиатуры ГОСТ веяло скукой и пылью. Примерно так и началось мое знакомство с семейством ГОСТ 34 на автоматизированные системы. Под катом удобная памятка по этому самому ГОСТу, которая совершенно случайно когда-то повстречалась на просторах сети и помогла систематизировать данные в знатном ворохе документов.

Владимир Бородин (на «Хабре» dev1ant), системный администратор группы эксплуатации систем хранения данных в «Яндекс.Почте», знакомит со сложностями миграции крупного проекта с Oracle Database на PostgreSQL. Это — расшифровка доклада с конференции HighLoad++ 2016.

Всем привет! Меня зовут Вова, сегодня я буду рассказывать про базы данных «Яндекс.Почты».

Сначала несколько фактов, которые будут иметь значение в будущем. «Яндекс.Почта» — сервис достаточно старый: он был запущен в 2000 году, и потому мы накопили много legacy. У нас — как это принято и модно говорить — вполне себе highload-сервис, больше 10 миллионов пользователей в сутки, какие-то сотни миллионов всего. В бэкенд нам прилетает более 200 тысяч запросов в секунду в пике. Мы складываем более 150 миллионов писем в сутки, прошедших проверки на спам и вирусы. Суммарный объём писем за все 16 лет — больше 20 петабайт.

О чем пойдет речь? О том, как мы перевезли метаданные из Oracle в PostgreSQL. Метаданных там не петабайты — их чуть больше трехсот терабайт. В базы влетает более 250 тысяч запросов в секунду. Надо иметь в виду, что это маленькие OLTP-запросы, по большей части чтение (80%).

Это — не первая наша попытка избавиться от Oracle. В начале нулевых была попытка переехать на MySQL, она провалилась. В 2007 или 2008 была попытка написать что-то своё, она тоже провалилась. В обоих случаях был провал не столько по технически причинам, сколько по организационным.

Масштабирование базы данных через шардирование и партиционирование

Денис Иванов (2ГИС)

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

Немного расскажу о себе — я работаю в команде WebAPI в компании 2GIS, мы предоставляем API для организаций, у нас очень много разных данных, 8 стран, в которых мы работаем, 250 крупных городов, 50 тыс. населенных пунктов. У нас достаточно большая нагрузка — 25 млн. активных пользователей в месяц, и в среднем нагрузка около 2000 RPS идет на API. Все это располагается в трех датацентрах.

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

Все начиналось довольно обыденно… Зачитывался Рихтером и усиленно штудировал Шилдта. Думал, что буду заниматься разработкой под .NET, но судьба на первом месяце работы распорядилась иначе. Один из сотрудников неожиданно покинул проект и во вновь образовавшуюся дыру докинули свежего людского материала. Именно тогда и началось мое знакомство с SQL Server.

С тех пор прошло чуть меньше 6 лет и вспомнить можно многое…

Про бывшего клиента Джозефа из Англии, который переосмыслил жизнь, за время отпуска в Таиланде, и в моем скайпе стал подписываться Жозефиной. Про веселых соседей по офису, с которыми приходилось сидеть в одной комнате: один страдал от аллергии на свежий воздух, а другой маялся от неразделенной любви к С++ дополняя это аллергией на солнечный свет. Один раз по команде свыше пришлось на время стать Александром отцом двух детей, чтобы изображать из себя обросшего скилами сениора по JS.

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

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

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

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

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

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

Из практики бизнес-аналитика: как клиенты пытаются запустить проект без ТЗ, и что с этим делать?

1. «У нас очень маленький и простой проект»

Когда я умру, и черти придут тащить меня в ад, они начнут именно с этой фразы. С каждым шагом они будут рассказывать мне о том, как вспомнили о каком-то новом ерундовом функционале, который изначально подразумевался и всем очевиден…

Утечки данных происходят почти каждый день. Согласно индексу утечки данных, с 2013 года более 4,762,376,960 записей было утеряно или украдено.

Я хочу стать архитектором ПО:

Это хорошая цель для разработчика

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

Хм. Ну, тогда ты вовсе не хочешь стать архитектором ПО.

Конечно хочу! Я хочу быть тем человеком, который принимает все важные решения.

Это хорошо, но ты не перечислил важных решений. Ты перечислил решения, не играющие особой роли.

В смысле? База данных – это не важное решение? Знаешь, сколько мы денег тратим на них?

Скорее всего слишком много. И нет, база данных – это не одно из самых важных решений.

Как можно такое говорить? База данных находится в самом центре системы! Там собраны все данные, они сортируются, индексируются и к ним осуществляется доступ. Без нее не будет системы!

База данных это просто устройство ввода-вывода. Так получилось, что она предоставляет некоторые полезные инструменты для сортировки, запросов и отчетов, но все это – вспомогательные аспекты в рамках системной архитектуры.

Яндекс, как и любая другая большая интернет-компания, хранит много, а точнее очень много данных. Это и пользовательские данные из разных сервисов, и намайненные сайты, и промежуточные данные для расчёта погоды, и резервные копии баз данных. Стоимость хранения ($/ГБ) — один из важных показателей системы. В этой статье я хочу рассказать вам про один из методов, который позволил нам серьезно удешевить хранилище.

В 2015 году, как вы все помните, сильно вырос курс доллара. Точнее, расти-то он начал в конце 2014-го, но новые партии железа мы заказывали уже в 2015-м. Яндекс зарабатывает в рублях, и поэтому вместе с курсом выросла и стоимость железа для нас. Это заставило нас в очередной раз подумать о том, как сделать, чтобы в текущий кластер можно было положить больше данных. Мы такое, конечно, делаем регулярно, но в этот раз мотивация была особенно сильной.

Каждый сервер кластера предоставляет для нас следующие ресурсы: процессор, оперативную память, жёсткие диски и сеть. Сеть здесь — более сложное понятие, чем просто сетевая плата. Это ещё и вся инфраструктура внутри дата-центра, и связность между разными дата-центрами и точками обмена трафиком. В кластере для обеспечения надёжности применялась репликация, и суммарный объём кластера определялся исключительно через суммарную ёмкость жёстких дисков. Нужно было придумать, как обменять оставшиеся ресурсы на увеличение места. Кстати, если после поста у вас останутся вопросы, которые бы вы хотели обсудить лично, приходите на нашу встречу.

Многие компании используют ленточные архивы для долговременных бэкапов и резервного копирования самой важной информации. Понять их несложно: достаточно дешевый, простой и надёжный метод хранения данных, успешно используюшийся много лет — срок годности картриджа составляет 2-3 десятка лет, информации на него влезает много, потоковый бэкап пишется быстрей, чем на классические дисковые системы, иными словами: зачем что-то менять, если это тебя устраивает?

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

К счастью, мир не стоит на месте, технологии развиваются, и сегодня VTL (virtual tape library) уже догнали в стоимости владения ленточные архивы, многократно превосходя их по ряду других параметров. Давайте разберёмся, чем собирается крыть лента, и не пора ли переходить на дисковые библиотеки?

В 2008 году в списке рассылки pgsql-hackers началось обсуждение расширения по сбору статистики по запросам. Начиная с версии 8.4 расширение pg_stat_statements входит в состав постгреса и позволяет получать различную статистику о запросах, которые обрабатывает сервер.

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

Я расскажу, какие метрики по запросам собирает наш агент, как мы их группируем, визуализируем, так же расскажу о некоторых граблях, по которым мы прошли.

Целостность данных легко нарушить. Бывает так, что в поле price попадает значение 0 из-за ошибки в коде приложения (периодически всплывают новости, как в том или ином инет-магазине продавали товары по 0 долларов). Или бывает, что удалили юзера из таблицы, но какие-то данные о нем остались в других таблицах, и эти данные вылезли в каком-то интерфейсе.

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

1. Кастомный подтип через ключевое слово DOMAIN

В ходе реализации нового проекта заказчик часто задаёт вопрос о том, каким образом защищена внедряемая СУБД. Один из вероятных ответов (неправильный на мой взгляд): «БД находится во внутреннем периметре вычислительной сети и недоступна для злоумышленника». По статистике инсайдеры более опасны, так как у них есть возможность легитимно исследовать уязвимости в предоставленных сервисах.

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

Система энергоснабжения — одна из самых критических составляющих инженерной инфраструктуры дата-центра. Без электричества дата-центр за доли секунды может превратиться в бесполезное здание с грудой простаивающего ИТ-оборудования. Чтобы такого не случалось, дата-центр имеет на борту дизельные генераторы и источники бесперебойного питания.

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

Перевод поста Стивена Вольфрама (Stephen Wolfram) "Solomon Golomb (1932–2016)".
Выражаю огромную благодарность Полине Сологуб за помощь в переводе и подготовке публикации

---

Содержание

— Наиболее часто используемый математический алгоритм в истории
— Как я встретил Сола Голомба
— История Соломона Голомба
— Регистры сдвига
— Предыстория регистров сдвига
— Для чего нужны последовательности, генерируемые регистрами сдвига?
— Ну и где же эти регистры?
— Клеточные автоматы и регистры сдвига с нелинейной обратной связью
— Полиомино
— Остальная часть истории

---

Наиболее часто используемый математический алгоритм в истории

Октиллион. Миллиард миллиардов миллиардов. Это очень приблизительная оценка того, сколько раз мобильный телефон или другое устройство сгенерировало бит с помощью регистра сдвига с линейной обратной связью максимальной длины. Думаю, это самый используемый математический алгоритм в истории. Автор — Соломон Голомб, скончавшийся 1 мая, с которым мы были знакомы больше 35 лет.

Основой книги Соломона Голомба «Последовательности регистрового сдвига», опубликованной в 1967 году, были его работы 1950-х гг. А ее содержание живет в каждой из современных систем связи. Прочтите спецификации для 3G, LTE, Wi-Fi, Bluetooth или даже для GPS, — и вы найдете упоминания о многочленах, определяющих последовательности, генерируемые регистрами сдвига, которые эти системы используют для кодирования отправляемых ими данных. Соломон Голомб — человек, который создал эти многочлены.

Этот материал будет полезен в первую очередь тем, кто много занимался программированием и вдруг внезапно стал вынужден заниматься управлением проектами и людьми. С год назад я рассказал про наказания на конференции, а солнышки из Битрикса сделали текстовую версию для #habr. К сожалению, потеряв в точности, четкости и правильности акцентов. За год материала добавилось. В конце — чеклист для ленивых :)

Итак. Если вы не садист или моральный урод, а ваши сотрудники — не мазохисты, то сомневаюсь, что кому-то из вас наказания доставляют удовольствие. Мне — нет.

Господа! Только что на сайте Imagination Technologies вышло исправленное издание бесплатного учебника на русском языке «Цифровая схемотехника и архитектура компьютера» Дэвида Харриса и Сары Харрис (кстати, они не супруги и вообще не родственники – просто так совпало). Предыдущее издание этого учебника вышло год назад, пост о нем собрал 145,000 просмотров на Хабре, количество скачиваний с британского сайта вызвало у его британских админов подозрение, что их атакуют русские хакеры, а впоследствие команду переводчиков лично благодарили за учебник преподаватели МФТИ, МВТУ им. Баумана, харьковского ХНУРЭ и других университетов.



Книжка содержит «введение во все», доступное способному школьнику или младшему студенту, который после ее прочтения может спроектировать, написать на SystemVerilog или VHDL и реализовать на ПЛИС несложный, но при этом совершенно настоящий конвейерный процессор. Книга написана живым языком и для введения концепций, например конечных автоматов, использует примеры типа:

Полгода назад на моем проекте было примерно около 0% покрытие кода юнит-тестами. Простых классов было достаточно мало, создавать для них юнит-тесты было легко, но это было относительно бесполезно, так как на самом деле важные алгоритмы находились в сложных классах. А сложные, с точки зрения поведения, классы было трудно юнит-тестировать так как такие классы были завязаны на другие сложные классы и классы конфигурации. Создать объект сложного класса и тем более его протестировать юнит-тестами было невозможно.

Некоторое время назад я прочёл "Writing Testable Code" в Google Testing Blog .

Ключевая идея в статье заключается в том, что C++ код, пригодный для юнит-тестирования, пишется совсем не так, как привычный C++ код.

В IT-области существует множество мифов. «От спама можно отписаться», «Два антивируса лучше, чем один», «Серверные жёсткие диски должны быть только фирменными». При замене и расширении парка ЖД нужно учитывать немало нюансов и тонкостей, и без своих предубеждений здесь тоже не обошлось. Какие бывают ЖД для серверов, чем они отличаются, на что нужно обращать внимание, и должны ли они быть с логотипом производителя сервера — об этом читайте под катом.

Определение 1. Однородный контейнер – это такой контейнер, в котором хранятся объекты строго одного типа.

Определение 2. Неоднородный контейнер — это такой контейнер, в котором могут храниться объекты разного типа.

Определение 3. Статический контейнер — это контейнер, состав которого полностью определяется на этапе компиляции.

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

Определение 4. Динамический контейнер — это контейнер, состав которого частично или полностью определяется на этапе выполнения.

По такой классификации, очевидно, существуют четыре вида контейнеров:

1. Статические однородные

   
   
   Сможете придумать пример?

   Обычный массив — int[n].

   
   

2. Статические неоднородные

   
   
   Примеры?

   Наиболее яркий пример такого контейнера — это кортеж. В языке C++ он реализуется классом std::tuple<...>.

   
   

3. Динамические однородные

   
   
   Догадались?

   Правильно, std::vector<int>.

   
   

4. Динамические неоднородные

   
   

   Вот об этом виде контейнеров и пойдёт речь в данной статье.