Які типи систем мають «масштабувати», а не «масштабувати»?

Мені давно було цікаво, чи існують системи, які повинні "масштабувати" (на більш потужному, більш дорогому сервері), а не "масштабувати", розбиваючись на багато менших серверів.

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

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

Отже, чи існують системи, які не можна масштабувати, а замість цього їх потрібно масштабувати? Що може викликати це, і як би ви визначили таку систему? (Чи загалом вони поділяють деякі спільні характеристики, які можуть зробити їх легше ідентифікувати?)

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

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

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

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

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

Наприклад, більшість з них - це головний / (багато-) раб, а не багатомайстерні проекти. Іншими словами, у вас може бути просто весь сервер, який просто сидить там і не в змозі обробляти запити. Деякі з них, але з обмеженнями ... наприклад, читати лише багатослов'янську конструкцію. Тож у вас може бути один сервер, який бере записи, а всі інші надають дані лише для читання. Ви помітите, коли ви налаштовуєте ці системи, це не завжди процес прямого руху і важко налагодити роботу. У багатьох випадках це відчувається сильним болтом.

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

Так що, здавалося б, найкращий спосіб досягти кращої продуктивності від традиційного SQL-сервера - це збільшення масштабів! У той час як з NOSQL та NewSQL вони одночасно збільшуються та збільшуються.

Причина традиційних систем RDBMS тісно пов'язана з тим, що всі вони потребують послідовного перегляду одних і тих же даних. Коли у вас є кілька серверів, які приймають оновлення одних і тих же даних від різних клієнтів, якому ви довіряєте? Будь-який метод, який намагається забезпечити узгодженість даних через якийсь механізм блокування, вимагає співпраці з іншими серверами, що або погіршує продуктивність, або впливає на якість даних, оскільки будь-які дані, прочитані у клієнта, можуть бути застарілими. І сервери повинні вирішувати між собою, які дані є останніми під час запису до одного запису. Як бачимо, це складна проблема, яка ускладнюється тим, що навантаження навантаження розповсюджується на сервери, а не лише серед процесів або потоків, де доступ до даних все ще досить швидкий.

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

Одинарна
нитка З будь-якої причини цей робочий процес може працювати лише в одній нитці.

Один потік означає, що одна система означає масштаб , щоб зробити його швидше.

Щільно з'єднаний паралелізм
Це багатопотокова система, де нитки потрібно щільно з'єднати між собою. Можливо, комунікація між процесами має бути дуже швидкою, або всім нею потрібно керувати за допомогою єдиного менеджера пам'яті. Більшість систем RDBMS - це подібні паралельні обчислення.

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

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

Це стиль , де масштаб з набагато простіше.