Невозможна ли обработка очень большого параллелизма?

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

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

Теперь это создало много вопросов в моей голове -

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

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

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

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


rest concurrency relational-database consistency
person Bruce_Wayne    schedule 22.01.2019    source источник

Ответы (3)


arrow_upward
2
arrow_downward

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

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

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

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

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

person Robert Bräutigam    schedule 22.01.2019
comment
Brautigam, говоря о масштабировании оборудования, вы имели в виду переход только на SSD, верно? или есть какие-то другие способы, о которых вы говорите? - person Bruce_Wayne; 22.01.2019
comment
@Bruce_Wayne Есть несколько вариантов. Вы можете ввести SSD, вы можете попробовать использовать несколько устройств в какой-то конфигурации RAID, программно или аппаратно. Вы можете использовать специализированное внешнее оборудование для хранения данных с высокой скоростью ввода-вывода в секунду. - person Robert Bräutigam; 22.01.2019

arrow_upward
2
arrow_downward

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

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

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

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

person Erwin Smout    schedule 05.02.2019

arrow_upward
0
arrow_downward

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

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

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

person VoiceOfUnreason    schedule 22.01.2019