Возможно ли управление очень большим параллелизмом?

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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