scalability of databases

440 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
440
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

scalability of databases

  1. 1. Субєктивні погляди на проблемимасштабування додатків, які побудовані на реляційних базах даних
  2. 2. Субєктивні погляди на деякі проблемимасштабування додатків, які побудовані на реляційних базах даних
  3. 3. Субєктивні погляди на деякі проблеми масштабування веб додатків
  4. 4. Вху із он дьюті тудей? Андрій Корнілов Buzzwords:Linux, php, python, mysql, postgresql, ip- telephony
  5. 5. 1998-2000Камянець-Подільський державний університет, Кафедра інформатики
  6. 6. 2000 - 2009 Bitternet.ua Програміст, системний адміністратор Проект CityNet, хостінг, розробка системидокументообігу, хелпдеску, систем клієнтськоїстатистики, воіп-телефонії і інтеграція всього з усім
  7. 7. 2008-2009 Stelex.comПрограміст в класичній компанії з Філадельфії Автоматизація бізнес-процесів,документообігу, підтримка процесів прийняття рішення OpenText LiveLink, Oracle, MS-SQL
  8. 8. 2009-2011Marktplaats.nl (лідер Ebay classifieds group) 10M клієнтів, 1M онлайн кожного дня LAMP на 1К серверів Програміст
  9. 9. 2011 - Lofty.com Стартап з NYC Пошук та бронювання готелів 5M номерів в базі150М за кілька місяців (якщо вдасться моя задача :-)) DBA експерт, python програміст
  10. 10. Це мало б бути в іншійпрезентації, але це важливо. Тому воно тут...
  11. 11. МоніторингВи не можете керувати тим, що ви не можете виміряти
  12. 12. МоніторингВажливі конкретні цифри
  13. 13. МоніторингВажливіше побачити, що щось змінилося (наприклад після чергового релізу)
  14. 14. МоніторингНайважливіше бачити (і розуміти) тенденції
  15. 15. Моніторимо все, що можна● Системні показники: цпу, меморі, дисковий імережевий іо● Згадайте про СМО● Бізнес показники: кількість відвідувачів● База даних: повільні запити, конкурентнізапити і взаємні блокування ​● Мемкеш: хіт-місс● Підсистеми додатка: пінба
  16. 16. МоніторингМоніторинг додатків і компонент == вимірювання якості архітектури
  17. 17. PINBA: архітектураКлієнтський модуль для PHPДля будь-якого запита збираєм запросазбираємо script_name, host, time, rusageПісля завершення відправляємо по UDPІ так з усіх машин веб-кластераСерверний тред в MySQL (v. 5.1.0+)SQL-інтерфейс до всіх даних
  18. 18. Нам відомі скрипти, періодичність і більш-менш зрозуміло де копати далі(c) Alexey Rybak, Badoo
  19. 19. Так «протухає» код(c) Alexey Rybak, Badoo
  20. 20. Короткий сеанс занудства :-)
  21. 21. Чи є щось спільне?Телефонні станції, супермаркети, автомагістралі, call-центри, ремонтні підприємства…
  22. 22. Відповідь очевиднаУсі вони задовільняють масовий потік вимог випадкового характеру
  23. 23. Але...Все це саме справедливо і для інтернет проектів!
  24. 24. Мережі масового обслуговування Перша робота - А.К.Ерланг, «The Theory of Probabilities and Telephone conversations», 1909 Теорія масового обслуговування (теорія черг) — розділ теорії ймовірностей, метою досліджень якого є раціональний вибір структурисистеми обслуговування та процесу обслуговування на основі вивчення потоків вимог на обслуговування, що надходять у систему і виходять з неї, тривалості очікування і довжини черг. У теорії масового обслуговування використовуються методи теорії ймовірностей та математичної статистики. (с) wikipedia
  25. 25. Базова модель канал обслуговування черга вимоги обслужені вимоги переповнення: відмовиХарактеристики:● Кількість вимог в одиницю часу● Пропускна здатність (кількість обслужених вимог)● Середній час обслуговування● Розподіл в часі● Число відмов в одиницю часу
  26. 26. Недоліки● Швидка деградація пропускної здатності ● Великий середній час обслуговування
  27. 27. N-канальна СМО з очікуванням канали (N) чергавимоги виконані вимогии
  28. 28. Це архітектура вашого додатку Шукайте подібні моделі в своїх проектах — все інше, в цілому, вторинне. Використання подібних підходів збільшить ефективність через:● Збільшення пропускної здатності системи● Зменшення часу очікування
  29. 29. Масштабування і СУБД
  30. 30. Чому ми говоритимемо саме про СУБД? Типово:Память в десять разів повільніша за регістри ЦПУ
  31. 31. Чому ми говоритимемо саме про СУБД? Типово:Мережа в десять разів повільніша за память
  32. 32. Чому ми говоритимемо саме про СУБД? Типово: Диск в десять разів повільніший за мережу
  33. 33. Типові цифри Memory #00 #01cache cache < 1e-6 sCPU <1e-9 s FS cache“HARD” DISK Network >1e-4 s >1e-5 s
  34. 34. Чому ми говоритимемо саме про СУБД?СУБД це на 10% про ЦПУ і на 90% про диск
  35. 35. Основні поняття- в чому вимірюємо? (система координат): транзакції-гроші, транзакції-кількість обладнання - типи масштабування (логарифмічне і лінійне)
  36. 36. Вертикальне масштабування Відмасштабувати систему вертикальноозначає додати більш потужне обладнання
  37. 37. Переваги вертикального масштабуванняНічого не треба переписувати!!!! Взагалі
  38. 38. Недоліки вертикального масштабування - вендор локінг (хардвер, софтвер - ліцензії) - ціна - масштабується не лінійно (а значить скоромасштабування перетвориться в надзвичайно дороге задоволення)
  39. 39. 39 / 86Мастер-слейв масштабування r/w спліт - пишемо на мастер, читаємо зі слейваПлюс: слейви різного призначення з різними наборами індексів, різним сторадж енджайнамиПросунутий варіант: кілька слейвів за одним неймом. Днс раундробін Бонус: прозорий r/w спліт — sql proxy
  40. 40. Проблеми? - Брокнута реплікація- Лаги реплікації (в критичних підсистемах після невдалого читання зі слейва треба спробувати зчитати з мастера) - Бін лог і “програвання команд” (можливі проблеми з таймстемпами)- Вимагає підтримки на рівні коду (прозоро - SQL proxy - добро і зло одночасно)
  41. 41. Ще проблеми?..Проблема деградації: логарифмічне падінняпродуктивності зі зростанням кількості слейвів Однопоточна реплікація в mysql (деякі операції виконуються паралельно але в бін лог потрапляють послідовно) Не ефективна утилізація ресурсів (копії даних на диску)
  42. 42. Як працює реплікація
  43. 43. G: 1) тим більше чим «важчі записи» 2) більше, чим інтенсивніший запис
  44. 44. Головна проблема...Ми змасштабували читання, __autoload але запис лишився не змасштабованим
  45. 45. Масштабування записуЦе основна і найдорожча (у вирішенні) проблема
  46. 46. Розбиття за функціональністюЄдине, що вам потрібно зробити — знайти кілька дуже завантажених таблиць іперемістити їх на окремий MySQL server.Таке розбиття все ще дозволяє зберегти архітектуру простою і працюватиме у більшості випадків
  47. 47. Що виокремлюємо?- Логінг і пошук — досить накладні і незалежні операції. - Система коментарів може бути легко виділена в окрему базу - В соціальних проектах звязки між учасниками можуть бути виділені в окрему базу. Інші приклади: користувачі, продукти, транзакції
  48. 48. ОбмеженняНема можливості зробити sql join за межамифункціональної області, розміщеної в окрему базу (в межах бази така можливість зберігається) Нема можливості підтримувати зсилочну цілісність засобами бази. Зявляється необхідність якось опрацьовувати цю ситуацію — кронджоб або забути про це :-)
  49. 49. Шардінг за ключем або хешем Вибираємо колонку (наприклад сурогатний праймарі кей) і ділимо дані на n серверів shard = key % 4 Головна проблема — ви практично фіксуєте кількість серверів, бо вона є частиною хешуючої функції. Добавляння новогосервера без даунтайму практично не можливе :(
  50. 50. Шардінг за діапазонами значеньМожна поділити дані за діапазонами значень ключа. Наприклад користувачі з id від 1 до 10000, з 10001 до 20000 і тд. Транзакції за2008, 2009, 2010 роки. Міста або перші цифри зіп кодів. Головні проблеми — треба добре вгадати розмір діапазонів, інакше можна отримати сервери не збалансовані за навантаженням. Наприклад шард для поточного року будезначно навантаженішим за позаминулорічний
  51. 51. Шардінг через Lookup Service Таке розбиття працює використовуючипевний тип сервісу, який ви попередньо маєте запитати “на якому шарді знаходяться ці дані?”. Це надзвичайно масштабована архітектура. Якщо ви напишете скріпти, які дозволять мігрувати дані між шардами, щоб використовувати обладнання ефективно. Єдина проблема — це складно :-)
  52. 52. де? WebApp Координатор● Node # 1234 data Storage nodes
  53. 53. Чому це складно?1. Програмістам спершу потрібно написатибільше коду, який реалізую логіку розбиття2. Операції над даними стають складнішими(резервне копіювання, додавання індексів, зміна схеми даних) Перший пункт важливий, але реальною проблемою може стати пункт два. Якщо не використовувати скріптів автоматизації, ви досить швидко “доживетеся” до повногобардаку, наприклад, із версіями схеми даних на різних шардах
  54. 54. ТакожЦентральний довідник може стати єдиною точкою відмови
  55. 55. ПрикладиСтарий підхід$connection = new_db_connection("host", port,"dbname");$statement = $connection->prepare($sql_statement, $params);$result = $statement->execute();
  56. 56. ПрикладиЛокатор, базований на URL$connection =new_db_connection("customer://1234");$statement = $connection->prepare($sql_statement, $params);$result = $statement->execute();Customer — сутність, 1234 — айді сутності
  57. 57. ПрикладиЛокатор, базований на URL (варіант 2)/*entity customer://1234 */ SELECT name FROMcustomer WHERE id = 1234
  58. 58. Прикладиcustomer://1234 (id)forums://master (r/w split)log://January/2008 (date)
  59. 59. Спільні проблеми для всіх схем розбиття З того моменту, як ви запровадили шардінг,ви матимете певні обмеження щодо операцій, які виконуються над базою даних. Головним чином ці обмеження повязані з тим, що запити, які включають кілька таблиць або велику кількість даних, не можуть бути виконані в межах одного сервера
  60. 60. Join-ни та денормалізація Вирішення проблеми обєднання кількох таблиць є денормалізація. Приклади: - в табличці списку форумів зберігатизагальну кількість постів, тему, дату та автора останнього посту. - в табличці користувачів записувати час останнього входу в систему
  61. 61. Зсилочна цілісність Форін кеї не працюють :-( Для підтримки цілісності даних потрібно створити інфраструктуру крондожобів, для очистки данихТакож потрібно уважно слідкувати за станомсистеми, яка реалізує денормалізацію даних
  62. 62. РебалансінгЩо робити, коли схема розбиття вибрана не правильно?У випадку розбиття за ключем чи діапазономзначень, вирішення цієї проблеми може бути дуже болючим і дорогим. Використання розбиття з використаннямсервіс локатора дозволяє зробити простіший ребалансінг за рахунок вищої складності системи і створення single point of failure
  63. 63. Висновки Якщо ви підтримуєте розбиття на рівніаплікації питання масштабування для вас більше не існує
  64. 64. Shared all
  65. 65. Shared nothing
  66. 66. Висновки Але зявляється комплекс інших питань. Менш критичних для вашого бізнесу.Ви позбуваєтесь технічних проблем ціною дорожчої розробки
  67. 67. Інші питання
  68. 68. SQL паттерни і антипаттерни Вибірка за первинним ключем Забуваємо про джоіниЗаміняємо (де можливо) складні запити на вьюви Вибираємо рекордсет а не рекорд Використовуємо функції
  69. 69. Зміна схеми Таличка Юзерс (часто апдейтиться) і табличка Профайл (рідко апдейтиться)Менші таблички — більше даних вміщаєтьсяв сторінку даних файлової системи — менше операцій зчитування, щоб отримати ту саму кількість данихРідко потрібні дані не займають місце в кеші
  70. 70. Count таблички
  71. 71. Count таблички
  72. 72. Асинхронні чергиЯкщо шардінг – це розподілення в просторі, то черга –розподілення в часіЯкщо щось можна зробити потім – нехай клієнт не чекає (цечасто можна бачити в твітері і фейсбуці)Досить легко зробити «універсальний» фреймворк дляроботи з чергамиАбо використати готовий
  73. 73. Асинхронні черги● Дозволяють Вам легше масштабуватися● Не кожна дія вимагає негайного виконання - відсилка пошти, твітів - логування, нотіси - вставка даних в базу, індексування● Деякі дії можна оптимізовувати для batch виконання
  74. 74. Gearman ● Message Queue ● A job coordinatorЕфективний елемент в розподіленій архітектурі
  75. 75. 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());}?>
  76. 76. Gearman<?php$client= new GearmanClient();$client->addServer();print $client->do("reverse", "Hello World!");?>
  77. 77. Атомарність і локінг ресурсівРейс кондішен при доступі до ресурсів в багатопоточному середовищі● begin; select * from table where flag = 0 for update; do work Commit;● 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Не забудьте розлокати :-)
  78. 78. АвтолоадЗвичайний __autoload() з php
  79. 79. АІОНе використовуємо апач
  80. 80. memcache- libketama- prolongate patch- add vs set- increment vs get, +1, set- cas - "check and set", значення будезбережене в кеші тільки у випадку, якщоінший клієнт не модифікував його значення зчасу, коли цей клієнт його отримав з кешу.- getmulti/setmulti
  81. 81. Clouds Повільні... ну те, що там називають “дисками” :-)Мережа єдина як для надання сервісу так і для доступу до мережевих дисківРішенням може бути software raid поверх кількох таких дисків
  82. 82. Екзотика! Матеріалізовані вьюви: http://code.google.com/p/flexviews/Матеріалізовані вьюви подібні до звичайних вьювів, за виключенням того, що вони зберігаються в реальних табличках Паралельне виконання запитів: http://code.google.com/p/shard-query/
  83. 83. Колонкові бази данихПроблема збереження великих масивів даних Проблема аналітичних запитів
  84. 84. 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-систем (Мусумеси, Лукидес)
  85. 85. Тут могла бути ваша реклама... ???
  86. 86. ПодякиВ презентації використані деякі матеріалиОлексія Рибака, представлені ним наконференції Хайлоад 2011

×