Репликация и модели согласованности

Нашёл несколько замечательных материалов по теме.

Consistency Models and Protocols in Distributed System [ссылка] в блоге некоего Qing-а
А еще хорошие  статей Майкла Уиттекера (молод, но уже много написал): сборник Consistency in Distributed Systems [ссылка] и его блог [ссылка]

Всё, что нужно знать о распределенной обработке данных

Наткнулся на статью со смелым названием Distributed Data Processing 101 – The Only Guide You’ll Ever Need (ссылка). И знаете, автор не подкачал. Кратко пробежался по основным уровням обработки (сбор, хранение, обработка, безопасность, визуализация). И чуть-чуть об основных архитектурах - Каппа и Лямбда. Вполне себе неплохая отправная точка для новичка в теме.

И вообще, на 8bitmen.com много интересных статей об ИТ-архитектуре банков и др продвинутых в этом плане организаций

Смарт-контракты с нуля

Как научиться писать смарт-контракты на Solidity, не имея вообще никакого представления о предмете?

Начать можно с онлайн-компилятора, который называется Remix (remix.ethereum.org). Уроков по написанию контрактов на Solidity в этом компиляторе полно в интернете. Проблема только в том, что многие из них написаны для старой версии Remix (а иногда для старой версии Solidity). Руководство, использующее новую версию, можно найти здесь.

Документация по языку Solidity - по адресу solidity.readthedocs.io, введение с примерами самых простых контрактов - здесь.

Прямо как я

Учиться чему-то и вести онлайн-дневник о процессе обучения - хорошая идея, так делаю не только я. Вот пост некой Фло из Нью-Йорка Live notetaking as I learn about distributed computing
(ссылка). Человек разработал для себя некий план (плюс список литературы), который должен помочь в изучении распределённых вычислений. Есть, что позаимствовать.

Несколько хороших статей об блокчейне

Сравнение Ethereum и Bitcoin на blockgeeks.com - статья Bitcoin VS Ethereum: [The Ultimate Step-by-Step Comparison Guide] (ссылка). Много интересных деталей:

1. Основные даты в истории развития этих двух криптовалют
2. Краткое описание proof-of-stake (протокол Casper). Майнеры делают некоторую ставку (из своих средств) при попытке сформировать новый блок. Если именно этот блок будет включён в блокчейн - майнер получит награду, пропорционально своей ставке. Если же будет замечена какая-то мошенническая активность с его стороны- его монеты будут списаны
3. Пользователь в своей транзакции может сам указывать размер награды майнеру. Чем больше награда - тем быстрее транзакция попадёт в блок
4. В Эфире различные операции стоят по-разному в единицах газа - приведена таблица "цен"
5. Эфир, как и биткоин, начался со статьи. Статьи Виталика, разумеется 😊
6. Аргументы за и против увеличения размера блока. Этот спор расколол Биткоин (произошёл хардфорк) на Bitcoin (который не стал увеличивать размер блока, вместо этого включил технологию) SegWit и Bitcoin Cash (без SegWit, размер блока стал 8 MБ).
7. В Эфире нет максимального размера блока, есть предел газа. Можно добавлять транзакции в блок, пока суммарное количество нужного для этих транзакций газа не превысит порогового значения.

Матричные часы

Про такие часы пишут куда меньше, чем про скалярные и векторные часы. А ведь у них даже и практические применения есть. 

Если у процесса Pi есть матричные часы Mi, то мы можем сказать, что Mi[j][k] - это представление i-го процесса о том, что знает j-й процесс про локальное время k-го процесса.

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

Допустим процесс номер 2 хочет переслать процессу номер 5 первые 30 записей из лога процесса 10. Сначала этот процесс посмотрит на соответствующую компоненту своих матричных часов M2[5][10]. Пусть M2[5][10] =23. Это означает, что по сведениям процесса 2 процесс 5 получил первые 23 записи из лога процесса 10. Значит, имеет смысл 2му процессу выслать 5му записи из лога 10го с 24й до 30й. Итог - экономия на пересылках.

Скрытые каналы

Что, если компоненты системы шлют сообщения по разным каналам? Отслеживать причинно-следственные связи станет очень сложно. Нечто подобное было в знаменитой статье Лэмпорта про время, часы и упорядочивание событий. Там люди кроме посылки сообщений ещё и по телефону говорили.

В науке это называется скрытые каналы (hidden channels). Пара примеров таких каналов есть в книге Distributed Systems for System Architects на стр 54 (есть на гугло-книгах, ссылка).

Книги по распределённым системам

Захотелось составить список литературы по распределенным системам. Сегодня книги.

A. S. Tanenbaum, M. van Steen Distributed Systems: Principles and Paradigms 

G. Coulouris et al  Distributed Systems: Concepts and Design

S. Ghosh Distributed Systems: An Algorithmic Approach

A.D. Kshemkalyani, M. Singhal Distributed Computing: Principles, Algorithms, and Systems

N. A. Lynch Distributed Algorithms 

G. Tel Introduction to Distributed Algorithms  

R. Sharp Principles of Protocol Design

Пара блогов о распределенных системах

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

Блог Уиттекера [ссылка] - Single-Decree Paxos, Visualizing Linearizability, Lamport's Logical Clocks,  Two Generals and Time Machines, An Illustrated Proof of the CAP Theorem

Блог Маркуса Чиу [ссылка]  - о распределенных алгоритмах (плюс миллион статей на другие темы).

Блог compiosition.al - здесь интересная статья про алгоритм снимков распределенной системы Чанди-Лэмпорта  [ссылка]

Страница семинара по распределенным системах (посты пишут сами студенты) [ссылка]

Гибридный консенсус

Proof of Stake and the History of Distributed Consensus: Part 1, Nakamoto Consensus, Byzantine Fault Tolerance, Hybrid Consensus, Thunderella [ссылка]

Линеаризуемость (ссылки)

A beginner’s guide to Linearizability [ссылка]
What is “Linearizability”? [ссылка]

Интересное о распределённых системах

On FLP Impossibility [ссылка]
Jeff Hodges Notes on Distributed Systems for Young Bloods [ссылка]
Забудьте САР теорему как более не актуальную [ссылка]

Paxos (ссылки)

1. Byzantine faults, Paxos, and consensus [ссылка]
2. Paxos by example [ссылка] 
3. Understanding Paxos [ссылка]

