Я.Субботник по Go - мой короткий отчёт

О чём были доклады:
• Сеть и ядро. Показали как обходить узкие места на уровне ядра и что это даёт под большой нагрузкой. Я узнал как такие вещи вообще делают и почему важно оставаться в экосистеме Go.
• Сборщик мусора. Разобрали текущий GC и новый Green Tea – на слайдах всё наглядно, как метятся объекты и как происходит очистка. Забавный факт – автор назвал его так просто потому, что любит зелёный чай.
• KV-хранилища. Конкретные кейсы и выгоды использования. Загорелся идеей попробовать YDB в будущих проектах.
• Debug Tree. Как навести порядок в отладке под высокой нагрузкой и даже на проде – шаги операции видно как на ладони.

Немного про людей:
• Кофе-брейк зашёл отлично – познакомился с несколькими людьми, обсудили идеи и наметил для себя как переносить процессы и даже проекты на Go.

Что возьму в работу:
• Продолжу изучать возможности Go
• Поработаю с кэшем и попробую оценить YDB на своих тестах.
• Подумаю над оптимизацией процесса отладки на подобие того, что был показан на субботнике.

Итог:
День получился практичным и живым. Ушёл с понятным списком экспериментов и несколькими новыми контактами.

#Go #конференция #yandex #ЯСубботник #networking #KV #GC #DebugTree #ydb

💡 Совет по Laravel: Получение исходных атрибутов

Аксессоры Laravel позволяют преобразовывать атрибуты модели при их извлечении. Но иногда может потребоваться получить исходное значение. Laravel предоставляет специальный метод для этого: getRawOriginal 🚀

Конкретно данное расширение более не обновляется и недоступно в перечне расширений для Docker Desktop

Как и обещал, публикую текущую версию MCP сервера https://github.com/sleleko/leko-mcp

В планах попробовать вариант реализации на базе Laravel MCP https://laravel.com/docs/12.x/mcp

🗄 MySQL: как мгновенно очистить таблицу на 11 ГБ без боли

Внимание ❗️: предлагаемое ниже решение не для production баз

В одной из баз данных столкнулся с таблицей craft_blitz_elementfieldcaches весом 11 620 МБ, которую нужно было полностью очистить.

Как я определил вес таблиц?

Взвесил таблицы запросом:

SELECT table_name,         ROUND((data_length + index_length) / 1024 / 1024, 2) AS MB FROM information_schema.tables WHERE table_schema = 'roke' ORDER BY MB DESC LIMIT 20;

Получил результат:

+------------------------------------+----------+
| craft_blitz_elementfieldcaches     | 11620.97 |
| craft_elements_sites               |   816.38 |
| craft_blitz_elementcaches          |   707.72 |
| craft_blitz_elementqueries         |    86.27 |
| craft_elements                     |    37.67 |
| craft_changedfields                |    28.67 |
| craft_entries                      |    19.64 |
| craft_redirect_404_log             |    12.50 |
| craft_blitz_elementquerycaches     |     9.03 |
| craft_formie_submissions           |     8.27 |
| craft_searchindex                  |     7.95 |
| craft_revisions                    |     7.55 |
| craft_entries_authors              |     6.55 |
| craft_blitz_caches                 |     4.20 |
| craft_structureelements            |     3.16 |
| craft_redirect_hits                |     1.72 |
| craft_projectconfig                |     1.52 |
| craft_feedme_logs                  |     0.64 |
| craft_redirects                    |     0.52 |
| craft_blitz_elementqueryattributes |     0.42 |
+------------------------------------+----------+
20 rows in set (0.07 sec)

Казалось бы - TRUNCATE и готово. Но не тут-то было:
TRUNCATE на больших InnoDB таблицах может вызвать лавину блокировок и откат транзакций на несколько часов.
Батчевый DELETE - рабочий вариант, но медленный.

Есть элегантный трюк:

-- 1. Создаём пустой клон структуры
CREATE TABLE craft_blitz_elementfieldcaches_new 
  LIKE craft_blitz_elementfieldcaches;

-- 2. Атомарная подмена — занимает миллисекунды
RENAME TABLE 
  craft_blitz_elementfieldcaches     TO craft_blitz_elementfieldcaches_old,
  craft_blitz_elementfieldcaches_new TO craft_blitz_elementfieldcaches;

-- 3. Удаляем старую в фоне — приложение уже не при делах
DROP TABLE craft_blitz_elementfieldcaches_old;

Почему это работает:

RENAME TABLE - атомарная операция.
Приложение моментально переключается на пустую таблицу и продолжает работу.
DROP старой таблицы может идти сколько угодно - он уже никому не мешает.
Если есть внешние ключи - добавь перед rename:

SET FOREIGN_KEY_CHECKS = 0;
-- после rename вернуть = 1

Итог: 11 ГБ "исчезли" за секунды, сервис не заметил ничего.
Этот же приём лежит в основе таких инструментов как pt-online-schema-change и gh-ost.

Примечание: Чтобы в MySQL обновилась информация о весе проблемной таблицы понадобилось дополнительно выполнить

USE craft_db;
ANALYZE craft_blitz_elementfieldcaches;

#mysql #devops #performance #backend #craftcms #blitz_cache #blitz

Постепенно разбираюсь с Golang

Между этим событием и первым сертификатом не так много времени прошло

Продолжаю повышать квалификацию , на этот раз по базам данных