Я думаю, что это справедливый вопрос, но любой будет изо всех сил пытаться дать вам ответ, так как ваши результаты всегда будут отличаться, и ответы от людей на местах будут слишком специфичными для их конкретной ситуации.
У меня есть реальное решение, которое мы используем в Azure.На самом деле, если вы решите использовать Azure, рассмотрите возможность его использования для оптимизации выделения экземпляра вычислений для Azure: http://www.paraleap.com:)
Я могу сказать, что вы хотите по крайней мере планировать бюджетНа 20% больше вычислительных часов из-за разного времени, когда вам нужно развернуть / повторно развернуть / и повторно развернуть среду в промежуточную область (которая требует дополнительных часовых приращений) только для того, чтобы узнать, что что-то еще в облаке не работает, когда оноработал в разработке ткани.Это особенно верно в начальное нестабильное время вашего приложения.Неважно, есть ли у вас большая группа по обеспечению качества, которая отлично справляется со своей средой Azure-QA, или вы собираетесь обратиться к клиентам за бета-тестированием, и они тестируют вашу среду Azure-Prod.Вам нужно будет часто их перераспределять.Кроме того, как я уже упоминал, планируйте настроить количество экземпляров по требованию - надеюсь, автоматически или по расписанию.Если вы собираетесь написать свой собственный мониторинг для этого, добавьте / Связка / к затратам на разработку, хранению и транзакциям только для этого.Аутсорсинг по-прежнему будет стоить немного, так как метрики производительности нужно будет хотя бы один раз сохранить и хотя бы один раз загрузить.Это позволит вам сэкономить на затратах на вычислительные экземпляры до 50-80%, в зависимости от того, насколько изменчива ваша потребность.
Затраты на хранение - их легко оценить, если вы знаете свои модели использования и цельсхема ... Проблема в том, что если вы раньше работали с реляционными базами данных и теперь будете использовать таблицу Storage, запланируйте размер в 3-4 раза больше, чем, по вашему мнению, ваша реляционная база данных.С таблицей-хранилищем вы получаете денормализацию ALOT больше.3-4x, может быть, даже слишком мало множителя - ваши результаты могут отличаться.
Транзакционные издержки.Я узнаю, что с этими, я был дальше в моих оценках.Исходя из реляционного мира, я не был полностью готов к тому уровню денормализации, который мне нужно было сделать.Денормализация приводит не только к более высоким затратам на хранение, но также к увеличению количества обращений (много вызовов) к хранилищу, что приводит к большему количеству транзакций.
К сожалению, моя природа приложения не очень хорошо используется.транзакционная модель.Если вы можете использовать транзакции, где куча вещей хранится в одном PartitionKey в одной таблице и фиксируется с одной транзакцией - тогда затраты намного меньше.Итак, какими бы вы ни считали ваши транзакционные издержки, умножьте это на 10 или около того, чтобы быть на пессимистической стороне.
Я обнаружил, что затраты на передачу проще всего планировать, возможно, потому, что они являются частью интерфейсов и намного лучше определены заранее.Ваш пробег может варьироваться.
И, наконец, диагностические данные - вы захотите сохранить некоторый счетчик / счетчик производительности и т. Д.Информация.Не забывайте планировать это.Он несколько денормализован и может занимать много места.
SQL Azure великолепен, так как не требует затрат на транзакции и затрат на передачу, если он находится в одном центре обработки данных, но очень ограничен пространством и стоимостью храненияданные.Поэтому я использую его для часто запрашиваемых, но небольших элементов данных.
Надеюсь, это поможет