scalability of databases

Суб'єктивні погляди на проблеми масштабування додатків, які побудовані на

реляційних базах даних

Суб'єктивні погляди на деякі проблеми масштабування додатків, які побудовані на

реляційних базах даних

Суб'єктивні погляди на деякі проблеми масштабування веб додатків

Вху із он дьюті тудей?

Андрій Корнілов

Buzzwords:

Linux, php, python, mysql, postgresql, ip-telephony

1998-2000

Кам'янець-Подільський державний університет,

Кафедра інформатики

2000 - 2009

Bitternet.ua

Програміст, системний адміністратор

Проект CityNet, хостінг, розробка системи документообігу, хелпдеску, систем клієнтської статистики, воіп-телефонії і інтеграція всього

з усім

2008-2009

Stelex.com

Програміст в класичній компанії з Філадельфії

Автоматизація бізнес-процесів, документообігу, підтримка процесів прийняття

рішення

OpenText LiveLink, Oracle, MS-SQL

2009-2011

Marktplaats.nl (лідер Ebay classifieds group)

10M клієнтів, 1M онлайн кожного дня

LAMP на 1К серверів

Програміст

2011 -

Lofty.com

Стартап з NYC

Пошук та бронювання готелів

5M номерів в базі

150М за кілька місяців (якщо вдасться моя задача :-))

DBA експерт, python програміст

Це мало б бути в іншій презентації, але це важливо.

Тому воно тут...

Моніторинг

Ви не можете керувати тим, що ви не можете виміряти

Моніторинг

Важливі конкретні цифри

Моніторинг

Важливіше побачити, що щось змінилося (наприклад після чергового релізу)

Моніторинг

Найважливіше бачити (і розуміти) тенденції

Моніторимо все, що можна

● Системні показники: цпу, меморі, дисковий і мережевий іо● Згадайте про СМО● Бізнес показники: кількість відвідувачів● База даних: повільні запити, конкурентні запити і взаємні блокування● Мемкеш: хіт-місс● Підсистеми додатка: пінба

Моніторинг

Моніторинг додатків і компонент == вимірювання якості архітектури

PINBA: архітектура

Клієнтський модуль для PHP

Для будь-якого запита збираєм запроса збираємо script_name, host, time, rusage

Після завершення відправляємо по UDP

І так з усіх машин веб-кластера

Серверний тред в MySQL (v. 5.1.0+)

SQL-інтерфейс до всіх даних

Нам відомі скрипти, періодичність і більш-менш зрозуміло де копати далі

(c) Alexey Rybak, Badoo

Так «протухає» код

(c) Alexey Rybak, Badoo

Короткий сеанс занудства :-)

Чи є щось спільне?

Телефонні станції, супермаркети, автомагістралі, call-центри, ремонтні підприємства…

Відповідь очевидна

Усі вони задовільняють масовий потік вимог випадкового характеру

Але...

Все це саме справедливо і для інтернет проектів!

Мережі масового обслуговування

Перша робота - А.К.Ерланг, «The Theory of Probabilities and Telephone conversations», 1909

Теорія масового обслуговування (теорія черг) — розділ теорії ймовірностей, метою досліджень якого є раціональний вибір структури

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

неї, тривалості очікування і довжини черг. У теорії масового обслуговування використовуються методи теорії ймовірностей та

математичної статистики. (с) wikipedia

Базова модель

Характеристики:

● Кількість вимог в одиницю часу

● Пропускна здатність (кількість обслужених вимог)

● Середній час обслуговування

● Розподіл в часі

● Число відмов в одиницю часу

черга

вимоги обслужені вимоги

переповнення: відмови

канал обслуговування

Недоліки

● Швидка деградація пропускної здатності● Великий середній час обслуговування

N-канальна СМО з очікуванням

черга

вимоги

канали (N)

виконані вимогии

Це архітектура вашого додатку

Шукайте подібні моделі в своїх проектах — все інше, в цілому, вторинне.

Використання подібних підходів збільшить ефективність через:

● Збільшення пропускної здатності системи● Зменшення часу очікування

Масштабування і СУБД

Чому ми говоритимемо саме про СУБД?

Типово:

Пам'ять в десять разів повільніша за регістри ЦПУ

Чому ми говоритимемо саме про СУБД?

Типово:

Мережа в десять разів повільніша за пам'ять

Чому ми говоритимемо саме про СУБД?

Типово:

Диск в десять разів повільніший за мережу

Типові цифри

#00 #01

cache

CPU

Memory

cache

>1e-5 s

<1e-9 s< 1e-6 s

>1e-4 s

“HARD” DISK

FS cache

Network

Чому ми говоритимемо саме про СУБД?

СУБД це на 10% про ЦПУ і на 90% про диск

Основні поняття

