MongoDB
 sql >> база данни >  >> NoSQL >> MongoDB

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

Ефективността е важен фактор при внедряването на MongoDB на AWS. От хардуерна гледна точка производителността на MongoDB на EC2 се определя основно от два фактора – RAM и скоростта на диска. Обикновено (винаги има изключения) процесорът не трябва да е проблем, нито паметта, тъй като има много налични опции за размер (R3, I2, C3/C4), които предлагат голямо количество RAM. За повече подробности относно това как да изберете правилния тип екземпляр, вижте другата ми публикация в блога: Как да изберете правилния тип екземпляр EC2

Исторически погледнато, скоростта на диска и латентността са били постоянен проблем в Amazon EBS. Въпреки това Amazon Web Services вече предлага няколко опции, които да ви помогнат с производителността на диска:

  1. Предоставени IOPS дискове

    В предоставения модел IOPS можете да посочите по време на създаване на диска броя IOPS, който искате да поддържа вашият диск. Колкото повече IOPS предоставяте, толкова по-голяма пропускателна способност ще може да поеме вашият диск. Можете да стигнете до 4000 IOPS/диск! Въпреки това, IOPS може да стане скъп на $0,065 на месец IOPS. Например, ако осигурите 4000 IOPS за диска, това ще ви струва $260/месец само за IOPS. Това може да се добави бързо, ако имате няколко сървъра.

  2. Локален SSD

    Това е най-добрият вариант за производителност на диска на Amazon AWS. Локалните SSD осигуряват най-добрата пропускателна способност и поведение на латентност от всички диск опции на AWS. Те обаче се наричат ​​„местни“ с причина. Ако по някаква причина вашата виртуална машина (VM) бъде спряна, разпределеното локално хранилище се освобождава. Така че тежестта на надеждността на данните е изцяло върху потребителя. Можете ли да разположите две локални SSD хранилища за данни в две различни зони на наличност (AZ) и да го наречете решено? Не точно. Ако AWS има прекъсване в целия регион, както беше в САЩ-Изток няколко години преди това, трябва да очаквате да загубите местните си SSD във всичките си AZ. Поради тези причини локалните SSD екземпляри не трябва да се използват като основно хранилище на данни за вашите данни.

Високопроизводителен MongoDB:Набор от реплики с 3 възела

Имайки предвид тези проблеми, представяме нашата високопроизводителна MongoDB конфигурация на AWS. Високопроизводителните клъстери използват хибрид от локален SSD и EBS осигурен IOPS диск, за да постигнат както висока производителност, така и висока надеждност. Типична конфигурация се разгръща с помощта на набор от реплики с 3 възела.

  • Основният и вторичният 1 използват локални SSD дискове
  • Secondary 2 използва осигурени от EBS IOPS

Набор реплики с 3 възела на MongoDB с висока производителност

Какво означава това? Тъй като Primary и Secondary 1 работят на локален SSD, вие получавате възможно най-добрата производителност на диска от вашите AWS машини. Няма повече мрежово базиран EBS, просто бърз локален SSD диск. Чете и записва на вашия първичен и дори четенията от вторичния 1 ще работят със скорост на SSD. Secondary 2 използва осигурени от EBS IOPS за диска с данни и можете да конфигурирате количеството IOPS, което да конфигурирате за вашия клъстер. Тази конфигурация осигурява пълна безопасност за вашите данни, дори в случай, че използвате локални SSD дискове. В момента предлагаме четири размера – Large, XLarge, X2XLarge, X4XLarge. За повече подробности вижте секциите „Донесете свой собствен облак (BYOC) и Специализирани клъстери на нашата страница с цени.

Ако имате много голямо натоварване при запис, възможно е вашият EBS екземпляр да не е в състояние да се справи с вашите SSD екземпляри. В този сценарий има няколко налични опции и нашият екип за поддръжка с удоволствие ще ви преведе през тях. Цялата ни съществуваща функционалност, включително архивиране, възстановяване, клониране, мащабиране, компактиране и т.н., продължават да работят както обикновено. Ако имате допълнителни въпроси, моля, свържете се с нас на [email protected].


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. MongoDB .Net драйвер 2.0 Pull (премахване на елемент)

  2. MongoError:Не може да се извлече гео ключове от обект с Тип:Точка

  3. В Flask преобразувайте формата POST обект в представяне, подходящо за mongodb

  4. Опции за пълно текстово търсене за настройка на MongoDB

  5. MongoDB:изведете 'id' вместо '_id'