Базы данных *

Лутаем Open Source #24. Они наконец-то починили MongoDB! Перенеся его на PostgreSQL...

DocumentDB – БД от Microsoft, которая состоит из 3-х частей:

1. PG расширение, добавляющее BSON формат (написанный, на С)

2. CRUD API поверх него (С)

3. Сервис трансляции 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-битных идентификаторов для объектов, таких как твиты, личные сообщения, пользователи и списки.

1. Бит знака — всегда равно 0 и зарезервировано на будущее.

2. Временная метка — количество миллисекунд, прошедших с начала эпохи UNIX.

3. ID ЦОД дает нам 2 ^ 5 = 32 центра обработки данных.

4. ID компьютера дает нам еще 2 ^ 5 = 32 компьютера в каждом ЦОД.

5. Номер последовательности.

6. При генерации каждого 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‑агент решает не только свои задачи, но и действует совместно с прочими - они делегируют задачи друг другу»

А вы рассматриваете нанять коллектив генИЕВ в рабочие процессы?

Нулевое время восстановления после сбоя в РЕД Базе Данных

Простой системы - это всегда потери. В отличие от других решений, РЕД База Данных предлагает уникальную на рынке гарантию мгновенного восстановления работоспособности.

Как это реализовано в других СУБД?

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

Как сделано в РЕД Базе Данных?

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

Для кого важно?

Это особенно важно в средах, где критична максимальная доступность: системы управления инфраструктурой, реального времени и другие сценарии, где даже минимальный простой недопустим.

Выбирайте РЕД Базу Данных, если для вашего проекта важна гарантированная целостность данных и отсутствие задержек при восстановлении.

Представлен открытый редактор таблиц NanoCell, который обрабатывает большие объёмы данных. При этом не нужно знать формулы и макросы. Проект помогает править документы от объёмных датасетов и финансовых данных до небольших формул для построения графиков и поиска одного значения в таблице. Решение разработал аналитик и датасайентист с многолетним стажем. Интерфейс у сервиса максимально простой и понятный. Данные сохраняется, включая все сведения и значения датасета на статическом сервере.

Data Warehouse: сравниваем подходы к хранению данных

На примере Data Warehouse рассказываем о подходах к хранению корпоративных данных и сравниваем альтернативные решения. Data Warehouse (DWH) — это централизованное корпоративное хранилище данных, в котором собирается, обрабатывается и хранится информация из разных источников. Его цель — предоставить единую и структурированную базу данных для анализа и принятия решений. В основе DWH лежит концепция предметно-ориентированной базы данных.

Чем Data Warehouse отличается от баз данных, Data Lake и Data Mart:

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

• Data Lake — это хранилище, куда можно складывать данные «как есть»: структурированные, полуструктурированные и неструктурированные. Например, логи, изображения, JSON-файлы и многое другое;

• Data Warehouse (DWH) — это усиленный уровень, предназначенный для аналитики. Данные сюда попадают после подготовки: проходят через процессы очистки, нормализации, трансформации и объединения;

• Data Mart — «мини-DWH» для конкретной задачи. Этот инструмент обычно проще и меньше по объему, но может обновляться чаще и работать с более узкой, оперативной аналитикой.

На старте проектирования архитектуры важно разобраться в разнице между разными типами хранилищ — у каждого своя специфика и уровень зрелости. Подробнее о Data Warehouse и подходах к построению DWH читайте в базе знаний Облака Рег.ру.

Gran KMS: как AI-ассистент революционизирует управление знаниями

Привет, Хабр! Сегодня хотим поделиться крутыми новостями о том, как развивается система Gran KMS и какие возможности открывает интеграция AI-технологий в управление корпоративными знаниями.

Что нового?

AI-ассистент стал настоящим прорывом в функционале системы. Теперь мы можем обрабатывать огромные массивы текстовых данных практически мгновенно. Представьте: многомиллионная библиотека знаний, тысячи документов — и всё это анализируется за считанные секунды!

