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

К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.

Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.

English version is also available.

Подготовили перевод следующей части многосерийной статьи, где сравнивается функциональность Apache Kafka и RabbitMQ. В этой публикации речь идёт о семантике и гарантии доставки сообщений. Обращаем ваше внимание, что автор учитывал Кафку до версии 0.10 включительно, а в версии 0.11 появился exactly-once. Тем не менее, статья остаётся актуальной и полна полезных с практической точки зрения моментов.
Предыдущие части: первая, вторая.

Это третья статья в цикле full-stack dev о секретной жизни данных. Она посвящена сложному и длинному маршруту SMS: набор, сохранение, отправка, получение и отображение. Добавлю немного истории и контекст, чтобы разбавить перечень протоколов. Хотя текст довольно технический, всё довольно легко понять.

Первые две части цикла:

• Cetus, о распространении ошибок в предках электронных таблиц XVII века
• «Вниз по кроличьей норе», о безумно сложном поиске источника одного набора данных

Итак, начнём…

В данный момент инсталяция по данному мануалу работать не будет. Из за больших изменений API Kubemaster, в данный момент я готовлю новый цикл статей где будут рабочие версии мануалов
Первая из статей habr.com/ru/post/462473

Здравствуйте!

В данной публикации я хотел бы рассказать о кластере Kubernetes с высокой доступностью (HA).



Оглавление:

1. Вступление
2. Список используемого софта
3. Список и назначение хостов
4. Принцип работы и развертывания
5. Подготовка ОС к развертыванию. Установка docker, kubeadm, kubelet и kubectl
6. Подготовка конфигурационного скрипта
7. Создание etcd кластера
8. Инициализация мастера с помощью kubeadm
9. Настройка CIDR
10. Инициализация остальных мастернод
11. Настройка keepalived и виртуального IP
12. Добавление рабочих нод в кластер
13. Установка ingress-nginx
14. Дополнительно
    
    • Dashboard
    • Heapster
    
    

Привет, Хабр!

Летом в нашем ланитовском блоге мы делали подборку сериалов про ИТ (и хакеров), а теперь в преддверии Нового года пришло время полного метра. Такие «Топ-10 фильмов про ИТ» появляются примерно раз в год, и список там примерно один и тот же: «Хакеры» с Джоли, «Пароль «Рыба-меч» и «Матрица».

Кстати, о последней. При всем уважении к братьям сёстрам Вачовски и трилогии, мы таки не относили бы «Матрицу» к фильмам про айтишников или хакеров. То, что мистер Андерсон работает программистом, а вне работы немного хакерит, всё же не является сюжетной канвой фильма. Рискуем возобновить старый холивар, но «Матрица» — это таки киберпанк. Контраргументы приветствуются.

Так вот, про подборку. Мы решили предложить вам  фильмы посвежее. Под катом нет Джоли и знаменитой сцены из «Пароль „Рыба-меч“», но есть фильмы про ИТ, суперкомпьютеры, и информационную безопасность, большинство из которых выпущены в 2010–2018 годах.

Кадр из фильма «Апгрейд»

Ваш любимый питомец пишет на Go и получает больше вас, а вы ещё нет? Не теряйте времени… Такая мысль может родиться у читателя от обилия статей по Go. Некоторым даже компании предлагают переучиться на этот язык. И, если вы хоть раз задумывались освоить язык, то я хочу вас предостеречь. Вернее показать странные вещи, попробовать объяснить зачем они и потом вы уже сами сделаете вывод нужен ли вам Go.

Понедельник. Постановка задачи

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

— Да, милая, я тебя тоже люблю.
Пальцы автоматически нажимают хоткей отправки сообщения. Я тру уставшие глаза, в которые неизвестный злой волшебник насыпал песка. Уже почти сутки без сна, надо выделить себе 4 часа. Это — мой цикл. Пять, шесть, семь часов — для меня самоубийство, я встану уставшим, недовольным, а значит, неэффективным. Следующая цифра — восемь, но это слишком много. Так что только 4 часа сна.
Прогресс-бар, дергаясь, словно в конвульсиях, дополз до правой границы, уперся в нее и исчез.
Я привычно лезу в лог отправки сообщений. Отклонений, вроде, нет. Четыре слоя шифрования, для скольких… для где-то тридцати символов. Надо будет до конца недели закончить скрипт-анализатор, а то вручную просматривать… бред.

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

