Mm
А бекапы и так надо делать, кронджобом хотябы
И желательно не туда же где висит бд :D
Size: a a a
2019 November 16
TS
Victor
Нормальный кейс как по мне через монго компас подключиться к прод базе чтоб например посмотреть красивые графики.
Датасеты для графиков должен генерировать сервер приложений и отдавать через апи или система мониторинга и заливать в сервис мониторинга
Mm
Датасеты для графиков должен генерировать сервер приложений и отдавать через апи или система мониторинга и заливать в сервис мониторинга
Что я и говорил, если это прод, то там по любому уже настроена система для мониторинга и визуализации, и прикрутить туда монгу не является проблемой
V
Ну я лично пользовался этой функциональностью компаса и чем это может навредить не вижу
Mm
Подключением к прод базе снаружи
V
Ну я по ссх тоже могу зайти на прод, какая разница
TM
В базе могут быть данные по клиентам. У нас так вообще к продовской базе имел доступ только админ, остальные пользовались репликой с затертыми данными на тестовом серве
O
Всем привет, есть задача, например раз в минуту доставать из базы все документы с определенным статусом, обращаться по каждому к 3d party api - проверять не изменился ли у них статус, и если изменился, стучаться в еще одно 3d party api и обновлять их статус в бд. Решение в лоб - заскедулить кроном, доставать все доки и по каждому осуществлять необходимые действия - понятно. Но мне кажется это плохой путь, особенно если учесть, что кол-во таких документов может расти и до сотен, и до тысяч, а 3d party api позволяет проверить только статус одного документа за один запрос. Может кто-то встречал или знает какие-то более оптимальные и производительные решения подобных задач? Буду благодарен за любые наводки, спасибо. Из первого что приходит в голову - писать под это отдельный микросервис и скейлить инстансами в зависимости от количества доков, но раньше ничего подобного не делал
BY
Всем привет, есть задача, например раз в минуту доставать из базы все документы с определенным статусом, обращаться по каждому к 3d party api - проверять не изменился ли у них статус, и если изменился, стучаться в еще одно 3d party api и обновлять их статус в бд. Решение в лоб - заскедулить кроном, доставать все доки и по каждому осуществлять необходимые действия - понятно. Но мне кажется это плохой путь, особенно если учесть, что кол-во таких документов может расти и до сотен, и до тысяч, а 3d party api позволяет проверить только статус одного документа за один запрос. Может кто-то встречал или знает какие-то более оптимальные и производительные решения подобных задач? Буду благодарен за любые наводки, спасибо. Из первого что приходит в голову - писать под это отдельный микросервис и скейлить инстансами в зависимости от количества доков, но раньше ничего подобного не делал
лучше серверлес, напиши три лямбдочки и пусть общаються через шину. имхо
O
лучше серверлес, напиши три лямбдочки и пусть общаються через шину. имхо
большое спасибо, посмотрю в этом направлении
B
лучше серверлес, напиши три лямбдочки и пусть общаються через шину. имхо
Лямбдочки амазоновские?
BY
Лямбдочки амазоновские?
да
B
Он не только для сервисов Амазон ?
BY
Он не только для сервисов Амазон ?
не понял вопрос до конца. мы используем serverless фреймворк, запускать лямбды можеш на любом провайдере, аля ажур или гугл клауд
https://serverless.com/
https://serverless.com/
2019 November 17
AS
Всем привет, есть задача, например раз в минуту доставать из базы все документы с определенным статусом, обращаться по каждому к 3d party api - проверять не изменился ли у них статус, и если изменился, стучаться в еще одно 3d party api и обновлять их статус в бд. Решение в лоб - заскедулить кроном, доставать все доки и по каждому осуществлять необходимые действия - понятно. Но мне кажется это плохой путь, особенно если учесть, что кол-во таких документов может расти и до сотен, и до тысяч, а 3d party api позволяет проверить только статус одного документа за один запрос. Может кто-то встречал или знает какие-то более оптимальные и производительные решения подобных задач? Буду благодарен за любые наводки, спасибо. Из первого что приходит в голову - писать под это отдельный микросервис и скейлить инстансами в зависимости от количества доков, но раньше ничего подобного не делал
Крон и очереди вам в помощь(rabbitMQ) . Как по мне самый оптимальный вариант.
O
Крон и очереди вам в помощь(rabbitMQ) . Как по мне самый оптимальный вариант.
Большое спасибо! 👍
O
Всем привет, есть задача, например раз в минуту доставать из базы все документы с определенным статусом, обращаться по каждому к 3d party api - проверять не изменился ли у них статус, и если изменился, стучаться в еще одно 3d party api и обновлять их статус в бд. Решение в лоб - заскедулить кроном, доставать все доки и по каждому осуществлять необходимые действия - понятно. Но мне кажется это плохой путь, особенно если учесть, что кол-во таких документов может расти и до сотен, и до тысяч, а 3d party api позволяет проверить только статус одного документа за один запрос. Может кто-то встречал или знает какие-то более оптимальные и производительные решения подобных задач? Буду благодарен за любые наводки, спасибо. Из первого что приходит в голову - писать под это отдельный микросервис и скейлить инстансами в зависимости от количества доков, но раньше ничего подобного не делал
Доброго! Якщо в БД є щось типу "id" документів, то може варто глянути в сторону "витягуваннятільки id-шок". За умови великих документів, може вийти доволі великий трафік до обміну з БД. В ряді БД є "аналог" циклу - курсор і певні БД з "вміють" працювати з http-запитами як в ролі сервера, так і клієнта. І запускати "сервіс" мабуть варто "поближче" до БД, якщо контроль за ними є...
ES
Всем привет, есть задача, например раз в минуту доставать из базы все документы с определенным статусом, обращаться по каждому к 3d party api - проверять не изменился ли у них статус, и если изменился, стучаться в еще одно 3d party api и обновлять их статус в бд. Решение в лоб - заскедулить кроном, доставать все доки и по каждому осуществлять необходимые действия - понятно. Но мне кажется это плохой путь, особенно если учесть, что кол-во таких документов может расти и до сотен, и до тысяч, а 3d party api позволяет проверить только статус одного документа за один запрос. Может кто-то встречал или знает какие-то более оптимальные и производительные решения подобных задач? Буду благодарен за любые наводки, спасибо. Из первого что приходит в голову - писать под это отдельный микросервис и скейлить инстансами в зависимости от количества доков, но раньше ничего подобного не делал
а у первого 3rd party API случайно нет возможности использовать вебхук, чтобы не ВЫ каждую минуту их спрашивали не изменилось ли чего, а ОНИ слали вам на вебхук когда что-то изменилось
O
І частота обрана - може вийти доволі "дорогою" для обчислення. Бажано додати перевірку, чи завершилась "попередня ітерація."
ES
Вопрос:насколько сильно уже считается "плохим тоном" node.js проект без Dependency Injection? 100 лет жили без него, писали без DI, и тут я слышу "ооо тут даже DI нет". Ну да, если проекту 3+ лет и его не рефакторили то DI нет