MongoDB та набори даних, які не вміщуються в оперативній пам’яті, незалежно від того, наскільки сильно ви натискаєте

Це дуже залежить від системи, але шанси майже певні, що ми пройдемо повз якусь довільну скелю і потрапимо в "Реальну неприємність". Мені цікаво, які саме правила існують для гарного співвідношення оперативної пам’яті та дискового простору. Ми плануємо наш наступний раунд систем і нам потрібно зробити вибір щодо оперативної пам'яті, SSD-дисків та кількості кожного нового вузла.

Але тепер про деякі деталі продуктивності!

Під час нормального робочого процесу одного проекту, MongoDB потрапляє з дуже високим відсотком записів (70-80%). Після того, як на другому етапі обробка трубопроводу потрапляє, він надзвичайно високо читається, оскільки йому потрібно дублювати записи, виявлені в першій половині обробки. Це робочий процес, для якого створено "зберігати робочий набір в оперативній пам'яті", і ми розробляємо це припущення.

Весь набір даних постійно отримує випадкові запити з джерел, отриманих від кінцевих користувачів; хоча частота нерегулярна, розмір, як правило, досить невеликий (групи з 10 документів). Оскільки це орієнтоване на користувачів, відповіді повинні бути під пороговим рівнем 3 секунди. Ця схема доступу набагато рідше знаходиться в кеші, тому велика ймовірність виникнення хітів диска.

Процес вторинної обробки - це читання попередніх циклів обробки, які можуть бути днями, тижнями, а то й місяцями, і вони запускаються нечасто, але все ще повинні бути блискавками. Доступ до 100% документів у попередньому циклі обробки буде доступний. Я підозрюю, що жодна кількість зігрівання кеш-пам'яті не може допомогти у цьому.

Розміри готових документів значно варіюються, але середній розмір становить близько 8 К.

Частина, що читається у звичайній обробці проекту, настійно пропонує використання реплік для розподілу трафіку читання. Я читав в інших місцях, що 1:10 RAM-GB до HD-GB є хорошим правилом для повільних дисків, оскільки ми серйозно розглядаємо можливість використання набагато швидших SSD, я хотів би знати, чи є подібне правило великого пальця для швидких дисків.

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

Це буде купа невеликих очок. На жаль, однозначної відповіді на ваше запитання немає.

MongoDB дозволяє ядру ОС обробляти управління пам'яттю. Окрім того, щоб викинути якомога більше оперативної пам’яті на цю проблему, є лише кілька речей, які можна зробити для «активного управління» робочим набором.

Єдине, що ви можете зробити для оптимізації запису - це спочатку запит на цю запис (читання), щоб він був у робочій пам'яті. Це дозволить уникнути проблем продуктивності, пов’язаних із глобальним блокуванням процесу (який повинен стати per-db у v2.2)

Не існує жорсткого і швидкого правила для відношення оперативної пам’яті проти SSD, але я думаю, що необроблений IOPS SSD повинен дозволяти вам переходити зі значно нижчим співвідношенням. У верхній частині моєї голови 1: 3 - це, мабуть, найнижчий рівень, з яким ви хочете піти. Але зважаючи на більш високі витрати та менші потужності, вам, швидше за все, знадобиться зменшити це співвідношення.