Решаем реальные проблемы

Каждый, кто работал с корпоративными знаниями, сталкивался с типичными проблемами:

• Разрозненность информации — данные разбросаны по разным системам и форматам

• Сложность редактирования — обновление контента превращается в квест

• Медленный доступ — поиск нужной информации занимает слишком много времени

Новая версия Gran KMS решает эти проблемы на уровне архитектуры системы. AI-ассистент не просто ищет информацию — он анализирует контекст, объединяет данные из разных источников и выдаёт релевантные ответы.

Как это работает?

Интеллектуальная обработка позволяет:

• Мгновенно анализировать тексты любой сложности

• Находить ответы даже в самых запутанных документах

• Консолидировать информацию из разнородных источников

• Предоставлять структурированные ответы

Если вы занимаетесь управлением знаниями в компании — обязательно обратите внимание на эти обновления. AI-ассистент Gran KMS может стать настоящим помощником в вашей работе!

А как вы решаете проблемы с управлением корпоративными знаниями? Делитесь опытом в комментариях!

Конец экспертизы и конкуренции?

В интересное время мы живём. Вернулся намедни с конференции, полностью посвящённой AI-инструментам для бизнеса и параллельно начал читать книгу весьма любопытного китайца с юморным именем Кай-Фу Ли. Настоящие кайфули, а не обрыдшее деловое чтиво, это видно уже по первым страницам.

Давненько не попадалось таких насыщенных смыслами бизнес-изданий. Чуть ли ни каждая глава содержит квинтэссенцию глубоких мыслей продвинутого практика и стратегическое видение «человека мира», именно на уровне мира. Спорить не с чем, всё чётко разложено по полочкам. Мало того, всё, что было автором предсказано, уже происходит и именно так, как было описано. Книга, на секундочку, издана в России в 2019-м году, т.е., написана была значительно раньше. С удивлением узнал, что развивается AI ещё с 80-х, а основные вехи в его развитии приходятся на середину нулевых и одно из самых значимых событий произошло в 2012-м. Ничего про это не знал тогда, да и сейчас это стало для меня большим сюрпризом.

И ещё мне очень понравилось сравнение автором эпохи AI с эпохой внедрения человечеством электричества. И то и другое уже изменило облик и всё, что происходит на планете Земля, только изменения, которые привносит прямо сейчас AI, могут оказаться даже более глобальными в итоге, чем это было в случае с электричеством.

Что же стало ясно как божий день, когда почти месяц сам начал интенсивно пользоваться нейросетями, да ещё послушал/почитал умных людей, которые «в теме», что называется?

Экспертиза доживает свои последние годы. Затрудняюсь определить направление, где её ожидает хоть что-то позитивное в будущем. Сам опробовал на себе такие далекие друг от друга направления и темы, как молекулярная биология, туризм, нумизматика, ботаника, философия и др. И везде результат превзошёл ожидания за считанные минуты и несколько итераций. А, если «эксперт с 20-летним опытом» вдруг допустил какую-то оплошность или что-то недоглядел (галлюцинациями, вроде, это зовётся?), призываешь на помощь «эксперта с 40-летним опытом», даёшь ему возможность покопаться в деталях, и он обязательно находит все ошибки, начинает говорить на совершенно другом, выраженно профессиональном языке и источники приводит самые, что ни на есть релевантные. И так по всем проверенным лично направлениям. Где сам знаю вопрос досконально и могу оценить качество ответов.

Конкуренция в бизнесе тоже меняется на глазах. Вместо маркетинга, барахтания в «красных океанах» и всей этой бла-бла-бла в товарах и услугах, всему этому приходит на смену скорость внедрения AI во все сферы бизнеса. Кто быстрее и эффективнее это реализует, тот и выиграл в долгосроке в своей нише. Неважно, какой бизнес. Важно, что удачливого игрока ожидает: 1) Снижение себестоимости, которое не сможет побить ни один конкурент; 2) Персонализация невиданных доселе масштабов; 3) И, разумеется, полное отсутствие конкуренции на самой вершине. Это иногда даже монополией зовут. А кто не успел, тот уже точно не успел. Пора ползти в другом направлении…

Что решил для себя? Экстренно необходимо становиться горячим амбассадором и внедрять AI в работу везде и во всём, где это только возможно и приносит пользу. Завтра будет поздно, потому что все туда ринутся, пихаясь локтями.

А на бытовом уровне меньше чем за месяц обращений к бесплатной версии, я уже понял, что границ по знаниям не существует. Границы, по сути, определяются только тарифом и его лимитами. То новое, что даёт тариф за 20$, мне ещё только предстоит узнать.

На простой вопрос «Есть ли то, чего ты не знаешь?» AI ответил тоже простыми 5-ю пунктами, среди которых были личные данные, мои мысли и будущее. Делаю вывод, что всё остальное не вызывает у него особых сложностей.

А в конце AI издевательски добавил: «Если хочешь, можешь попробовать найти мой предел — задай что-нибудь каверзное». На этом моменте я впал в ступор...

Три новых облачных сервиса теперь в общем доступе ☁️☁️☁️

Теперь для них доступны все конфигурации, полноценная поддержка, а также соблюдение тарифов и SLA.

Вы уже можете использовать:

• Evolution Managed Metastore — для хранения метаданных.

• Evolution Managed Trino — массивно-параллельный аналитический SQL-движок для обработки больших объемов данных из разных источников.

• Evolution Managed Redis — для создания и управления кластерами Redis.

👉 А если хотите узнать больше о сервисах для работы с данными, спросите нашего AI-помощника в личном кабинете. Он расскажет обо всех нюансах и подберет подходящий вам вариант.

В Облаке Рег.ру повысили лимит на количество баз данных — в 100 раз

В Облачной платформе Рег.ру обновили лимит на количество баз данных в кластерах DBaaS: теперь пользователи могут добавлять до 1000 баз. Расширили возможности системы в 100 раз для повышения гибкости и масштабируемости проектов пользователей. 

Мы часто получаем запросы на развитие платформы, и этот релиз — результат обратной связи от наших клиентов. Спасибо вам!

Напомним, что в облаке Рег.ру доступно два вида управляемых БД — PostgreSQL и MySQL. Добавить новые базы данных в существующем кластере можно в личном кабинете, а узнать подробнее про возможности DBaaS — здесь.

ITFB Group совместно с Nexign, Sber Tech и Arenadata приглашают на вебинар, посвященный теме Датацентричность как стратегический приоритет: какие ИТ-инструменты помогут бизнесу принимать обоснованные решения?

Когда: 10 июля, 11:00

Где: онлайн

В рамках вебинара вас ждет уникальный формат:

• Экспертные доклады

• Живой круглый стол

Что обсудим:

• Лучшие российские платформы для управления данными (ETL, BI, BigData)

• Практические кейсы внедрения от Nexign, Arenadata и СберТех

• Как измерить ROI от дата-стратегии и ускорить цифровую трансформацию

Спикеры:

• Дмитрий Лемеш (Nexign) – интеграция данных для бизнеса

• Антон Близгарёв (Arenadata) – BigData без сложностей

• Владимир Федосеев (СберТех) – аналитика на автомате Модератор: Николай Чекин (ITFB Group)

Для кого?

→ ИТ-директора и директора по данным
→ Руководители цифровой трансформации
→ Специалисты по работе с данными (ETL, DWH, BI)

Регистрируйтесь сейчас!

Зарегистрироваться

Сравниваем NoSQL и SQL: что выбрать

Сравнили реляционные СУБД с NoSQL (Not Only SQL) — альтернативными системами хранения и управления данными для лучшей обработки неструктурированной информации. Когда при работе с хаотичными данными мощности традиционных СУБД уже не хватает, такая альтернатива может быть разумной заменой.

