Сравнителен анализ на MongoDB – повишаване на производителността на NoSQL

Системите за бази данни са важни компоненти в цикъла на всяко успешно работещо приложение. Следователно всяка организация, която ги включва, има мандат да гарантира гладко представяне на тези DBM чрез последователно наблюдение и справяне с незначителни неуспехи, преди те да ескалират в огромни усложнения, които могат да доведат до прекъсване на приложението или бавна производителност.

Може да попитате как можете да разберете дали базата данни наистина ще има проблем, докато работи нормално? Е, това е, което ще обсъдим в тази статия и го наричаме сравнителен анализ. Сравнителен анализ по същество изпълнява някакъв набор от заявки с някои тестови данни, заедно с определени ресурси, за да се определи дали тези параметри отговарят на очакваното ниво на производителност.

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

Идеята зад сравнителния анализ е да получите обща представа за това как различните опции за конфигурация влияят на производителността, как можете да настроите някои от тези конфигурации, за да получите максимална производителност и да оцените разходите за подобряване на тази реализация. Освен това приложенията нарастват с времето по отношение на потребителите и вероятно количеството данни, което трябва да се обслужва, следователно трябва да се направи известно планиране на капацитета преди това време. След като осъзнаете нарастваща тенденция на данните, трябва да направите някои сравнителни показатели за това как ще отговаряте на изискванията на тези огромни нарастващи данни.

Съображения при сравнителния анализ на MongoDB

1. Изберете работни натоварвания, които са типично представяне на съвременните приложения. Съвременните приложения стават все по-сложни всеки ден и това се предава надолу към структурите от данни. Това означава, че представянето на данни също се е променило с времето, например съхраняване на прости полета в обекти и масиви. Не е съвсем лесно да се работи с тези данни с конфигурации по подразбиране или по-скоро нестандартни, тъй като това може да ескалира до проблеми като лошо забавяне и лоша пропускателна способност, включващи сложните данни. Следователно, когато изпълнявате бенчмарк, трябва да използвате данни, които са ясно представяне на вашето приложение.
2. Двойна проверка при запис. Винаги се уверете, че всички записи на данни са извършени по начин, който не позволява загуба на данни. Това е за подобряване на целостта на данните, като се гарантира, че данните са последователни и най-приложими, особено в производствената среда.
3. Използвайте обеми от данни, които са представяне на набори от данни за „големи данни“, които със сигурност ще надхвърлят капацитета на RAM за отделен възел. Когато тестовото натоварване е голямо, това ще ви помогне да предвидите бъдещите очаквания за производителността на вашата база данни, следователно започнете планиране на капацитета достатъчно рано.

Методология

Нашият сравнителен тест ще включва някои големи данни за местоположението, които могат да бъдат изтеглени от тук и ще използваме софтуер Robo3t, за да манипулираме нашите данни и да събираме информацията, от която се нуждаем. Файлът има повече от 500 документа, които са напълно достатъчни за нашия тест. Използваме MongoDB версия 4.0 на Ubuntu Linux 12.04 Intel Xeon-SandyBridge E3-1270-Quadcore 3.4GHz специален сървър с 32GB RAM, Western Digital WD Caviar RE4 1TB въртящ се диск и Smart XceedIOPS 256GB SSD. Вмъкнахме първите 500 документа.

Изпълнихме командите за вмъкване по-долу

db.getCollection('location').insertMany([<document1, <document2>…<document500>],{w:0})
db.getCollection('location').insertMany([<document1, <document2>…<document500>],{w:1})

Напишете загриженост

Загрижеността за запис описва нивото на потвърждение, поискано от MongoDB за операции по запис в този случай към самостоятелен MongoDB. За операция с висока пропускателна способност, ако тази стойност е настроена на ниска, тогава повикванията за запис ще бъдат толкова бързи, което намалява латентността на заявката. От друга страна, ако стойността е зададена висока, тогава повикванията за запис са бавни и следователно се увеличават латентността на заявката. Простото обяснение за това е, че когато стойността е ниска, тогава не се притеснявате от възможността да загубите някои записи в случай на срив на mongod, грешка в мрежата или анонимна системна повреда. Ограничение в този случай ще бъде, няма да сте сигурни дали тези записи са били успешни. От друга страна, ако притеснението при запис е голямо, има подкана за обработка на грешка и по този начин записите ще бъдат потвърдени. Потвърждението е просто разписка, че сървърът е приел записа за обработка.

