Компания DBI приняла участие в TAdviser SummIT 2022

31 мая компания DBI приняла участие в офлайн — мероприятии TAdviser SummIT 2022!

Формат мероприятия был очень грамотно спланирован. Сначала состоялась общая, пленарная часть, на которой выступили ИТ-директора крупных коммерческих компаний и государственных ведомств России. Они рассказали, как с помощью ИТ-технологий повышают эффективность бизнеса и государства, а также с помощью каких методик добиваются успеха и строят работу.

К примеру, крупная металлургическая компания использует решение компании Microsoft — Azure DevOps Server, которое объединяет в себе управление версиями, сбор кода, построение отчетов, отслеживание статусов и изменение по проекту, а также оно позволяет совместно работать над проектами, как ИТ, так и бизнес-специалистам. С помощью эффективной организации инфраструктуры и оптимальных архитектурных решений, стандартизация разработки ПО позволяет: обеспечить надежность и устойчивость цифровых продуктов, ускорить выход новых приложений на рынок, унифицировать и сократить расходы по топовым проектам.

Одна из топливных компаний, рассказала о стратегии Цифровизации, поделилась подходами разработки и ее связями с бизнес-целями, проектами в области сквозных цифровых технологий и управления данными.

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

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

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

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

Подводя итоги конференции важно отметить, что первый приоритет в бизнесе — это сервис.

Бизнес ждет от ИТ: скорости, роста производительности, импортозамещения во всех направлениях и выделения команды под конкретные процессы бизнес-функций.

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

Мы живем в эпоху столкновения цивилизаций и нам необходимо добиваться лучшего вместе!

Наша команда подготовила крутое предложение, комплексная услуга «Администратор баз данных как сервис».

Будем рады помочь вам и подобрать решение для ваших задач contact@dbi.ru

DBI участвует в TAdviser SummIT 2022

Компания DBI примет участие в мероприятии TAdviser SummIT 2022! Приглашаем всех желающих присоединиться к нам в этой масштабной офлайн-конференции, 31 мая в Москве.

TAdviser SummIT 2022 — это возможность посетить 8 тематических сессий, которые будут идти параллельно: «ИТ в госсекторе», «ИТ в банках», «ИТ в промышленности», «ИТ в ритейле», Cloud, «ИТ в медицине», Big Data и BI, IT Security Day. И конечно же, это хорошая возможность, встретиться лично с коллегами по бизнесу, обсудить многие вопросы кулуарно, познакомиться с интересными людьми.

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

Мы будем рады встретиться с вами на Саммите, наш стенд — №16.

Регистрация и условия участия на сайте: https://summit.tadviser.ru/

DBI получил сертификат по направлению Oracle Business Analytics

Oracle подтвердил экспертизу DBI по направлению Business Analytics на территории Восточной Европы, (в т.ч. Россия и страны бывшего СНГ). Данная сертификация подтверждает опыт DBI, положительные отзывы клиентов, а также квалификацию сотрудников.