Логические часы

Про логические часы пишут много, иногда попадаются интересные вещи. Вот, например, некий Стивен Ван Допре сделал реализацию скалярных часов на Питоне [ссылка]. А на coursehero можно почитать про различие между скалярными, матричными и векторными часами [ссылка] (правда, дан только ознакомительный фрагмент лекции).

А какую такую проблему решают матричные часы, которую не могут решить векторные, обсуждают на stackoverflow [ссылка] ? Насколько я понял, матричные часы дают возможность понять, какие обновления достигли всех узлов и, соответственно, информацию о них можно не хранить (сделать чистку).

Некоторые протоколы, которые помогают поддерживать причинно-следственный порядок сообщений в системе, можно найти по [ссылке].  Это протоколы Бирмана-Шипера-Стефенсона и Шипера-Эггли-Сандоза.

О протоколе Бирмана-Шипера-Стефенсона  (а также об алгоритмах синхронизации физических часов) хорошо написано в лекции Бибхаса Гошаля [ссылка]

А ещё мне очень понравились лекции Виджея Гарга [ссылка] - строгая математика, отношения, рефлексивность-транзитивность и всё такое прочее:)

Лекция Николы Драгони (итальянец, преподающий в каком-то датском университете) про логические часы [ссылка]. План его курса по распределённым системам (названия лекций, рекомендуемая литература) - по ссылке. Курс хорош. Сами лекции находятся в Гугле по запросу Nicola Dragoni <название лекции из плана> pdf.

Лекция Антонио Корради (ун. Болоньи) [ссылка] Очень много о групповой рассылке (мультикаст)

Fundamentals of Distributed Computing: A Practical Tour of Vector Clock Systems [ссылка]

Хорошая лекция о логическом (виртуальном) времени и глобальных состояниях Венкатасубраманиана [ссылка]

Обход невозможности записи в контейнерах SquashFS (Singularity)

Скачал тут контейнер RabbitMQ (имя образа rabbitmq.simg), пытаюсь запустить кроличий сервер - ан нет, ошибка could_not_write_file (не может писать в лог). Оказалось, что в этом котейнере используется SquashFS - файловая система, допускающая только чтение. 

Чтоб это обойти, используем образ - подложку (overlay). Создадим образ:
singularity image.create rmq-overlay.simg
Теперь будем запускать экземпляр контейнера RabbitMQ, подложив этот наш новый образ (в который писать можно):
singularity instance.start --overlay rmq-overlay.simg rabbitmq.simg rmq1
Здесь rmq1 - имя экземпляра.

После этого запускаем шелл внутри экземпляра
singularity shell instance://rmq1

Теперь вызов rabbitmq-server отрыбатывает нормально, сервер запускается.

Полезные ссылки: 

• Документация Singularity - страница про overlay [ссылка]
• Обсуждение на github.io про проблемы с контейнерами squashfs [ссылка]

Контейнеры Singularity

Говорят, эта технология скоро унасекомит Докер - якобы работают сингулярные контейнеры быстрее, и с безопасностью всё гораздо лучше. Не очень верится. Изначально Singularity затевался как контейнеры для высокопроизводительных вычислений. Будут ли пользователи из других сфер переходить на них - посмотрим.

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

Рассинхронизация часов

Интересное исследование скорости расхождения показаний часов в распределённых системах: Internal Clock Drift Estimation in Computer Clusters [ссылка]

Из интересного: в спутниках GPS используются атомные часы, поэтому с синхронизацией времени там попроще.

Пара интересных каналов на Youtube

Ken Shamir [ссылка] - распределенные системы, блокчейн, Neo, Ripple
Computerphile [ссылка] - всё на (компьютерном) свете - пакетное радио, большие данные, иск. интеллект, SSH изнутри. Масса всего интересного.

Исследуем elf-файлы

Если захотелось покопаться в бинарниках формата elf, нужно вооружиться тремя инструментами - readelf, nm, objdump. И почитать статьи: How is a binary executable organized? Let's explore it! [ссылка] (из блога одной канадской барышни) и Linux 101: Understanding the insides of your program [ссылка]. Подробнее об nm - в статье 10 Practical Linux nm Command Examples [ссылка] .

Живость и безопасность в распределённых системах

Нашел тут другую формулировку результата FLP (надо уже саму статью почитать наконец) - в полностью асинхронной системе невозможно создать алгоритм консенсуса, который одновременно гарантировал бы отказоустойчивость, живость и безопасность (liveness and safety). Поскольку отказоустойчивостью обычно стараются не жертвовать, выбор приходится делать между живостью и безопасностью. Ситуация очень похожа на ту, что мы видим в CAP-теореме.

Мне очень понравилось видео на эту тему профессора Гупты из Иллинойского университета [ссылка]. А на medium.com есть хорошая статья Safety and Liveness — Blockchain in the Point of View of FLP Impossibility [ссылка], где рассматриваются разные алгоритмы консенсуса.

Линеаризуемость

Это одна из самых строгих моделей согласованности. Кстати, под consistency в CAP-теореме подразумевается именно линеаризуемость.

Оказывается, есть популярное введение в эту тему: A beginner’s guide to Linearizability [ссылка]. Спасибо автору - Владу Михалчеа

Детекторы отказов в распределенных системах

Согласно теорем FLP консенсус невозможен в системах с асинхронными коммуникацией. Чандра и Туэг в статье  Unreliable failure detectors for reliable distributed systems показали, что ситуацию можно исправить за счёт добавления в распределённую систему специального сервиса - детектора отказов. 

С чего начать знакомство с этой темой? Книги по распределённым алгоритмам могут отпугнуть своими формулами и теоремами. Хочется чего-нибудь попроще.

Могу порекомендовать пост Failure Detection in Distributed Systems [ссылка] - довольно приятно и легко написано.

Страх и ненависть в распределённых системах

Очередная лекция  - обзор распределенных систем в целом (автор - Роман Гребенников). Получилось интересно и весело. Много о линеаризуемости, CAP-теореме. Код на Scala, тесты с помощью Jepsen. Видео и текстовая версия. Вот [ccылка].

Пассивная и активная репликация

