Size: a a a

Господин Архитектор

2017 February 27
Господин Архитектор
Про сообщение по теме тулинга я не забыл. Однако оно требует примеров и иллюстраций, поэтому затянулось — но будет, просто позднее.

А пока выдам небольшую тележку про RDBMS. В последнее время распространилось большое веяние, что RDBMS это зло, и вообще всем пора переползать на NoSQL. Только случится это нескоро, а кормит нас всех часто всё-таки легаси и энтерпрайз. Кроме того, моё личное мнение, что про NoSQL обычно говорят в таком акцепте:

- Do you know SQL Databases?
- No
- Ok, I see you're master at NoSQL Database.

Между тем, знание хотя бы поверхностное устройства RDBMS сильно упрощает жизнь и повышает качество всей той бороды, которую вы зачем-то называете SQL Data Access Layer. А может, вам и самим придётся писать storage, принципы устройства никуда не меняются.

Итак, из чего состоит типовая RDBMS. Из 4х частей:

1. Обработчик запросов на подключение от клиента. Назовём этот модуль Request Servant. Это он отвечает за то, чтобы клиентская библиотека успешно преодолела все трудности, связанные с удалённым доступом, получила соединение к БД, далее её запрос был принят "в руки" и отшедуллен на конкретного исполнителя внутри БД. Объём памяти и воркеров на подключения, пулы запросов, обрабатывать подключения в потоках или процессах, исполнять там же или передавать в отдельные воркеры — это всё настраивается здесь. Ошибки разного сетевого уровня, ошибки аутентификации, порты и соединения, пулы и высокая доступность, репликации и протоколы — всё вопросы сюда.

2. Планировщик запросов (Query planner). Отвечает за то, чтобы странслировать команду, которую вы направили, в набор примитивных операций, которым владеет данная СУБД, и вернуть вам результат. Здесь делается всё для того, чтобы ваш запрос распарсить, составить оптимальнейший план для него (или взять план из кеша), оценить его трудоёмкость десятками методов и обсчитать сотни тысяч вариантов (например, на основании статистики предыдущих запросов) и отправить на исполнение. Хитрые оптимизации, разные баги исполнения запросов — всё таится здесь. Кеш результатов запроса, кеш планов, стоимость операций — всё настраивается тут.
В этом месте фасеточные глаза разработчика открываются на всякие спецэффекты, типа, почему надо использовать именованные параметры СУБД, а не клеить запросы из строк (потому что кеш планов запросов засоряется, например).

3. Сегменты данных (Data segments). Это ваши данные, доступ к которым организует БД. Если брать примитивно, то сегмент данных — это огромный файл со строками, над которым построено некоторое количество деревьев с дублированием данных или без дублирования (т.н. представления и индексы) и гора семафоров/мьютексов, которая позволяет реализовать совместный доступ (да, не всё так уж и параллельно!). Ровно то, как вы себе представляете чтение и редактирование этого файла, так и устроена работа в БД, магии не существует. Тут настраивается объём этого файла, и какую часть надо его читать в память, сразу или по запросу, политику кеширования данных в памяти, расположение данных на носителях и т.п.
Поняли это — можете прикинуть стоимость операций доступа к данным, это 99% времени, которое тратится в запросе. Именно тут становится понятно, почему колоночные СУБД рулят на OLAP-задачах (подсказка: потому что данные по колонкам лежат рядом, поэтому типовая выборка 5 колонок из 50 будет требовать гораздо меньший объём IOPS).
источник
Господин Архитектор
4. Механизм организации целостности данных (Transactioning). В простейшем случае, это набор блокировок на чтение/запись. Кстати, из этого понимания следует, почему уровни изоляции именно такие, какие мы все помним (на самом деле, НЕ помним, чего уж там). Уровни изоляции это не таблица умножения, которую надо запомнить, они легко выводятся. Достаточно понять, на каком уровне захватывается блокировка, и когда она отпускается (сразу, по окончании оператора, по окончании транзакции). В более сложном случае (mvcc) присутствует ещё сегмент отката данных, который реализует оптимистические блокировки взамен честных для ускорения. Но это уже детали.
Знание подробностей позволяет писать запросы с минимальным количеством блокировок (= contention = сбоев конкурентного доступа к данным), и понимать, почему транзакция может быть убита и откатиться, даже если "в вакууме" делает всё по красоте.