- в чому вимірюємо? (система координат): транзакції-гроші, транзакції-кількість

обладнання

- типи масштабування(логарифмічне і лінійне)

Вертикальне масштабування

Відмасштабувати систему вертикально означає додати більш потужне обладнання

Переваги вертикального масштабування

Нічого не треба переписувати!!!!

Взагалі

Недоліки вертикального масштабування

- вендор локінг (хардвер, софтвер - ліцензії)- ціна

- масштабується не лінійно (а значить скоро масштабування перетвориться в надзвичайно

дороге задоволення)

Мастер-слейв масштабування

r/w спліт - пишемо на мастер, читаємо зі слейва

Плюс: слейви різного призначення з різними наборами індексів, різним сторадж

енджайнами

Просунутий варіант: кілька слейвів за одним неймом. Днс раундробін

Бонус: прозорий r/w спліт — sql proxy

39 / 86

Проблеми? - Брокнута реплікація

- Лаги реплікації (в критичних підсистемах після невдалого читання зі слейва треба

спробувати зчитати з мастера)

- Бін лог і “програвання команд” (можливі проблеми з таймстемпами)

- Вимагає підтримки на рівні коду (прозоро - SQL proxy - добро і зло одночасно)

Ще проблеми?..

Проблема деградації: логарифмічне падіння продуктивності зі зростанням кількості слейвів

Однопоточна реплікація в mysql (деякі операції виконуються паралельно але в бін

лог потрапляють послідовно)

Не ефективна утилізація ресурсів (копії даних на диску)

Як працює реплікація

G: 1) тим більше чим «важчі записи» 2) більше, чим інтенсивніший запис

Головна проблема...

Ми змасштабували читання, але запис лишився не

змасштабованим

__autoload__autoload

Масштабування запису

Це основна і найдорожча (у вирішенні) проблема

Розбиття за функціональністю

Єдине, що вам потрібно зробити — знайти кілька дуже завантажених таблиць і

перемістити їх на окремий MySQL server.

Таке розбиття все ще дозволяє зберегти архітектуру простою і працюватиме у

більшості випадків

Що виокремлюємо?

- Логінг і пошук — досить накладні і незалежні операції.

- Система коментарів може бути легко виділена в окрему базу

- В соціальних проектах зв'язки між учасниками можуть бути виділені в окрему

базу.Інші приклади: користувачі, продукти,

транзакції

Обмеження

Нема можливості зробити sql join за межами функціональної області, розміщеної в окрему

базу (в межах бази така можливість зберігається)

Нема можливості підтримувати зсилочну цілісність засобами бази. З'являється необхідність якось опрацьовувати цю

ситуацію — кронджоб або забути про це :-)

Шардінг за ключем або хешем

Вибираємо колонку (наприклад сурогатний праймарі кей) і ділимо дані на n серверів

shard = key % 4

Головна проблема — ви практично фіксуєте кількість серверів, бо вона є частиною хешуючої функції. Добавляння нового

сервера без даунтайму практично не можливе :(

Шардінг за діапазонами значеньМожна поділити дані за діапазонами значень

ключа. Наприклад користувачі з id від 1 до 10000, з 10001 до 20000 і тд. Транзакції за

2008, 2009, 2010 роки. Міста або перші цифри зіп кодів.

Головні проблеми — треба добре вгадати розмір діапазонів, інакше можна отримати

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

значно навантаженішим за позаминулорічний

Шардінг через Lookup Service

Таке розбиття працює використовуючи певний тип сервісу, який ви попередньо маєте

запитати “на якому шарді знаходяться ці дані?”. Це надзвичайно масштабована

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

використовувати обладнання ефективно. Єдина проблема — це складно :-)

● WebApp Координатор

де?

Node # 1234

data

Storage nodes

Чому це складно?

1. Програмістам спершу потрібно написати більше коду, який реалізую логіку розбиття

2. Операції над даними стають складнішими (резервне копіювання, додавання індексів,

зміна схеми даних)

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

досить швидко “доживетеся” до повного бардаку, наприклад, із версіями схеми даних

на різних шардах

Також

Центральний довідник може стати єдиною точкою відмови

Приклади

Старий підхід

$connection = new_db_connection("host", port, "dbname");

$statement = $connection->prepare($sql_statement, $params);

$result = $statement->execute();

Приклади

Локатор, базований на URL

$connection = new_db_connection("customer://1234");

$statement = $connection->prepare($sql_statement, $params);

$result = $statement->execute();

Customer — сутність, 1234 — айді сутності

Приклади

Локатор, базований на URL (варіант 2)

/*entity customer://1234 */ SELECT name FROM customer WHERE id = 1234

Приклади

customer://1234 (id)

forums://master (r/w split)

log://January/2008 (date)

Спільні проблеми для всіх схем розбиття

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

чином ці обмеження пов'язані з тим, що запити, які включають кілька таблиць або

велику кількість даних, не можуть бути виконані в межах одного сервера

Join-ни та денормалізація

Вирішення проблеми об'єднання кількох таблиць є денормалізація.

Приклади:- в табличці списку форумів зберігати

загальну кількість постів, тему, дату та автора останнього посту.

- в табличці користувачів записувати час останнього входу в систему

Зсилочна цілісність

Форін кеї не працюють :-(

Для підтримки цілісності даних потрібно створити інфраструктуру крондожобів, для

очистки даних

Також потрібно уважно слідкувати за станом системи, яка реалізує денормалізацію даних

Ребалансінг

Що робити, коли схема розбиття вибрана не правильно?

У випадку розбиття за ключем чи діапазоном значень, вирішення цієї проблеми може бути

дуже болючим і дорогим.

Використання розбиття з використанням сервіс локатора дозволяє зробити простіший

ребалансінг за рахунок вищої складності системи і створення single point of failure

Висновки

Якщо ви підтримуєте розбиття на рівні аплікації питання масштабування для вас

більше не існує

Shared all

Shared nothing

Висновки

Але з'являється комплекс інших питань.Менш критичних для вашого бізнесу.

Ви позбуваєтесь технічних проблем ціною дорожчої розробки

Інші питання

SQL паттерни і антипаттерни

Вибірка за первинним ключемЗабуваємо про джоіни

Заміняємо (де можливо) складні запити на вьюви

Вибираємо рекордсет а не рекордВикористовуємо функції

Зміна схеми

Таличка Юзерс (часто апдейтиться) і табличка Профайл (рідко апдейтиться)

Менші таблички — більше даних вміщається в сторінку даних файлової системи — менше операцій зчитування, щоб отримати ту саму

кількість данихРідко потрібні дані не займають місце в кеші

Count таблички

Count таблички

Асинхронні черги

Якщо шардінг – це розподілення в просторі, то черга – розподілення в часі

Якщо щось можна зробити потім – нехай клієнт не чекає (це часто можна бачити в твітері і фейсбуці)

Досить легко зробити «універсальний» фреймворк для роботи з чергами

Або використати готовий

Асинхронні черги

● Дозволяють Вам легше масштабуватися● Не кожна дія вимагає негайного виконання

- відсилка пошти, твітів- логування, нотіси- вставка даних в базу, індексування

● Деякі дії можна оптимізовувати для batch виконання

Gearman

● Message Queue● A job coordinator

Ефективний елемент в розподіленій архітектурі

Gearman

<?php

$worker= new GearmanWorker();

$worker->addServer();

$worker->addFunction("reverse", "my_reverse_function");

while ($worker->work());

function my_reverse_function($job)

{

return strrev($job->workload());

}

?>

Gearman

<?php

$client= new GearmanClient();

$client->addServer();

print $client->do("reverse", "Hello World!");

?>

Атомарність і локінг ресурсів

Рейс кондішен при доступі до ресурсів в багатопоточному середовищі

● begin;select * from table where flag = 0 for update;do workCommit;

● exclusive file lock

● update events set status = 'processing', worker_id = 11111 where worker_id is null limit 30;select * from events where status = 'processing' and worker_id = 1111;

● Open tcp port

Не забудьте розлокати :-)

Автолоад

Звичайний __autoload() з php

АІО

Не використовуємо апач

memcache

- libketama

- prolongate patch

- add vs set

- increment vs get, +1, set

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

- getmulti/setmulti

Clouds

Повільні... ну те, що там називають “дисками” :-)

Мережа єдина як для надання сервісу так і для доступу до мережевих дисків

Рішенням може бути software raid поверх кількох таких дисків

Екзотика!

Матеріалізовані вьюви: http://code.google.com/p/flexviews/

Матеріалізовані вьюви подібні до звичайних вьювів, за виключенням того, що вони зберігаються в реальних табличках

Паралельне виконання запитів:http://code.google.com/p/shard-query/

Колонкові бази даних

Проблема збереження великих масивів даних

Проблема аналітичних запитів

RTFM

Слайди з конференцій – mysql, velocity, osconn.

Блоги - http://www.mysqlperformanceblog.com/, http://www.planetmysql.com

Книг надзвичайно мало:● High Performance MySQL (2nd ed. Shwartz, Zaitsev & co)● Building Scalable Web Sites (Henderson)● Scalable Internet Architectures (Schlossnagle)● Настройка производительности UNIX-систем (Мусумеси,

Лукидес)

Тут могла бути ваша реклама...

???

Подяки

В презентації використані деякі матеріали Олексія Рибака, представлені ним на конференції Хайлоад 2011