Мы перенесли наше приложение с Parse на Azure, но стоимость DocumentDB очень высока. Мы делаем что-то не так?

Судя по вашим снимкам экрана, у вас есть 15 коллекций в базе данных Parse. С Parse: помимо системных классов, каждый из ваших пользовательских классов хранится в отдельной коллекции. И учитывая, что начальная скорость запуска каждой (неразделенной) коллекции составляет ~24 доллара в месяц (для коллекции S1), вы можете увидеть, какой будет базовая стоимость для 15 коллекций (около 360 долларов).

Вы платите за зарезервированное хранилище и емкость RU. Независимо от использования RU, вы платите любую стоимость за эту емкость (например, S2 стоит около 50 долларов США в месяц за сбор, даже если вы не выполняете ни одного запроса). Подобно запуску виртуальной машины с определенной мощностью ЦП, а затем ничего на ней не запускаемой.

Параметр пропускной способности по умолчанию для коллекций синтаксического анализа установлен на 1000 RUPS. Это будет стоить 60 долларов за сбор (из расчета 6 долларов за 100 RUPS). После завершения миграции с разбором пропускная способность может быть снижена, если вы считаете, что рабочая нагрузка уменьшилась. Это уменьшит заряд.

Чтобы узнать, как это сделать, см. https://azure.microsoft.com/en-us/documentation/articles/documentdb-performance-levels/ (изменение пропускной способности коллекции).

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

Azure — это модель «плата за то, что вы используете», особенно в отношении таких ресурсов, как DocumentDB и база данных SQL, где вы платите за требуемый уровень производительности вместе с требуемым пространством для хранения. Поэтому, если ваши требования заключаются в том, что все запросы/транзакции имеют время отклика меньше секунды, вы можете заплатить больше, чтобы получить эту гарантию производительности (игнорируя оптимизацию и т. д.).

Одна вещь, на которую я бы серьезно обратил внимание, — это инструмент оценки стоимости DocumentDB; это позволяет вам получить оценки затрат на пропускную способность на основе типов транзакций на основе предоставленных вами образцов документов JSON:

Итак, в этом примере у меня есть документ JSON размером 8 КБ, в котором я рассчитываю сохранить 500 КБ из них (чтобы получить приблизительную стоимость хранения) и указать, что мне нужна пропускная способность для создания 100 документов в секунду, чтения 10/сек и обновления 100/сек. сек (тот же документ я использовал в качестве примера того, как будет выглядеть обновление).

ПРИМЕЧАНИЕ: это необходимо делать ДЛЯ КАЖДОГО ДОКУМЕНТА. Если вы храните документы, которые не обязательно соответствуют заданной «схеме» или структуре в той же коллекции, вам нужно будет повторить этот процесс. для КАЖДОГО типа документа.

Основываясь на этой информации, я использую эти значения в качестве входных данных для калькулятора цен. Это говорит мне о том, что я могу оценить около 450 долларов США в месяц только для служб DocumentDB (если это был мой ожидаемый шаблон использования).

Существуют дополнительные способы оптимизации единиц запроса (ЕЗ — показатель, используемый для измерения стоимости данного запроса/транзакции — и того, за что вам выставляются счета): оптимизация стратегий индексирования, оптимизация запросов и т. д. Ознакомьтесь с документацией. в разделе блоки запросов для получения дополнительных сведений.