Така че, преди да инвестирате много време и енергия в конкретен облак, е важно да разберете общите характеристики на производителността на MongoDB в този облак. Потърсихме тази информация и не я намерихме – затова решихме да я съберем за вас като част от нашата поредица от изпълнения.

Станционната платформа

Решихме да сравним AWS, Azure и DigitalOcean за този тест. Бяха избрани два различни комплекта конфигурации. Таблицата по-долу обобщава конфигурациите на машината:

* Вижте тук под „MongoDB хостинг“ за  подробните конфигурации на машината.
** DigitalOcean има директно прикачени SSD дискове.

Тестовете за сравнителна производителност бяха извършени с YCSB Workload A (актуализация тежко работно натоварване). Говорихме за YCSB, настройката му и натоварванията му в много подробна публикация миналия месец.

1. Всички тестове за сравнителен тест бяха извършени в самостоятелна конфигурация
2. За и двете конфигурации, 5 милиона записа бяха вмъкнати с различни нива на натоварване на сървъра (въз основа на броя клиентски нишки).
3. За средната конфигурация, тогава работно натоварване A беше изпълнено със стойности по подразбиране (50% актуализация, 50% четене) с брой операции от 5 милиона  при различни нива на натоварване на сървъра.
4. За голямата конфигурация тогава Работно натоварване A беше изпълнено със стойности по подразбиране (50% Актуализация, 50% Четене) с брой на операциите от 10 милиона при различни нива на натоварване на сървъра.

Резултати

Ще обсъдим резултатите въз основа на производителността на вмъкване и характеристиките на пропускателна способност/закъснение при голямо натоварване на актуализацията.

Вмъкване на производителност

Средни екземпляри

Характеристиките на пропускателната способност/закъснението за вмъкване на 5M запис в средна конфигурация:

Големи екземпляри

Характеристиките на пропускателната способност/закъснението за вмъкване на 5M запис в голяма конфигурация:

Актуализиране на производителността

Средни екземпляри

Характеристиките на пропускателната способност/закъснението за 5M операции за запис/актуализация на конфигурацията на носителя:

Тестът беше проведен с 32 нишки само за DigitalOcean. AWS и Azure бяха плоски облицовки с 16 нишки. DigitalOcean обаче създава впечатление за линейно мащабиране до 32 нишки.

Големи екземпляри

Характеристиките на пропускателната способност/закъснението за 10M операции за запис/актуализация на голяма конфигурация:

Общ анализ

1. Както се очаква, MongoDB на DigitalOcean има постоянно висока пропускателна способност/ниска латентност през цялото време и превъзхожда останалите по време на фазата на вмъкване, извличайки максималното от своите локални SSD устройства. Интересното е, че въпреки че върви много добре по време на фазата на четене/актуализация, други доставчици му дават доста голяма конкуренция, особено когато натоварването на сървъра се увеличи. Очевидно AWS/Azure използват мрежово хранилище с много по-висока производителност.
2. За да получи по-добра производителност от AWS диск, потребителят може да използва по-големи размери на диска или да разпредели повече осигурени IOPS.
3. При средни екземпляри, MongoDB на Azure изглежда работи много по-добре от AWS последователно, както по време на фазите на вмъкване, така и след това на актуализиране/четене. Това беше изненадващо. Хардуерът е доста равномерно съчетан. При големи екземпляри производителността на AWS е значително по-добра от Azure.
4. И AWS, и Azure се влошават в латентностите доста добре с увеличаване на натоварването. Azure изглежда има доста добра крива на влошаване на латентността.
5. Друг интересен аспект на MongoDB за производителността на AWS навсякъде е колко е „плоска линия“:Изглежда, че се влошава грациозно дори в логаритмичен мащаб.
6. Въз основа на числата на латентностите, от гледна точка на натоварването изглежда най-доброто място за средни и големи екземпляри е съответно 8 и 16 нишки.