Расширения PostgreSQL в Amvera Cloud
Работа с векторами, временными рядами и геоданными в PostgreSQL требует специальных расширений. И мы наконец их добавили.
Теперь можно создать кластер с pgVector, PostGis и TimescaleDB. Дополнительно появилась возможность управления локалями и некоторыми другими параметрами.
Грамота исследует язык информационных технологий
Многие термины в сфере информационных технологий заимствованы из английского языка. В шорт-листе ИТ-номинации прошлогоднего «Слова года» по версии Грамоты оказались только заимствованные слова: промпт, дипфейк, опенсорс, копилот.
Даже те слова в сфере информационных технологий, которые выглядят исконно русскими, часто возникают в результате калькирования. Например, «мышка» и «папка» возникли именно так, в результате буквального перевода на русский английских слов mouse и folder.
Портал «Грамота.ру» в коллаборации с компанией «Хабр» собираются изучить, как сами ИТ-специалисты воспринимают свою профессиональную лексику, насколько сложно подобрать «русскоязычную» замену иноязычным терминам и с чем связана эта сложность.
Если вы знаете, что такое дейлик и баг, и употребляете в своей речи слова смер(д)жить или отрефакторить — нам очень нужна ваша помощь!
Приглашаем ИТ-специалистов и представителей других специальностей, работающих в ИТ-компаниях, принять участие в исследовании «Язык профессиональных сообществ».
Пройдите наш опрос по ссылке — он займет всего 10 минут:
https://forms.gle/KvB2Yv6ueS9AkDFB8
Результаты исследования будут опубликованы на Хабре и на Грамоте.
Подборка бесплатных обучающих материалов о PostgreSQL
Привет, Хабр! Новая пятница — новая порция обучающих статей. Сегодня собрал публикации, которые помогут тем, кто хочет лучше разобраться в PostgreSQL. По классике: все бесплатно. Чтобы прочитать подборки, даже регистрироваться нигде не нужно. Бонусом в конце поста будет ссылка на курс. Он тоже не стоит ни копейки, но там все же нужно зарегистрироваться. Итак, поехали.
PostgreSQL для новичков
В подборке 14 статей на два с половиной часа чтения. Здесь база: установка и настройка PostgreSQL, нюансы управления, резервного копирования и репликации. Для ленивых — что делать, если администрировать самим БД не хочется.
Средний уровень
В девяти статьях за полтора с небольшим часа рассматриваем настройку PostgreSQL в Docker и для работы с 1С. Вы разберетесь в командах, триггерах, индексах и организации мониторинга.
PostgreSQL на максималках: практикум по расширениям
Пять статей и чуть больше часа на их изучение. Эта подборка — ваш гид по расширениям PostgreSQL: от безопасности и оптимизации до работы с геоданными. Вы познакомитесь со всеми этими pgcrypto, jsquery и т. д., а заодно научитесь применять их без лишней теории.
Бонус. Бесплатный онлайн-курс для новичков «Погружение в PostgreSQL»
В семи уроках вы освоите основы SQL, научитесь создавать и связывать таблицы, выполнять базовые операции с данными. Эти знания станут хорошим стартом для дальнейшего изучения PostgreSQL. Курс подойдет начинающим администраторам баз данных, разработчикам, DevOps-инженерам и аналитикам.
Дарим 35 000 рублей, чтобы протестировать сервисы Evolution Data Platform 🎁
Переходите по ссылке, чтобы получить 35 000 рублей и попробовать сервисы для работы с Big Data и машинным обучением. Оцените интерактивную аналитику, постройте ETL-пайплайны и Data Lakehouse-решения для вашего бизнеса.
Какие сервисы можно протестировать с бонусными рублями?
Evolution Managed Trino — аналитический SQL-движок Trino, чтобы облегчить обработку больших объемов данных с помощью распределенных запросов.
Evolution Managed Spark позволит развернуть кластерный вычислительный сервис, создать и конфигурировать инстансы Spark.
Evolution Managed Metastore подойдет для хранения метаданных: информацию о таблицах, колонках и партициях.
Evolution Managed BI — облачный сервис для удобной визуализации и анализа данных. Собирайте информацию из MySQL, Oracle, PostgreSQL и других источников — и стройте на их основе графики, таблицы и диаграммы.
Evolution Managed Airflow позволяет обрабатывать данные по принципу ETL, объединять задачи в пайплайны, планировать и запускать их по расписанию.
Тратьте бонусные рубли прозрачно: 1 бонус = 1 рубль. Получить подарок можно до конца года, а действовать он будет 60 дней с момента активации.
🚀 Объём корпоративных данных растёт на десятки процентов в год, а специалистов всё так же не хватает. В статье для VC.RU мы вместе с Екатериной Ризановой рассказали, как ИИ-агенты помогают решать эту проблему: берут на себя рутинные задачи в хранилищах данных и BI-системах, ускоряют работу команд и экономят компаниям миллионы рублей в год.
ИИ-агент — это не чат-бот. Он сам выполняет действия: анализирует код витрин, строит lineage, генерирует SQL, находит инсайты и помогает сотрудникам сосредоточиться на действительно важных задачах.
👉 Делюсь материалом: https://vc.ru/ai/2233616-ii-agent-dlya-rabotyi-s-bolshimi-dannymi
Квиз: основы работы с базами данных
Если вы изучаете базы данных или давно не работали с ними и хотите проверить знания, приглашаем пройти наш новый квиз. Ответьте на несколько теоретических вопросов и попробуйте расшифровать SQL-запросы — в конце получите промокод на 1000 бонусов в панели Selectel.
Не забудьте поделиться результатами в комментариях!
Привет, коллеги! 👋
Снова с вами рубрика "вечерний вайбкодер", и сегодня я принёс вам MyRepETL (Ссылка на github)— инструмент для ETL через MySQL репликацию.
Зачем это нужно?
Задача: у вас куча MySQL баз в микросервисах, нужно всё это затащить в Metabase для красивых отчетов.
Проблема в том, что:
В каждой базе своя схема и структура
Данные нужно объединить и нормализовать
Metabase любит когда всё в одном месте
Ручной экспорт/импорт — это боль
MyRepETL решает это: берёт данные из всех ваших баз, трансформирует их на лету и складывает в единую аналитическую базу для Metabase.
Что умеет MyRepETL
🚀 Основные фишки
Многопоточность из коробки
Каждый источник работает в своём потоке
Не блокирует друг друга
Автоматически восстанавливается при сбоях
Гибкие трансформации
Переименование таблиц и колонок
Вычисляемые поля
Фильтрация данных
Кастомные Python-функции
JSON-конфигурация
Всё настраивается через конфиг
Как использовать
Простая синхронизация
Самый базовый случай — просто скопировать данные из одной базы в другую:
{
"sources": {
"prod_db": {
"host": "prod-mysql",
"user": "repl_user",
"password": "repl_pass",
"database": "production"
}
},
"targets": {
"backup_db": {
"host": "backup-mysql",
"user": "backup_user",
"password": "backup_pass",
"database": "backup"
}
},
"mapping": {
"prod_db.users": {
"source": "prod_db",
"target": "backup_db",
"source_table": "users",
"target_table": "users"
}
}
}
С трансформациями
А теперь добавим магию — переименуем таблицу, добавим вычисляемые поля:
{
"mapping": {
"prod_db.customers": {
"source": "prod_db",
"target": "analytics_db",
"source_table": "customers",
"target_table": "users",
"column_mapping": {
"id": {"column": "user_id"},
"name": {"column": "full_name"},
"email": {"column": "email"},
"birth_date": {"column": "age", "transform": "transform.calculate_age"},
"phone": {"column": "formatted_phone", "transform": "transform.format_phone"},
"created_at": {"column": "registration_date"},
"source": {"column": "source_system", "value": "production"}
}
}
}
}
Создайте файл transform.py с вашими функциями:
# transform.py
def calculate_age(birth_date, row_data, table):
from datetime import datetime
if not birth_date:
return None
birth = datetime.strptime(birth_date, '%Y-%m-%d')
return (datetime.now() - birth).days // 365
def format_phone(phone, row_data, table):
if not phone:
return None
# 79991234567 -> +7 (999) 123-45-67
return f"+7 ({phone[1:4]}) {phone[4:7]}-{phone[7:9]}-{phone[9:11]}"
Запуск
# Установка с GitHub
pip install git+https://github.com/tumurzakov/myrepetl.git
# Или клонировать и установить локально
git clone https://github.com/tumurzakov/myrepetl.git
cd myrepetl
pip install -e .
# Запуск с конфигом
myrepetl run config.json
# Или через Docker
docker run -v ./config.json:/app/config.json myrepetl:latest
На этом всё, удачного кодинга! 👨💻
Хеш-таблица с транзакциями на Go
Привет, продолжим удивительное. Смех смехом, но на Go стали доступны:
И в отличие от C++, они еще не создают проблемы для Garbage Collector. Вы угадайте почему, а я немного процитирую:
------------------8<------------------
Все выглядит примерно так:
func NewMemDb() MemDb { /* ... */ }
type MemDb interface {
Close() error
StartTrn() Transaction
}
type Transaction interface {
Close() error
Get(key Ptrsz) (Ptrsz, bool)
All(getKeys bool, getVals bool) (keys []Ptrsz, vals []Ptrsz)
Set(key Ptrsz, val Ptrsz)
Del(key Ptrsz)
DependVal(key Ptrsz, val Ptrsz)
DependDel(key Ptrsz)
Commit() error
Rollback() error
}А именно:
Объект MemDb создается с помощью функции NewMemDb().
У MemDb есть функция Close() -- мы ОБЯЗАНЫ ее вызвать!!!
Объект Transaction создается с помощью функции StartTrn().
У Transaction тоже есть функция Close(). Да, мы ОБЯЗАНЫ!
Transaction работает с данными через lib.Ptrsz. Точно также, как и mdb.BlobMap.
Чтение данных выполняется посредством функций Get() и All(). Возвращаемые ими Ptrsz указывают на внутренние структуры MemDb. Они остаются валидными пока не завершена транзакция и не было вызовов Set() и Del(), инвалидирующих указатели.
Изменение данных выполняется посредством функций Set() и Del(). MemDb копирует себе байты, на которые указывают key и val.
Функции DependVal() и DependDel() устанавливают зависимости. Их проверяет Commit().
Функции Commit() и Rollback() завершают транзакцию. Завершают, но не закрывают! Мы ОБЯЗАНЫ вызвать Close()!!
Просто Close() означает Rollback().
------------------8<------------------
Вот, кстати, полный текст статьи, но там почти что невозможно обнаружить ссылку на исходники... Ага, не раз такое видел в комментариях!
Приглашаем на Java Jam — бесплатный митап ЮMoney для Java-разработчиков
Спикеры из ЮMoney и главный эксперт по технологиям Сбера расскажут о своём опыте и пообщаются с аудиторией. Вот какие темы будут на митапе:
🟣 Как мы уменьшали нагрузку на базы данных в очередях задач. Расскажем, как реализовать надёжное асинхронное и отложенное исполнение задач.
🟣 Советы по производительному коду. Поговорим про время выполнения программ, работу со строками и коллекциями, вещественную и битовую арифметику, алгоритмические трюки и многое другое.
🟣 Уязвимости не пройдут. Обсудим, как повысить безопасность разработки с помощью SAST и SCA.
25 сентября, в четверг, в 18:30 (мск) — приходите на митап в Санкт-Петербурге или подключайтесь онлайн!
Подробности — на сайте митапа Java Jam
19 сентября — СУБД-митап Tantor JAM
Митап от разработчика СУБД Tantor Postgres и машин баз данных Tantor XData пройдет в Москве. Это отличный повод встретиться для всех, кто интересуется развитием российских СУБД и будущим сферы управления корпоративными данными.
В программе мероприятия:
Стратегия «Тантор Лабс» на 3 года;
Новая версия платформы Tantor — ведущего enterprise-решения для администрирования и мониторинга любых БД на основе PostgreSQL;
Новинки СУБД Tantor Postgres для более высокой производительности и защищённости данных;
Инструментарий для управления интеграциями и загрузкой данных, осуществления миграций с минимумом даунтайма;
Особое внимание будет уделено Tantor XData — первой российской машине баз данных от вендора СУБД, созданной для самых сложных промышленных задач, высоконагруженных защищённых систем и крупномасштабной аналитики в стратегически важных отраслях.
Митап пройдет 19 сентября 2025 г. на 40-м этаже башни Mercury Space по адресу: Москва, 1-й Красногвардейский проезд, 15. Регистрация участников стартует в 12.00.
Будем рады видеть вас и ваших коллег!
Может ли кто-нибудь создать Википедию Вселенной, других цивилизаций?
По стилю - современная Википедия (или похоже), но разных миров и как будто с информацией из условного 100к-ого года нашей эры, где человечество выжило и знает намного больше о Вселенной. Например, чтобы Проксима b была с картой, историей и т.д.
Да, есть много фантастики, но целая фантастическая Википедия - этого у нас пока нет. Есть множество Вики по различным сюжетам, но это не то же самое. В "Википедии Вселенной" может быть надпись, которую видят все новые пользователи: "Что, если бы мы знали намного больше о Вселенной? Если бы у нас были Википедии других цивилизаций? Этот проект - фантазия людей и ИИ на тему", а дальше или случайная генерация одной из "Википедий будущего", или несколько на выбор, или одна.
Лутаем Open Source #24. Они наконец-то починили MongoDB! Перенеся его на PostgreSQL...
DocumentDB – БД от Microsoft, которая состоит из 3-х частей:
PG расширение, добавляющее BSON формат (написанный, на С)
CRUD API поверх него (С)
Сервис трансляции Mongo Query в SQL (Rust)
Для кого это?
И вроде как: "PG – классная база, а MongoDB Query + BSON популярные технологии" – и можно было бы поразмышлять чем это круто, но сначала важно ответить на один туманный вопрос: "кому такая БД может быть нужна?"
Классический PG
Сначала рассмотрим кейс, когда мы накладываем DocumentDB на обычный PostgreSQL.
Те, кто используют MongoDB если попробуют переехать на такой сэтап столкутся с тем, что:
Там нет шардинга (и насколько бы он не был сложно реализован в MongoDB, он есть и им активно пользуются)
Придется использовать двойной тулинг: Compas, чтобы наблюдать за корректностью данных с MongoDB Query, и SQL если надо посмотреть что там внутри
MongoDB поддерживает Uncommitted Read и Write Majority, что странно накладывается на PG: если разраб достаточно продвинутый и намеренно использовал Uncommitted, то с PG он потеряет скорость и Availability из-за PG Committed, а если он использовал Write Majority, то PG не совсем дает такую гарантию (обвал диска при WAL репликации – менее надежен, чем Write Majority)
А самое главное: когда ты работаешь с MongoDB ты можешь открывать 1000 коннекшенов и он вполне себе все это сожрет, потому что (1) коннекшен это тред, (2) при запросах нет никакой проверки реляционной целостности, да и в целом проверка сильно проще, чем в PG, а значит придется потанцевать с пуллерами и даже менять где-то запросы, чтобы не упасть по скорости
То есть, у mongo-юзеров это заберет все особенные фичи MongoDB и при этом не даст фишки PostgreSQL.
Distributed PG-like
А что, если мы положим DocumentDB на что-нибудь из серии CockroachDB, YugabyteDB, AWS Aurora, Citus или Neon?
Все 3 проблемы решаются:
Шардинг из коробки
Достаточно высокая скорость записи и чтения
Отсутствие проблем с коннектами
В такой ситуации DocumentDB начинает играть новыми красками.
Но если в Neon и Citus (и может YugabyteDB) еще есть шанс добавить текущий DocumentDB BSON плагин, то в для других представителей придется писать его с нуля (причем под каждый свой, потому что они построены каждый на своем KV хранилище).
Переезд в Linux Foundation
А еще они сейчас в процессе переезда из Microsoft в Linux Foundation, из плюсов они будут полностью под MIT лицензией и пейвола, за который будут прятать полезные фичи, из минусов, Microsoft могут и забросить, а никто другой не подхватить.
Итоги
Неоднозначная технология, пока имеет смысл в каких-то тонких кейсах, но в общем и целом, не вижу пока где тут middle-ground, может, вы что-то подскажете?
P.S.
А еще приглашаю вас к обсуждению в свой паблик в телеграмме 🦾 IT-Качалка Давида Шекунца 💪
❓Сколько ошибок вы уже допустили в ClickHouse? Мы — много! На бесплатном вебинаре «ClickHouse Fail Fest: Собрали все грабли, чтобы вам не пришлось» покажем, какие проблемы чаще всего встречаются и как их обойти.
🗓 Дата: 5 сентября
🕓 Время: 16:00–17:00 (Мск)
Что разберём:
🔧 нормализацию данных и её подводные камни;
🔧 апдейты, долёты и малые вставки данных;
🔧 влияние структуры таблиц на производительность;
🔧 ошибки в оценке масштаба данных;
🔧 реальные кейсы и альтернативные подходы.
После эфира вы получите набор антипаттернов и проверенных решений, которые помогут:
✔️ повысить надёжность,
✔️ сократить издержки,
✔️ использовать ClickHouse максимально эффективно.
👨💻 Для кого: разработчики, тестировщики, аналитики и архитекторы ПО.
👉 Зарегистрируйтесь и приходите — час эфира избавит вас от десятков часов экспериментов и отладки.
Как правильно откатывать миграции? Если коротко, то никак.
В продакшене миграции могут идти только вперед. Какого? Откат миграции во время ролбека (при неудачном деплое) во-первых сильно усложняет всю процедуру, во-вторых, в теории, может ее некисло замедлить, уже не говоря про потенциальные локи на время отката. На фоне этого возможны ошибки, которые приведут всю систему в неконсистентное состояние.
Ролбек, в идеале, это просто переключение с одной версии кода на другую. Но ведь тогда возможны ошибки связанные с изменениями в базе? Если делать через жопу, то возможны. При правильном подходе, база всегда обратно совместима как минимум на одну версию. Только в этом случае мы можем обеспечить и бесшовный деплой (zero downtime deploy) и практически моментальный откат.
А это значит, что нельзя менять тип у колонок (если тип сужается), нельзя менять именования таблиц и полей. Если это все таки нужно, то существует немало техник, позволяющих сделать переход через создание новых сущностей и синхронизацией либо через код либо через саму базу (например с помощью триггеров). По этой теме даже написали целую книгу "Refactoring Databases: Evolutionary Database Design".
Получается, что любые ошибки в базе будут только накапливаться? Не совсем. Обратная совместимость обычно нужна только на текущую и следующую версию. Если у нас не коробка, а облачное решение, то одновременно могут работать только две версии. В таком случае, мы без проблем можем писать любые миграции, которые удаляют и меняют все что угодно, что уже не используется. Заметьте, это не откат, а новые миграции.
А вот в разработке откат миграции конечно же удобен. Пока код еще не слит в основную ветку или лежит только локально, то мы без проблем можем откатить и удалить миграции, которые сами же недавно создали, но в процессе проработки поняли что они нам не нужны или их нужно переделать.
Больше про разработку в моем телеграм-канале организованное программирование
Снятся ли управляемым СУБД быстрые NVME-oF RDMA-диски — тема доклада на IT-конференции GoCloud Tech 2025 ☁️
Мы задались вопросом улучшения производительности управляемой PostgreSQL и хотим рассказать, что из этого получилось. По ходу доклада обсудим:
- почему IO Latency имеет значение, а bandwidth нет;
- причем тут подключаемые диски NVME-oF;
- почему offloading — не панацея, а RDMA полезен лишь в малых дозах;
- как провести full-scale эксперименты в целой AZ и остаться вменяемым человеком.
Трек: Data&Analytics — обсудим тренды и возможности облачных сервисов, методы их интеграции с AI-агентами, а также инструменты для быстрого и эффективного решения задач хранения, обработки и анализа данных.
📅 Когда: 3 сентября в 13:40 мск
Что еще интересного будет на GoCloud Tech, смотрите в программе конференции.
Тренды в мире данных: куда стремятся СУБД и как их сравнивать в новых реалиях — тема доклада на IT-конференции GoCloud Tech 2025 ☁️
Приглашаем обсудить современные тенденции в мире данных. На встрече поговорим о стремлении СУБД к «облачности» и HTAP-универсальности, а еще разберем нововведения в бенчмарках — почему классических решений недостаточно и что с этим делать.
Трек: Data&Analytics — обсудим тренды и возможности облачных сервисов, методы их интеграции с AI-агентами, а также инструменты для быстрого и эффективного решения задач хранения, обработки и анализа данных.
📅 Когда: 3 сентября в 15:20 мск
Что еще интересного будет на GoCloud Tech, смотрите в программе конференции.
Три способа сформировать идентификатор пользователя.
Привет, меня зовут Рамис и я работаю дата-аналитиком в Garage Eight. Так как аналитики довольно часто (почти всегда) используют id пользователя для объединения таблиц, я хочу рассказать о различных способах формирования идентификатора пользователя (user_id, id, account_id и пр.).
Первый способ, который приходит на ум — это инкрементальное увеличение id пользователя, также известный как последовательный или автоинкрементный ID. То есть самый первый пользователь будет иметь id = 1, следующая регистрация 2 и так далее. Вроде бы идеально?
Плюсы:
Уникальность.
Порядок регистрации.
Простота реализации.
Минусы:
Требуют централизованного управления, что может замедлять работу при масштабировании.
Предсказуемы (идут по порядку), что может быть небезопасно, ведь злоумышленники могут угадать ID.
Для генерации нового ID часто нужно обращаться к базе данных (БД), что увеличивает нагрузку.
В шардированных или реплицированных БД могут возникать конфликты и задержки в генерации ID.
Невозможно встроить дополнительную информацию (например, временные метки или идентификаторы сервисов).
Кстати, проблему шардирования можно частично решить следующим образом: id увеличивается не на 1, а на число k, равное количеству используемых БД.
Второй способ — UUID, или универсально уникальный идентификатор (Universally Unique Identifier), — это 128-битное число.
Плюсы:
Уникальный, почти никогда не повторяется.
Генерится где угодно, не нужна база данных.
Не угадать, особенно, v4 и v7.
Для больших систем, так что хорошо подходит для микросервисов.
Можно сортировать, в v7 есть время создания.
Минусы:
Длинный — 128 байт (обычные ID короче).
Неудобный, сложно запомнить (типа a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11).
Медленнее в БД, иногда тормозит индексы.
Без порядка, v4 нельзя сортировать (v7 решает).
Не число.
Третий способ — Twitter snowflake id (теперь X) — это система генерации уникальных 64-битных идентификаторов для объектов, таких как твиты, личные сообщения, пользователи и списки.
Бит знака — всегда равно 0 и зарезервировано на будущее.
Временная метка — количество миллисекунд, прошедших с начала эпохи UNIX.
ID ЦОД дает нам 2 ^ 5 = 32 центра обработки данных.
ID компьютера дает нам еще 2 ^ 5 = 32 компьютера в каждом ЦОД.
Номер последовательности.
При генерации каждого id на отдельно взятом компьютере или процессе номер последовательности инкрементируется на 1, каждую миллисекунду этот инкремент обнуляется.
Плюсы:
Уникальность.
Распределенная генерация.
Можно сортировать.
Эффективность. 64-битный формат обеспечивает достаточную ёмкость для идентификаторов, а также эффективную обработку данных.
Простота. Логика генерации Snowflake довольно проста для понимания и реализации.
Популярность. Идентификаторы Snowflake широко используются, что облегчает интеграцию с различными системами и библиотеками.
Минусы:
Ограничение по времени. Максимальная точность Snowflake — миллисекунды, что может быть недостаточно для некоторых приложений, требующих большей точности.
Риск переполнения. При очень высокой скорости генерации идентификаторов существует риск переполнения порядкового номера, что может привести к потере уникальности.
Зависимость от синхронизации времени. Точность временной метки зависит от синхронизации времени на серверах.
Сложность в распределенных системах. При неправильной настройке распределенной системы могут возникать проблемы с уникальностью идентификаторов.
Необходимость управления идентификаторами машин. Каждой машине, генерирующей идентификаторы, необходимо присваивать уникальный идентификатор.
На этом все, но это неполный список, есть еще сервер тикетов и прочие.
Информацию взял из книги «System Design. Подготовка к сложному интервью», Алекс Сюй.
Делимся расписанием бесплатных вебинаров на следующую неделю:
🎬 19 августа в 16:00 (Мск) «Как ускорить работу с данными в 3 раза? Основы ДБТ за час» — вебинар про DBT, его возможности, принципы работы и способы с его помощью сделать свою деятельность эффективнее.
🎬 21 августа в 16:00 (Мск) «От идеи до продакшена: какой Kafka-клиент упростит вам жизнь?» — практический вебинар: какие высокоуровневые клиенты Kafka выбрать для Spring Boot, .NET и NestJS. Разберём ключевые отличия, реальные примеры использования и лучшие практики.
🎬 22 августа в 18:00 (Мск) «Как LDA и ARTM могут изменить подход к анализу текстовых данных» — вебинар по тематическому моделированию с LDA и ARTM, примеры на Python и практические кейсы.
Увидимся на вебинарах!
Переход 1С на PostgreSQL и прогнозы до 2031 года
Ни для кого не секрет, что клиент‑серверный вариант 1С изначально затачивался под MS SQL. Вспоминаю год 2017-й и точно помню, что в тот момент Postgres ставили в основном те компании, которые хотели сэкономить. Плевались, но использовали. Чуть более или менее серьезная нагрузка — и всё.
Помню, как мы для «Управления IT‑отделом 8» написали расчет SLA по графикам техподдержки. На файловой базе и в MS SQL все работало прекрасно. Выпустили обновление, но один клиент на Postgres начал жаловаться. Долго выясняли, в чем дело. В конечном итоге я подключился к нему на тестовый сервер, прошелся отладчиком и… бинго! Действительно наша ошибка: не указали сортировку в одном из вложенных запросов. На файловой и на MS SQL такой запрос, повторю, работал отлично. Postgres в этом деле оказался строже — сказано в документации, что выборка не гарантирует порядок? Будьте добры предусмотрите это.
Эта история из прошлого отлично иллюстрирует те же проблемы, с которыми бизнес сталкивается сегодня, когда переход стал практически неизбежным.
Если коротко, то вот главные грабли, на которые наступают при миграции 1С на PostgreSQL:
Проблема № 1: Деградация производительности. Миграция «в лоб» почти всегда приводит к проблемам с блокировками и работой планировщика запросов. Приходится переписывать код и оптимизировать его под PostgreSQL. Возможно, даже менять что‑то в самой платформе.
Проблема № 2: Кадры. Найти опытного DBA по Postgres, который глубоко понимает специфику 1С, значительно сложнее и дороже. С MS SQL всё было проще: установил, клик, клик — готово. Даже без тонких настроек многое работало «из коробки».
Ну и самое главное: миграция — это не просто смена СУБД. Это полноценный проект, требующий тестирования, переписывания узких мест в коде и, возможно, обучения команды. Экономия на лицензиях может быть полностью съедена затратами на внедрение и поддержку (да и не сказал бы, что тот же Postgres Pro дешевый).
А теперь о том, почему этот разговор вообще имеет смысл.
Раньше мы всегда советовали клиентам MS SQL как надежную и проверенную СУБД. Да, в 2015-м появился платный Postgres Pro, но, честно сказать, мы его всерьез не рассматривали. Зачем, если есть деньги на проверенный MS SQL? А если хотелось сэкономить — был бесплатный Postgres со всеми его тогдашними особенностями.
Но потом пришел 2022-й год, санкции вендоров и постепенная миграция стала трендом. А сейчас это уже не вопрос выбора, а вопрос времени.
Это не просто ощущения, это подтверждают цифры из исследования ЦСР.
Уже в 2024 году на новые продажи зарубежного ПО пришлось всего ~10% рынка. Прогноз до 2031 года следующий: российские решения для работы с базами данных могут занять до 99% новых продаж (!) Процесс импортозамещения будет идти, а если мы берем 1С, то тут в выигрыше PostgreSQL/Postgres Pro. Причины понятны: уход западных вендоров, требования регуляторов и развитие отечественных продуктов.
Для компаний использующих 1С это означает полный стратегический переход на Postgres в ближайшие годы. Но, как показывает практика, делать это нужно с умом.
У меня вопрос. Планируете переход на PostgreSQL или, как и мы, пока живете на старом софте?
‑-
Понравилась эта аналитика? В моем блоге Код ИТ‑директора я гораздо чаще делюсь мыслями, короткими кейсами и полезными инструментами, которые не всегда доходят до формата большой статьи.
Пора знакомиться! ГенИИ и Агентный ИИ.
Внедрение ИИ в работу контакт‑центров уже не обсуждается. Сегодня это необходимость. Но мы переходим на следующую эволюционную ступень развития - это внедрение генеративного интеллекта (генИИ). Мы изучили исследование и в этой публикации - самый сок!
Итак, исследование «Тренды использования генеративного ИИ в клиентском сервисе» проводилось Национальной Ассоциацией Контактных Центров (НАКЦ) в партнёрстве с компанией BSS. В результате выяснилось - 30% клиентских служб уже активно использует генИИ. Ещё 42% используют, но только в некоторых процессах.
Какой была выборка? В исследовании приняли во внимание ответы 465 респондентов из России, Беларуси, Казахстана, Узбекистана и др. стран. Это были представители банковской и финансовой сфер, телекоммуникационных компаний, сервис‑провайдеров, розничной торговли, аутсорсинговых контакт‑центров.
72% опрошенных подтвердили, что активно или частично используют генИИ для обслуживания клиентов. Ещё 24% планируют внедрение данной технологии
Что же хотят от генеративного ИИ? С помощью генИИ компании стремятся создать уникальный и персонализированный клиентский опыт. ИИ способен учитывать множество факторов и данных, что помогает прогнозировать потребности клиентов и проактивно предлагать свои услуги и продукты.
Респонденты заинтересованы в гиперперсонализированных рекомендациях, когда ИИ предлагает индивидуальные товары, услуги, цены или контент на основе истории покупок, предпочтений или поведения пользователя.
Первичная задача использования генИИ — автоматизация клиентского обслуживания с помощью текстовых и голосовых роботов: «Это даёт наиболее быстрый и измеримый эффект: затраты на обслуживание падают, скорость обслуживания растёт»
И все же ключевым трендом и генеральной линией дальнейшего развития генИИ в перспективе ближайших лет эксперты считают мультиагентность. Это как определённая совокупность ботов на генИИ, которые смогут взаимодействовать между собой.
«Мультиагентность предполагает объединение отдельных агентов генИИ в некий "коллектив“ AI‑агентов. И в этом „сообществе“ каждый AI‑агент решает не только свои задачи, но и действует совместно с прочими - они делегируют задачи друг другу»
А вы рассматриваете нанять коллектив генИЕВ в рабочие процессы?