Направление Oracle Business Analytics включает в себя полный набор инструментов для анализа данных: Oracle Autonomous Data Warehouse (#ADW), Oracle Data Integrator (#ODI), Oracle Analytics Server/ Cloud (#OAC, #OAS) и ряд вспомогательных сервисов.

Комментарий Семена, руководителя отдела бизнес-аналитики и визуализации данных компании DBI:

“Помимо того, что это пополнение портфолио каждого специалиста моего отдела, получившего сертификат по OAC, ADW и инфраструктуре Oracle Cloud, и хороший аргумент для подтверждения квалификации и повышения, это также и прямой путь на рынок Европы для получения новых проектов по одному из наших флагманских продуктов — OBI/OAS/OAC — за счет включения нас в соответствующую маркетинговую программу Oracle. Но на этом наши планы не заканчиваются, т.к. это хороший старт для выхода на мировой рынок.

Особенности при миграции из Oracle в PostgreSQL (Life Hacks)

1 — Constraints (ограничения)

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

2 — Delete

При удалении данных в PostgreSQL для указания таблицы необходимо использовать синтаксис FROM, в Oracle же не требуется.

3 — Удаление объектов базы данных

В PostgreSQL разрешение на удаление объектов ограничено только владельцем таблицы базы данных или суперпользователем. Это не предоставляемая привилегия, хотя членство в роли, которая владеет объектом, может быть предоставлено. Если возможность удаления объектов базы данных в Oracle также предоставлено как членство в роли, то тогда необходимо будет переписать или перенастроить объект.

4 — Dual Table

Поскольку предложение FROM является обязательным в Oracle для каждого оператора SELECT, FROM DUAL используется для операторов SELECT, где имя таблицы не требуется. PostgreSQL не требует предложения FROM, поэтому FROM DUAL не требуется и обычно его можно опустить. Если в PostgreSQL требуется dual table, ее можно сгенерировать как представление.

5 — Пустые строки и NULL

В Oracle пустые строки имеют значения NULL, но они не считаются NULL в PostgreSQL. В Oracle можно проверить, пуста ли строка или нет, с помощью оператора IS NULL, но в PostgreSQL он вернет FALSE для пустой строки (и TRUE для NULL).

6 — Federation to Foreign Data Wrappers

Функция Oracle Federation позволяет пользователям обрабатывать таблицы из других баз данных, как локальные данные. Оболочки сторонних данных PostgreSQL более универсальны и позволяют подключаться к более широкому диапазону данных.

7 — GRANT

Команда GRANT действует аналогично в Oracle и PostgreSQL. Есть два основных варианта — они могут использоваться для предоставления привилегий для объекта базы данных и для предоставления членства роли.

При этом, не все привилегии Oracle доступны в PostgreSQL. Например, предоставление привилегии триггера для таблицы позволяет пользователям создавать триггеры, но в отличие от Oracle только владелец таблицы может удалять триггеры.

8 — Иерархические запросы

PostgreSQL не поддерживает START WITH. . .CONNECT BY, который Oracle использует для иерархических запросов. Вместо этого PostgreSQL использует WITH RECURSIVE.

9 — Joins with (+)

В Oracle есть специальный оператор (+) для выполнения левого и правого outer joins. В PostgreSQL эта функция отсутствует, поэтому необходимо указывать команду JOIN.

10 — Проверка NOT NULL

Для определения какие столбцы в таблице Oracle НЕ являются NULL, необходимо использовать команду CHECK (<column_name> IS NOT NULL). В PostgreSQL же вместо этого имеется столбец «attnotnull» в pg_attribute, в котором хранится информация о столбцах таблицы, в том числе – о столбце с Constraint NOT NULL.

11 — Преобразование PL / SQL в PL / pgSQL

Процедурный язык PostgreSQL PL/pgSQL во многих отношениях похож на Oracle PL/SQL. Оба являются императивными языками с блочной структурой и похожими форматами для присваиваний, циклов и условных выражений.

12 — Remote objects

Для доступа к remote objects можно использовать оболочку внешних данных (Oracle_fdw) для доступа к любой другой базе данных. Столбцы ROWID, CTID и IdentityPostgreSQL не имеет точного эквивалента псевдостолбцу ROWID в Oracle, который предоставляет адрес строки в таблице. CTID в PostgreSQL аналогичен, за исключением того, что его значение изменяется каждый раз при выполнении VACUUM. Вместо этого используются столбцы идентификаторов, значения которых создаются автоматически при создании строки и никогда не изменяется. Значение можно указать, чтобы оно создавалось ВСЕГДА или ПО УМОЛЧАНИЮ. GENERATED BY DEFAULT позволяет пользователю вставить или обновить значение, а не использовать значение, сгенерированное системой.

13 — Sequences

Sequences имеют другой синтаксис в Oracle и PostgreSQL, и их необходимо обновлять вручную или с помощью скрипт.

14 — SUBSTR

Функция SUBSTR по-разному работает в Oracle и PostgreSQL. В Oracle оператор SELECT SUBSTR (‘ABC’, — 1) FROM DUAL; возвращает «C», а эквивалентный SELECT SUBSTR (‘ABC’, — 1); в PostgreSQL вернет ABC.

15 — MERGE INTO

В PostgreSQL отсутствует оператор MERGE INTO, в отличие от Oracle.

16 — Синонимы

PostgreSQL не поддерживает синонимы. Вместо CREATE SYNONYM Oracle для доступа к удаленным объектам в PostgreSQL можно использовать SET search_path для включения удаленного определения.

17 — SYSDATE

Функция Oracle SYSDATE возвращает дату и время (в часовом поясе сервера). PostgreSQL не имеет соответствующей функции, но существует ряд методов для получения даты и времени для различных целей: statement_timestamp () дает текущую дату и время с начала текущего оператора; now () и transaction_timestamp () дают дату и время с начала текущей транзакции, а clock_timestamp () дает текущую дату и время с момента выполнения функции.

18 — TO_DATE

Функция to_date () как в Oracle, так и в PostgreSQL возвращает тип данных даты. Однако тип данных даты PostgreSQL предоставляет дату (год, месяц, день), а значение типа данных даты Oracle предоставляет дату и время (год, месяц, день, час, минута, секунда). Чтобы избежать этой несовместимости, используйте to_timestamp () PostgreSQL. Решением этой несовместимости является преобразование TO_DATE () в TO_TIMESTAMP ().

19 — Транзакции

Oracle всегда использует транзакции, но в PostgreSQL их нужно активировать. В Oracle выполнение любого оператора запускает транзакцию и заканчивается оператором COMMIT. В PostgreSQL транзакция начинается с оператора BEGIN, а также заканчивается оператором COMMIT. Уровни изоляции транзакций одинаковы в PostgreSQL и Oracle, и Read Committed является уровнем изоляции по умолчанию для обоих.

20 — Обработка ошибок транзакции

PostgreSQL создан для облегчения управления транзакциями и обработки ошибок с полной поддержкой ACID и уровнями изоляции. Он также способен обрабатывать ошибки времени выполнения и предоставляет надежные коды ошибок и сообщения для PL/pgSQL или кода приложения. Однако они обрабатываются иначе, чем Oracle, поэтому изменения все же необходимо внести. Вот несколько советов по оптимизации обработки ошибок в PostgreSQL:

  • Контроль транзакций внутри PL / pgSQL не разрешен: вы не можете зафиксировать или откатить транзакцию внутри хранимой процедуры.
  • Когда во время транзакции возникает исключительная ситуация во время выполнения, транзакция должна быть отменена, перед выполнением другой операции, потому что транзакция прерывается, когда обнаруживает ошибку. Журнал приложения покажет следующее сообщение об ошибке:
  • Используйте блок BEGIN… EXCEPTION… END для обработки исключений, чтобы код улавливал любые возникающие ошибки. Это автоматически устанавливает точку сохранения перед блоком и откатывается к ней при возникновении исключения. Имейте в виду, что, поскольку блоки исключений создают точку сохранения, они дороги, поэтому добавляйте их осторожно.
  • Сопоставьте коды ошибок и типы исключений из Oracle в PostgreSQL. Хотя некоторые коды ошибок одинаковы в обоих случаях, другие различаются. Язык программирования также влияет на это — например, специфичные для Oracle исключения JDBC должны быть заменены либо общими исключениями между базами данных, либо специфичными для PostgreSQL.
  • Обеспечение правильной обработки транзакций и ошибок в базе данных PostgreSQL является важной частью процесса миграции и обычно требует тщательного анализа базы данных и кода приложения.

Этапы оценки при переходе с коммерческих СУБД на PostgreSQL

1 — Общая оценка

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

2 — Оценка совместимости

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

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

  • Ресурсы сервера (память / дисковое пространство / открытые сетевые порты между источником и местом назначения).
  • Операционная система.
  • Программное обеспечение для переноса данных и соответствующие драйверы установлены и настроены.

3 — Оценка кода приложения

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

Ситуация усложняется, если вы используете встроенный язык программирования. Такой как Oracle Pro * C, динамически построенный SQL, или связываетесь с библиотеками, специфичными для Oracle, такими как: OCI или классы Oracle JDBC. Их корректировка требует твердого понимания базовой логики приложения и должна быть тщательно протестирована.

4 — Оценка архитектуры и очистка

На процесс миграции могут существенно повлиять настройка и архитектура базы данных и ее содержимого. Миграция предоставляет хорошую возможность очистить архитектуру и содержимое базы данных от лишнего — объектов, которые больше не нужны. Например старые временные таблицы или резервные копии данных, статических исторических данных, либо перейти к архивному хранилищу. А также уменьшить размер базы данных и ресурсы, необходимые для резервного копирования и восстановления.

Переход на PostgreSQL также открывает возможность разделения обработки онлайн-транзакций (OLTP) и аналитики по разным хранилищам, что может улучшить как оперативность, так и возможности аналитики.

5 — Преобразование схемы

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

PostgreSQL поддерживает стандартный синтаксис SQL и типы данных ANSI SQL. С помощью инструментов следует идентифицировать неподдерживаемые объекты, а затем преобразовывать их вручную с помощью синтаксиса, поддерживаемого PostgreSQL или обходных путей.

Приглашаем на семинар: Оптимизация DWH на платформе Vertica

Компания DBI совместно с Vertica и при поддержке компании Mont приглашает Вас принять участие в семинаре: Оптимизация DWH на платформе Vertica.
В рамках семинара мы расскажем о методах построения эффективной аналитической системы, обсудим этапы эволюции подхода к хранению и анализу данных на базе технологий Vertica, а также вместе с экспертами обсудим интересующие вопросы.
Специальные гости: эксперты S7 Airlines — поделятся опытом развития DWH.
Мероприятие состоится 15 октября 2021 года, в 15:00, в ресторане Lambic Brasserie на Новослободской, в формате “meetup”, что предполагает обмен опытом и неформальное общение.
Участие в семинаре бесплатное, но в связи с ограниченным количеством мест, требуется предварительная регистрация:
Программа:
15:00 — Регистрация участников и приветственный кофе;
15:30 — Унифицированное аналитическое хранилище — новый этап в развитии аналитических платформ;
16:00 — Сценарии использования Vertica для оптимизации DWH/КХД;
16:20 — Бизнес-кейс: Эволюция DWH в компании S7;
17:00 Кофе-брейк;
17:10 — Администрирование и техническая поддержка — помощь в разворачивании, мониторинге, сопровождении DWH на базе Vertica;
17:30 — Workshop: Демонстрация аналитического аппарата Vertica на примере моделирования поведения пользователя на сайте букинга отелей;
18:00 Ужин, неформальное общение + «Круглый стол»: преимущества и недостатки использования MPP-баз данных для построения DWH.

Будем рады встрече с Вами!

#meetup #dbi #mont #vertica #S7Airlines

Пять способов для сокращения стоимости облачных сервисов

Одно из преимуществ использования облачных технологий — это сокращение расходов на инфраструктуру и оплата только, того, чем реально пользуются сотрудники.
Но всегда ли это так? И можно ли и тут снизить расходы?
Наша команда DevOps инженеров предлагает 5 практических подходов к снижению стоимости облачных ресурсов.

Тэги

Тэги — это основа успешной и эффективной модели регулирования расходов в облаке. Они позволяют точнее определять основные точки расходов и контролировать их во всё возрастающем количестве используемых ресурсов.
Представьте облачную инфраструктуру из 20 виртуальных машин, одни тестовые или девелоперские, другие продуктовые и еще несколько не используются вообще. Если их называли просто VM1, VM2… , то через некоторое время будет просто невозможно определить, что есть что.

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

Внедрение и использование тэгов

Стандартизированный подход к тэгам позволяет улучшить контроль и отслеживаемость всех ресурсов и нагрузок. К примеру, используя тэг «прод системы» вы можете быстро определить нужные системы. Это позволит настраивать доступы к тем или иным системам и отследить стоимость используемых ресурсов. Теперь вы точно сможете определить на основании каких изменений стоимость услуг выросла и обратиться с вопросом к конкретному отделу компании.

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

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

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

Автоматическое масштабирование и оптимизация размера

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

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

Лучшее решение — это комбинирование оптимизации размера инстанса и автоматического масштабирования. Современная облачная инфраструктура должна быть сконфигурирована в соответствии с текущими потребностями в максимально выгодном ключе, но с возможностью быстрого увеличения мощности. Автоматическое масштабирование работает в двух направлениях – горизонтальном и вертикальном. Оно может возникать как при внезапном увеличении/снижении нагрузки, но также может быть и запланированным процессом.

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

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

Если вы спросите сколько инстансов нужно развернуть, то ответом будет ровно столько, сколько нужно. Не больше, не меньше.

Не забывайте стоимость тестовых систем

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

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

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

Объединенный билинг и поиск подходящих лицензий

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

Большинство компаний начинает свой путь в системе облачных технологий по подписке «платим за то, что используем». Это хорошо для теста облака, но вести бизнес в таком ключе не очень выгодно. Существует несколько вариантов облачных подписок которые могут сократить стоимость и улучшить контроль за ресурсами:

  • Работа с облачным провайдером позволяет более плотно работать с поддержкой облачного провайдера.
  • Энтерпрайз соглашения позволяет получить дополнительные скидки на текущие используемую инфраструктуру.
  • Тестовые подписки могут быть более выгодным подходом для команд разработчиков. Эти подписки значительно дешевле, но в них есть ограничения по доступности ресурсов.
  • Объединенные отчеты по тратам в облаке позволяют корректнее отслеживать затраты всей организации в целом.
  • Гибридные лицензии позволяют сократить расходы на виртуальные машины и базы данных.
    Бесплатные лицензии помогают в обучении новых специалистов и тестировании. В некоторых из них доступно использование ПО, к примеру, Visual Studio.

AWS Spot и Azure Spot

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

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

Надеемся эта статья будет полезна для вас. Свяжитесь с нами, если хотите узнать, как наша команда сможет вам помочь в данном вопросе.

DBI участвует в Yandex Scale 2021

Спешим поделиться новостью: DBI выступает партнером компании Yandex.Cloud на мероприятии Yandex Scale 2021! Приглашаем всех желающих присоединиться к нам в этой масштабной онлайн-конференции 24 сентября с 10:00 до 17:00.

Команда Yandex.Cloud расскажет о стратегических планах, а также обновлениях сервисов платформы. Клиенты и партнеры поделятся реальными кейсами и решениями в облаке, а пространство для общения позволит обменяться идеями и пообщаться в режиме реального времени. Минимум маркетинга, максимум полезного контента.

Участие в конференции бесплатное, узнать больше и зарегистрироваться можно по ссылке: https://scale.yandex.ru/partners#scale-form

#YandexScale2021 #DBI #YandexCloud