Я хотів би задати питання про кращу практику, описану в цьому документі:

http://info.mongodb.com/rs/mongodb/images/MongoDB-Performance-Best-Practices.pdf

Використовуйте кілька маршрутизаторів запитів. Використовуйте кілька процесів монго, розкинутих на декілька серверів. Загальне розгортання - це локалізація процесу mongos на серверах прикладних програм, що дозволяє здійснювати локальну комунікацію між додатком та процесом mongos. Відповідна кількість процесів mongos залежатиме від характеру програми та розгортання.

Ще трохи інформації про наше розгортання. У нас є безліч вузлів сервера додатків. Кожен з них здійснює один процес, заснований на JVM, з RESTful WS без громадянства. Як свідчить ця найкраща практика, кожен вузол сервера додатків запускає свій власний mongosпроцес, а це означає, що кількість процесів JVM завжди дорівнює кількості mongosпроцесів.

Усі mongosпроцеси підключаються до 3-х серверів конфігурації та декількох фрагментів монго (із набором реплік у межах кожного фрагмента). Незважаючи на те, що ми використовуємо розточене розгортання, ми не дуже розширюємо свої колекції. Насправді у нас є велика кількість баз даних, які розповсюджуються по всіх черепках під час їх створення (і це наш головний випадок використання для загострення на даний момент).

Оскільки найкраща практика також передбачає, що "відповідна кількість процесів монгос буде залежати від характеру програми та розгортання", я почав задаватися питанням, чи правильне наше використання, mongosчи буде краще для нас декілька виділених mongosвузлів і наші сервери додатків підключаються до них, не mongosпрацюючи локально.

Яка ваша думка щодо найкращого підходу, щоб визначити, скільки mongosекземплярів є відповідними щодо кількості екземплярів сервера додатків або розміру кластера MongoDB?

Нещодавно ми почали вивчати управління кластерами для наших веб-служб без громадянства, під якими я маю на увазі такі інструменти, як Docker, Apache Mesos та Kubernetes. Якщо ми використовуємо Docker, то, як правило, не рекомендується запускати більше одного процесу в контейнері. Враховуючи цей факт, стає важко переконатися, що контейнер та mongosконтейнер сервера додатків завжди розташовані на одному фізичному вузлі та мають рівну кількість процесів. Це змушує мене замислитися, чи застосовується ця найкраща практика для архітектури кластерів, яку я тільки що описав Якщо ні, чи можете ви підказати, який би був кращий спосіб пошуку та розгортання mongosпроцесів у цій архітектурі?

Оскільки вже є і подана відповідь, і корисна, і дійсна на це, я не хочу відволікатися на її корисність, але дійсно є моменти, які піднімають це, що виходить за рамки лише короткого коментаря. Тож розглянемо це "збільшення", яке, сподіваємось, справедливе, але насамперед на додаток до вже сказаного.

Правда полягає в тому, щоб по-справжньому розглянути "як ваша програма використовує дані", а також бути в курсі факторів у "шахматному середовищі", а також запропонованого "контейнерного середовища", які впливають на це.

Фоновий випадок

Загальна рекомендація щодо практичного розміщення mongosпроцесу разом із екземпляром програми - це усунення будь-яких накладних витрат на мережу, щоб програма могла спілкуватися з цим mongosпроцесом. Звичайно, також "рекомендується практика" вказувати ряд mongosпримірників у рядку з'єднання додатків у тому випадку, коли той "найближчий" вузол з якоїсь причини не повинен бути доступним, тоді інший може бути обраний, хоча з можливим накладним зв'язком з a віддалений вузол.