Щодо фаз «Записати проти читання», чи правильно я читаю, що після того, як записано запис, він рідко оновлюється («доповнено»)? Якщо це так, можливо, варто буде розмістити два кластери; звичайний кластер запису та оптимізований для читання кластер для даних "у віці", які не були змінені за [X період часу] . Я б точно включив читання рабовласницької роботи на цьому кластері. (Особисто я би керував цим, включивши значення, змінені датою, в об'єктні документи вашого db.)

Якщо у вас є можливість завантажувати тести перед тим, як вступити в Prod, perf слідкуйте за цим пеклом. MongoDB був написаний з припущенням, що його часто розгортатимуть у ВМ (їхні референтні системи знаходяться в EC2), тому не бійтеся випромінювати їх до VM.

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

Ви можете перевірити поточні параметри для читання (в Linux), запустивши blockdev --report(зазвичай потрібні права доступу sudo / root). Це дозволить роздрукувати таблицю з одним рядком для кожного дискового пристрою. У стовпці RA міститься значення для читати. Це значення - кількість 512 байтових секторів (якщо розмір сектору не є за замовчуванням - зауважте, що на момент написання цієї публікації навіть диски з більшими розмірами ядрами вважаються 512 байтовими секторами), які читаються на кожному доступ до диска.

Ви можете встановити параметр читати на певний дисковий пристрій, виконавши:

blockdev --setra <value> <device name>

Використовуючи систему RAID на основі програмного забезпечення, переконайтеся, що встановіть читальну головку на кожному дисковому пристрої, а також на пристрої, що відповідає RAID-контролеру.

Чому це важливо? Що ж, readahead використовує той самий ресурс, який намагається використовувати MongoDB, щоб оптимізувати ваші читання для послідовного доступу - ОЗУ. Коли ви робите послідовні читання на спінінг-дисках (або пристроях, які так чи інакше поводяться на зразок спінінг-дисків - EBS, я дивлюся на вас), отримання даних, що знаходяться поблизу, в оперативній пам’яті може значно підвищити продуктивність, заощадити на пошуках і високу настройку для читання правильне середовище може отримати вам вражаючі результати.

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

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

Для пояснення: ви хочете переконатися, що читальна голова досить висока, щоб стягнути повний єдиний документ і не потрібно повертатися до диска. Візьмемо згаданий вами середній розмір 8k - оскільки сектори на диску, як правило, 512 байт, для читання у всьому документі без читального голову потрібно 16 доступу. Якби у вас була читальна глава з 16 секторів і більше, ви б прочитали весь документ лише з однією поїздкою на диск.

Насправді, оскільки індексні вершини MongoDB дорівнюють 8 к., Ви ніколи не захочете встановлювати читати голову нижче 16, інакше буде потрібно 2 доступу до диска для зчитування в одному індексному відрізку. Загальна добра практика полягає в тому, щоб почати з ваших поточних налаштувань, зменшити їх вдвічі, потім переоцінити використання оперативної пам’яті та введення-виведення даних та перейти звідти.

Вам слід подумати про використання реплік для запитів кінцевих користувачів та виконання робочого процесу на інших машинах.

Використовуючи правило 10:10, ви дивитесь приблизно на 128 ГБ оперативної пам’яті на 1 ТБ дискового накопичувача; Незважаючи на те, що деякі доступні SSD-диски сьогодні заявляють, що вони досягають> 60 К IOPS, реальні цифри у світі можуть дещо відрізнятися, а також, використовуєте ви RAID зі своїми SSD-дисками, чи ні, і якщо ви є, то RAID-карта також надзвичайно важлива. .

На момент публікації цієї публікації перехід від 128 ГБ оперативної пам’яті DDR3 ECC до 256 ГБ здається приблизно на 2000 доларів додатково на сервері Intel 1U, і це дасть вам співвідношення 1: 5 з 1 ТБ даних, що, на мою думку, було б ще краще співвідношення. Якщо вам потрібне завантаження роботи якомога швидше, більше оперативної пам’яті обов’язково допоможе, але чи справді це так терміново?

Вам також потрібно буде виконати налаштування файлової системи, щось на кшталт "noatime, data = writeback, nobarrier" на ext4, і вам може знадобитися зробити деякі налаштування ядра, а також видалити найвищу ефективність, яку ви можете досягти система.

Якщо ви збираєтеся з RAID, RAID-10 стане досить хорошим вибором, і при належному RAID-контролері буде запропоновано збільшити продуктивність, але вдвічі зменшити доступний простір. Ви також можете заглянути в RAID50, якщо хочете пристойного підвищення продуктивності, не вдвічі зменшуючи доступне місце. Ризик запуску RAID полягає в тому, що у вас більше немає доступу до TRIM на своїх накопичувачах, а це означає, що вам потрібно раз і знову переміщувати свої дані, розбивати RAID, TRIM-накопичувачі та відтворювати RAID.

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