Как да конфигурирам MongoDB Java драйвер MongoOptions за производствена употреба?

Актуализирано до 2.9 :

• autoConnectRetry просто означава, че драйверът автоматично ще се опита да се свърже отново със сървъра(ите) след неочаквано прекъсване на връзката. В производствени среди обикновено искате този набор да е true.

• connectionsPerHost са количеството физически връзки, които един екземпляр на Mongo (това е сингълтон, така че обикновено имате по една на приложение), които може да установи към процес mongod/mongos. По време на писане java драйверът в крайна сметка ще установи това количество връзки, дори ако действителната пропускателна способност на заявката е ниска (с думи ще видите как статистиката "conn" в mongostat се увеличава, докато не достигне този брой на сървър на приложения).

  Не е необходимо да задавате това по-високо от 100 в повечето случаи, но тази настройка е едно от онези неща „тествайте и вижте“. Имайте предвид, че ще трябва да се уверите, че сте задали това достатъчно ниско, така че общото количество връзки към вашия сървър да не надвишава

  db.serverStatus().connections.available

  В момента в производството имаме това на 40.

• connectTimeout . Както подсказва името, броят милисекунди, драйверът ще изчака, преди да бъде прекъснат опит за свързване. Задайте време за изчакване на нещо дълго (15-30 секунди), освен ако няма реалистична, очаквана вероятност това да попречи на иначе успешни опити за свързване. Обикновено, ако опитът за свързване отнема повече от няколко секунди, вашата мрежова инфраструктура не е способна на висока пропускателна способност.

• maxWaitTime . Брой ms, която нишката ще изчака връзката да стане достъпна в пула за връзки и поражда изключение, ако това не се случи навреме. Запазете по подразбиране.

• socketTimeout . Стандартна стойност на изчакване на сокета. Задайте на 60 секунди (60 000).

• threadsAllowedToBlockForConnectionMultiplier . Множител за connectionsPerHost, който обозначава броя на нишките, на които е разрешено да чакат връзките да станат достъпни, ако пулът в момента е изчерпан. Това е настройката, която ще доведе до изключението „com.mongodb.DBPortPool$SemaphoresOut:Out of semaphores to get db connection“. Той ще изхвърли това изключение, след като тази опашка с нишки надхвърли стойността threadsAllowedToBlockForConnectionMultiplier. Например, ако connectionsPerHost е 10 и тази стойност е 5, могат да блокират до 50 нишки, преди да бъде изхвърлено гореспоменатото изключение.

  Ако очаквате големи пикове в пропускателната способност, които биха могли да причинят големи опашки, временно увеличете тази стойност. Имаме го на 1500 в момента точно по тази причина. Ако натоварването на заявката ви постоянно изпреварва сървъра, просто трябва да подобрите своя хардуер/ситуацията с мащабиране съответно.

• readPreference . (АКТУАЛИЗИРАНО, 2.8+) Използва се за определяне на предпочитанията за четене по подразбиране и замества "slaveOk". Настройте ReadPreference чрез един от фабричните методи на класа. Пълно описание на най-често срещаните настройки можете да намерите в края на тази публикация

• ж . (АКТУАЛИЗИРАНО, 2.6+) Тази стойност определя "безопасността" на записа. Когато тази стойност е -1, записът няма да докладва никакви грешки, независимо от грешките в мрежата или базата данни. WriteConcern.NONE е подходящият предварително дефиниран WriteConcern за това. Ако w е 0, тогава мрежовите грешки ще направят записа неуспешен, но грешките при mongo не. Това обикновено се нарича "изстреляйте и забрави" пише и трябва да се използва, когато производителността е по-важна от последователността и издръжливостта. Използвайте WriteConcern.NORMAL за този режим.

  Ако зададете w на 1 или по-високо, записът се счита за безопасно. Безопасните записи изпълняват записа и го следват със заявка към сървъра, за да се уверят, че записът е успешен или извлича стойност за грешка, ако не е (с други думи, изпраща команда getLastError() след като пишете). Имайте предвид, че докато тази команда getLastError() не бъде завършена, връзката е запазена. В резултат на това и на допълнителната команда пропускателната способност ще бъде значително по-ниска от записа с w <=0. Със стойност w от точно 1 MongoDB гарантира, че записът е успешен (или потвърдено неуспешен) в екземпляра, до който сте изпратили записа.

  В случай на набори от реплики можете да използвате по-високи стойности за w, които да кажат на MongoDB да изпрати записа до поне "w" членове на набора от реплики, преди да се върне (или по-точно, изчакайте репликацията на вашето записване до членовете "w" ). Можете също да зададете w на низа "мнозинство", който казва на MongoDB да извърши записа към по-голямата част от членовете на набора от реплики (WriteConcern.MJORITY). Обикновено трябва да зададете това на 1, освен ако не се нуждаете от необработена производителност (-1 или 0) или репликирани записи (>1). Стойности, по-високи от 1, оказват значително влияние върху пропускателната способност на запис.

• fsync . Опция за издръжливост, която принуждава mongo да се изтрива на диск след всяко записване, когато е активирана. Никога не съм имал проблеми с издръжливостта, свързани с изоставане при запис, така че имаме това на false (по подразбиране) в производството.

• j *(НОВО 2.7+) *. Булев, който когато е зададен на true, принуждава MongoDB да изчака успешно групово записване на журнал, преди да се върне. Ако сте активирали дневник, можете да активирате това за допълнителна издръжливост. Обърнете се към http://www.mongodb.org/display/DOCS/Journaling, за да видите какво ви носи журналирането (и по този начин защо може да искате да активирате този флаг).

ReadPreference Класът ReadPreference ви позволява да конфигурирате към какви екземпляри на mongod се пренасочват заявките, ако работите с набори от реплики. Налични са следните опции:

• ReadPreference.primary() :Всички показания отиват само до първичния член за повторно задаване. Използвайте това, ако искате всички заявки да връщат последователни (последно написани) данни. Това е по подразбиране.

• ReadPreference.primaryPreferred() :Всички четения отиват към повторно зададения първичен член, ако е възможно, но може да поиска вторични членове, ако основният възел не е наличен. Като такъв, ако основното стане недостъпно, четенията в крайна сметка стават последователни, но само ако основният е недостъпен.

• ReadPreference.secondary() :Всички четения отиват към вторични членове за повторно задаване и основният член се използва само за запис. Използвайте това само ако можете да живеете с евентуално последователно четене. Допълнителни членове за повторно настройване могат да се използват за увеличаване на производителността на четене, въпреки че има ограничения за количеството членове (гласуващи), които може да има повторното настройване.

• ReadPreference.secondaryPreferred() :Всички четения отиват към вторични членове за повторно задаване, ако някой от тях е наличен. Основният член се използва изключително за записвания, освен ако всички вторични членове не станат недостъпни. Освен резервния вариант към основния член за четения, това е същото като ReadPreference.secondary().

• ReadPreference.nearest() :Четенията отиват до най-близкия член за повторно задаване, достъпен за клиента на базата данни. Използвайте само ако евентуално последователното четене е приемливо. Най-близкият член е членът с най-ниска латентност между клиента и различните повторно зададени членове. Тъй като заетите членове в крайна сметка ще имат по-високи латентности, това трябва също така автоматично балансира натоварването при четене, въпреки че според моя опит вторичният (предпочитан) изглежда го прави по-добре, ако латентностите на членовете са относително последователни.

Забележка:Всички изброени по-горе имат версии на същия метод с активиран маркер, които вместо това връщат екземпляри на TaggableReadPreference. Пълно описание на етикетите за набор от реплики може да се намери тук:Реплика на етикети за набор