Детерминированные тесты TigerBeetle: проверки внутри реплик
Обстоятельный разбор тестирования распределённой базы с доступом к состоянию каждой реплики. Проверки через публичный API показывают поведение базы для клиента, но не охватывают все внутренние гарантии.
Симулятор запускает настоящий код базы, заменяет сеть и диски управляемыми моделями и ускоряет время. Он воспроизводит разрывы сети, повреждения дисков и падения реплик; найденный сбой можно повторить.
При фиксации каждой операции симулятор сверяет её контрольную сумму между репликами. Разбор также показывает, как проверки хранения связаны с требованием побайтового совпадения данных. В рабочей базе нарушение проверяемой гарантии останавливает реплику.
Для разработчиков распределённых систем это карта проверок за пределами API. Условие подхода: код базы должен выполняться детерминированно.
#разборы #архитектура
Обстоятельный разбор тестирования распределённой базы с доступом к состоянию каждой реплики. Проверки через публичный API показывают поведение базы для клиента, но не охватывают все внутренние гарантии.
Симулятор запускает настоящий код базы, заменяет сеть и диски управляемыми моделями и ускоряет время. Он воспроизводит разрывы сети, повреждения дисков и падения реплик; найденный сбой можно повторить.
При фиксации каждой операции симулятор сверяет её контрольную сумму между репликами. Разбор также показывает, как проверки хранения связаны с требованием побайтового совпадения данных. В рабочей базе нарушение проверяемой гарантии останавливает реплику.
Для разработчиков распределённых систем это карта проверок за пределами API. Условие подхода: код базы должен выполняться детерминированно.
#разборы #архитектура
Ускорение строковых агрегаций в DuckDB через таблицу измерений
SQL-гайд по замене повторяющихся строк числовыми ключами показывает, как сократить обработку текста при группировке. Таблица измерений хранит каждое название один раз вместе с ключом: запрос считает группы по числам и возвращает названия после агрегации.
Пример построен на 380 959 записях об остановках поездов и 537 названиях станций. Для них хватает двухбайтового USMALLINT. Ключи назначаются в алфавитном порядке, поэтому сортировка по ключу сохраняет порядок названий. LEFT JOIN сохраняет строки без станции, с NULL вместо ключа.
Для инженеров данных разобраны два варианта: сохранить ключи в основной таблице или соединять её со справочником при каждом запросе. Первый требует переписать таблицу один раз; второй оставляет обработку строк при каждом соединении.
#производительность #гайды
SQL-гайд по замене повторяющихся строк числовыми ключами показывает, как сократить обработку текста при группировке. Таблица измерений хранит каждое название один раз вместе с ключом: запрос считает группы по числам и возвращает названия после агрегации.
Пример построен на 380 959 записях об остановках поездов и 537 названиях станций. Для них хватает двухбайтового USMALLINT. Ключи назначаются в алфавитном порядке, поэтому сортировка по ключу сохраняет порядок названий. LEFT JOIN сохраняет строки без станции, с NULL вместо ключа.
Для инженеров данных разобраны два варианта: сохранить ключи в основной таблице или соединять её со справочником при каждом запросе. Первый требует переписать таблицу один раз; второй оставляет обработку строк при каждом соединении.
#производительность #гайды
Адаптивное разбиение HashJoin в Bolt: меньше повторных выгрузок на диск
При соединении таблиц через хеш-таблицу нехватка памяти вынуждает Bolt разбивать строки на разделы и писать их на диск. Если раздел снова не помещается в память, цикл повторяется: чтение, разбиение, запись.
В техническом разборе адаптивного разбиения первая нехватка памяти служит оценкой вместимости. Bolt сопоставляет число обработанных строк с общим числом строк: при 10 млн строк и вместимости около 800 тысяч фиксированных 4 разделов мало, а адаптивный выбор может дать 16 или 32.
В статье показан путь статистики строк до решения о разбиении. Число разделов только увеличивается; ширина строк влияет на точность оценки, а перекос ключей всё ещё может создавать слишком крупные разделы. Разработчикам аналитических движков здесь есть что учесть при диагностике повторных выгрузок.
#производительность #разборы
При соединении таблиц через хеш-таблицу нехватка памяти вынуждает Bolt разбивать строки на разделы и писать их на диск. Если раздел снова не помещается в память, цикл повторяется: чтение, разбиение, запись.
В техническом разборе адаптивного разбиения первая нехватка памяти служит оценкой вместимости. Bolt сопоставляет число обработанных строк с общим числом строк: при 10 млн строк и вместимости около 800 тысяч фиксированных 4 разделов мало, а адаптивный выбор может дать 16 или 32.
В статье показан путь статистики строк до решения о разбиении. Число разделов только увеличивается; ширина строк влияет на точность оценки, а перекос ключей всё ещё может создавать слишком крупные разделы. Разработчикам аналитических движков здесь есть что учесть при диагностике повторных выгрузок.
#производительность #разборы
Bolt
Adaptive Spill Partitioning: Using Runtime Row Counts to Reduce Recursive HashJoin Spill
When the build side of a HashJoin exceeds its memory budget, the hash table has to be split by hash partition and written to disk. The basic mechanism is straightforward: split build rows into partitions, read partitions back one by one, rebuild the hash…
Как StarTree проверяет релизы Apache Pinot под нагрузкой и при отказах
В инженерном разборе StarTree показывает устройство сервиса проверки релизов своей аналитической платформы на Apache Pinot. Стенд совмещает приём данных и запросы с перебалансировкой таблиц и случайными перезапусками серверов.
Сервис на FastAPI принимает задания, а Argo Workflows управляет их выполнением. Команда сохраняет структуру клиентских запросов, скрывает чувствительные имена и значения и создаёт синтетические данные. Результаты преобразования строк сравнивают на текущей и следующей версиях, чтобы выявить несовместимость до обновления.
Разбор для разработчиков распределённых систем: здесь есть многодневные проверки и сценарии одновременных операций. Успешная проверка перебалансировки сама по себе не показывает, как система выдержит её на фоне интенсивного приёма данных.
#разборы #архитектура
В инженерном разборе StarTree показывает устройство сервиса проверки релизов своей аналитической платформы на Apache Pinot. Стенд совмещает приём данных и запросы с перебалансировкой таблиц и случайными перезапусками серверов.
Сервис на FastAPI принимает задания, а Argo Workflows управляет их выполнением. Команда сохраняет структуру клиентских запросов, скрывает чувствительные имена и значения и создаёт синтетические данные. Результаты преобразования строк сравнивают на текущей и следующей версиях, чтобы выявить несовместимость до обновления.
Разбор для разработчиков распределённых систем: здесь есть многодневные проверки и сценарии одновременных операций. Успешная проверка перебалансировки сама по себе не показывает, как система выдержит её на фоне интенсивного приёма данных.
#разборы #архитектура
Бенчмарки TidesDB и RocksDB: где настройки определяют результат
Обстоятельный разбор сравнения TidesDB 10.0.0 и RocksDB 11.8.1 на двух серверах показывает, почему вместе со скоростью нужно читать условия замеров. В основе пять нагрузок, от смешанных операций до корзины покупок.
Основное сравнение использует настройки по умолчанию, но сжатие отключено у обеих баз. TidesDB отдельно хранит крупные значения; у RocksDB аналогичная возможность проверена дополнительным прогоном. Каждый замер длится 60 секунд, результат берётся как медиана трёх повторов.
На большом сервере преимущество TidesDB сокращается. Но меняется не только диск: потоки закреплены за ядрами, а база заново заполняется перед каждым замером. Инженерам производительности здесь стоит сверить методику своих тестов: различия между серверами нельзя объяснить одним накопителем.
#производительность #разборы
Обстоятельный разбор сравнения TidesDB 10.0.0 и RocksDB 11.8.1 на двух серверах показывает, почему вместе со скоростью нужно читать условия замеров. В основе пять нагрузок, от смешанных операций до корзины покупок.
Основное сравнение использует настройки по умолчанию, но сжатие отключено у обеих баз. TidesDB отдельно хранит крупные значения; у RocksDB аналогичная возможность проверена дополнительным прогоном. Каждый замер длится 60 секунд, результат берётся как медиана трёх повторов.
На большом сервере преимущество TidesDB сокращается. Но меняется не только диск: потоки закреплены за ядрами, а база заново заполняется перед каждым замером. Инженерам производительности здесь стоит сверить методику своих тестов: различия между серверами нельзя объяснить одним накопителем.
#производительность #разборы
👍1
Forwarded from Нейроканал
Showboat и Rodney помогают показать работу ИИ-агента
Саймон Уиллисон собирает демонстрации кода с помощью двух своих инструментов. Showboat выполняет команды и записывает их вывод в документ. Rodney управляет Chrome из командной строки и делает скриншоты интерфейса.
Эту команду автор предлагает дать агенту: в справке есть всё необходимое, чтобы тот создал документ с демонстрацией новой функции.
Уиллисон замечал и обход механизма: агент напрямую правит текст отчёта. Тогда записанный вывод может расходиться с реальным запуском. Содержимое демонстрации тоже требует проверки.
#ии #инструменты
Саймон Уиллисон собирает демонстрации кода с помощью двух своих инструментов. Showboat выполняет команды и записывает их вывод в документ. Rodney управляет Chrome из командной строки и делает скриншоты интерфейса.
uvx showboat --helpЭту команду автор предлагает дать агенту: в справке есть всё необходимое, чтобы тот создал документ с демонстрацией новой функции.
Уиллисон замечал и обход механизма: агент напрямую правит текст отчёта. Тогда записанный вывод может расходиться с реальным запуском. Содержимое демонстрации тоже требует проверки.
#ии #инструменты
Forwarded from Нейроканал
Вспомните последний раз, когда ИИ сделал для вас рабочий результат: код, тесты, документацию или требования. Как вы его проверяли?
Anonymous Poll
16%
Внимательно разобрал сам
36%
Проверил на практике: тесты, запуск, реальные данные
27%
И разобрал, и проверил на практике
1%
Отдал на ревью коллеге
12%
Не проверял, сразу использовал
5%
Не было такого случая или не помню
3%
Другое (напишу в комментариях)
Панель слоёв Figma: меньше вычислений и кэш с линейным расходом памяти
В инженерном разборе панели слоёв команда Figma показывает, почему отрисовки только видимых строк недостаточно: прежний код всё равно собирал данные для всех раскрытых узлов, хотя на экране обычно видны 20–30 строк.
Сбор разделили на два прохода: сначала получают порядок строк, затем вычисляют имена, значки и состояния только для видимых. Кэш учитывает зависимости между узлами, поэтому изменение ветки требует пересчёта лишь затронутых частей дерева.
Отдельный раздел посвящён памяти: вместо копий списков потомков кэш хранит общие части по ссылкам. Расход растёт линейно с числом узлов, ценой дополнительных переходов по указателям. Для разработчиков сложных списков это повод проверить и объём вычислений, и устройство кэша.
#производительность #архитектура
В инженерном разборе панели слоёв команда Figma показывает, почему отрисовки только видимых строк недостаточно: прежний код всё равно собирал данные для всех раскрытых узлов, хотя на экране обычно видны 20–30 строк.
Сбор разделили на два прохода: сначала получают порядок строк, затем вычисляют имена, значки и состояния только для видимых. Кэш учитывает зависимости между узлами, поэтому изменение ветки требует пересчёта лишь затронутых частей дерева.
Отдельный раздел посвящён памяти: вместо копий списков потомков кэш хранит общие части по ссылкам. Расход растёт линейно с числом узлов, ценой дополнительных переходов по указателям. Для разработчиков сложных списков это повод проверить и объём вычислений, и устройство кэша.
#производительность #архитектура
Мобильные тесты Shopify: строгие проверки и визуальный поиск элементов
В инженерном разборе обёртки над Appium команда Shopify показывает, как вернула тесты пользовательских сценариев в обязательные проверки изменений кода. По её данным, доля успешных запусков отдельных тестов выросла с 50% до 98%.
Каждое действие требует проверки: ожидаемое условие должно быть ложным до действия и истинным после. Вместо поиска элементов в дереве компонентов тест ищет их на снимке экрана: PaddleOCR распознаёт текст, OpenCV сопоставляет иконки с образцами. Appium по-прежнему управляет устройством.
Видео с отметками поиска и нажатий помогает разобрать сбой без повторного запуска. Новые тесты проходят многократные прогоны перед допуском к обязательным проверкам. Мобильным разработчикам стоит читать ради устройства API, которое ограничивает способы написать нестабильный тест.
#разборы
В инженерном разборе обёртки над Appium команда Shopify показывает, как вернула тесты пользовательских сценариев в обязательные проверки изменений кода. По её данным, доля успешных запусков отдельных тестов выросла с 50% до 98%.
Каждое действие требует проверки: ожидаемое условие должно быть ложным до действия и истинным после. Вместо поиска элементов в дереве компонентов тест ищет их на снимке экрана: PaddleOCR распознаёт текст, OpenCV сопоставляет иконки с образцами. Appium по-прежнему управляет устройством.
Видео с отметками поиска и нажатий помогает разобрать сбой без повторного запуска. Новые тесты проходят многократные прогоны перед допуском к обязательным проверкам. Мобильным разработчикам стоит читать ради устройства API, которое ограничивает способы написать нестабильный тест.
#разборы
Резервные копии PostgreSQL без вытеснения данных из кэша Linux
В техническом разборе резервного копирования ClickHouse Managed Postgres показано, как чтение всей базы заполняет кэш Linux и вытесняет данные для запросов. Прямое чтение с O_DIRECT обходит кэш, но отключает упреждающее чтение: ядро больше не загружает следующие порции данных заранее.
На массиве RAID0, где последовательные блоки распределены между дисками, маленький запрос задействует лишь один диск. Поэтому для четырёх дисков команда увеличила размер чтения до 4 МиБ. Число параллельных читателей WAL-G подбирают отдельно, чтобы диски не простаивали между запросами.
В тесте на базе 467 ГБ обычный бэкап вытеснил из кэша все 40 ГиБ заранее прочитанной таблицы, прямое чтение сохранило их. Администраторам PostgreSQL: при настройке бэкапов учитывайте и сохранность кэша, и загрузку дисков.
#разборы #производительность
В техническом разборе резервного копирования ClickHouse Managed Postgres показано, как чтение всей базы заполняет кэш Linux и вытесняет данные для запросов. Прямое чтение с O_DIRECT обходит кэш, но отключает упреждающее чтение: ядро больше не загружает следующие порции данных заранее.
На массиве RAID0, где последовательные блоки распределены между дисками, маленький запрос задействует лишь один диск. Поэтому для четырёх дисков команда увеличила размер чтения до 4 МиБ. Число параллельных читателей WAL-G подбирают отдельно, чтобы диски не простаивали между запросами.
В тесте на базе 467 ГБ обычный бэкап вытеснил из кэша все 40 ГиБ заранее прочитанной таблицы, прямое чтение сохранило их. Администраторам PostgreSQL: при настройке бэкапов учитывайте и сохранность кэша, и загрузку дисков.
#разборы #производительность
Forwarded from Типичный программист
🧑💻 Какие навыки помогают вам в разработке в 2026 году?
Что вы чаще используете в работе? В каких задачах помогает ИИ, а где проще справиться самостоятельно?
Мы решили собрать портрет современного разработчика — и приглашаем вас поделиться своим опытом. Расскажите, какие навыки вам пригодились и как вы используете ИИ. Если обходите его стороной, нам тоже интересно узнать почему.
Опрос анонимный и займёт около 5 минут. Результаты опубликуем в общем большом исследовании.
👉 Пройти опрос
Что вы чаще используете в работе? В каких задачах помогает ИИ, а где проще справиться самостоятельно?
Мы решили собрать портрет современного разработчика — и приглашаем вас поделиться своим опытом. Расскажите, какие навыки вам пригодились и как вы используете ИИ. Если обходите его стороной, нам тоже интересно узнать почему.
Опрос анонимный и займёт около 5 минут. Результаты опубликуем в общем большом исследовании.
👉 Пройти опрос
Ленивое декодирование PostgreSQL в маршрутизаторе Neki
Маршрутизатор шардированной базы добавляет сетевой переход и обработку ответов. В техническом разборе Neki показано, как сократить эту работу: хранить строки в байтах протокола PostgreSQL и разбирать значения по мере необходимости.
При точечном запросе маршрутизатор декодирует параметр ключа шардирования, а ответ передаёт клиенту без разбора столбцов. Заголовки сообщений и длины при этом проверяются. Для
В статье разобраны параметры
#производительность #архитектура
Маршрутизатор шардированной базы добавляет сетевой переход и обработку ответов. В техническом разборе Neki показано, как сократить эту работу: хранить строки в байтах протокола PostgreSQL и разбирать значения по мере необходимости.
При точечном запросе маршрутизатор декодирует параметр ключа шардирования, а ответ передаёт клиенту без разбора столбцов. Заголовки сообщений и длины при этом проверяются. Для
LIMIT нужны границы строк; для сортировки — значения ключа сортировки. Остальные поля могут оставаться в исходном формате.В статье разобраны параметры
Bind, текстовые и бинарные значения, удаление служебного столбца из ответа. Для разработчиков прокси и движков запросов это пример архитектуры, где каждый следующий уровень представления данных создаётся только тогда, когда он нужен операции.#производительность #архитектура
❤1
Как батчинг меняет производительность OLTP в TigerBeetle
Перенос привычной схемы работы с SQL-базой в TigerBeetle может дать слабый результат. Множество клиентов, отправляющих по одной транзакции, не раскрывает возможности движка.
В разборе банковской нагрузки авторы меняют модель данных, используют батчи и идентификаторы с временной компонентой. Одна логическая транзакция состоит из двух переводов: флаг
Пока клиент ждёт ответа на текущий запрос, он собирает новые операции в следующий батч. Отдельная искусственная задержка для накопления не нужна. Сетевые и репликационные издержки распределяются на несколько операций.
Материал полезен при проектировании транзакционных сервисов: разобраны модель, способ подачи нагрузки и локальность записей. Показанное ускорение относится к конкретному эксперименту; переносить его цифры на любой сервис нельзя.
#производительность #разборы
Перенос привычной схемы работы с SQL-базой в TigerBeetle может дать слабый результат. Множество клиентов, отправляющих по одной транзакции, не раскрывает возможности движка.
В разборе банковской нагрузки авторы меняют модель данных, используют батчи и идентификаторы с временной компонентой. Одна логическая транзакция состоит из двух переводов: флаг
Linked связывает их атомарно — фиксируются оба либо ни один.Пока клиент ждёт ответа на текущий запрос, он собирает новые операции в следующий батч. Отдельная искусственная задержка для накопления не нужна. Сетевые и репликационные издержки распределяются на несколько операций.
Материал полезен при проектировании транзакционных сервисов: разобраны модель, способ подачи нагрузки и локальность записей. Показанное ускорение относится к конкретному эксперименту; переносить его цифры на любой сервис нельзя.
#производительность #разборы
Почему счёт записывают в TigerBeetle последним, а проверяют первым
В техническом разборе создания счёта без общей транзакции TigerBeetle определяет, существует ли действующий счёт: запись в нём разрешает переводы. Поэтому сведения о владельце сначала сохраняют в PostgreSQL. Обратный порядок при сбое может оставить деньги без установленного владельца.
Существование проверяют сначала в TigerBeetle: запись только в PostgreSQL ещё не разрешает переводы. Временное расхождение баз допустимо, деньги без соответствующей записи о владельце в PostgreSQL недопустимы.
Допустим, процесс упал после записи в PostgreSQL, до сохранения результата шага. Пока счёта нет в TigerBeetle, переводы отклоняются. При восстановлении шаг повторяется: те же данные считаются успехом, затем создаётся счёт в TigerBeetle. Другие данные означают конфликт и остановку.
#архитектура #разборы
В техническом разборе создания счёта без общей транзакции TigerBeetle определяет, существует ли действующий счёт: запись в нём разрешает переводы. Поэтому сведения о владельце сначала сохраняют в PostgreSQL. Обратный порядок при сбое может оставить деньги без установленного владельца.
Существование проверяют сначала в TigerBeetle: запись только в PostgreSQL ещё не разрешает переводы. Временное расхождение баз допустимо, деньги без соответствующей записи о владельце в PostgreSQL недопустимы.
Допустим, процесс упал после записи в PostgreSQL, до сохранения результата шага. Пока счёта нет в TigerBeetle, переводы отклоняются. При восстановлении шаг повторяется: те же данные считаются успехом, затем создаётся счёт в TigerBeetle. Другие данные означают конфликт и остановку.
#архитектура #разборы
👏1
Как leaky bucket ограничивает допуск нагрузки
Leaky bucket задаёт вместимость и скорость освобождения ёмкости. Новая операция занимает часть объёма; если места не хватает, её отклоняют. Состояние меняется с течением времени, независимо от завершения запросов.
В разборе механизма admission control показаны два варианта: измеритель разрешает работу сразу, а очередь удерживает её до выпуска. В варианте измерителя не нужен фоновый процесс, который постоянно «осушает» ведро: достаточно хранить прежний уровень и время проверки, затем пересчитать уровень при обращении.
На примере GraphQL API Shopify разобрана стоимость запросов: она зависит от запрошенных данных. После выполнения разница между оценкой и фактической стоимостью корректирует состояние ведра.
Для разработчиков API и баз данных здесь есть ориентир: определить стоимость работы, допустимый всплеск и поведение клиента при отказе. Ограничение скорости само по себе не ограничивает число одновременно выполняющихся запросов.
#алгоритмы #архитектура
Leaky bucket задаёт вместимость и скорость освобождения ёмкости. Новая операция занимает часть объёма; если места не хватает, её отклоняют. Состояние меняется с течением времени, независимо от завершения запросов.
В разборе механизма admission control показаны два варианта: измеритель разрешает работу сразу, а очередь удерживает её до выпуска. В варианте измерителя не нужен фоновый процесс, который постоянно «осушает» ведро: достаточно хранить прежний уровень и время проверки, затем пересчитать уровень при обращении.
На примере GraphQL API Shopify разобрана стоимость запросов: она зависит от запрошенных данных. После выполнения разница между оценкой и фактической стоимостью корректирует состояние ведра.
Для разработчиков API и баз данных здесь есть ориентир: определить стоимость работы, допустимый всплеск и поведение клиента при отказе. Ограничение скорости само по себе не ограничивает число одновременно выполняющихся запросов.
#алгоритмы #архитектура
Forwarded from Библиотека ИИ для айтишников
Почему разработчик планирует отдавать больше задач Claude
Винсент Шмальбах описал план перераспределить расходы на ИИ: больше работы отдавать Claude, а Codex сохранить для части задач.
К решению его подтолкнули затяжные сессии. По наблюдениям автора, агент иногда часами продолжал проверки и добавлял соседние задачи. Квота расходовалась, а момент, когда можно принять результат и двигаться дальше, было трудно предсказать.
В личном разборе Шмальбах связывает эти эпизоды с условиями подписки и затратами на собственные проекты.
#ии #инструменты
🐸 Библиотека ИИ для айтишников
Винсент Шмальбах описал план перераспределить расходы на ИИ: больше работы отдавать Claude, а Codex сохранить для части задач.
К решению его подтолкнули затяжные сессии. По наблюдениям автора, агент иногда часами продолжал проверки и добавлял соседние задачи. Квота расходовалась, а момент, когда можно принять результат и двигаться дальше, было трудно предсказать.
В личном разборе Шмальбах связывает эти эпизоды с условиями подписки и затратами на собственные проекты.
#ии #инструменты
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Библиотека ИИ для айтишников
Если приходилось уходить с одного ИИ-инструмента на другой, что стало главной причиной?
Anonymous Poll
29%
Качество ответов и кода стало не устраивать
14%
Упёрся в лимиты или не хватает функций
10%
Цены кусаются
17%
Проблемы с доступом: блокировки, нужен VPN
3%
Сложности с оплатой
3%
Стало неудобно работать
23%
Не менял инструмент — сижу на привычном
Как Cloudflare проверяет выводы ИИ-агентов
В первом прототипе агент получал всё расследование одним запросом. Он смешивал телеметрию с гипотезами, выходил за область проверки и терял различие между отсутствием данных и неудачным поиском.
В инженерном разборе Cloudflare сбор свидетельств вынесен в детерминированный код. До вызова модели система фиксирует область расследования, источники, время и пробелы в данных. Один снимок можно использовать повторно, чтобы сравнивать интерпретации агентов.
Четыре специализированных агента исследуют трафик, историю клиента, глобальную телеметрию и сведения об угрозах. Код проверяет ссылки на свидетельства и принадлежность расследованию. Сбои источников сохраняются явно: «не проверено» отличается от «проверено, совпадений нет».
Для разработчиков агентных систем это пример разделения сбора данных, анализа и проверки результата. Решение о мерах защиты принимает аналитик.
#архитектура #разборы
В первом прототипе агент получал всё расследование одним запросом. Он смешивал телеметрию с гипотезами, выходил за область проверки и терял различие между отсутствием данных и неудачным поиском.
В инженерном разборе Cloudflare сбор свидетельств вынесен в детерминированный код. До вызова модели система фиксирует область расследования, источники, время и пробелы в данных. Один снимок можно использовать повторно, чтобы сравнивать интерпретации агентов.
Четыре специализированных агента исследуют трафик, историю клиента, глобальную телеметрию и сведения об угрозах. Код проверяет ссылки на свидетельства и принадлежность расследованию. Сбои источников сохраняются явно: «не проверено» отличается от «проверено, совпадений нет».
Для разработчиков агентных систем это пример разделения сбора данных, анализа и проверки результата. Решение о мерах защиты принимает аналитик.
#архитектура #разборы
Как Uber ограничивает лавину повторных запросов
Сервис C вернул ошибку. B повторил запрос к C, а после неудачи сообщил об ошибке A. Если A тоже повторит запрос, вся цепочка запустится заново. Даже небольшой лимит ретраев на каждом уровне усиливает нагрузку.
В разборе Uber используется error ownership: инфраструктура сопоставляет входящие и исходящие ошибки, чтобы определить, где сбой возник, а где его только передали дальше.
Если C объявил себя источником ошибки, B может повторить обращение к нему в пределах retry budget. Когда ошибка уходит выше, B снимает признак владения: A уже не должен повторять всю цепочку.
В статье есть схема передачи
#архитектура #разборы
Сервис C вернул ошибку. B повторил запрос к C, а после неудачи сообщил об ошибке A. Если A тоже повторит запрос, вся цепочка запустится заново. Даже небольшой лимит ретраев на каждом уровне усиливает нагрузку.
В разборе Uber используется error ownership: инфраструктура сопоставляет входящие и исходящие ошибки, чтобы определить, где сбой возник, а где его только передали дальше.
Если C объявил себя источником ошибки, B может повторить обращение к нему в пределах retry budget. Когда ошибка уходит выше, B снимает признак владения: A уже не должен повторять всю цепочку.
В статье есть схема передачи
x-uber-error-claim и обработка сложных случаев: потерянного контекста и совпавших независимых ошибок. Подход требует понимания зависимостей сервисов — одного общего правила «повторять любой 500» для этого недостаточно.#архитектура #разборы
Почему реплики для чтения могут замедлять запись
В текущем хранилище GitHub полные копии репозитория на файловых серверах обеспечивают и сохранность данных, и обработку запросов. Добавление реплики помогает чтению, но увеличивает работу при каждом push.
В разборе новой Git-архитектуры GitHub описывает разделение этих задач. Данные репозиториев планируют хранить в Azure Blob Storage, а запросы обслуживать вычислительными воркерами с кешем. Дополнительная мощность для чтения тогда не требует новой полной реплики.
Согласование хотят сосредоточить на обновлении ссылки Git. Хранение объектов и проверки можно выполнять параллельно с другими записями, а compaction и сборку мусора вынести с серверов, обслуживающих запросы.
Это развивающаяся архитектура. Заявленное увеличение пропускной способности записи до 35 раз получено во внутренних бенчмарках; такой результат не обещает ускорить каждый пользовательский push в 35 раз.
#архитектура #производительность
В текущем хранилище GitHub полные копии репозитория на файловых серверах обеспечивают и сохранность данных, и обработку запросов. Добавление реплики помогает чтению, но увеличивает работу при каждом push.
В разборе новой Git-архитектуры GitHub описывает разделение этих задач. Данные репозиториев планируют хранить в Azure Blob Storage, а запросы обслуживать вычислительными воркерами с кешем. Дополнительная мощность для чтения тогда не требует новой полной реплики.
Согласование хотят сосредоточить на обновлении ссылки Git. Хранение объектов и проверки можно выполнять параллельно с другими записями, а compaction и сборку мусора вынести с серверов, обслуживающих запросы.
Это развивающаяся архитектура. Заявленное увеличение пропускной способности записи до 35 раз получено во внутренних бенчмарках; такой результат не обещает ускорить каждый пользовательский push в 35 раз.
#архитектура #производительность