Вот, собственно, и вся RDBMS до копейки. Похоже, после этого курса молодого бойца вы в одном шаге, чтобы написать свою РСУБД!
источник
2017 March 03
Господин Архитектор
источник
2017 March 09
Господин Архитектор
Есть такая тенденция у большинства тех, кто называет себя архитекторами:
- решение появляется раньше требований
- требования появляются раньше списка стейкхолдеров (интересантов)
- стейкхолдеры (интересанты) ограничивается заказчиком и, в редких случаях, пользователем.
Особенно это бывает заметно там же, где микросервисную архитектуру рисуют. Решение выдуманных проблем масштабирования "как в Инстаграмме" и так далее. Считаете, что выдумка? Попросите "архитектора" системы нарисовать и рассказать "о том, что важно в вашей системе". Попробуйте найти в рисунке интересантов, пользователей, требования. Скорее всего, будете неприятно удивлены.
Если всё это увидели — хватайте человека скорее, от него будет толк.
источник
2017 March 10
Господин Архитектор
По стартаповедению ничего лучше цикла "Антистартап" от А. Морейниса в жизни не читал. Хорошо зашло поверх "системной инженерии" А. Левенчука.
Почему я об этом пишу в чате про архитектуру? Потому что стартап это про стратегирование, а стратегирование — это инженерия требований к бизнес-альфе предприятия, даже такого маленького предприятия, как стартап
источник
2017 March 14
Господин Архитектор
Расскажу про интересную многим тему технических собеседований. Я чуть раньше писал, что прошу изобразить "всё важное", и жду, что в итоге получится. Почитайте. Кроме того, есть ещё и техническая часть. Техническая часть у меня на собеседовании не отличается разнообразием — всем я задаю одни и те же вопросы.

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

Если автор ещё и (божечки-кошечки!) утверждает, что он неплох в разработке кода (обычно managed, а то и нет), прошу рассказать про сборщик мусора в языке/рантайме, который ему известен лучше всех. Кейсы простые: два объекта ссылаются друг на друга; финализация и управление unmanaged-ресурсами. Иногда прошу нарисовать что-то на бумажке, изредка — несколько строк кода.

Кое-как обычно справляются 3-4 из 10, справляются на хорошо (т.е. если свои ошибки понял по наводящим вопросам) 1 из той же 10. Ответы на вопросы, как вы понимаете, напрямую ни на что не влияют — такие вопросы это предмет для раскручивания дискуссии и способ вручить микрофон автору, чтобы он сам себя "закопал".
источник
2017 March 15
Господин Архитектор
СУБД для кофейников
источник
Господин Архитектор
В ответ на вопрос засылаю хорошую книгу по устройству СУБД. Только посмотрите, кто там авторы!
источник
Господин Архитектор
Чтобы не вставать два раза с СУБД, рекомендую ещё одно развивающее чтение на ту же тему, но в другом разрезе. Обещаю, что будет крайне полезным
http://www.redbook.io/index.html
источник
2017 March 17
Господин Архитектор
Немалое испытание в проектировании архитектуры крупной системы в том, чтобы:
- согласиться, что ни у кого никогда не будет на 100% актуального описания реальной системы (описания всегда отстают от жизни);
- согласиться, что не будет единого описания а ля "single source of truth", будет набор с разных точек зрения, а иногда они будут даже входить в противоречие.
- согласиться, что пункты выше влияют на развитие позитивно, а не негативно
источник
Господин Архитектор
С опытом работы всё больше верю, что программирование - наука во многом гуманитарная. Отсюда все споры про элементы творчества, про несовпадение потребностей одних и возможностей других, про регулярный размеренный крах одной строго выверенной и рассчитанной идеи за другой
источник
2017 March 18
Господин Архитектор
Самый главный (но не замеченный и не обозначенный многими явно) сдвиг парадигмы с приходом микросервисов это то, что понятие "приложение" теряет свой смысл и границы. Больше нельзя сказать: так, вот это приложение (продукт) у меня развёрнуто тут и ограничено вот этими узлами, и за него отвечает некоторая команда
источник
Господин Архитектор
architect_says
Самый главный (но не замеченный и не обозначенный многими явно) сдвиг парадигмы с приходом микросервисов это то, что понятие "приложение" теряет свой смысл и границы. Больше нельзя сказать: так, вот это приложение (продукт) у меня развёрнуто тут и ограничено вот этими узлами, и за него отвечает некоторая команда
Ну т.е. смотрите — если у вас есть в компании "продукты", за которые назначена выделенная ответственность команд, то на MSA это будет укладываться с большим трудом. Либо ваше MSA при внедрении рискует деформировать ся до такой степени, что вы соберёте всё худшее из обоих миров, и не получите ожидаемых выгод
источник
2017 March 20
Господин Архитектор
Пост о важности формулировок, особенно в архитектурных описаниях.

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

