Русский
Русский
English
Статистика
Реклама

Бд

Перевод Рекомендации по развертыванию Гибридного Облака (Hybrid Cloud) PostgreSQL

26.03.2021 18:19:00 | Автор: admin

Привет, хабровчане. В рамках набора в группу курса "PostgreSQL" подготовили для вас перевод материала.

Приглашаем также на открытый demo-урок на тему
Блокировки. На занятии вы узнаете, как работают блокировки; научитесь находить проблемные места в работе БД. Рассмотрим темы: блокировки объектов, блокировки строк, блокировки в памяти.


Гибридное Облако (Hybrid Cloud) это общий архитектурный дизайн в любой компании. Эта концепция сочетает в себе публичное облако, частное облако и даже локальные решения, что позволяет компаниям иметь гибкость в отношении того, где хранить и как использовать свои данные. Она также помогает при реализации среды высокой доступности (High Availability environment). Проблема заключается в том, что развертывание такой среды может быть сложной и трудоемкой задачей. В этом блоге мы увидим, что такое гибридное облако, рассмотрим некоторые соображения, которые необходимо принять во внимание, прежде чем использовать его, а также то, как развернуть эту среду с помощью ClusterControl.

Что такое Гибридное Облако?

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

Вопросы в области применения баз данных гибридных облаков (Hybrid Cloud Databases Considerations)

Переход к гибридной среде (Hybrid Environment) отличается для каждой компании, так как у них есть свой уникальный набор данных, требований, ограничений и процессов, которые с ним связаны.

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

  • Совместимость: Убедитесь, что вы выбрали поставщика, который специализируется в вашей отрасли и знаком с особенностями требований, которые должны быть соблюдены, будь то HIPAA, FISMA, PCI, или любые другие правила, на которые подписывается ваша компания. В конечном счете, ваша стратегия управления базой данных должна определяться тем, какая архитектура будет наилучшим образом соответствовать потребностям вашего бизнеса и масштабу по мере вашего роста.

  • Рабочая нагрузка: Каждая база данных имеет различные рабочие нагрузки. Некоторые из них будут лучше работать в публичном облаке, другие в локальном варианте установки, а какие-то в частном облаке. Знание своей рабочей нагрузки необходимо для нахождения оптимального сочетания ваших баз данных.

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

Как разместить PostgreSQL в среде гибридного облака

Предположим, что у вас запущена инсталляция ClusterControl и вы уже создали два разных аккаунта Cloud Provider, или одну учетную запись, если вы используете публичное и частное облако в одном Cloud Provider, или если вы используете комбинацию облачных (Cloud) и локальных (On-prem) сред.

Подготовка вашей облачной среды

Во-первых, необходимо создать свою среду в основном облачном провайдере. В этом случае мы будем использовать AWS (Amazon Web Services) с 2 узлами PostgreSQL :

Убедитесь, что у вас есть SSH (Secure Shell) и PostgreSQL трафик, который разрешён с вашего сервера ClusterControl, посредством редактирования группы безопасности (Security Group):

Затем перейдите к следующему облачному провайдеру (Cloud Provider), или к Частным (Private) или Локальным (On-prem) серверам, и создайте, по крайней мере, одну виртуальную машину, которая будет резервным узлом.

И снова, убедитесь, что вы разрешаете SSH и PostgreSQL трафик с вашего сервера ClusterControl:

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

Развертывание Кластера PostgreSQL

Зайдите на сервер ClusterControl и выберите опцию "Deploy (Развернуть)". Если у вас уже запущен экземпляр PostgreSQL, то вам нужно выбрать "Import Existing Server/Database (Импортировать Существующий Сервер/Базу данных)".

При выборе PostgreSQL, вы должны указать User (Пользователь), Key (Ключ) или Password (Пароль), а также порт для подключения по SSH к вашим узлам PostgreSQL. Вам также нужно имя вашего нового кластера и если вы хотите, ClusterControl установит и настроит для вас соответствующее программное обеспечение.

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

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

