Производительность - Сервис таблицы, SQL Azure - вставка. Скорость запроса на большом количестве данных

Я бы прочитал много сообщений и статей о сравнении SQL Azure и Table Service, и большинство из них сказали, что Table Service более масштабируема, чем SQL Azure.

Извините за http, я новый пользователь > _ < Но http://azurescope.cloudapp.net/BenchmarkTestCases/ эталон показывает различное изображение.

Мое дело. Использование SQL Azure: одна таблица со многими вставками, около 172 000 000 в день (2000 в секунду). Могу ли я ожидать хорошей производительности для вставок и выбора, когда у меня есть 2 миллиона записей или 9999.... 9 миллиардов записей в одной таблице?

Использование Table Service: одна таблица с некоторым количеством разделов. Количество разделов может быть большим, очень большим.

Вопрос №1:. Служба таблицы имеет некоторые ограничения или лучшие практики для создания множества, многих и многих разделов в одной таблице?

Вопрос №2: в одном разделе у меня есть большое количество небольших объектов, например, в примере SQL Azure. Могу ли я ожидать хорошей производительности для вставок и выбора, когда у меня есть 2 миллиона записей или 9999 миллиардов объектов в одном разделе?

Я знаю о решениях для sharding или partition, но это облачный сервис, облачный не мощный и все работает без навыков моего кода?

Вопрос № 3: Может ли кто-нибудь показать мне тесты для запроса на большое количество данных для SQL Azure и Table Service?

Вопрос № 4: Возможно, вы могли бы предложить лучшее решение для моего дела.

Ответ 1

Короткий ответ

Я не видел много разделов, вызывающих проблемы с Azure Tables (AZT), но у меня нет этого объема данных.
Чем больше элементов в разделе, тем медленнее запросы в этом разделе
Извините, у меня нет тестов.
См. ниже

Длинный ответ

В вашем случае я подозреваю, что SQL Azure не работает для вас, просто из-за ограничений на размер базы данных SQL Azure. Если каждый из этих строк, которые вы вставляете, составляет 1K с индексами, вы достигнете предела 50 ГБ примерно за 300 дней. Это правда, что Microsoft говорит о базах данных размером более 50 ГБ, но они не имеют временных рамок. SQL Azure также имеет пропускную способность, которую я не могу найти на данный момент (я уверен, что она меньше, чем вам нужно). Возможно, вам удастся обойти это, разбив данные на несколько баз данных SQL Azure.

Преимущество SQL Azure, хотя есть возможность запускать агрегированные запросы. В AZT вы даже не можете написать select count(*) from customer без загрузки каждого клиента.

AZT также имеет предел 500 транзакций в секунду на раздел и лимит "несколько тысяч" в секунду на учетную запись.

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

Для примера, если эти строки, которые вы вставляли, были заказами, а заказы принадлежат клиенту. Если для вас было более распространено перечисление заказов клиентом, у вас будет PK = CustomerId, RK = OrderId. Это означало бы найти заказы для клиента, которому просто нужно запросить ключ раздела. Чтобы получить конкретный заказ, вам нужно знать CustomerId и OrderId. Чем больше заказов у клиента, тем медленнее находить какой-то конкретный порядок.

Если вам просто нужно получить доступ к заказам только с помощью OrderId, вы должны использовать PK = OrderId, RK = string.Empty и поместить CustomerId в другое свойство. Хотя вы все равно можете написать запрос, который возвращает все заказы для клиента, потому что AZT не поддерживает индексы, отличные от PartitionKey и RowKey, если ваш запрос не использует PartitionKey (а иногда даже если он работает в зависимости от того, как вы пишете их) вызовет сканирование таблицы. С количеством записей, о которых вы говорите, было бы очень плохо.

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

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