В настоящее время мы оцениваем службу базы данных SQL Azure (по сравнению с локальной установкой), поскольку мы хотели бы, чтобы функция «Всегда зашифрованная» была интегрирована в наше (основанное на Java) приложение.
Проблема в том, что выступления ужасные.
Я подключаюсь с физического сервера, расположенного в том же районе (Париж), к базе данных, созданной в регионе «Центральная Франция».
Я написал очень простое java-приложение, которое выполняет 5000 вставок (подготовленных операторов) в очень простую таблицу, используя драйвер Microsoft jdbc и предоставленную Azure строку подключения.
Это займет около минуты, независимо от типа базы данных SQL, которую я использую (последний тест с S6 Standard). Приложение Java работало на производственном сервере (8 ядер). Я бы ожидал некоторой задержки при использовании удаленной базы данных, но не до этого уровня. (тот же тест выполняется за 5 секунд с SQL Server на локальном сервере).
Этого и следовало ожидать? Я думал, что наш случай был рассмотрен службой базы данных SQL (удаленный сервер SQL). Я также создал виртуальную машину в том же регионе, подключившись через общедоступный IP-адрес базы данных, и это было почти так же плохо. Я пробовал создавать базы данных SQL в других европейских странах, и это было намного хуже.
Кажется разумным. Особенно, если вставки идут серийно. Разбивая это:
Скажем, RTT между приложением и сервером базы данных составляет 30 мс. Поскольку SQLServer является базой данных, совместимой с ACID, и драйвер базы данных учитывает это, теоретическое максимальное количество TPS составляет 33 в секунду, поскольку драйвер будет блокировать, пока не получит ACK из базы данных. (1000 мс / 30 мс = ~ 33 TPS)
Вы достигли примерно 83 TPS, поэтому я предполагаю, что задержка между сервером приложений и БД составляет около 12 мс.
На локальном сервере у вас, вероятно, есть время меньше миллисекунды.
Удаленные базы данных - просто плохая идея. Но если вам нужно это сделать, попробуйте объединить операции в одну транзакцию, так как вы можете упаковать больше данных в интервал RTT. С учетом сказанного, это означает, что сбой намного дороже (повторная попытка 1 вставки против повторной попытки всех 100). Учтите все это, но все, что вы можете сделать для уменьшения задержки (или увеличения параллелизма), будет иметь существенное значение.