При добавлении ваших серверов вы можете ввести IP или имя хоста. На этом шаге также можно добавить узел, размещенный во вторичном облаке (Cloud Provider) или локально (on-prem), так как ClusterControl не имеет никаких ограничений по использованию сети, однако для большей ясности мы добавим его в следующем разделе. Единственным требованием здесь является наличие SSH-доступа к узлу.

На последнем шаге вы можете выбрать, будет ли ваша репликация Синхронной (Synchronous) или Асинхронной (Asynchronous).

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

Вы можете отслеживать статус процесса создания в мониторе активности ClusterControl.

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

Добавление удаленного узла ожидания (Remote Standby Node)

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

Перейдите к действиям кластера и выберите "Add Replication Slave (Добавить ведомое устройство репликации)":

Давайте используем опцию "Добавить новый ведомый узел репликации (Add new Replication slave)", так как мы предполагаем, что удаленный узел является новой установкой, если нет, то вы можете использовать опцию "Импортировать существующий ведомый узел репликации (Import existing Replication Slave)".

Здесь вам нужно только выбрать основной сервер (Primary server), ввести IP-адрес вашего нового резервного сервера и порт базы данных. Затем вы можете выбрать, если вы хотите, чтобы ClusterControl инсталлировал программное обеспечение, и должна ли репликация быть Синхронной (Synchronous) или Асинхронной (Asynchronous). Опять же, если вы добавляете узел в другом месте (другой облачный провайдер или локально установленный), вы должны использовать асинхронную репликацию, чтобы избежать проблем, связанных с производительностью сети.

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

Вы можете контролировать создание узла репликации в мониторе активности ClusterControl.

И проверьте свою окончательную топологию в разделе Topology View Section.

Заключение

Эти функции ClusterControl позволят вам быстро настроить репликацию в среде гибридного облака, между различными облачными провайдерами или даже между облачным провайдером и локальной (On-prem) средой для базы данных PostgreSQL (и других различных технологий), а также управлять настройкой простым и удобным способом. Обмен данными между облачными провайдерами или между Частным (Private) и Публичным (Public) облаками из соображений безопасности должен ограничивать трафик и использовать только известные источники, чтобы снизить риск несанкционированного доступа к вашей сети.


Узнать подробнее о курсе "PostgreSQL".

Смотреть вебинар Блокировки.

Подробнее..

Что такое транзакция

16.01.2021 00:08:21 | Автор: admin

Транзация это набор операций по работе с базой данных (БД), объединенных в одну атомарную пачку.

(Предполагается, что вы знаете, что такое БД. Но чуть позже тут будет ссылка на статью что это такое)

Транзакционные базы данных (базы, работающие через транзакции) выполняют требования ACID, которые обеспечивают безопасность данных. В том числе финансовых данных =) Поэтому разработчики их и выбирают.

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

Содержание

Что такое транзакция

Транзакция это архив для запросов к базе. Он защищает ваши данные благодаря принципу всё, или ничего.

Представьте, что вы решили послать другу 10 файликов в мессенджере. Какие есть варианты:

  1. Кинуть каждый файлик отдельно.

  2. Сложить их в архив и отправить архив.

Вроде бы разницы особой нет. Но что, если что-то пойдет не так? Соединение оборвется на середине, сервер уйдет в ребут или просто выдаст ошибку...

В первом случае ваш друг получит 9 файлов, но не получит один.

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

Казалось бы, ну недополучил файлик, что с того? А если это критично? Если это важные файлики? Например, для бухгалтерии. Потерял один файлик? Значит, допустил ошибку в отчете для налоговой. Значит, огребешь штраф и большие проблемы! Нет, спасибо, лучше файлы не терять!

И получается, что тебе надо уточнять у отправителя:

Ты мне сколько файлов посылал?

10

Да? У меня только 9... Давай искать, какой продолбался.

И сидите, сравниваете по названиям. А если файликов 100 и потеряно 2 штуки? А названия у них вовсе не Отчет 1, Отчет 2 и так далее, а hfdslafebx63542437457822nfhgeopjgrev0000444666589.xml и подобные... Уж лучше использовать архив! Тогда ты или точно всё получил, или не получил ничего и делаешь повторную попытку отправки.

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

Допустим, вы переводите все деньги с одной карточки на другую. Выглядит это "внутри" системы как несколько операций:

delete from счет1 where счет = счет 1

insert into счет2values ('сумма')

Принцип всё или ничего тут очень помогает. Было бы обидно, если бы деньги со счета1 списались, но на счет2 не поступили... Потому что соединение оборвалось или вы в номере счета опечатались и система выдала ошибку...

Но благодаря объединению запросов в транзакцию при возникновении ошибки зачисления мы откатываем и операцию списания. Деньги снова вернулись на счет 1!

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

Как отправить транзакцию

Чтобы обратиться к базе данных, сначала надо открыть соединение с ней. Это называется коннект (от англ. connection, соединение). Коннект это просто труба, по которой мы посылаем запросы.

Чтобы сгруппировать запросы в одну атомарную пачку, используем транзакцию. Транзакцию надо:

  1. Открыть.

  2. Выполнить все операции внутри.

  3. Закрыть.

Как только мы закрыли транзакцию, труба освободилась. И ее можно переиспользовать, отправив следующую транзакцию.

Можно, конечно, каждый раз закрывать соединение с БД. И на каждое действие открывать новое. Но эффективнее переиспользовать текущие. Потому что создание нового коннекта тяжелая операция, долгая.

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

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

Как открыть транзакцию

Зависит от базы данных. В Oracle транзакция открывается сама, по факту первой изменяющей операции. А в MySql надо явно писать start transaction.

Как закрыть транзакцию

Тут есть 2 варианта:

  1. COMMIT подтверждаем все внесенные изменения;

  2. ROLLBACK откатываем их;

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

Например, я пишу запрос:

insert into clients (name, surname) values ('Иван', 'Иванов');-- добавь в таблицу клиентов запись с именем Иван и фамилиев Иванов

Запрос выполнен успешно, хорошо! Теперь, если я сделаю select из этой таблицы, прям тут же, под своим запросом он находит Иванова! Я могу увидеть результат своего запроса.

Но! Если открыть графический интерфейс программы, никакого Иванова мы там не найдем. И даже если мы откроем новую вкладку в sql developer (или в другой программе, через которую вы подключаетесь к базе) и повторим там свой select Иванова не будет.

А все потому, что я не сделала коммит, не применила изменения:

insert into clients (name, surname) values ('Иван', 'Иванов');commit;

Я могу добавить кучу данных. Удалить полтаблицы. Изменить миллион строк. Но если я закрою вкладку sql developer, не сделав коммит, все эти изменения потеряются.

Когда я впервые столкнулась с базой на работе, я часто допускала такую ошибку: подправлю данные на лету для проведения теста, а в системе ничего не меняется! Почему? Потому что коммит сделать забыла.

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

Если имя = Тест

И фамилия = Тестовый

...

Удалили. Делаем select count посмотреть количество записей в таблице. А там вместо миллиона строк осталось 100 тысяч! Если база реальная, то это очень подозрительно. Врядли там было СТОЛЬКО тестовых записей.

Проверяем свой запрос, а мы там где-то ошиблись! Вместо И написали ИЛИ, или как-то еще. Упс... Хорошо еще изменения применить не успели. Вместо коммита делаем rollback.

Тут может возникнуть вопрос а зачем вообще нужен ROLLBACK? Ведь без коммита ничего не сохранится. Можно просто не делать его, и всё. Но тогда транзакция будет висеть в непонятном статусе. Потому что ее просто так никто кроме тебя не откатит.

Или другой вариант. Нафигачили изменений:

Удалить все строки, где имя Иван;

Поменять код города с 495 на 499;

....

Но видим, что операцию надо отменять. Проверочный select заметил, что база стала неконсистентной. А мы решили Ай, да ладно, коммит то не сделали? Значит, оно и не сохранится. И вернули соединение в пул.

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

Так что лучше сразу сделайте откат. Здоровей система будет!

Итого

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

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

Чтобы отправить транзакцию к базе, нам нужно создать соединение с ней. Или переиспользовать уже существующее. Соединение называют также коннект (англ connection) это просто труба, по которой отправляются запросы. У базы есть пул соединений место, откуда можно взять любое и использовать, они там все свободные.