Справа "докер", яку ви згадуєте, здається дещо довільною. Хоча це правда, що одна з головних цілей контейнерів (а до цього щось подібне до в'язниць BSD або навіть chroot) - це, як правило, досягти певного рівня "ізоляції процесів", насправді немає нічого поганого в запуску декількох процесів, поки ви зрозуміти наслідки.

У даному конкретному випадку mongosпозначається, що він "легкий" і виконується як "додаткова функція" до процесу подачі заявок таким чином, що він є значною мірою "парною" частиною самого додатка. Таким чином, зображення самих докерів не мають "initd" подібного процесу, але насправді нічого поганого в тому, щоб запустити контролер процесу, як supervisord (наприклад), як основний процес для контейнера, який потім дає точку контролю над процесом той контейнер. Така ситуація "парних процесів" є розумним випадком, а також досить поширеним запитанням, щоб на це була офіційна документація .

Якщо ви вибрали такий тип "парної" операції для розгортання, то вона дійсно стосується первинної точки підтримання mongosекземпляра в тому ж мережному з'єднанні і справді "серверного екземпляра", як і сам сервер додатків. Це також може розглядатися певним чином як випадок, коли «весь контейнер» повинен був вийти з ладу, тоді сам вузол просто недійсний. Не те, що я б рекомендував це, і насправді вам, мабуть, все ж слід налаштувати з'єднання для пошуку інших mongosпримірників, навіть якщо вони доступні лише через мережеве з'єднання, що збільшує затримку.

Версія конкретна / специфічне використання

Тепер, коли це зроблено, інший розгляд тут повертається до первинного розгляду питання про спільне розміщення mongosпроцесу з додатком для цілей затримки в мережі. У версіях MongoDB до 2.6 та конкретно стосовно таких операцій, як рамки агрегації, тоді траплялося так, що буде набагато більше мережевого трафіку та наступних після обробки робіт, що виконуються mongosпроцесом для роботи з даними від різних осколків . Зараз це не так вже й багато, тому що велика частина робочого навантаження тепер може бути виконана на самих осколках, перш ніж "переганяти" на "маршрутизатор".

Інший випадок - це самі схеми використання ваших програм щодо заточування. Це означає, чи є основне навантаження в "розподілі запису" по декількох фрагментах, чи це підхід "розкидання-збирання" при консолідації запитів на читання. У тих сценаріях

Тест, тест, а потім ще раз тест

Отже, остаточний момент тут справді роз'яснюється і зводиться до основного консенсусу будь-якого розумного відповіді на ваше запитання. Це не нова річ для MongoDB або будь-якого іншого рішення для зберігання даних, але ваше фактичне середовище розгортання потрібно перевірити на "моделях використання", наближених до реальної реальності так само, як і на будь-якому "тестуванні одиниць" очікуваної функціональності з основних компонентів або загальні результати потрібно перевірити.

Насправді не існує "остаточного" твердження, щоб сказати "налаштувати так" або "використовувати таким чином", що насправді має сенс окрім тестування того, що "насправді працює найкраще" для роботи та надійності програми, як очікується.

Звичайно, "найкращим випадком" завжди буде не "переповнити" mongosекземпляри запитами від "багатьох" джерел сервера додатків. Але потім, щоб дозволити їм деякий природний "паритет", який можна розподілити за наявними ресурсами навантаженнями, що мають "принаймні" "пул ресурсів", який може бути обраний, і справді в ідеалі у багатьох випадках, але усуваючи необхідність викликати додатковий "мережевий транспорт накладні".

Це і є мета, але в ідеалі ви можете "провести лабораторні випробування" різних сприйнятих конфігурацій, щоб прийти до "найкращого" рішення для вашого можливого рішення щодо розгортання.

Я також настійно рекомендую "безкоштовні" (як у пиві) курси, як уже було зазначено, і незалежно від рівня вашого знання. Я вважаю, що різні джерела матеріалів для курсів часто пропонують "приховані дорогоцінні камені", щоб дати більше розуміння речам, які ви, можливо, не вважали або іншим чином не помітили. Як згадувалося, клас M102 розроблений та проводиться Адамом Комерфордом, для якого я можу засвідчити, що він володіє високим рівнем знань щодо широкомасштабних розгортань MongoDB та інших архітектур даних. Варто часу хоча б розглянути новий погляд на те, що, на вашу думку, ви вже знаєте.

Оскільки найкраща практика також передбачає, що "відповідна кількість процесів монго залежатиме від характеру програми та розгортання", я почав цікавитись, чи насправді використання монгос насправді

Я думаю, що це питання, на яке в кінцевому підсумку можна відповісти лише ви, як йдеться в документації.

Однією з рекомендованих стратегій є надання mongosсервісу на кожному з вузлів програми та, можливо, навіть додатковий виділений вузол для додаткової доступності. Оскільки у вас це зараз, я не бачу нічого поганого у вашому поточному розгортанні. Якщо у вашій архітектурі нічого не змінюється, то ви зараз добре перебуваєте в передовій практиці. Однак ...

Якщо ми використовуємо Docker, то, як правило, не рекомендується запускати більше одного процесу в контейнері.

Оскільки mongosпроцес не дуже ресурсомісткий, ви також можете помістити його екземпляр на кожну свою черепку і дозволити кожному mongodвузлу також діяти як mongosвузол. Це може мати більше сенсу, якщо ви зробите архітектуру сервера додатків дещо складнішою.

Я особисто не надто знайомий з цими продуктами, але я також звернувся до постачальника щодо їх рекомендацій, оскільки він mongosможе бути менш інтенсивним, ніж більшість інших процесів, які ви можете запускати поряд.

Нарешті, ви завжди зможете залучати спеціальні вузли для mongosпроцесу залежно від масштабу, ресурсів тощо, що також не підпадає під найкращі практики. Справжнє вилучення тут полягає в тому, що поки у вас десь є маса mongosпроцесів, тоді ви робите добре.

Скільки дійсно залежить від розміру розгортання та вимог угоди про угода про угода. Якщо ви використовуєте осколки, вас буде більш ніж достатньо, але якщо ви збираєтесь використовувати виділені вузли, я б спробував максимально наблизити кількість прикладних вузлів.

Ви можете переглянути це відео з онлайн-курсу MongoDB M102, який обговорює ці теми, і, можливо, захочете спробувати підписатися на клас M102 для DBA наступного разу, коли він буде на сесії (безкоштовно, онлайн).