Ryzen быстрее в однопоточных задачах, EPYC уверенно лидирует в многопоточной нагрузке, работе с памятью и серверных функциях. Разбираем результаты 25 тестов и объясняем, когда переплата за EPYC действительно оправдана.
Привет, Хабр! Пишет эту статью Александра Лысенко — вчера я была студенткой, а сегодня как инженер-программист Nexign спешу поделиться приобретенным опытом.
Мой первый проект для реального бизнеса был связан с миграцией с Oracle на PostgreSQL. Сегодня расскажу, как внедрение диапазонного типа данных при переходе между СУБД позволило не просто сохранить производительность, но и превзойти исходные показатели. Если вы тоже только начинаете свой карьерный путь — надеюсь, этот материал вам поможет.
Когда мы выпустили Auto Embeddings — функцию автоматического преобразования текстов в векторные представления — без развёртывания отдельного сервиса для работы с ML-моделью, — главный запрос пользователей касался скорости работы. Ранее для генерации эмбеддингов использовался только стек SentenceTransformers поверх Candle (Rust-рантайм Hugging Face для ML-инференса), и ресурсы CPU использовались далеко не полностью: в большинстве сценариев нагрузки показатель QPS держался на уровне нескольких десятков документов в секунду независимо от способа подачи данных, а параллельные запросы обрабатывались последовательно в рамках одной сессии модели.
Поэтому мы в течение нескольких недель оптимизировали механизм запуска ONNX-моделей в Manticore. Новый бэкенд ONNX Runtime доступен начиная с Manticore Search 27.1.5 . ONNX (Open Neural Network Exchange) — переносимый формат моделей, в котором уже публикуется большинство популярных open-source моделей для эмбеддингов: MiniLM, BGE, E5 и другие. В результате получилось решение, которое в среднем в 14 раз быстрее прежней реализации SentenceTransformers/Candle на том же оборудовании (обычный недорогой сервер с 16 ядрами / 32 потоками), с той же моделью и теми же весами, если усреднить по всей матрице замеров threads × batch, — и это преимущество сохраняется как при одном клиентском потоке, так и при тридцати двух. Предыдущая реализация во всём диапазоне нагрузок показывала 5–11 документов/с; новая реализация работает в диапазоне 70–230 документов/с.
Эмбеддинги (иначе говоря, векторные представления) — это способ представления абстрактных данных в виде набора чисел (в виде векторов, как вы могли уже понять), близкие значения которых связаны семантически и математически и с которыми может работать модель искусственного интеллекта.
Разберемся какие модели лучше других подходят для кодирования слов. Параллельно с этим разберём принципы, на которые нужно опираться при выборе эмбеддинг-модели, пощупаем русские BERT-модели и внесём ясность про системные требования, контекстное окно и размер батча.
Многие из backend-разработчиков получали ошибки с неприятным содержанием, суть которого можно описать двумя словами: deadlock detected. Эти ошибки коварные. Возникают они там, где их не ждёшь, отладочной информации крайне мало или вообще нет, и для их решения необходимо глубокое понимание архитектуры как самого запроса и метода, из которого он вызвался (или методов, возможно, чужих...), так и архитектуры самой СУБД. Поэтому часто у таких ошибок либо переносится срок, либо попытки их исправить приводят к тому, что они возвращаются снова и снова. А deadlock-и так никуда и не исчезают...
Manticore Search 27.1.5 выпущен. Этот релиз приносит встроенные аутентификацию и авторизацию, шардированные таблицы, conversational search, более быструю сборку HNSW, улучшенные фасетирование и агрегации, а также длинный список исправлений в KNN, репликации, совместимости протоколов и других областях.
Этот пост - сводка всего, что вышло с 25.0.1 по 27.1.5.
Кратко: Три изменения в HNSW-поиске ускоряют KNN-поиск до 29% при больших k и дают более 20% прироста при параллельной нагрузке. Без изменений API, без перестроения индексов и без новых настроек — просто более быстрый поиск.
«HTAP», «единая платформа для OLTP и OLAP», «никаких ETL» — такие обещания в индустрии делают каждые полгода. Обычно за этим следуют компромиссы: либо транзакции деградируют, либо аналитика тормозит, либо архитектура превращается в Франкенштейна. Мы расскажем, что конкретно сделали в Postgres Pro AXE — и почему это работает иначе.
Представьте: пользователь добавляет одного сотрудника в группу где‑то в глубине иерархии — и сидит, смотрит на крутящийся лоадер почти минуту. А запрос «покажи всех участников этой группы» отрабатывает так долго, что проще сходить за кофе. Стоит иерархии стать чуть глубже — база и вовсе падает по тайм‑ауту. Именно так вела себя наша старая схема хранения оргструктуры, когда бизнес пришёл с новыми аппетитами: сотни тысяч человек в одной группе и вложенность втрое больше, чем та, на которую всё проектировалось.
Так выглядела наша точка отсчёта. Речь о Директории — компоненте B2B‑платформы Яндекс 360, который отвечает за жизненный цикл организаций и служит единым источником истины об их оргструктуре для других сервисов: Календаря, Почты, Мессенджера, Диска. Когда вы ставите встречу на целый отдел или отправляете общую рассылку для бухгалтерии, под капотом к Директории прилетает запрос «Дай мне всех пользователей этой группы с учётом всей вложенности». Это наш самый горячий запрос, и старая архитектура с ним перестала справляться.
Привет! Меня зовут Малик, я занимаюсь развитием B2B‑платформы в Яндекс 360. В этой статье я расскажу, зачем нам вообще понадобился граф при хранении оргструктур, почему мы решили засунуть этот граф именно в PostgreSQL и как мы это реализовали. А ещё — как нам удалось выкатить такое масштабное архитектурное изменение в продакшен без даунтаймов и что мы получили в итоге.
В марте 2024 года Redis сменил лицензию и, тем самым, положил начало развитию Valkey. Два года Valkey активно развивался: набирал количество контрибьютеров, коммитов, был встроен в многие проекты — в общем, показал себя на практике. Пришло время подвести итоги и понять: есть ли в этом сравнении победитель.
В статье разберем обе технологии. Будет немного про историю развития и хронологические предпосылки, разбор ключевых фич и почти детективное расследование о жизни двух хранилищ. Также, покажем за кем будущее (по нашему мнению) и зачем мы контрибьютим в одно из них.
Мы уже разобрались с тем, что такое BaaS, почему появились Firebase и Supabase, чем они отличаются от обычного backend и можно ли самому собрать что-то похожее.
Как я и говорил в прошлой статье, сегодня мы наконец попробуем самостоятельно собрать альтернативу Firebase с Realtime исключительно на open-source компонентах!
Но важная оговорка: мы не будем делать полный клон Firebase с его тонной функционала, но мы соберем минимальную рабочую альтернативу, которую уже можно подключить к frontend через SDK и использовать почти как Firebase.
ILM (управление жизненным циклом данных) в Tantor Postgres 18 работает в три этапа: администратор задаёт правила, система собирает статистику и выдаёт рекомендации, а вот что делать дальше - решение за администратором. В туториале я последовательно прохожу все эти этапы: установка расширений, настройка tablespace'ов, работа с обычными и секционированными таблицами и проверка рекомендаций через Flamegraph. В общем, разбираю новый функционал с практической стороны.
Привет, Хабр!
Меня зовут Жуйков Андрей, в Диасофт я занимаюсь развитием и продвижением СУБД Digital Q.DataBase.
Импортозамещение СУБД перешло из разряда регуляторных требований в практическую плоскость: компаниям нужно менять платформы без остановки бизнеса. Типичная проблема — огромная экосистема вокруг MS SQL, PostgreSQL или Oracle с тысячами процедур, отчетов и интеграций. Ручной перенос такого объема (например, 900 тысяч строк кода) занимает месяцы и несет риски, при этом даже автоматизация не исключает доработок.
Даже с автоматизированными средствами конвертации большинство проектов миграции СУБД требует доработок и тестирования, поэтому ключевым требованием становится сохранение существующей логики приложений. Digital Q.DataBase решает эту задачу через воспроизведение функциональности популярных СУБД и поддержку их диалектов SQL, что позволяет переносить системы быстрее без масштабной переработки прикладного слоя.
В новой версии Digital Q.DataBase существенно переработана архитектура продукта. Вместо единого монолитного решения СУБД получила независимые модули, воспроизводящие функциональность PostgreSQL, Microsoft SQL Server и Oracle Database. Это упрощает установку, сопровождение и обновление системы, а также позволяет использовать только те компоненты, которые действительно необходимы в конкретном проекте.
В этой статье покажу, как установить Digital Q.DataBase 18.2 на Astra Linux 1.8, познакомлю с новой архитектурой продукта и продемонстрирую подключение к каждому из поддерживаемых диалектов.
Какое-то время назад у меня возник инцидент с IOPS в продакшене (я уже писал о нём). Однако у меня не было никакой возможности замерить происходившее. Так как EBS скрывает от меня все механизмы, я решил замерить поведение того запроса в контролируемой мной среде. План такой: я выполняю один и тот же запрос трижды, каждый раз замеряя показания (сначала со страницами в общих буферах, затем со страницами, которые находятся только в кэше страниц операционной системы и, наконец, при чтении всего с диска). После этого я сравню результаты с двумя дисками, скрытыми под облачными абстракциями: с томом EBS из инцидента и с сервером Hetzner, бенчмарк которого я уже проводил.
Система довольно проста: моя домашняя машина с Debian. У меня работает Postgres 17 в Docker с shared_buffers = 16MB, track_io_timing = on. В качестве накопителя используется локальный SSD NVMe с ext4. Я намеренно создал таблицу такого размера, чтобы она не умещалась в кэш.
Почти любая интеграция 1С с внешним сервисом начинается одинаково.
Есть документ в 1С. Есть внешний API. Нужно при проведении документа отправить данные наружу. На первой встрече задача звучит просто: «Собрать JSON, дернуть метод, записать ответ».
Но есть нюансы...
Стоимость и сроки реакции по 1С:РКЛ регламентированы фирмой «1С». Но на практике качество сопровождения у разных подрядчиков может отличаться в разы.
Почему так происходит? Потому что SLA фиксирует рамку: как быстро принять обращение, в какие сроки начать работу, как выстроен формальный процесс. Но для бизнеса важен не сам факт реакции на заявку, а скорость восстановления работоспособности системы, точность диагностики и снижение вероятности повторения инцидента.
17 июня на вебинаре Инфостарт эксперты разобрали практику сопровождения корпоративных систем 1С в рамках 1С:РКЛ и обсудили, на что действительно стоит смотреть при выборе подрядчика.
Под катом - основные выводы и несколько кейсов из реальной практики.
Привет, Хабр! Меня зовут Денис, я тимлид инфраструктурной Core команды в Timeweb Cloud.
Итак... представьте обычную виртуальную машину клиента. Она принимает запросы, пишет в базу, держит файловый кэш, обновляет память, что-то постоянно меняет на диске. А теперь нам нужно перевезти её с одной физической ноды на другую так, чтобы клиент не заметил переезд.
Звучит просто, пока не вспоминаешь, что у виртуальной машины есть память, диски, снапшоты, сетевые настройки, разные формат хранилищ, отличающиеся модели и вендоры CPU и состояния в базе управления. Любая из этих деталей может превратить задачу типа «перенести сервер» в ручную операцию с окном обслуживания, тикетом в поддержку и нервным инженером у консоли.
Мы переписали модуль миграции VDS так, чтобы эти детали стали частью алгоритма, а не частью ночной операционной инструкции.
В этой статье расскажу, как мы устроили живые миграции на базе libvirt, зачем оставили rsync, почему перешли на NBD для активных дисков, как выбираем RDMA или TCP, что дают SYNC_WRITES, ZEROCOPY, DETECT_ZEROES, AUTO_CONVERGE и другие флаги, и почему всё это важно не только инженерам, но и бизнесу.
Кодовые фрагменты взяты из реального модуля управляющего трансферами. Они немного сокращены и упрощены для статьи, но отражают настоящую логику. В целом материал будет полезен как системным инженерам, так и пользователям, для понимания всех внутренних процессов — что и как устроено и почему работает так, как работает.
На одном из проектов заказчика объём базы 1С:ERP достиг 16 ТБ, а регистр накопления «СебестоимостьТоваров» вырос до 4 ТБ и 2 млрд строк. При таких объёмах оптимизация перестала быть опцией и превратилась в обязательную задачу.
Симптомы были типичными для системы, которая упёрлась в пределы физического хранения: запросы к себестоимости выполнялись десятки минут, расчёт себестоимости тормозил, а серверный диск работал на пределе возможностей.
Были применены стандартные подходы к оптимизации: работа с индексами и статистикой, а также дефрагментация. Существенного эффекта они не дали.
Для решения задачи использовалось секционирование (партиционирование) таблиц на уровне MS SQL Server. Но, как оказалось, у 1С и секционирования сложные отношения.
Меня зовут Владимир Андрейков, я руководитель группы разработки в GRI. Эта статья — разбор практического кейса из проекта заказчика. Она будет полезна тем, кто работает с крупными внедрениями 1С:ERP и упирается в ограничения SQL Server при больших объёмах данных.
Привет, Хабр! Я — Дмитрий Селищев, в компании «Синимекс» совмещаю роли руководителя подразделения и разработчика баз данных. В этом материале хочу поделиться историей о том, как простые, но не всегда очевидные приемы помогают кардинально ускорить SQL-запросы. Мы поговорим о стандартных конструкциях CASE и FILTER, которые позволяют писать более чистый код и, что важнее, на порядки сокращать время построения сложных отчетов. Давайте на живых примерах посмотрим, как это работает.
В 1915 году Владимир Иванович Вернадский запустил проект, который сегодня назвали бы национальной базой данных ресурсов. Без компьютеров и цифровых технологий комиссия КЕПС собрала сведения о недрах, лесах, водах и энергии страны, заложив основы подхода «сначала данные, потом решения».