Два основных подхода к отказоустойчивости при репликации - пассивный (primary-backup, подход с главной репликой) и активный (state machine, машина состояний - или конечный автомат?). В первом случае все обновления идут через главную реплику, они ретранслируются на вторичные реплики. При падении лидера, вторичные реплики выбирают нового. Во втором случае обновления могут идти на любую реплику. Для обеспечения согласованности реплики с помощью некоторого алгоритма консенсуса устанавливают общий порядок примененения обновлений.

Мне понравилось, как это всё изложено у Дермота Келли (из какого-то ирландского университета) в его курсе по параллельным и распределённым системам [ссылка на курс], [ссылка на лекцию об отказоустойчивости].

Покороче - в лекции Донгмана Ли [ссылка].

Португало-бразильский дуэт написал интересную статью об активном подходе [ссылка] под названием A Guided Tour on the Theory and Practice of State Machine Replication.

Некто Альваро Видела написал пост о моделях отказов [ссылка] процессов с выжимкой из  книги  Fault-Tolerant Real-Time Systems: The Problem of Replica Determinism. У него целый ряд постов по этой книге, надо почитать.

Лексемы, идентификаторы, литералы

Вот эти все термины хорошо объяснены в курсе С++ для 9 класса [ссылка]. Думаю, для других языков данные в тексте определения тоже подойдут.

Бессерверные вычисления

Чего?! Бессерверные?!! На пальцах, что ли?

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

PAXOS

блог Understanding Paxos [ссылка] - всего один пост, но зато написано замечательно
Кластеризация согласно консенсусу [ссылка] - описано несколько вариантов Паксоса, дан код

Двухфазная и трёхфазная фиксация

Шехар Джулати о 2PC [ссылка] - краткое описание, как выполняется требование атомарности, связь с CAP
Балрайа Суббиа о 2PC и 3PC [ссылка] - больше об различных видах отказов
Лекция Принстонского университета [ссылка] - отказоустойчивость, живость и безопасность, как это всё связано с 2PC, протокол Straw Man и атомарной фиксации
Разница между протоколами 2PC и X/Open XA [ссылка] - из документации NuoDB

B+ деревья

Элементарное введение на GeeksForGeeks [ссылка]

Хорошая статья с примерами [ссылка]

Лекция по древовидным индексам - университет Каролины [ссылка] - ISAM и B+деревья; картинки с коровами (?). Примечание: RID = row id, fanout - ветвление.

Коммуникации в распределённых системах

Французская лекция по групповым коммуникациям [ссылка]
Очень коротко по видам связей (упрямые, надежные) [ссылка]

LSM-деревья

SSтаблицы и LSM-деревья [ссылка] - статья Александра Межова

Владимир Кузнецов - о структурах данных в СУБД

Несколько видео Владимира Кузнецова на канале Сергея Немчинского
Про В-деревья [ссылка]; про LSM-деревья [ссылка]; про log-based [ссылка].

Алекс Петров (database internals)

Это такой совсем молодой парень из Мюнхена, который долго писал книгу Database internals и наконец написал. И её издал O'Reilly.

В поддержку книги он делал доклады на конференциях, писал статьи в интернете. Соответственно, часть его труда попала в открытый доступ. Даю ссылки:

Algorithms behind Modern Storage Systems [ссылка] - видеозапись доклада на конференции QCon2018 (размещена на Youtube канале InfoQ)

Блог Databasss на metium.com [ссылка] - B-деревья, LSM-деревья, немного о распределённых системах

Доказательство FLP

Оно было опубликовано в 1983 году в статье Impossibility of Distributed Consensus with One Faulty Process [ссылка]. 

В более доступной форме его можно найти в:

A Brief Tour of FLP Impossibility [ссылка] - статья

The FLP Proof [ссылка] - ролик на Youtube

Кстати, нашёл конспект лекций по распределенным алгоритмам знаменитой Нэнси Линч, одного из авторов FLP [ссылка]

История распределенных систем

Вводная лекция (Introduction to Distributed Systems) из курса Андреа Омичини [ссылка] - опирается на книгу Таненбаума

A Thorough Introduction to Distributed Systems - текст с DataCamp [ссылка]. Быстренько пробежались по HDFS, BitTorrent, blockchain.

Короткая вводная лекция из курса Г.Као [ссылка] - схематическая информация.

Статья The Evolution of Distributed Systems с DZone [ссылка] - виртуальные машины, Docker, Kubernetes

Заметки Аспнеса по теории распр систем

Обнаружил объёмистый труд за авторством Джеймса Аспнеса. Аж 484 страницы. Называется почему-то notes - заметки. Полное название Notes on Theory of Distributed Systems [ссылка], лежит на сайте Йеля.

Разбито на три части - передача сообщений, общая память и другие коммуникационные модели. Есть Паксос. Что ещё интереснее - кроме часов Лэмпорта есть часы Найгера-Туэга-Уэлша, которых я вообще нигде больше не встречал. Так что буду читать.

История СУБД

Небольшой текст A Timeline of Database History [ссылка]. В конце есть источники, можно пройти по гиперссылкам и найти побольше информации.

Реферат по истории СУБД [ссылка]

А вот статья History Of Databases [ссылка] на researchgate. Пока не читал.

СУБД с нуля

Некий товарищ решил разобраться, как работает СУБД, путём написания игрушечной копии SQLite. Получилось отличное руководство (с кодом), в котором раскрываются многие детали. Есть про B-деревья. Вот [ссылка] на оглавление.

B-деревья

Вот, кстати, еще про дендритов.

B-деревья -- одна из самых используемых в области СУБД структур данных. Применяется как для хранения таблиц, так и для индексов.

Статьи
R. Bayer, C. McReight Organization and maintenance of large ordered indices // Acta Inf. 1, 3 (1972), 173- 189 [ссылка] - похоже, оригинал 

D.Comer The Ubiquitous B-Tree [ссылка]  - разбор "для маленьких", есть про модификации B-деревьев

Видео на YouTube
B-Tree Indexes [ссылка] - коротенькое введение с картинками
File Systems 1: File Indexes with B-Trees [ссылка] - много примеров на вставку и удаление

Посты
How Database B-tree Indexing works [ссылка] - самое полезное из того, что я нашел; конкретно показано, как хранить таблицы и индекс в B-дереве

В-деревья в блоге stalinko[ссылка] - кратко об алгоритмах, небольшие примеры


Лекции
Лекция М.Курносова [ссылка] - очень обстоятельно о предмете

