Хранилище данных SQL Azure - максимальное количество одновременных запросов

Question

Мне нужно принять решение об использовании хранилища данных SQL Azure или хранилища данных SQL на основе Microsoft SQL Server, виртуализированного на виртуальной машине.

Проблема, которую я не понимаю, заключается в ОГРАНИЧЕНИИ МАКСИМАЛЬНЫХ ОГРАНИЧЕНИЙ К 32То же самое для базы данных SQL Azure - 6400.

Если честно, когда я хочу использовать хранилище данных Azure в среде Enterprise, 32 одновременных запроса смешны или я не понимаю.

Предположим, что компания имеет 10.000 сотрудников по всему миру, и я настроил хранилище данных Azure для целей отчетности, где предположим, что 250 постоянно запрашивают данные или еще 250 сотрудников работают с бизнес-приложением, которое использует данные из хранилища данных.Как это должно работать без крайних недостатков производительности?

Answer 1

Это не та проблема, о которой вы могли бы подумать.

Во-первых, ограничение теперь составляет 128. (https://docs.microsoft.com/en-us/azure/sql-data-warehouse/memory-and-concurrency-limits#gen2-1)

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

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

Возможно, лучшее доказательство, которое я могу дать, - это то, что я работаю с Azure SQLКлиенты хранилища данных ежедневно. Я часто получаю такие вопросы, когда клиент впервые сталкивается с ASDW, но у меня никогда не возникает вопросов о параллелизме к тому времени, когда он находится в производстве. Другими словами, проблема «параллелизма» простоне важно для большинства клиентов.