Сопоставили отличительные черты NoSQL и SQL, и вот что получилось:

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

Как уведомить Роскомнадзор об обработке персональных данных?

На Хабр вышла наша статья, прочтение которой поможет корректно подать уведомление в Роскомнадзор о намерении обрабатывать персональные данные. Особенно она будет полезна для ИТ-компаний и стартапов.

Из статьи вы узнаете:

• кто и в какие сроки должен подать уведомление

• как правильно заполнить уведомление

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

PlantUML | Шаблон для описания таблиц БД

Делюсь с Вами разработанным мною шаблоном, для описания таблицы БД в PlantUML, c элементами автоматизации, описание которых указанно в комментариях.

Всем привет!
Делюсь с Вами разработанным мною шаблоном, для описания таблицы БД в PlantUML, c элементами автоматизации, описание которых указанно в комментариях.

Протестировать можете тут, а сам код шаблона указан ниже:

 ' Шаблон описания таблицы БД (в PlantUML)
@startuml

skinparam {
' Параметры для управления нижним колонтитулом
    FooterFontColor #blue
    FooterFontSize 12
' Параметры для управления легендой
    LegendBackgroundColor #lightblue
    LegendBorderThickness 0
}

' Переменные для ускорения описания таблицы
' - PRIMARY KEY можно указывать как: "$PK"
    !$PK="  <size:11><#DarkKhaki:key:></size> (PK)  "
' - FOREIGN KEY можно указывать как: "$FK"
    !$FK="  <size:11><#DeepPink:key:></size> (FK)  "
' - NOT NULL (N-N) можно указывать как: "$NN"
    !$NN="  <#LightGreen> **N-N**  "
' - NULL можно указывать как: "$N"
    !$N = "  <#LightCoral> **NULL**  "


' Переменные для ускорения добавления информации о таблице
' - Наименование таблицы БД (латинское)  
    !$table_name="Наимнование_таблицы_БД"
' - Краткое описание таблицы (на русском) 
    !$description="Краткое описание таблицы (на русском)"
' - Ссылка на описание таблицы (на русском)
    !$doc_url="Ссылка"

' Контакты, отображаемые в нижнем колонтитуле
    !$autor ="Зимин Антон"
    !$email ="antzim_in@ya.ru"
    !$telegram="antzim_in"

' Заголовок документа, формируется автоматически из заполненных выше параметров (при необходимости можно удалить)
    title $table_name | $description

' Легенда (может быть заполнена любыми необходимыми данными)
' - "right" говорит о том, что легенда будет расположена справа 
legend right
**Легенда:**
| Версия документа: | 1.0.0 |
end legend



' Описание таблицы
' - заголовок таблицы, с кликабельной ссылкой (если выгружать в SVG) формируется автоматически
class "[[$doc_url $table_name]] ($description)" as $table_name << (T,#FF5722) >>{

|=   PK,FK  |=   Поле   |=   Тип   |=   Обязательность   |=   Значение\n по умолчанию   |=   Описание   |
| $PK | id | serial | $NN | | Идентификатор записи в таблице |
| $FK | subscriber_id | integer | $NN | | Идентификатор записи в таблице subscriber |
|     | electronic_address | varchar(255) | $N | | Электронный адрес \n клиента |
|     | created_at | timestampz | $NN | now() | Дата и время создания записи в БД |
|     | updated_at | timestampz | $NN | now() | Дата и время обновления записи в БД |
}

' Нижний колонтитул (формируется автоматически из введенных параметров)
footer © $autor | tg: [[https://t.me/$telegram @$telegram]] | email: $email
@enduml

Буду рад Вашим комментариям, отзывам, а если еще и поднимите карму то буду крайне благодарен.

Всем спасибо.
----

Пообщаться со мной можно в telegram: @antzim_in
P.S. Также, если Вам интересно, я веду telegram канал @sa_chulan и буду очень рад Вашей подписке.