Покажу на простом примере. Многие слышали, наверное, что такое SRP — Single Responsibility Principle, его ещё переводят как "принцип единственной ответственности". Если вы считаете (не подглядывая в оригинальную формулировку), что принцип расшифровывается как "каждый элемент должен отвечать за одну конкретную вещь/функцию и только за неё", то у меня для вас плохие новости — вы подменили исходное значение чем-то понятным себе (но никак не обоснованным), и ходите с этим ложным определением. Будьте внимательны.
источник
Господин Архитектор
Немножко о микросервисах от Netflix:

"We built Conductor to help us orchestrate microservices based process flows at Netflix with the following features:
   Allow creating complex process / business flows in which individual task is implemented by a microservice.
 ..
 Expose control semantics around pause, resume, restart, etc allowing for better devops experience.
 ..
 Ability to synchronously process all the tasks when needed.
 ..
 Be able to operate on HTTP or other transports e.g. gRPC.

Why not peer to peer choreography?

With peer to peer task choreography, we found it was harder to scale with growing business needs and complexities. Pub/sub model worked for simplest of the flows, but quickly highlighted some of the issues associated with the approach.."
источник
Господин Архитектор
Вы, наверное, уже поняли — эта неделя пройдёт под знаком микросервисов. В конце постараюсь дать некоторое summary, возможно, в развёрнутом формате. Обсудим плюсы и минусы
источник
Господин Архитектор
architect_says
Пост о важности формулировок, особенно в архитектурных описаниях.

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

Покажу на простом примере. Многие слышали, наверное, что такое SRP — Single Responsibility Principle, его ещё переводят как "принцип единственной ответственности". Если вы считаете (не подглядывая в оригинальную формулировку), что принцип расшифровывается как "каждый элемент должен отвечать за одну конкретную вещь/функцию и только за неё", то у меня для вас плохие новости — вы подменили исходное значение чем-то понятным себе (но никак не обоснованным), и ходите с этим ложным определением. Будьте внимательны.
Напомню формулировку SRP для тех, кто не нашёл времени посмотреть: "у каждого элемента системы должна быть одна и только одна причина для внесения изменений". Как видите, истинная формулировка на самом деле имеет принципиальные различия с ошибочным, но популярным, прочтением, и это серьёзно влияет на вашу конструкцию
источник
2017 March 21
Господин Архитектор
Как принято говорить, любая проблема может быть решена введением ещё одного уровня абстракции. С микросервисами - введением ещё одного микросервиса. Никогда ещё построить сложную архитектуру не было так просто
источник
Господин Архитектор
Очень хочу, чтобы в этой ленте я был не проповедником, а одним из тех, кто делится опытом. А вы, в свою очередь, делитесь своим. И первый вопрос - что полезного и душеспасительного можно почитать про управление своей компанией? Попадалось ли годное кому-то? Ответы можно писать @meowthsli
источник
2017 March 23
Господин Архитектор
Хорошего архитектора отличает умение сделать правильный выбор в ситуации, когда кажется, что никакого выбора нет вообще
источник