В некоторых системах транзакцию нужно открыть, в других она открывается сама. А вот закрыть ее нужно самостоятельно. Варианты:

  1. COMMIT подтверждаем все внесенные изменения;

  2. ROLLBACK откатываем их;

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

Не путайте соединение с базой (коннект) и саму транзакцию. Коннект это просто труба, операции (update, delete) мы посылаем по трубе, старт транзакции и commit /rollback это группировка операций в одну атомарную пачку.

PS больше полезных статей ищите в моем блоге по метке полезное. А полезные видео на моем youtube-канале

Подробнее..

Backend веб-сервиса в базе данных. Как заложить бизнес логику и сделать микросервси-ретранслятор для API фронтенду

27.01.2021 14:17:26 | Автор: admin
Эта статья будет рассказывать как организовать легкое проектирование бизнес логики веб-сервиса в базе данных на встроенном PL-SQL.
Я расскажу как сделать простой сервис ретранслятор для фронтенда (пример будет на php), а так же как легко проектировать в базе аналог API и регистрировать это для ретрансляции фронтенду.


PS: пример бекенда и фронтенда будет на PHP, база данных firebird. Но это не обязательно, можно использовать любой язык программирования и любую БД.


PS: Прошу шапками не закидывать. Знаю, сейчас это не популярно, в силу определенных общественных причин, специалистов по PHP или Python на рынке больше чем SQL-программистов, они стоят дешевле, все любят ОРМ. Считается что при закладке логики в базе сложнее организовать микросервсиную архитектуру. Go компилируется и должен работать быстрее чем БД. Популярно закладывать бизнес логику в фреймворках на php и т.п.
Причин много и у всех есть аргументы и с одной и с другой стороны, и абсолютно по каждому можно глубоко поспорить.
Но эта статья для тех, кто хочет задавать бизнес логику именно в базе, считая что это проще и более эффективно. Здесь нет цели пропагандировать такой способ. Отвечать на комментарии призывающие поднять срач по поводу что лучше или хуже не буду.


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

CREATE TABLE DFM_PROC (    ID           INTEGER NOT NULL,    NAME         VARCHAR(70) NOT NULL,    DISCRIPTION  VARCHAR(1000));


Например:
image

Схема следующая:
image

Здесь мы будем рассматривать как организовать работу микросервиса Service for interface.

Пример фронтенда приведу на php