Indexing [ссылка] - лекция из курса Database Systems [ссылка на курс] университета Южной Калифорнии; про индексы вообще и B-tree индексы в частности

Лабораторная работа по B-деревьям [ссылка] - хорошие примеры на вставку, удаление

Студопедия про B-деревья [ссылка] - тоже есть примеры

Деревья

Я про структуру данных. Насколько же важны и разнообразны деревья в информатике! Сколько там разных интересных идей и алгоритмов.

На GeeksForGeeks есть отдельная категория статей про деревья. Вот [ссылка], например, текст о распечатке двоичного дерева (здесь его на бок кладут). А сбоку - ссылки на другие статьи о "древесных" алгоритмах. Читать - не перечитать.

Как СУБД хранят данные на диске

На канале InfoQ нашёл лекцию о двух структурах данных, которые используются в СУБД [ссылка на видео].

Первая - неизменяемая (immutable, данные только дописываются), называется log-structured merge-tree (LSM-tree). Попробую перевести как лог-структурированное дерево слияний. Или просто LSM-дерево. Используется в HBase, Cassandra. Докладчик сослался на статью The Log-Structured  Merge-Tree  (LSM-Tree)
[ссылка].

Вторая - изменяемая (mutable). Это знаменитые B-деревья. Ссылка на статью The Ubiquitous B-Tree [ссылка].

В конце приводится статья о гипотезе RUM. Это очередной треугольник типа CAP-теоремы. Рассматривается три параметра: количество чтений (R),  стоимость обновления (U) и накладные расходы по памяти (M). И дается утверждение: попытка оптимизировать любые два параметра приводит к ухудшению третьего параметра. Статья называется Designing Access Methods: The RUM Conjecture [ссылка]

Ссылки: браузеры и компиляторы

И те, и другие парсят программы, поэтому сваливаю их в один пост.

Как работают браузеры: принципы работы современных веб-браузеров (ссылка)
Краткий и бодрый обзор архитектуры компиляторов (ссылка)

Ставим Zookeeper и Kafka на Ubuntu

На эту тему есть масса информации в Интернете, но всё как-то не мог найти подхдящее описание - то слишком коротко, то вообще устаревшие сведения.

В итоге остановился на статье Zookeeper & Kafka Install с ресурса BogoToBogo.  Вполне себе доходчиво и наглядно.

А вот ещё хорошее руководство для начала работы с Кипером c DZone - Zookeeper primer.

Интересно, что везде Zookeeper рассматривается как основа для Kafka. Такое впечатление, что больше нигде Смотритель зоопарка и не применяется:)

Как обрушить программу на C++

Пытаемся выйти за пределы массива и получить segfault:
int *p = new int[3];
p[100] = 100;

Компилируем g++. Ничего не происходит. А все потому, что тут undefined behaviour, компилятор имеет право разбираться с проблемой как хочет. Вот тут об этом подробно (Accessing an array out of bounds gives no error, why?).

Делим на 0:
int x = 1/0;
Опять ничего! Программа компилируется, запускается.

Попробуем создать массив из минус одного элемента:
int *p = new int[-1];

Компилятор проглатывает без проблем. Но при запуске получаем исключение bad_alloc. Ура! Программа грохнулась!

std::set - как с ним работать?

Множество обладает свойством уникальности элементов. Как же там хранить какие-то сложные типы данных, как будут сравниваться элементы на равенство? Оказывается, в типе элементов просто нужно перегрузить оператор< . Вот простейший пример:

class mPair
{
        int x, y;
        public:
                mPair(int a, int b)
                {
                        x = a; y = b;
                }

                bool operator<(const mPair &p) const
                {
                        return x

                }
};

Оператор < обязательно должен быть оформлен именно таким образом - константный и с константным аргументом.

Кстати, вот статья с крайне подробным разбором std::set.

C/C++: лезем внутрь

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

• Постигаем Си глубже, используя ассемблер 
• C++ internals explained with assembly
• C++  tutorial - taste of assembly - 2018 

Выбор варианта перегруженной функции в С++

Сложная тема. Если на cppreference почитать - вообще страх. Но можно для начала почитать Resolving function overloads - хорошо рассказано, правда, в основном про случай одного аргумента.

Шаблонная функция в нешаблонном классе

Такую функцию сделать можно. Но если схема компиляции раздельная (описание класса -в .h, а определение методов - в .cpp), то нужны дополнительные телодвижения.

Как пишут на stackoverflow, в конце cpp-шника придется явно выписывать все необходимые конкретизации шаблонного метода.

И приводят вот такой пример:
// .h file
class Foo
{
public:
template void some_method(T t);
}

