На сколько следующий код подходит для тяжелых операций с БД?

Question

[beduin01]

Не думаю что язык сильно принципиален. Устроят советы Шарпистов и тех кто на Dart пишет. Оригинал кода на Dart. Но думаю он всем предельно понятен будет.

Database db;

void main() async {
  db = Database();

  var pidFile = File("pid.txt");
  pidFile.writeAsStringSync(pid.toString());

  connection = PostgreSQLConnection('localhost', 5432, 'db', username: 'postgres', password: '123456', queryTimeoutInSeconds: 30);
  await connection.open();

  app.post('/db', (req, res) async {
    var r = await db.someLongDBOperation(req.body);
    return res.json({"data": r});
  });  

 }

Вопрос в следующем. На сколько этот код оптимален с точки зрения выполнения каких-то тяжелых операций с БД? Имеет ли смысл использовать Изоляты (или отдельные потоки если говорим о C#)?

Паттерн использования такой. На хэндлер летит огромное количество запросов на вставку в БД. `someLongDBOperation` соответственно их обрабатывает.

Какие могут быть узкие места и как их исправить?

Comments

[Василий Банников]

так у вас дарт или c#? про что именно вопрос?

Answer 1

[Василий Банников]

Если операция очень долгая, то у клиента может произойти таймаут.

Comments

[beduin01]

Как его избежать?

[Василий Банников]

beduin01, Просто вы выполнять осень долгие операции вместе с основным запросом.
Очень долгие - это больше 5 секунд, и при этом клиенту не обязательно сразу получить результат операции.

[Владимир Коротенко]

beduin01, в коннекшкн стринге указываете время, в авите указываете то же время, ну и желательно CancelationToken для корректной обработки отказа

[Василий Банников]

Владимир Коротенко, а кто человеку скажет, что это нормально, что у него страница 30 сек грузится?

[Владимир Коротенко]

Василий Банников, страницу лучше отдавать скелетом, а все долгоиграющее подгружать со спинерами. Я так вижу это самый оптимальный путь.

[Василий Банников]

Владимир Коротенко, большинство браузеров сами по себе бывает убивают долгие запросы.

[beduin01]

Василий Банников, предлагаете отдельный хэндлер сделать куда посылать потенциально долгие запросы?

[Василий Банников]

beduin01, я предлагаю сначала разобраться, почему запросы долгие, и чем они отличаются от недолгих.

var r = await db.someLongDBOperation(req.body);
    return res.json({"data": r});

Вот такой код в принципе выглядит очень подозрительно. Будто вы в теле запроса тупо SQL передаёте.

[Владимир Коротенко]

Василий Банников, что то я про это не слышал. Регулярно вижу в консоли тупящие по 2-3 минуты

[Василий Банников]

Владимир Коротенко, мб это как-то решается. Тут я не уверен.

[beduin01]

Василий Банников, да так и есть, я в теле передаю запросы. Но у меня сервер изолированный и опасности инъекций нет. Запросы только от специальной софтины принимаются.

[Василий Банников]

beduin01, тогда ок, ничего трогать не нужно.

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

Answer 2

[Владимир Коротенко]

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

Comments

[beduin01]

Нагрузка равномерная.

[Владимир Коротенко]

beduin01, тогда без шаманства не обойтись. Смотрите допустим есть запрос который длится 1 секунду в минуту вы сможете обслужить 60 клиентов в идеале. Как другой вариант кидайте сырые данные в бд и оставляйте номер запроса. Клиенту уходит этот номер и в дальнейшем он может проверить статус данной работы.

[beduin01]

Владимир Коротенко, у меня клиентов как таковых нет. У меня специальная софтина XML в SQL INSERT преобразовывает. Работает в 4 потока.

[Владимир Коротенко]

beduin01, а кто вам сказал что в 4 потока оно быстрее будет? Переделайте в один поток и отправляйте данные в пакетах, пакетная вставка сильно быстрее. Кроме этого если используется ORM отключите контроль изменения данных это сильно убыстрит процесс. Наиболее ультимативный способ переписать все на daper в сочетании с пакетной вставкой

[beduin01]

Владимир Коротенко, Каждый генератор XML2SQL берет свой джоб. 4 потока по т.к. на процессоре 6 ядер.
Пакетную вставку не могу т.к. мне тогда нужно где-то аккумулировать все прилетевшие данные. И нужно логику по его хранению писать и потенциально 1 на 10000 записей может иметь дубликат, тогда у меня операция пакетной вставки упадет. А если пофайлово обрабатывать, то если вдруг что не так, то я четко знаю где проблема

Answer 3

[Виталий Качан]

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

Comments

[beduin01]

А как их собирать на сервере? Мне прилетает набор SQL INSERT в виде текста. Есть какие-то инструменты?
У меня еще проблема в том, что в данных потенциально могут быть дубликаты (1 на 10000 запросов). Если вставка падает из-за дубликата, я выполняю удаление дубликатов и повторяю операцию вставки.

[Виталий Качан]

Переделывать то, что прилетает. Т.е. не SQL Insert принимать (потенциальная SQL-инъекция), а данные, на основе которых строить запрос в БД. Иначе только парсить.

[Виталий Качан]

beduin01, если прилетать будут данные и есть проблема с дубликатами - то перед вставкой сделать SELECT запрос можно на проверку.

[beduin01]

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