metaclass (metaclass) wrote,
metaclass
metaclass

Асинхронный UI оперденей

А скажите, как сейчас у нормальных людей (т.е. не пост-советское ИТ для пост-советских госконтор, не попильные хипстер-социальные сети, не доисторические ERP-системы выдаваемые внедренцами за элитный товар) обстоят дела с асинхронными запросами к БД и их отображением?

Ну т.е., вот некий юзер делает из своей опердени запрос к небольшой реляционной БД (10-100 гб), запущенной на обычном soho-сервере, т.е. никаких сука датацентров и амазонов на 1000 инстансов с мап-редьюсами, никаких графовых БД, оптимизированных под запросы "как показать френдов, которые запостили фотки котиков едящих блинчики и рядом рекламу муки для блинов и одежды для котиков", обычная тупая двух-трехзвенная опердень на 10-100 человек юзеров и скукота вроде "дайте мне оборотную ведомость по клиентам".

Как это выглядит там, где инженерные решения не застряли на уровне фокспро и дельфей 1995 года? Есть ли прогресс-бары? Есть ли статус выполнения запроса в стиле "читаю 50/100 гб базы, аггрегирую, сожрав 60% памяти сервера и буду еще работать 30 минут"? Есть ли отмена запроса без извращений вроде "подключится еще раз, найти в мониторинг таблицах свое подключение и удалить его"? Есть ли возможность поставить тяжелый запрос в очередь и пойти делать отчеты дальше, периодически поглядывая на статус выполняющегося запроса (в том же приложении, а не запуская 10 инстансов, по одному на тяжелый запрос)?

Я просто вот про все вышеописанное подумываю, как бы сделать без особой боли, но может уже давно это все отменили еще в прошлом веке, давно все готовые СУБД и сервера приложений умеют, а мы тут до сих пор в лесу воюем, да поезда под откос пускаем, по белорусскому обычаю?
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 41 comments
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →