Дизайн системы: несколько клиентов базы данных или прокси и меньше подключений к базе данных

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

Мой вопрос заключается в том, было бы лучше, если бы каждая система подключалась напрямую к базе данных и вставляла (это единственная необходимая операция) данные или отправляла их на сервер с помощью сервера обмена сообщениями, такого как ie. HornetQ и иметь один (или несколько) экземпляр программного обеспечения, потребляющего данные из HornetQ и записывающего их в систему базы данных?

Я хотел бы знать, как эти два подхода сравниваются с точки зрения стоимости ЦП/памяти и масштабируемости, особенно на стороне сервера системы (т.е. системы баз данных предназначены для обслуживания большого количества клиентов).


person Vitor    schedule 01.02.2016    source источник


Ответы (2)


Преимущества использования промежуточной очереди сообщений:

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

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

person Paulo Pedroso    schedule 02.02.2016

person    schedule
comment
Есть ли у вас какие-либо ссылки, подтверждающие это? Иметь 1000 одновременных записывающих клиентов для базы данных - плохая идея ни в каком мире. Кроме того, в чем проблема с автоинкрементными полями в этом сценарии? - person Vitor; 03.02.2016
comment
В конце дня вы пишете на диск. Я не уверен, сколько данных вы должны записать, но каждый из ваших писателей, по крайней мере, подождет, пока disk io завершит операцию записи. Также будут накладные расходы из-за подключений к базе данных 1K и т. д., если вы попытаетесь вставить в одну и ту же таблицу с 1000 одновременных потоков, каждый из которых должен ждать получения автоматически увеличивающегося идентификатора, и есть какой-то мьютекс для предотвращения дублирования идентификатора на стороне базы данных AFAIK. - person cool; 03.02.2016