В нашия тест загрижеността за запис, зададена на ниско, доведе до изпълнение на заявката за мин. 0,013 ms и максимум за 0,017 ms. В този случай основното потвърждение на запис е деактивирано, но все пак можете да получите информация относно изключенията на сокетите и всяка мрежова грешка, която може да е била задействана.

Когато загрижеността за запис е висока, отнема почти двойно повече време за връщане, като времето за изпълнение е 0,027 ms min и 0,031 ms макс. Потвърждението в този случай е гарантирано, но не 100% е достигнало дисковия журнал. В този случай шансовете за загуба на запис са 50% поради прозореца от 100 мс, при който дневникът може да не бъде изтрит на диск.

Записване в дневник

Това е техника за гарантиране на липса на загуба на данни чрез осигуряване на издръжливост в случай на повреда. Това се постига чрез записване напред във файловете на дневника на диска. Най-ефикасно е, когато загрижеността за запис е зададена високо.

За въртящ се диск времето за изпълнение с активирано водене на журнал е малко по-високо, например в нашия тест беше около 0,251 мс за същата операция по-горе.

Времето за изпълнение за SSD обаче е малко по-малко за същата команда. В нашия тест това беше около 0,207 мс, но в зависимост от естеството на данните понякога това може да бъде 3 пъти по-бързо от въртящ се диск.

Когато журналирането е активирано, това потвърждава, че записи са направени в дневника и по този начин гарантира трайността на данните. Следователно операцията на запис ще оцелее след изключване на mongod и гарантира, че операцията по запис е издръжлива.

За операция с висока пропускателна способност можете да попълвате заявките наполовина, като зададете w=0. В противен случай, ако трябва да сте сигурни, че данните са записани или по-скоро ще бъдат в случай на връщане към живота след неуспех, тогава трябва да зададете w=1.

Репликация

Потвърждението на проблем при запис може да бъде активирано за повече от един възел, който е първичен и вторичен в рамките на набор от реплика. Това ще се характеризира с това какво цяло число се оценява на параметъра за запис. Например, ако w =3, Mongod трябва да гарантира, че заявката получава потвърждение от главния възел и 2 подчинени. Ако се опитате да зададете стойност, по-голяма от една и възелът все още не е репликиран, ще изведе грешка, че хостът трябва да бъде репликиран.

Репликацията идва с забавяне, така че времето за изпълнение ще се увеличи. За простата заявка по-горе, ако w=3, тогава средното време за изпълнение се увеличава до 270ms. Движещ фактор за това е обхватът на времето за реакция между възлите, засегнати от латентността на мрежата, комуникационните разходи между 3-те възела и претоварването. Освен това и трите възела чакат един друг да завършат, преди да върнат резултата. Следователно при производствено внедряване няма да е необходимо да включвате толкова много възли, ако искате да подобрите производителността. MongoDB е отговорен за избора кои възли да бъдат потвърдени, освен ако в конфигурационния файл няма спецификация, използваща тагове.

Въртящ се диск срещу Solid State Disk

Както бе споменато по-горе, SSD дискът е доста бърз от въртящия се диск в зависимост от включените данни. Понякога може да бъде 3 пъти по-бързо, следователно си струва да плащате, ако е необходимо. Въпреки това, използването на SSD ще бъде по-скъпо, особено когато се работи с огромни данни. MongoDB има заслуга, че поддържа съхраняване на бази данни в директории, които могат да бъдат монтирани, следователно има възможност за използване на SSD. Използването на SSD и активиране на водене в журнал е страхотна оптимизация.

Заключение

Експериментът беше сигурен, че деактивираната загриженост за запис води до намалено време за изпълнение на заявка за сметка на шансовете за загуба на данни. От друга страна, когато проблемът за запис е активиран, времето за изпълнение е почти 2 пъти, когато е деактивирано, но има сигурност, че данните няма да бъдат загубени. Освен това можем да оправдаем, че SSD е по-бърз от въртящ се диск. Въпреки това, за да се гарантира трайността на данните в случай на системна повреда, препоръчително е да активирате проблемът за запис. Когато активирате загрижеността за запис за набор от реплика, не задавайте твърде голямо число, така че да може да доведе до влошаване на производителността от края на приложението.