Содержание

• JIT-компиляция
• Секционирование
• Индексы
• Покрывающие индексы
• SP GiST
• Производительность
• WAL
• Бэкап и репликация
• Для DBA
• Параллельное выполнение
• Оптимизаторы
• Window-функции
• Изменения в полнотекстовом поиске
• Json(b) и полнотекст
• PL/* процедуры
• pgbench
• Улучшения PSQL

Привет, Хабр!

Мы решили собрать очередную встречу разработчиков, на этот раз поговорим о backend.

Когда: 21 июня, четверг, с 19:00.
Где: Москва, ул. Большая Полянка, д.2/10, стр. 1 (Corporate Innovations Hub).



Регистрация на событие открыта, подробности – под катом.

Пару недель назад вышел .NET Core 2.1 RC1. Это первая версия SDK, где есть фича под названием "Глобальные утилиты .NET Core" (".NET Core Global Tools"). Она дает простой способ создания кросс-платформенных консольных утилит.

Мы познакомимся с основами использования .NET Core Global Tools и кратко посмотрим, что внутри. А еще вы можете скачать .NET Core 2.1 SDK и попробовать написать собственный пример.

В прошлых статьях мы рассмотрели механизм индексирования PostgreSQL и интерфейс методов доступа, а также хеш-индексы, B-деревья, GiST, SP-GiST, GIN, RUM и BRIN. Нам осталось посмотреть на индексы Блума.

Bloom

Общая идея

Классический фильтр Блума — структура данных, позволяющая быстро проверить принадлежность элемента множеству. Фильтр очень компактен, но допускает ложные срабатывания: он имеет право ошибиться и счесть элемент принадлежащим множеству (false positive), но не имеет права сказать, что элемента нет в множестве, если на самом деле он там присутствует (false negative).

Фильтр представляет собой битовый массив (называемый также сигнатурой) длиной m бит, изначально заполненный нулями. Выбираются k различных хеш-функций, которые отображают любой элемент множества в k битов сигнатуры. Чтобы добавить элемент в множество, нужно установить в сигнатуре каждый из этих битов в единицу. Следовательно, если все соответствующие элементу биты установлены в единицу — элемент может присутствовать в множестве; если хотя бы один бит равен нулю — элемент точно отсутствует.

В случае индекса СУБД мы фактически имеем N отдельных фильтров, построенных для каждой индексной строки. Как правило, в индекс включаются несколько полей; значения этих полей и составляют множество элементов для каждой из строк.

Благодаря выбору размера сигнатуры m, можно находить компромисс между объемом индекса и вероятностью ложного срабатывания. Область применения Блум-индекса — большие, достаточно «широкие» таблицы, запросы к которым могут использовать фильтрацию по любым из полей. Этот метод доступа, как и BRIN, можно рассматривать как ускоритель последовательного сканирования: все найденные индексом совпадения необходимо перепроверять по таблице, но есть шанс вовсе не рассматривать значительную часть строк.

(В статье использованы примеры и пояснения из книги Nouveaulités de PostgreSQL 10. (с) Dalibo, перевод с французского Игоря Лёвшина, редактор Егор Рогов (оригинал). Примеры проверены, иногда изменены для большей наглядности)

Конечно, мы уже ждем не дождемся появления 11-й версии PostgreSQL. Но уже сейчас ясно, что некоторые довольно радикальные улучшения производительности появились уже в версии 10. Определенно есть смысл разобраться сначала с ними.

Производительность "десятки" улучшилась сразу в нескольких направлениях. В этой статье речь пойдет об ускорении за счет:

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

Мы начнем с параллелизма.

У многих достижений версии PostgreSQL 10 прописка в разделе Секционирование (Partitioning). И это справедливо: очевидно, что при переходе от 9.6 к 10 произошел мощный технологический скачок. В предыдущих версиях секции строили и управляли ими, теми средствами, что уже имелись: механизмом наследования со всеми его ограничениями и неудобствами.

В версии 10 перешли к более специализированным механизмам и более привычному (в том числе для пользователей Oracle, а с этим приходится считаться) синтаксису. Этот скачок при переходе от 10 к версии 11 должен был подкрепиться важными дополнениями, которые должны расширить функциональность и улучшить производительность операций, использующих секционирование. Но из итогов последнего комитфеста (он закончился 8 апреля) видно, что не все задуманное удалось довести до рабочего состояния, а значит не все попадет в версию 11.

К тому же последние пару лет параллельно велись разработки модуля pg_pathman в Postgres Professional. Некоторые важные возможности пересеклись, некоторые остались уникальны для PostgreSQL и pg_pathman (который работает с ванильной версией, то есть PostgreSQL 10 + pg_pathman дает уже вполне впечатляющую сумму функциональности). Об этом будет отдельная статья. Замечания, относящиеся к версии 11 и к pg_pathman для удобства выделены курсивом.

Эта статья представляет собой переработанные и дополненные фрагменты книжки Nouveaulités de PostgreSQL 10. (с) Dalibo, перевод с французского Игоря Лёвшина (оригинал). Примеры из книги проверены, иногда адаптированы и локализованы для большей наглядности.

Полнотекстовый поиск даёт возможность искать документы по текстовому содержимому. Такая необходимость может возникнуть, когда система содержит много текстовых сущностей, а пользователям требуется учитывать эти данные во время поиска. Мы столкнулись с подобной ситуацией при разработке решения для документооборота*. Данные системы хранятся в MS SQL Server или PostgreSQL, а гибкий атрибутивный поиск позволяет находить документы по различной мета-информации. Однако со временем этого стало недостаточно. Перед нами встала задача: научиться искать документы по текстовым свойствам и приложенным файлам.

Мы уже познакомились с механизмом индексирования PostgreSQL и с интерфейсом методов доступа, и рассмотрели хеш-индексы, B-деревья, индексы GiST и SP-GiST. А в этой части займемся индексом GIN.

GIN

— Джин?.. Джин — это, кажется, такой американский спиртной напиток?..
— Не напиток я, о пытливый отрок! — снова вспылил старичок, снова спохватился и снова взял себя в руки. — Не напиток я, а могущественный и неустрашимый дух, и нет в мире такого волшебства, которое было бы мне не по силам.

Лазарь Лагин, «Старик Хоттабыч».

Gin stands for Generalized Inverted Index and should be considered as a genie, not a drink.

README

Общая идея

GIN расшифровывается как Generalized Inverted Index — это так называемый обратный индекс. Он работает с типами данных, значения которых не являются атомарными, а состоят из элементов. При этом индексируются не сами значения, а отдельные элементы; каждый элемент ссылается на те значения, в которых он встречается.

Хорошая аналогия для этого метода — алфавитный указатель в конце книги, где для каждого термина приведен список страниц, где этот термин упоминается. Как и указатель в книге, индексный метод должен обеспечивать быстрый поиск проиндексированных элементов. Для этого они хранятся в виде уже знакомого нам B-дерева (для него используется другая, более простая, реализация, но в данном случае это несущественно). К каждому элементу привязан упорядоченный набор ссылок на строки таблицы, содержащие значения с этим элементом. Упорядоченность не принципиальна для выборки данных (порядок сортировки TID-ов не несет в себе особого смысла), но важна с точки зрения внутреннего устройства индекса.

Привет, Хабр! Такое понятие, как «Глубокое обучение», существует с 1986 года, когда его впервые употребила Рина Дехтер. Развитие технология получила в 2006 после выхода публикации Джеффри Хинтона об эффективном предобучении многослойной нейронной сети. Сегодня deep learning часто живет в связке с распознаванием речи, пониманием языка и компьютерным зрением. Под катом вы узнаете про использование алгоритмов глубокого обучения в SQL. Заглядывайте!

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

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

Сегодня я хочу рассказать о системе деплоя Octopus Deploy. На данный момент на Хабре есть всего одна вводная статья на эту тему, поэтому в своем материале я хочу расширить описание системы, подробнее рассказать о таких важных понятиях как «жизненные циклы» (lifecycles) и «каналы» (channels), а также о том, как мы внедрили и используем Octopus в своей работе.

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