Возможно ли управление очень большим параллелизмом? - PullRequest
0 голосов
/ 22 января 2019

В последнее время я создаю API REST как часть назначения, где я предполагаю увеличить счетчик в таблице базы данных, предполагая, что таблица имеет только один столбец, и я предполагаю, что к этому API REST будет выполняться 1000 запросов в секунду. чтобы увеличить счетчик, и в конце данные должны быть согласованы, т. е. если изначально значение счетчика в БД равно 0, то после успешного выполнения 1000 запросов одновременно оно должно быть 1000.

Пока не беспокойтесь, я достиг этого с помощью блокировки на уровне строки базы данных, другим способом могло бы стать использование транзакции (с максимальной изоляцией) вокруг кода, который увеличивает счетчик, но я заметил, что его можно поддерживать согласованность, но это достигается ценой высокой задержки, например, я запускаю тест Jmeter с 1000 req / sec в течение 5 секунд, и все запросы полностью выполняются примерно за 26 секунд, что действительно огромная задержка.

Это вызвало у меня много вопросов -

  1. Там должны быть некоторые сценарии или приложения в реальном времени, где этот уровень высокий параллелизм обрабатывается с низкой задержкой, не так ли?

  2. Всегда ли это ограничение в реляционной базе данных и может быть каким-то образом решил нереляционную базу данных nosql?

  3. Я думал, что стоит ставить в очередь такие параллельные запросы с каким-то сообщением очереди, но опять же, это будет поведение не в реальном времени, если пользователь в ожидании ответа

Заранее спасибо, любая помощь приветствуется.

Ответы [ 3 ]

0 голосов
/ 22 января 2019

Должны быть некоторые сценарии или приложения в реальном времени, где этот уровень высокого параллелизма обрабатывается с низкой задержкой, не так ли?

Вы хотите просмотреть литературу по использованию структуры данных кольцевого буфера для обмена сообщениями с помощью LMAX.

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

0 голосов
/ 05 февраля 2019

«Ограничение» не имеет ничего общего с тем, что базы данных являются «реляционными» (или нет).

Суть вашего сценария в том, что вы не можете начать добавлять 1 (например, чтобы получить 3) до того, как предыдущий актер закончил добавлять 1, чтобы получить 2, и полностью завершил и зафиксировал это изменение. Если 2 + 1 = 3, вы не можете начать вычисление до тех пор, пока оба значения не будут доступны и надежны. Поэтому, если 2 является результатом какого-либо другого действия, вы не сможете начать, пока это другое действие не завершится полностью.

Это [иногда] называется "синдром конвоя", и это может произойти практически в любой технологии.

Там есть множество магазинов, где они делают внешне похожие вещи с "высокой валютой", но либо они добьются этого избегая любой формы общего центрального ресурса, вызывающего синдром конвоя (например, ваш счетчик), или они достигнут его путем пожертвования ваша гарантия «должна закончиться 1000».

0 голосов
/ 22 января 2019

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

Дело в том, что все это сводится к операциям ввода-вывода. Чтобы гарантировать, что ваша транзакция записана на 100% и не может быть потеряна, базы данных обычно сбрасывают данные на диск. В зависимости от того, какие у вас диски, это занимает очень много времени в диапазоне миллисекунд.

Итак, на ваши вопросы:

  1. Приложения с высоким параллелизмом обычно избегают транзакций, строгих гарантий или, по крайней мере, операций ввода-вывода для каждого запроса.
  2. Да, существует множество нереляционных баз данных, которые не выполняют сброс для каждого запроса или не сохраняют данные в памяти полностью.
  3. Очереди или другие уловки не могут решить фундаментальную проблему IO / второго узкого места.

Вы можете достичь своей цели, переключившись на SSD как диски, теоретически они могут достигать 1000 с / с, тогда как вращающийся диск работает со скоростью не более 100 с / с. Затем вы должны убедить свою базу данных сделать как можно меньше iops для одного запроса.

...