// .cpp file
//...
template void Foo::some_method(T t) 
{//...}
//...

template void Foo::some_method < int >(int);
template void Foo::some_method < double >(double);

Лекция: STL

Об STL рассказывать сложно. Перечислять контейнеры и алгоритмы? Скучно, да и все равно всего не охватишь. Можно так:

1. STL - часть std
2. контейнеры vector и list
3. требования к типу хранимого значения T (CopyConstructible, CopyAssignable)
4. параметр шаблона контейнера Allocator, значение по умолчанию - std::allocator
5. итераторы (iterator, reverse_iterator, const_iterator)
6. итератор - пример класса, описанного внутри класса
7. свойства итераторов у разных контейнеров (какие операции можно делать с ними, можно ли сравнивать и т.д.)
8. цикл по диапазону for_each; функтор
9. удаление по условию; remove_if; предикат

Как я уже писал, в 17х плюсах iterator считается устаревшим.  На cppreference.com он помечен как LegacyBidirectionalIterator. Информации по итераторам в STL в интернете как-то маловато. Мне больше всего понравилась статья на geeksforgeeks. 

STL в быстро меняющемся C++

Современное программирование на C++, как я понимаю - это интенсивное использование стандартной библиотеки. А STL - это часть этой самой стандартной библиотеки.

Контейнеры хороши тем, что с ними работать безопаснее, чем с указателями. А что там с эффективностью? Статья Do not waste time with STL vectors наглядно показывает, что push_back у vector - это весьма медленная операция (быстрее всего заполнять vector с помощью [] - как обычный массив). А вот инициализация вида

vector< int > v = {10, 23} 

появилась только в C++11.

Кстати, чтоб push_back работал побыстрее, можно перед заполнением зарезервировать память (reserve()). Но если при этом еще и в конструкторе вектора указать длину - программа повиснет...

Зато есть возможность проверки выхода за границу - используя at() вместо operator[] (как подсказывают здесь). Если происходит выход за диапазон - кидается исключение std::out_of_range (описано в < stdexcept >)

А в 17м C++ уже объявили std::iterator устаревшим. Подробнее - std::iterator is deprecated: Why, What It Was, and What to Use Instead

Вот так все быстро меняется...

Полиморфизм в C++

Все время путаюсь в разновидностях этого понятия, поэтому сделаю короткую запись. Ориентируюсь на этот пост.

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

Динамический полиморфизм (overriding) - какой конкретно метод будет вызван, станет известно во время выполнения.

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

Автор поста определяет понятие полиморфизма очень коротко: множество функций с одинаковым названием.

Ссылки: Docker

Полезные ссылки на  статьи по Докеру будут здесь.

Русскоязычное сообщество Docker
https://docker.crank.ru/
 Мне там, например, понравилась статья Управление данными в контейнерах  (volume и т.д.)

Полное практическое руководство по Docker
https://habr.com/ru/post/310460/

Ссылки: С++

В этом посте будет сборник полезных ссылок на материалы по C++

 C++ 11 FAQ от Бьярна Страуструпа. Очень хороший подробный обзор.
http://sergeyteplyakov.blogspot.com/2012/05/c-11-faq.html

The many faces of operator new in C++
https://eli.thegreenplace.net/2011/02/17/the-many-faces-of-operator-new-in-c

Алёна C++: Приведение типов в C++
http://alenacpp.blogspot.com/2005/08/c.html

7 Features of C++17 that will simplify your code (можно компилировать код прямо в тексте статьи; в 17м стандарте есть автоматическое выведение типов у шаблонов!)
https://www.codingame.com/playgrounds/2205/7-features-of-c17-that-will-simplify-your-code/introduction

С++ FAQ Lite (вообще не lite, размер порядочный)

http://www.parashift.com/c++-faq-lite/ 

Docker: работа с файлами

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

Запустим контейнер с Redis на основе Alpine:
docker run --name mredis -d redis:alpine

Флажок -d, кстати, означает detach -открепленный режим (без доступа к терминалу, по сути фоновый).

Запустим внутри контейнера командную оболочку ash (в Alpine нет bash, только sh и ash):
docker exec -it mredis /bin/ash

Флаги: -i - интеракт режим (stdin остается открытым, даже если к нему нет прикрепления), -t  - открыть псевдотерминал.

В терминале выполним:

echo "Hello world" > /home/test.txt

Файл /home/test.txt будет существовать внутри контейнера. После выхода из оболочки (командой exit) он продолжит существовать. Его можно скопировать на диск так:

docker exec -it mredis cat /home/test.txt  > HELLO.txt

Файл HELLO.txt будет размещен в текущей директории (из которой выполняем команды над контейнерами).

Redis-кластер в докерах

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

docker run --name xredis -d redis:alpine
docker run --name yredis -d redis:alpine
docker run --name zredis -d redis:alpine

IP_X=$(docker inspect --format '{{.NetworkSettings.IPAddress}}' xredis)

docker exec -it yredis redis-cli slaveof $IP_X 6379
docker exec -it zredis redis-cli slaveof $IP_X 6379

Грохнуть кластер (удалить все контейнеры) можно с помощью другого скрипта:

docker rm -f xredis
docker rm -f yredis
docker rm -f zredis

Singularity - Docker для суперкомпьютеров

На многопроцессорных машинах, где распределением нагрузки по узлам занимается планировщик, используют специальные контейнерные решения. Одним из них является Singularity. В статье Singularity : a "Docker" for HPC environments  перечисляются преимущества этой платформой - безопасность, переносимость и т.д. В комментариях один пользователь перечислил другие средства для работы с контейнерами на суперкомпьютерах (UNIVA и что-то Майкрософтовское). А быстрый старт по Singularity можно почитать здесь . 

Сети контейнеров Docker

Оказалось, что флаг --link - это устаревший способ соединения контейнеров. Теперь это можно делать с помощью сети.

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

Посмотреть состояние сети (в т.ч. информацию по каждому контейнеру):

docker network inspect bridge

Выдрать ip-адрес контейнера yredis и сохранить в переменную IP_Y:
IP_Y=$(docker inspect --format '{{.NetworkSettings.IPAddress}}' yredis)

Изнутри контейнера xredis запустить консоль redis-cli, которую присоединить к экземпляру Redis, который крутится в контейнере yredis:
docker exec -it xredis redis-cli -h $IP_Y

Очевидно, про --link можно забыть. Если контейнеров хотя бы 5 штук - уже вручную их не увяжешь. А к bridge контейнеры присоединяются вручную.

ПО в докерах

Буду кидать сюда ссылки на полезные материалы по работе с различным ПО в контейнерах

Hadoop
Some tips to run a multi-node Hadoop in Docker

Zookeeper
страница образа на DockerHub

MySQL

Basic Steps for MySQL Server Deployment with Docker
More Topics on Deploying MySQL Server with Docker

Соединение контейнеров Docker

Соединить два контейнера оказалось не так и сложно. Запустим первый контейнер под именем mredis: 

docker run --name mredis -d redis:alpine

Запустим другой под именем yredis. Присоединим его к контейнеру mredis, который будет хостом под тем же именем (поэтому mredis:mredis после link): 

docker run -d --name yredis --link=mredis:mredis redis:alpine

Теперь изнутри yredis я могу запустить консоль Redis, которую подключу к хосту mredis:

docker exec -it yredis redis-cli -h mredis

А как соединить несколько контейнеров? На stackoverflow пишут, что вот так:

docker run -d --link node1:node1 --link node2:node2 --link node3:node3 -p hostport:containerport your-image

Docker: первые шаги

Занялся я тут всеми этими докерами-шмокерами. Ну, в целом, не так уж все и сложно. Хотим, допустим, с Redis поиграться. Пишем

docker run --name mredis -p 6379:6379 -d redis:alpine





Поясню: run - запустить контейнер из образа redis:alpine (т.е. редис на основе Alpine - всего 5 Мб; если на локальной машине такого образа нет - он будет стянут с DockerHub), имя контейнера будет mredis, открываем порт контейнера 6379, который прикрепим к порту нашего сервера 6379). Флаг -d говорит, что контейнер запустится в фоновом режиме.

Теперь нужно поработать с Redis, т.е. нужно запустить консоль redis-cli. Делается это изнутри запущенного контейнера:

docker exec -it mredis redis-cli



Ну, и еще пару мелочей. Остановить контейнер:

docker stop mredis

удалить контейнер:

docker rm mredis

посмотреть запущенные контейнеры

docker ps

посмотреть все (в т.ч. остановленные) контейнеры

docker ps -a



Очень интересно, как связать два контейнера. Скажем, в одном крутится СУБД, в другом - клиент. Это рассказано в статье How to Connect Docker Containers . Разберусь с этим потом.

На смену Hadoop идет Kubernetes

Столько разговору было про эти хадупы-шмадупы, и вот... В статье Is Hadoop Dead? How Kubernetes and Cloud-Native Could Displace Hadoop утверждается, что Хадуп потихоньку сдувается. Пик популярности пройден в 2015м.

Автор отмечает недостатки Хадупа:

• сложен в освоении
• много записей на диск
• обработка данных пакетная - поэтому неприменим для аналитики в реальном времени

Короче, нужно что-то еще. Apache Spark - скажет большинство. Но вот, оказывается, есть еще одна восходящая звезда - Kubernetes, менеджер контейнеров.

Чуть подробнее рассказано в статье Modern Big Data Pipelines over Kubernetes . Вкратце, там говорится, что людям мало стандартной инфраструктуры Hadoop ((Map/Reduce, YARN и HDFS) . Нужно, чтоб кластер умел работать с такими вещами как  Kafka, Spark и TensorFlow,  и такими СУБД как Cassandra, Elasticsearch и облачными хранилищами. Почему это невозможно с Хадупом - я пока не разобрался.

В статье также упоминаются serverless frameworks (Kubeless и OpenFaaS). Они легко разворачиваются без докеров, yaml и т.д. Т.е. уже и сервера не нужны?)) 

А еще говорится о Nuclio. Это платформа (тоже serverless) , которая использует Kubernetes вместо YARN, что позволяет работать с такими фреймворками как Spark ML, Presto, TensorFlow & Python. 

Интересно, конечно, но где гарантии, что все эти чудеса инженерии не окажутся очередными спиннерами?

Структура проекта и makefile

Понадобилось сделать хорошую прозрачную структуру проекта, чтоб не путаться. Нашел статью A Simple C++ Project Structure, где расписана типовая структура проекта. Исходные тексты держим в src, объектные файлы в build, тестовые в test, заголовочные файлы в include и т.д. Не очень понятно, это и есть full GNU C++ standard project? Мне и такой структуры хватит.  

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

                     all: library.cpp main.cpp

переменная $@ равна all, $< - это library.cpp, а $^ - это library.cpp main.cpp.

Сам makefile не выкладываю, он далек от идеала. Но принцип такой - компилируем исходники из src и tst в объектники, их отправляем в build. Затем все объектники собираем в бинарник, который отправляем в bin.

Конструктор копирования в C++

Конструктор копирования в классе MyClass будет выглядеть так:

           MyClass(const MyClass &arg)

Почему const? Потому что при копировании оригинал не должен меняться. Почему параметр по ссылке передается? А потому что, если по значению, то будет происходить копирование аргумента. Т.е. в функции, которая должна копировать происходит вызов функции копирования... Бесконечная рекурсия.

Конструктор копирования вызывается

1. При инициализации объекта
   MyClass a;
   MyClass b = a; //инициализация объекта b объектом a
2. При передачи объекта в функцию по значению (создается копия аргумента)
3. При возвращении по значению (создается временный объект)

(Про всё это хорошо написано в памятке C++ Notes: OOP: Copy Constructors)

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

MyClass make_obj()
{
            MyClass c;
            return c;
}

int main()
{
           MyClass a = make_obj()
 }

Конструктор копирования вызывается при создании временного объекта, возвращаемого из фунции и при инициализации объекта а. 

Но. Откомпилировав программу с помощью g++ и запустив, мы увидим, что конструктор копирования ни разу не вызывается! Чтоб в этом убедиться - вставим в конструктор отладочный вывод. 

Как же так? Компилятор оптимизирует? Но флаг -O0 не помог, всё по-прежнему.

Отгадка нашлась здесь.

man GCC-4.4.7:
-fno-elide-constructors
The C++ standard allows an implementation to omit creating a temporary which is only
used to initialize another object of the same type.

Т.е. все дело действительно в оптимизации, просто отключать ее нужно специальным флагом

База данных COD

COD (Crystallography Open DB) оказалась здоровенной - 54 Гб. Команда du -sh COD шуршала в районе 2 мин, чтоб выдать мне этот результат.

Полезные ссылки:
- как скачать COD;
- описание файлового формата  mmCIF (основной формат в COD);
- отличная презентация Big­Data Analytics in Materials Science на тему анализа подобных БД - постановки задач, ссылки на работы, список открытых химических и материаловедческих БД;
- полное описание формата файла cif ;
- примерчик изготовления простейшего cif-файла;
- подробное руководство A guide to CIF for authors.

Может быть, пригодится статья Crystal Structure of Graphite, Graphene and Silicon

О потоках данных

Пытаюсь вникнуть в тему, пока какие-то крупицы собираю по разным статьям. Вот, скажем, текст "Как построить IIoT архитектуру своими руками". На предприятии много датчиков, они передают информацию на шлюз (в его роли выступает Raspberry Pi). На шлюзе крутится брокер Mosquitto, который дальше будет гнать данные по MQTT. Кроме того, в системе участвует Apache NiFi - система управления потоками.

Overcomittment

Столкнулся с этим термином применительно к виртуальным машинам. Стал гуглить, нашел хорошее определение здесь


Вольный перевод первого абзаца:

Memory overcommit (или overcommitment) - это возможность гипервизора выделить виртуальным машинам (суммарно) больше памяти, чем имеется физически. Например, платформа виртуализации VMware ESX позволяет запустить 4 гостевые машины с 1 гигабайтом на каждую на сервере с 2 Гб оперативной памяти.

Большие научные базы данных