function ser1($proc_id,$json){//Формируем запрос к микросервису$post='hash='.$_SESSION['sess_id'].'&user_id='.$_SESSION['id_user'].'&proc_id='.$proc_id.'&json='.base64_encode($json);//Адрес микросервиса$url = 'http://192.168.128.1/ser.php'; $ch = curl_init();    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);    curl_setopt($ch, CURLOPT_URL, $url);    curl_setopt($ch, CURLOPT_POST , true);    curl_setopt($ch, CURLOPT_POSTFIELDS ,$post);    $result = curl_exec($ch);    $arr_res=json_decode($result,true);curl_close($ch);return $arr_res;}//В фронтенде например при обработке нажатия кнопки формируем запрос к бекенду//В данном примере будет создаваться новый профиль юзера//Процедура 4 - добавляет новый профиль в нашем примереif (isset($_POST['go_new_prof'])){    unset($arr);    $arr['0']=$_SESSION['id_user'];    $arr['1']=(int)$_GET['tp'];    $arr['2']=(int)$_POST['lang_list'];    $arr_prof=ser1(4,json_encode($arr));}


Пример вызываемой процедуры на SQL

create or alter procedure DFM_PROF_ADD (    USER_ID smallint,    TYPE_ varchar(10),    LANG smallint)asbegin  INSERT INTO DFM_PROFILES (USER_ID, TYPE_, LANG)    VALUES (:USER_ID, :TYPE_, :LANG);  suspend;end


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

<?php$proc_id=(int)$_POST['proc_id'];$json= base64_decode($_POST['json']);$arr_json = json_decode($json,true);//Валидируем JSONswitch (json_last_error()) {   case JSON_ERROR_NONE:      $err = null;   break;   case JSON_ERROR_DEPTH:      $err = 'Достигнута максимальная глубина стека';   break;   case JSON_ERROR_STATE_MISMATCH:      $err = 'Некорректные разряды или не совпадение режимов';   break;   case JSON_ERROR_CTRL_CHAR:      $err = 'Некорректный управляющий символ';   break;   case JSON_ERROR_SYNTAX:      $err = 'Синтаксическая ошибка, не корректный JSON';   break;   case JSON_ERROR_UTF8:      $err = 'Некорректные символы UTF-8, возможно неверная кодировка';   break;   default:      $err = 'Неизвестная ошибка';   break;}//Выполняем только если нет ошибки JSONif ($err==null) {      //Перед всем этим кодом авторизируйте юзера и задайте его ID   $user_id=1;   //Получаем название процедуры по ее ID   $sql_proc = "select p.name from DFM_PROC p where p.id=".$proc_id;   $res_proc = ibase_query($dbh, $sql_proc);   $prom_proc = ibase_fetch_row($res_proc);      //Начинаем формировать текст запроса в базу   $sql_in='select ';      //Получаем исходящие параметры процедуры,    //в служебной таблице RDB$PROCEDURE_PARAMETERS содержится название входящих и исходящих параметров процедуры   $sql = 'select pp.rdb$parameter_number, pp.rdb$parameter_name from DFM_PROC pleft join RDB$PROCEDURE_PARAMETERS pp on pp.rdb$procedure_name=UPPER(p.name)where p.id='.$proc_id.' and pp.rdb$parameter_type=1 --исходящиеorder by pp.rdb$parameter_number';   $res = ibase_query($dbh, $sql);   $i_cou_out=0;   while($prom = ibase_fetch_row($res))   {      //p. - это будет ниже мнемоника процедуры      $i_cou_out++;      if ($prom[0]>0) $sql_in.=',';       $sql_in.='p.'.$prom[1];            $name_out[$prom[0]]=$prom[1];   }      //После того как сформировали строку с параметрами идем дальше в формировании запроса - вбиваем название процедуры   $sql_in.=' from '.$prom_proc[0];      //Если ответа быть не должно, а чисто выполнение процедуры, то делаем execute procedure   if ($i_cou_out==0) $sql_in='execute procedure '.$prom_proc[0];      //заполняем входящие параметры с учетом типа данных   $sql = 'selectpp.rdb$parameter_number,pp.rdb$parameter_name,case   when f.rdb$field_type=7 then 1 --smalint   when f.rdb$field_type=8 then 2 --integer   when f.rdb$field_type=16 and f.rdb$field_scale=0 then 3 --bigint   when f.rdb$field_type=16 and f.rdb$field_scale<0 then 4 --frloat   when f.rdb$field_type=12 then 5 --date   when f.rdb$field_type=13 then 6 --time   when f.rdb$field_type=35 then 7 --timestamp   when f.rdb$field_type=37 then 8 --varcahrend,f.rdb$field_type, --тип данныхf.rdb$character_length, --длина текстаf.rdb$field_precision, --целых знаковf.rdb$field_scale --дробных знаковfrom DFM_PROC pleft join RDB$PROCEDURE_PARAMETERS pp on pp.rdb$procedure_name=UPPER(p.name)left join RDB$FIELDS f on f.rdb$field_name=pp.rdb$field_sourcewhere p.id='.$proc_id.' and pp.rdb$parameter_type=0 --входящиеorder by pp.rdb$parameter_number';   $res = ibase_query($dbh, $sql);               $i_cou=0;   while($prom = ibase_fetch_row($res))   {      $i_cou++;      if ($prom[0]>0)  $sql_in.=','; else $sql_in.='(';                  if (($prom[2]==5)or($prom[2]==6)or($prom[2]==7)or($prom[2]==8))         //Обрабатываем параметры где нужны кавычки         //Елси пришла пустота подставляем null         if ($arr_json[$prom[0]]=='')            $sql_in.="null";         else            $sql_in.="'".($arr_json[$prom[0]])."'";      else         //Обрабатываем параметры без кавычек         if ($arr_json[$prom[0]]=='')            $sql_in.="null";         else            $sql_in.=($arr_json[$prom[0]]);         }      //Закрываем входящие параметры процедуры   if ($i_cou_out==0)      {if ($i_cou>0) $sql_in.=')';}   else      {if ($i_cou>0) $sql_in.=') p'; else $sql_in.=' p';}      //Тут задали мнемонику p. для исходящих параметров      //Выполняем процедуру   $res_in = ibase_query($dbh, $sql_in);         if ($i_cou_out==0)   {      //Задаем ответ фронтенду если execute procedure      $json_out='{"error_json":"","error_code_json":"","result":"выполнено execute procedure","result_code":0}';    }   else   {      //Заполняем в json ответ фронтенду      $i_json=0;      $json_out='{';      while($prom_in = ibase_fetch_row($res_in))      {         if ($i_json>0) $json_out.=',';         $json_out.='"'.$i_json.'":{';         foreach($prom_in as $k => $v)         {            if ($k>0) $json_out.=',';            $json_out.='"'.trim($name_out[$k]).'":"'.$v.'"';         }         $json_out.='}';         $i_json++;      }      $json_out.='}';   }      //Если процедура была выполнена с ошибкой - отправляем код ошибки, если нет, то результат   if (ibase_errmsg()=='')   {      //Результат для фронтенда      echo $json_out;      }   else   {      //Код ошибки для фронтенда      $err_json='{"error_json":"'.$err.'","error_code_json":'.json_last_error().',"result":"'.str_replace('"','\'',ibase_errmsg()).'","result_code":2,"sql_err":"'.$sql_in.'"}';      echo $err_json;   }               }else {   //Код ошибки валидации входящего JSON   $err_json='{"error_json":"'.$err.'","error_code_json":'.json_last_error().',"result":"Ошибка json","result_code":3}';   echo $err_json;      }?>


Что получаем в итоге.

1) Микросервис-рестранслятор пишем 1 раз. Все остальное проектирование архитектуры бекенда происходит в базе. В PHP (или Go, Python- на чем будет микросервис) мы больше не лезем.
Например понадобилась новая фишка на сайте делается фронтенд, делается процедура. Процедура регистрируется в табличке и фронтенд по ее регистрационному номеру обращается к API микросервиса. ВСЕ.

