User
Многим, кто работает с MySQL, известно, что команда EXPLAIN используется для оптимизации запросов, получения информации об использованных и возможных индексах. Большинство разработчиков и администраторов СУБД этой информацией и ограничивается. Я же предлагаю изучить команду EXPLAIN максимально подробно.
FastStream - это относительно новая блестящая игрушка в руках Python'истов, которая создана специально для работы с брокерами сообщений.
В Python сложилось устойчивое убеждение, что если мы работаем с MQ - то нам нужен Celery, но он слегка устарел. Именно поэтому люди пытаются выкинуть "деда" и затащить вместо него любой новый многообещающий MQ-инструмент. Кроме того, культ Celery настолько силен в умах, что практически все новые библиотеки для работы с MQ пытаются стать его "убийцей" и заменой.
Однако, это не совсем верно. Существует огромный пласт проектов, которым нужен не фреймворк для менеджмента задач, а просто "голый" функционал Kafka/RabbitMQ/NATS/whatever для межсервисного взаимодействия. И все эти проекты вынуждены довольствоваться "сырыми" python-клиентами к своим брокерам, а всю обвязку вокруг этих клиентов писать самостоятельно. FastStream целится как раз в эту нишу.
В рамках статьи я хочу убедить вас, что не Celery мы едины, и для альтернативных инструментов найдется место под солнцем. А также рассмотрим фичи FastStream, которые он привносит в застоявшийся мир MQ-инструментов.
Привет! Сегодня мы поговорим про flexbox в css. Это очень важная тема, в которой должен разбираться каждый фронтенд-разработчик или верстальщик. Я покажу вам как flexbox работает на реальных примерах. А в конце статьи покажу лайфхаки, которыми сам постоянно пользуюсь на работе.
В PostgreSQL есть довольно интересный функционал - диапазонные типы данных (range). Они весьма удобны в использовании. Для индексирования этих типов данных существует GIST индекс. Однако на практике часто требуется сочетание BTREE индекса с GIST, что реализуется расширением btree_gist. Насколько эффективно удобство, предоставляемое диапазонными типами данных в сочетании с btree_gist мы и разберем в этой статье.
Для ЛЛ - с производительностью при использовании btree_gist будет плохо.
Задача матчинга в последнее время набирает всё большую популярность и используется во многих сферах: банки матчат транзакции, маркетплейсы – товары, а Google и другие IT-гиганты проводят соревнования по решению таких задач на Kaggle.
Для маркетплейса матчинг – очень важный процесс, который решает сразу несколько задач:
1. При поисковом ранжировании из множества товаров показывать сначала самые выгодные предложения.
2. Объединять множество товаров в одну сущность и показывать предложения одного и того же товара от разных селлеров.
3. Понимать, как предложения селлеров выглядят относительно друг друга, и поощрять их дополнительными бонусами.
Сегодня мы поговорим не только о решении этой задачи, но и о способах её реализации: offline (batch) vs online (realtime). Также обсудим, как и зачем переходить от первого ко второму.
Привет, Хабр!
Представьте себе, вы приходите домой после долгого рабочего дня, и вас встречает пушистый котик. Вы знаете, что он ждет вас, чтобы вы рассказали ему о своих подвигах на работе. И вот, вы начинаете свой рассказ, а он, этот милый мурлыка, вдруг спрашивает: "А как там у тебя с оптимизацией запросов в PostgreSQL?"
Вы, конечно, удивлены: "Откуда у кота такие знания?" Но котик смотрит на вас с понимающим видом и говорит: "Ведь хороший запрос должен быть как прыжок кошки - быстрым, точным и грациозным..."
В первой части из тестов стало понятно, что в векторном поиске с терминами что-то не так. И точность достаточно низкая для корректной работы RAG (retrieval augmentation generation). Давайте попробуем гибридный поиск и посмотрим, что из этого получится.
Примерно шесть лет назад я написал пост о том, как пишу HTTP-сервисы на Go, и сегодня я снова хочу рассказать, как пишу HTTP-сервисы.
Тот пост оказался довольно популярным и вызвал обсуждения, повлиявшие на то, как я делаю это сегодня. И спустя годы ведения подкаста Go Time, обсуждения Go в X/Twitter и поддержки подобного кода я решил, что настало время обновить информацию.
(Если вы педант и скажете, что Go не совсем 13 лет, то я отвечу, что начал писать HTTP-сервисы на Go версии .r59.)
В этом посте рассматривается широкий спектр тем, связанных с созданием сервисов на Go
Характеристики водо-водяных струйных насосов и гидроэлеваторов. Принцип работы гидроэлеватора с функцией вакуумного насоса.
После публикации статьи про лабораторный «водоструйный вакуумный насос» возникла теоретическая основа для рассмотрения принципа работы и более широкой группы водо-водяных «струйных эжектирующих насосов».
Про вакуумные гидроструйные насосы (см. ссылку).
К этой группе водо-водяных струйных насосов относятся также и «элеваторы» для систем отопления.
При всей простоте конструкции водоструйных насосов есть некоторые отличия от вакуумных водоструйных насосов, затрудняющие анализ их работы.
Начнём с простейших водоструйных насосов.
Струйными насосами могут быть как водо-водяные, так и водо-газовые или газо-газовые насосы (см.рис.1.)
Внутри Dolt, первой в мире базе данных SQL с полнофункциональными возможностями контроля версий, таится много интересной computer science. Недавно я писал о системе хранения Dolt, в ней есть очень тонкая особенность — применение вероятностного поиска на больших выборках 64-битных целых чисел.
В любом учебном плане по Computer Science есть курс алгоритмов. Моим был CS 102, и одним из пунктов, который объяснялся в нём досконально, было то, что поиск — это, по сути, задача O(log2(N)) при условии, если данные отсортированы. За свою карьеру я многократно встречался с этим в том или ином виде — если сортируешь информацию и сохраняешь её, то стоит ожидать, что для поиска потребуется время O(log2(N)). В общем случае мы соглашаемся на время поиска O(log2(N)), потому что оказывается, что можно перебрать большой объём данных с логарифмическим коэффициентом масштабирования. Эта система работает, потому что мы уже почти автоматически сортируем всё заранее.
Но что если мы добавим дополнительные ограничения на наши данные, которые позволят нам выполнять поиск за константное время?
Будет ли эта статья историей о необязательной оптимизации? Да, будет. В этом конкретном случае поиск будет занимать гораздо меньше времени, чем чтение с диска. Мы говорим о величинах менее чем 0,1% от суммарного времени. Будет ли эта статья историей о преждевременной оптимизации? Нет, не будет. Это бы подразумевало, что мы не осознаём, что время тратится не на то. Эта статья — история о заманчивости алгоритма константного времени.
Всем привет! В этой статье я опишу алгоритм работы формата сжатия изображений без потерь. Сжатие использует известные методики, которые и дали ему название. Проект начинался с простых экспериментов, которые вышли из под контроля. Не смотря на то, что формат чаще сжимает лучше чем png, никакого практического применения этот формат не имеет, оставаясь чисто академическим.
Внимание! В статье много картинок.
Струйные насосы-эжекторы
В статье про тепловые узлы домов уже рассматривался элеваторный узел как вариант использования водоструйного насоса с приводом от напора тепловых сетей.
Элеватор вовсе не уникальное устройство, а лишь одна из версий применения широко известного семейства «струйных насосов».
Такими струйными насосами могут быть как водо-водяные, так и водо-газовые, газо-водяные или газо-газовые насосы. (см.рис.1.)
Казалось бы, в посгресе и так есть неплохой полнотекстовый поиск (tsvector/tsquery), и вы из коробки можете проиндексировать ваши тексты, а потом поискать по ним. Но на самом деле это не совсем то, что нужно — такой поиск работает лишь по чётким совпадениям слов. Т.е. postgres не догадается, что "кошка гонится за мышью" — это довольно близко к "котёнок охотится на грызуна". Как же победить такую проблему?
TLDR:
С развитием генеративного искусственного интеллекта (ИИ) и расширением сфер его применения создание серверов с искусственным интеллектом стало критически важным для различных секторов — от автопрома до медицины, а также для образовательных и государственных учреждений.
Эта статья рассказывает о наиболее важных компонентах, которые влияют на выбор сервера для искусственного интеллекта, — о центральном и графическом процессорах (CPU и GPU). Выбор подходящих процессоров и графических карт позволит запустить суперкомпьютерную платформу и значительно ускорить вычисления, связанные с искусственным интеллектом на выделенном или виртуальном (VPS) сервере.
В последнее время активно разрабатываются технологии экстремально малоразрядного квантования, например, BitNet и 1.58 bit. Они пользуются большим интересом в сообществе машинного обучения. Основная идея данного подхода заключается в том, что перемножение матриц с квантованными весами можно реализовать и умножения, что потенциально полностью меняет правила игры применительно к скорости вычислений и эффективности больших моделей машинного обучения.
Эта статья написана в схожем ключе, но нас наиболее интересует, возможно ли напрямую квантовать предобученные модели при экстремальных настройках, в том числе, при двоичных весах (0 и 1). Уже имеющиеся работы нацелены на обучение моделей с нуля. Но в открытом доступе сейчас достаточно много отличных предобученных моделей, таких как Llama2. Более того, обучение с нуля — это ресурсозатратная задача в пересчёте как на вычисления, так и на данные, поэтому такие подходы не слишком доступны в свободном сообществе.
В этой статье мы подробно разберём крайне малоразрядное (2 и 1-разрядное) квантование предобученных моделей с применением HQQ+. HQQ+ — это адаптация HQQ (полуквадратичного квантования), в которой для повышения производительности используется адаптер с низкой размерностью. Наши результаты показывают, что при обучении лишь небольшой части весов в верхней части HQQ-квантованной модели (даже одноразрядной) качество вывода значительно возрастает, такая модель может даже превосходить небольшие модели полной точности.
Модели находятся на Hugging Face: 1-разрядная, 2-разрядная.