Где взять большие данные, вопрошают те, кто хочет заняться модным направлением Big Data. Банки и сотовые операторы не отдадут ведь накопленную информацию, это ж понятно. Эххх :(

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

Вот, например, Protein Data Bank (PDB). Содержит массу информации о структуре всяких белков. Насколько я знаю, там в районе 40 ГБ данных. Поиск по PDB можно делать на этой страничке.  Там в основном файлы в формате .cif. Информация о работе с этим форматом есть на mmcif.wwpdb.org. 

А еще есть Crystallography open database. Располагается здесь. Думаю, там не меньше данных собрано.

Pig и Hive

Давно хотел понять, в чем разница. Попалась хорошая статья на Хабре, где все разложено по полочкам. 

Выделю основное. В Hive запросы пишутся на HQL - аналоге SQL. Внутри проебразуются в MapReduce, за счет чего выборки должны шустро работать на кластере. Однако сложные запросы на языке HQL превращаются в нечто трудночитаемое, поэтому в этом случае есть смысл переходить на Pig.

В Pig более богатый язык запросов PigLatin (который, однако, имеет кое-что общее с SQL). Кроме того, предусмотрено несколько структур данных.

Про boid

Boid - это алгоритм симуляции стайного поведения (flocking behavior).

Каждый бойдик в стае придерживается трех основных принципов: 

1. Стая должна оставаться единым целым, для этого каждый участник движется в направлении к центру относительно ближайших соседей;
2. Бойды стараются не сталкиваться - движутся от соседа, если расстояние стало слишком маленьким;
3. Бойды стараются сделать свою скорость близкой к скоростям соседей.

Подробнее можно прочитать в разделе Flocking замечательной книги AI for Game Developers (полностью выложена в онлайн). 

Компилируем .cpp как С-программу

Вот тут есть хорошие примеры. Компилируем cpp файл как программу на С:
         gcc -x c your-file-name.cpp
Первый файл компилируем как C программу, второй - как программу на С++ (отменяем действие -x c с помощью -x none):
         gcc -x c your-filename.cpp -x none other-file-name.cpp

Leader lease и миграция схемы

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

Читаю, значит, интересный пост на eax.me : Колхозная реализация выбора лидера на Go и Consul . Там рассказана интересная идея по поводу организации лидерства среди реплик. Делается это с помощью записи в некое хранилище ключ-значение (здесь выбран Consul). Важным моментом является наличие compare and swap - чтоб при чтении одной и той же записи разными репликами не возникало бы состояния гонки.

Так вот, тут упоминается понятие leader lease. А не консенсус или выбор лидера. Полез искать этот самый лиз. Нашел в документации по CockroachDB. Здесь есть понятие leaseholder - реплика, которая координирует запросы на чтение и записи (обычно совпадает с репликой-лидером, выбранной Raft). Почему-то уменьшает количество вызовов RPC - в этом пока не разобрался. Есть статья про Аврору, где говорится, что в Cockroach запрос на чтение или запись направляется той реплике, у которой в данный момент временное лидерство (lease). Упоминание про lease встречается и в описании консенсуса в Consul.

Как пример ситуации, когда необходим этот самый лиз, в посте на eax упоминалась миграция схемы БД. Это что еще?! Неплохо объясняется в Вики.  Вкратце - это процесс изменения схемы БД. Она может меняться параллельно с разработкой ПО. И если развитие ПО контролируется системой контроля версий, то со схемой так не получится. Она поменяется, а наша программа не сможет найти в ней нужные столбцы. Конкретные советы, как делать миграции даются в статье "Миграция схемы данных без головной боли: идемпотентность и конвергентность для DDL-скриптов". Хм, идемпотентность и конвергентность? Сразу навевает мысли о CRDT, не так ли?

Новое о gdb

Вот интересно - как посмотреть значение константы, которая задана с помощью #define? Если просто сделать print CONST - отладчик скажет, что он никакого CONST не знает. Как быть? При компиляции gcc задать флаг не -g, а -g3. Тогда задефайненные константы можно будет распечатать.

Можно ли вызывать функции отлаживаемой программы в gdb? Можно, используя call. Это хорошо для отладочной печати - у нас сложная структура, пишем функцию распечатки, в отладчике вызываем эту функцию. Опять-таки, использовать задефайненные константы в качестве аргументов можно только если программа откомпилирована с -g3.

И совсем интересное. Есть переменная i - обычный индекс для цикла for. Пытаюсь что-нибудь про неё узнать: info address i. Мне пишут Symbol "i" is a variable with complex or multiple locations . Это как? Несколько мест расположений? У меня правда две i - локальная в main и локальная в show_arr. Может, это имеется ввиду.

Установка nginx

Почитал я хороший пост на eax.me про nginx и решил с ним поиграться. Хотя бы поставить на свою Ubuntu:)

У меня на сервере был запущен Apache - перед установкой nginx лучше его остановить:
sudo service apache2 stop

Далее - установка:
sudo apt-get install nginx

Запуск:
sudo service nginx start

Заходим на свой сервер через браузер - показывает страничку Apache. Это потому, что в /var/www остался файл index.html от Апача (говорят, он там даже после удаления Апача останется). Nginx кладет в ту же папку свой индекс, но с суффикосм nginx-ubuntu. Если его сделать index.html - браузер покажет ожидаемое "Welcome to nginx!"

При установке пользовался советами отсюда (необходимость остановки Апача перед установкой nginx) и отсюда (замена апачевского index.html). Там еще много информации, стоит почитать.

Забавы с нейросетями в R

Решил поиграться с нейросетями. Поставил себе R-вский пакет neuralnet. Хороший материал нашел - "neuralnet: Train and Test Neural Networks Using R". Как-то пока не очень идет - работает медленно даже на самом простом наборе данных - два массива x и y по 100 элементов в каждом, y=3x. При использовании первых 95 элементов в качестве тренировочных данных и значении порога 0.001 остальные элементы предсказываются с ошибкой в третьем знаке после запятой. При уменьшении порога вообще нет сходимости. Скрытые слои - по схеме (2,1).

Без нормализации данных вообще ничего не работает, это надо иметь ввиду.

Кстати, вот здесь пишут, что зачастую более простые (в плане вычислений) методы, типа support vector machines (SVMs), дают результаты не хуже, чем нейросети.

Docker для начинающих

Хорошие руководства по Docker:

• "Полное практическое руководство по Docker: с нуля до кластера на AWS",
• "A Beginner-Friendly Introduction to Containers, VMs and Docker".

Выглядит все очень даже просто. Хотя после чтения поста на eax.me "Зачем нужен Docker и практика работы с ним" понимаешь, что Докер - не хухры-мухры...

ЕЩЕ. Добавлю ссылку на пост Как я приручал Docker из Блога ленивого программиста (хороший блог, жаль, что заброшенный).

Машобуч - улов статей

Решил я погрузиться в пучины модного нынче machine learning. Полез, понятное дело, в Интернет. И нашел там массу всего интересного.

Вот, например - можно ли машинно обучаться с помощью SQL? Обычно-то используют R и Python. Но вот некто Адам Праут считает, что нужно начинать с SQL - "Building a Machine Learning Application? Start with SQL". Адам считает, что современный SQL неплохо параллелится. А сочетание распределенного SQL хранилища с очередью сообщений (типа Kafka) и исполнительного движка типа Spark - вообще огонь.

Кстати, плюсы и минусы Spark хорошо разобраны в статье "Apache Spark — достоинства, недостатки, пожелания".

Внимательного прочтения заслуживает статья "Modeling and simulation in the big data era".

Появление больших данных заставляет разрабатывать распределенные алгоритмы машобуча. Об этом - в статье "Distributed Machine Learning Is The Answer To Scalability And Computation Requirements".

Технические конференции

Поискал конференции об IT-технологиях (в Москве). Конференции есть, немало. Вот списочек найденного:

1. Конференция PGConf.Russia 2019 (Экономический ф-т МГУ, 4–6 февраля в 09:00) - о PostGres
2. Конференция «Технологии блокчейна 2019» 
3. С++ Russia

Во всех этих мероприятиях один жирный минус - огромные взносы за участие. На PGConf, например, от 10 тыс руб. Взнос на  конференцию о блокчейне даже смотреть страшно, выделю только ключевые слова - Hyperledger Fabric, Ethereum, Exonum, R3 Corda, Ripple, «Мастерчейн», Quorum. На С++ преподавателям и студентам дается хорошая скидка, получается около 6 тысяч. Судя по описанию, конференция просто шикарная, с большим разнообразием мероприятий.

Так что вот - накопи денежек и окунись в мир высоких технологий.

C++, тестирование: моки

Не так просто найти хороший материал по мокам и стабам (используются в юнит-тестировании). Либо что-то очень запутанное попадается, либо про Google Mock (а мне хочется посмотреть, как самому писать заглушки и объекты-имитации).

Наконец нашлось кое-что вразумительное. Статья Mock objects в блоге Clean C++. 

Моки в этой статье рассказываются на достаточно простом примере. Пусть имеется класс play_time, который показывает геймеру, сколько времени он просидел за игрой. Этот класс нужно протестировать - проверить, что он действительно показывает правильное время. Стратегия тут простая - запустили таймер в play_time, затем вызвали sleep() на несколько секунд, остановили таймер, прочитали время из play_time. 

Проблема в том, что тестировать таким образом неудобно. Придется ждать, пока закончится время сна. Таким образом, наш класс play_time зависит от функционала системы, и эту зависимость предлагается сделать явной. Для этой создается класс-интерфейс second_clock, 

экземпляр этого класса нужно будет передавать в конструктор play_time. В этом самом second_clock и будет спрятан ход времени.

Нормальные системные часы будут реализованы как класс system_clock, наследник клаcса second_clock. Для нормальной работы класса play_time в его конструктор нужно подсунуть именно system_clock.

А вот для тестирования создаются "поддельные" часы - класс mock_clock, которые тоже наследуются от second_clock (вот и появился мок). В подделке часы не тикают - их устанавливают вручную.

И схема тестирования теперь выглядит следующим образом. Создаем объект-таймер типа  play_time, в конструктор передаем часы-мок. Запускаем таймер, продвигаем "поддельные" часы вручную (просто делаем set_time), останавливаем таймер. Теперь можно проверять время. На этот раз обошлись без ожидания в течение реального промежутка времени.

В закладки: обзор по NoSQL

Попалась мне хорошая статья на портале jetinfo  Называется "СУБД NoSQL - сильные и слабые стороны".

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

Дальше в статье приводится хорошая иллюстрация CAP-теоремы (пример с сервисом напоминаний, где оператор записывает в блокнотик факты, о которых нужно напомнить пользователю в определенное время).

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

Виртуализация - основы

источник картинки: sputnik-georgia.com

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

Удобно сделать несколько виртуальных серверов, дав каждому свою роль - сервер БД, веб-сервер и т.д. Администрирование будет проще,  чем если у одного физического сервера будет несколько ролей.

Обо всём этом (и многом другом) написано в цикле статей Введение в виртуализацию (не первой свежести, конечно, 2012 год, но для новичка вполне подойдёт). Меня особенно обнадёжила фраза "Несмотря на кажущуюся сложность виртуальная машина (ВМ) представляет собой всего лишь папку с файлами". Стало не так страшно разбираться в этой теме.

И вот еще статья на Хабре, которая мне очень понравилась: Основные принципы виртуализации на пальцах. Примеры оптимизации расходов с помощью виртуализации, основные понятия темы, интересные факты (на 2015 год половина серверов в мире были виртуальными).

Трудная дорога в облака

Я решил освоить облачные технологии. Уже сейчас понятно, насколько это непросто - нужно проработать множество тем, в которых не разбираюсь (виртуализация, например).

Первый вопрос, который встал передо мной - что выбрать, OpenStack или OpenNebula. И он решился буквально за полчаса гугления. OpenStack точно изучать не буду в ближайшем будущем. Слишком много отрицательных отзывов. Достаточно проглядеть названия текстов: Боль и страдания OpenStack (на Хакере), OpenStack или как не стоит делать проекты (видео лекции Бориса Павловича), Итак, вы решили развернуть OpenStack (статья на Хабре; в названии никакого негатива нет, но сам автор характеризует свой текст как "пост ненависти к OpenStack"). 

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

В общем, решил я остановиться на OpenNebula. Тоже open, тоже бесплатная платформа, но вроде бы попроще и попонятнее. Начну, пожалуй со статьи на Вике МГТУ им. Баумана.

Кстати, где-то там в недрах OpenNebula используется алгоритм консенсуса Raft. Об этом можно прочитать в посте Романа Богачева.