Работа коммутатора в сети. Как проходят запросы от рабочей станции до другого коммутатора?

На самом деле для ответа недостаточно информации, даже если считать все устройства расположенными в одном L2 домене (т.е. узел 1 выполняет коммутацию между 2 и 3, но не роутинг).
Один очень хитрый момент: таблица заполняется при получении пакета из порта.
Если узел E не ответит на пакет от B (и от него нет другой сетевой активности) - то узла E в таблицах коммутации свичей всё так же не будет и последующие пакеты от B до E всё равно будут рассылаться по всем портам и их будут получать все.
Но после прохождение любого пакета от E до свича 2 этот свич будет предполагать что знает на каких портах расположены оба адресата и переправлять пакеты с порта на порт не прибегая к рассылке по всем портам. То есть 4 эти пакеты уже получать не будет.

Пожалуй, сразу поясню "будет предполагать что знает": если вы переключите кабель узла E из узла 3 в 4 - то E не будет получать адресованные ему пакеты пока не будут удалены соответствующие записи из таблицы либо пока E не отправит какие-то пакеты.

Получается такая цепочка: станция В --> свитч 6 --> хаб 5 --> свитч 2 -->(хаб 4 (нет совпадений) и маршрутизатор 1) --> свитч 3 --> станция Е

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

А вот хост I может совершенно незаметно подслушивать коммуникацию между B и E, т.к. получает эти пакеты из-за использования всего-лишь хаба.

Хотя скорее всего я просто вас запутал =) Представляйте поведение каждого узла в отдельности, на самом деле ни один из них не знает, к чему подключён. Напрямую пк к пк, через хаб или свитч или долгим путём через кучу устройств - на L2 у них у всех достаточно простая логика работы.

Блокировки в mysql, есть ли альтернатива?

Опишите сначала что должно происходить, затем уже надо думать, что при этом пойдёт не так в конкурентной среде и как это избежать.
Пока что мне кажется что вам нужен уникальный индекс и insert on duplicate key update

Почему незафисксированная транзакция 1-ым юзером отображается у 2-го?

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

Почему незафисксированная транзакция 1-ым юзером отображается у 2-го?

JackShcherbakov, , я не вполне понял к каким соединениям относится какая транзакция в вашем тесте.
Если в одном соединении последовательно сделать:

begin;
insert into ...
begin; -- implicit commit here
insert another row
rollback;

то будет неявно закоммичен первый insert, несмотря на то, что коммита для него не было. rollback откатит только свою транзакцию из второго insert

Сможет ли другое соединение увидеть изменения незафиксированной транзакции - зависит от уровня изоляции транзакций. На READ UNCOMMITTED возможно читать то, что находится ещё в транзакции.
Неявный коммит же остаётся всё равно коммитом. После него все изменения будут видны новым транзакциям. (при read commited изоляции - и уже запущенным транзакциям тоже)

Почему незафисксированная транзакция 1-ым юзером отображается у 2-го?

нигде ничего автоматом не коммитится никогда

Эти бы слова, да в ядро mysql... https://dev.mysql.com/doc/refman/5.7/en/implicit-c...
Да, если вы уже в транзакции и пытаетесь сделать ещё раз begin - предыдущая транзакция будет неявно закоммичена.

Какую утилиту лучше использовать для реорганизации таблиц PostgreSQL (например: pg_repack vs pgcompactor vs подстройка автовакума)?

Как раз дописывал пару слов. Must have. Дефолтные настройки базы для того чтобы запуститься на любом калькуляторе, а не для работы.

Как вы измеряете профиль нагрузки (соотношение кол-ва чтений/кол-ву записей) в PostgreSQL?

Потому что соотношение чтения к записи не делают по числу запросов. Знаете ли, select одной строки по первичному ключу и половины таблицы seqscan'ом - это всё ещё один запрос с кардинально разными затратами io.

А с переносом части чтения на реплики - берёте topN отчёт и так и говорите:

ребята, смотрите: у нас дофига нагрузки вот от этих пары oltp запросов. Они же вроде не критичны к мелкому лагу? Давайте их на реплику скинем.
А вот этот милый запрос на 20% суточной нагрузки - это же вообще аналитика за прошлые сутки для менеджеров, давайте на аналитическую slow реплику перенесём, нафиг оно нам на мастере автовакууму мешает

Как вы измеряете профиль нагрузки (соотношение кол-ва чтений/кол-ву записей) в PostgreSQL?

Бессмысленная метрика. Нет, отдельных счётчиков нет.
Осмысленная метрика - сколько таплов читали-писали: n_tup_ins/n_tup_upd/n_tup_del/n_tup_hot_upd/seq_tup_read/idx_tup_fetch в pg_stat_all_tables.
И другая осмысленная метрика - topN запросов по времени выполнения из pg_stat_statements.

Процессор греется под водянкой до 100 градусов. Есть эксперты?

Хладагент-то циркулирует?

Как оптимизировать проверку на уникальность ID?

600к записей добавлялись 5 часов. Это нормально?

Если вы коммитили каждую запись отдельно, да ещё на дефолтном конфиге - могло было быть и хуже чем ~33 tps.
Если прочитать bulk insert раздел - то будет совсем другой результат.

TINYINT vs ENUM: в ситуации, когда возможных целочисленных значений всего несколько?

(1,60) зависит от strict sql_mode
(2,5) у меня на 5.5 работает, может запретили в 5.7 (хотя буду удивлён).

Если вам не кажется странным - то используйте. Я бы предпочёл не исследовать удивительные фокусы типизации enum и его взаимодействия с и без того мягкой типизации mysql.
Жаль что в mysql check constraint нет - вот это было бы реальное решение задачи без странных фокусов.

TINYINT vs ENUM: в ситуации, когда возможных целочисленных значений всего несколько?

Ммм, примера было недостаточно для описания причин?

Как организовать базу дневных температур в mysql?

Нормальная форма - это термин теории реляционных баз данных.
Т.е. сначала свои данные приводите к нормальной форме. Если это будет давать проблемы - тогда отходите от нормальной формы (т.е. денормализуете данные)

Как получить от PostgreSQL массив данных сразу в Json формате для Symfony?

Медлителен потому что такая гора кода в принципе не может быть эффективна по производительности рантайма в условиях shared nothing архитектуры PHP "обработал запрос и умер". Симфони берут не ради производительности.

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

Как получить от PostgreSQL массив данных сразу в Json формате для Symfony?

Измерьте.
Симфони медлителен сам по себе, может вы вовсе не в латентность сети до базы упираетесь, а в само приложение.

Насколько хорошо backend разработчик должен разбираться в Linux?

Есть в коробке у дебиана sudo или нет - зависит от ответов на вопросы установщика. Если задать root пароль - возможно sudo не будет (не помню), если не задавать - будет настроен sudo для следом создаваемого пользователя.

Как выбрать из базы mysql фразу "от `min` до `max`", если в базе есть значения `min` и `max`?

if(min=max, min, concat(...))

Как обновляют структуру БД и данные на продакшене?

Mikhail Osher, действительно, стоит явно упомянуть этот пункт

Вопрос по поводу mysql транзакций?

Я бы даже слово добавил: блокировки снимутся только после окончания транзакции.
Вернуть блокировку до окончания транзакции невозможно (кроме некоторых нетранзакционных блокировок).

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

Какую выставить частоту оперативной памяти?

какая часть фразы непонятна?

CPU-z на вкладке SPD пишет то, что в SPD модуля, а не текущее состояние. Текущее состояние - в memory