Как Picodata исполняет SQL на кластере: план, адресация к бакетам, двухфазная агрегация и motion — перенос данных между узлами. Почему соединение по ключу шардирования обходится без переноса, а обычное на объёме просто не выполняется, и откуда берутся два лимита, в которые упирается всё
Как C++, Rust, Go и Java решают один и тот же вопрос — кто и когда освобождает память: вручную, детерминированно по владению (корректность проверяет компилятор) или в рантайме через сборщик мусора. Стек против кучи, стоимость аллокации, паузы сборщика, утечки и фрагментация — и на что смотреть под свою нагрузку
Redis держит данные в оперативной памяти — значит, память рано или поздно закончится. Разбираем, что происходит на границе: как устроен аллокатор и откуда берётся фрагментация, какие есть политики вытеснения (LRU/LFU/по TTL/noeviction), что значит upper bound через maxmemory и что делает Redis при OOM. Плюс инструменты диагностики: MEMORY DOCTOR, INFO memory.
Разложить данные по узлам — самая простая часть. Дальше начинается счёт: запрос без ключа шардирования идёт во все шарды, join между по-разному распределёнными таблицами Citus по умолчанию вообще отказывается планировать, глубокая страница тащит с шардов сотни тысяч строк ради двадцати, а добавленный узел сам по себе не берёт на себя ни одного шарда. Всё — замерами на живом кластере Citus
Hashed и ranged shard key, chunk splitting, balancer, роутинг через mongos, config servers, zone sharding, jumbo chunks и resharding — на живом шардированном кластере, с хотспотами и тем, как их ловить
Где живёт значение — на стеке или в куче — в Go решает не программист, а escape-анализ компилятора. Что уводит переменную в кучу (возврат указателя, боксинг в interface, захват замыканием), как это увидеть через go build -gcflags=-m, чем это грузит сборщик мусора и как проверять бенчами — на живом стенде с реальным выводом
Генерация Go-ассемблера через avo вместо ручного письма, честный замер наивного Go против рукописного AVX2 через benchstat и чек-лист «когда asm не нужен» — возврат к привратнику серии
Как писать собственный Go-ассемблер: регистровый ABI (ABIInternal/ABI0), структура пакета со стабом и .s-файлами, рукописный AVX2 для dot product на amd64 и его перенос на arm64/NEON с обязательным pure-Go fallback
Как читать чужой Go-ассемблер: go tool objdump и -gcflags=-S, Plan 9-синтаксис (порядок операндов, суффиксы размера, псевдорегистры FP/SB/SP/PC) и разбор дизасма наивного dot product — доказательство того, что компилятор не векторизовал цикл
Зачем в Go может понадобиться ассемблер, где он реально работает в stdlib (crypto, math/bits, bytes.IndexByte, runtime) и почему в 99% случаев правильный ответ — не писать asm. Знакомство со сквозным примером серии — dot product для []float64