Рекомендую микросервис-ретранслятор писать на Go как на компилируемом и существенно более быстром. Преимущество в том что это надо написать только 1 раз и программа не сложна. При этом это будет высоконагруженный элемент, к которому происходят интенсивные обращения.
Библиотека для подключения firebird к goland: https://github.com/nakagami/firebirdsql

2) Вся обработка уходит в процедуры мы получаем компилированные элементы, которые обрабатывают все на уровне базы данных и выдают РЕЗУЛЬТАТ. Т.е. если операция состоит из нескольких select, insert, update и т.п. мы не гоняем данные по сети к бекенду, а сразу обрабатываем в базе.
Плюс процедура компилированный элемент с сформированным планом запроса. На это тоже ресурсы не тратятся.

3) Микросервис ретарнслятор чтобы сформировать процедуру обращается в базу данных 4 раза.
1. Получает ее название
2. Получает ее исходящие параметры
3. Получает ее входящие параметры
4. Выполняет процедуру
4 раза, потому что рассмотрели универсальный способ. Это можно сократить до одного раза.

Как:
1. Это можно хранить локально в тектовике на веб сервере например. Периодически просто дергая эту таблицу и обновляя когда добавляется новое.
2,3. Аналогично можно хранить локально, дергая все это когда что-то обновляется.

4) Не весь бекенд можно сделать на базе данных! Это существенная часть всего, но надо руководствоваться соображениями целесообразности.
Например какие-нибудь чаты, рассылки и т.п. стороны жизни веб-сервиса конечно надо делать отдельными микросервисами на языке программирования, наиболее удобного для этого. Не надо всю логику веб-сверсиса перенсить в базу во чтобы это ни стало! Надо переносить только ту часть, которая удобна для этого!
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru