Характеристики  водо-водяных струйных насосов и   гидроэлеваторов. Принцип  работы гидроэлеватора с функцией вакуумного насоса.

После публикации статьи про лабораторный «водоструйный вакуумный насос» возникла  теоретическая основа для рассмотрения  принципа работы и более широкой группы водо-водяных «струйных эжектирующих насосов».

Про вакуумные гидроструйные насосы (см. ссылку).

К этой группе водо-водяных струйных насосов относятся также и «элеваторы» для систем отопления.

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

Начнём с простейших водоструйных насосов.

Струйными насосами могут быть как водо-водяные, так и водо-газовые или газо-газовые насосы (см.рис.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:

1. Преобразовываем наши тексты в наборы чисел (векторы) при помощи API openAI.
2. Сохраняем векторы в базе с помощью pgvector.
3. Легко ищем близкие друг к другу векторы или ищем их по вектору-запросу.
4. Ускоряем индексами.

С развитием генеративного искусственного интеллекта (ИИ) и расширением сфер его применения создание серверов с искусственным интеллектом стало критически важным для различных секторов — от автопрома до медицины, а также для образовательных и государственных учреждений.

Эта статья рассказывает о наиболее важных компонентах, которые влияют на выбор сервера для искусственного интеллекта, — о центральном и графическом процессорах (CPU и GPU). Выбор подходящих процессоров и графических карт позволит запустить суперкомпьютерную платформу и значительно ускорить вычисления, связанные с искусственным интеллектом на выделенном или виртуальном (VPS) сервере.

В последнее время активно разрабатываются технологии экстремально малоразрядного квантования, например, BitNet и 1.58 bit. Они пользуются большим интересом в сообществе машинного обучения. Основная идея данного подхода заключается в том, что перемножение матриц с квантованными весами можно реализовать и умножения, что потенциально полностью меняет правила игры применительно к скорости вычислений и эффективности больших моделей машинного обучения.

Эта статья написана в схожем ключе, но нас наиболее интересует, возможно ли напрямую квантовать предобученные модели при экстремальных настройках, в том числе, при двоичных весах (0 и 1). Уже имеющиеся работы нацелены на обучение моделей с нуля. Но в открытом доступе сейчас достаточно много отличных предобученных моделей, таких как Llama2. Более того, обучение с нуля — это ресурсозатратная задача в пересчёте как на вычисления, так и на данные, поэтому такие подходы не слишком доступны в свободном сообществе.

В этой статье мы подробно разберём крайне малоразрядное (2 и 1-разрядное) квантование предобученных моделей с применением HQQ+. HQQ+ — это адаптация HQQ (полуквадратичного квантования), в которой для повышения производительности используется адаптер с низкой размерностью. Наши результаты показывают, что при обучении лишь небольшой части весов в верхней части HQQ-квантованной модели (даже одноразрядной) качество вывода значительно возрастает, такая модель может даже превосходить небольшие модели полной точности.

Модели находятся на Hugging Face: 1-разрядная, 2-разрядная.

В этой части мы рассмотрим процесс проектирования автономной системы канализации с септиком и сооружениями подземной фильтрации сточных вод. Также продолжим знакомиться с проблемами, возникающими при проектировании и строительстве таких систем. Статья будет полезна всем, кто планирует строить автономную канализацию, равно как и тем, кто уже эксплуатирует таковую.

Продолжаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".

В этой лекции мы узнаем, что такое план выполнения запроса, как и зачем его читать (и почему это совсем непросто), и о каких проблемах с производительностью базы он может сигнализировать. Разберем, что такое Seq Scan, Bitmap Heap Scan, Index Scan и почему Index Only Scan бывает нехорош, чем отличается Materialize от Memoize, а Gather Merge от "просто" Gather.

Как обычно, для предпочитающих смотреть и слушать, а не читать - доступна видеозапись (часть 1, часть 2) и слайды.

Привет! Меня зовут Михаил Кажемский, я Lead DevOps в IT‑интеграторе Hilbert Team. В последнее время к нам часто обращаются заказчики, которым нужна помощь с организацией хранения долгосрочных метрик в российских облаках. Так как для многих эта задача сейчас актуальная, в данной статье мы с моим коллегой Денисом Бабичевым решили рассказать, как мы используем мощные возможности ClickHouse для эффективного долгосрочного хранения метрик Prometheus. В статье вы найдете рекомендации по использованию инструмента и описание альтернативных решений, таких как Thanos, Grafana Mimir и Victoria Metrics.

Погружение в мир контейнеризации с докером — это путь к оптимизации развёртыванию приложений, а также ключ к упрощению жизни разработчиков и системных администраторов. Меня зовут Андрей Аверков, в IT c 2008 начинал пусть с аналитика-проектировщика IT систем, 11 лет в роли разработчика и последние годы на руководящих должностях. Сейчас я тимлид команды разработки из 9 человек в группе компании Кокос. Мы занимаемся созданием и поддержкой CPA платформ (gdeslon.ru, fxpartners.ru, ads.mobisharks.com), а также проектом по генерации лендингов — lpgenerator.ru. У нас большой опыт в разделении продуктов на части, поэтому, сегодня мы собрали самое основное и необходимое для работы с Docker. В нашей шпаргалке вы найдете все необходимое для успешного старта с докером: от базовых концепций и установки до продвинутых техник работы с контейнерами.

Представьте себе, что вы читаете книгу и хотите найти все места, где упоминается слово «кот». Не знаю, зачем вам это, но пока остановимся на том, что вы это хотите. Вот очень надо.

Так как это сделать?

Вы можете просто пролистать книгу и прочитать ее с начала до конца, буквально вручную находя всех котиков, но… Это может занять много времени и усилий. Гораздо проще будет воспользоваться индексом в конце книги, где перечислены все места, где упоминается слово «кот». Проблема в том, что в обычной печатной книге такого нет, а вот если вы читаете электронку — да, вполне. Можно воспользоваться поиском по слову.

Но это вы так можете, а вот компьютеры — нет.

Компьютеры не могут просто прочитать текст и понять, что он означает. Они нуждаются в помощи токенизаторов, которые преобразуют текст в набор токенов, или отдельных единиц информации, которые можно анализировать и обрабатывать.

Токенизация — это первый шаг в обработке текстовых данных. Без токенизации компьютеры не смогли бы понимать текст и находить в нем полезную информацию. Токенизаторы помогают преобразовать текст в данные, которые можно анализировать и использовать для решения различных задач, таких как классификация текстов, распознавание речи, машинный перевод и многие другие.

Токенизаторы, подобно электронным поисковым системам для текста, помогают компьютерам эффективно найти и организовать нужную информацию, так же как электронные индексы в электронных книгах облегчают поиск конкретных фраз. Без них компьютерам было бы гораздо сложнее «понимать» и анализировать текстовые данные.

Все знают что плохо оставлять дефолтные пароли. Но что произойдет если поднять PostgreSQL позабыв о безопасности? Нас взломают? Как быстро взломают?

Я развернул PostgreSQL, настроил сборку логов и ниже расскажу что будет (спойлер — вас очень быстро похекают).

В прошлый раз я описал, как можно поставить задачу (Job) в очередь Laravel из хранимой процедуры или триггера PostgreSQL.

В этой статье я расскажу, как можно преобразовать события, возникающие в PostgreSQL, в события Laravel.

Рабочий пример выложен на GitHub.

Первая часть статьи описывает возростание сложности системы, за счёт постоянного увеличения сбора метрик, задач и конечно же используемых плагинов

Закончилось это всё не очень хорошо, так заполнение "ежедневной рутины" усложнилось настолько, что заполнять её уже не хотелось. Поэтому критической задачей стало упрощение (идём обратно) в местах где сложность излишняя и автоматизация в местах, где есть лишние 2-3 клика.

Попробуем теперь всё упросить...

P.S. Как у любого новоиспечённого автора, у меня после написания первой статьи появился тг-канал. Милости прошу. Там пишу чаще, проще и более свободно. Формат статьи всё-таки сдерживает в каких-то рамках повествования.