Бенчмаркінг баз даних

Я бачу багато дискусій про ефективність db 'x' або про те, що перехід від 'x' до 'y' покращив роботу нашого сайту.

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

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

2. Як би ви вирішили розробити такий орієнтир?

Коротка відповідь

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

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

Довга відповідь

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

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

2. Ви переміщуєте додаток до нової бази даних.

3. Ви робите ті ж заходи.

4. Ви порівнюєте

Наприклад, якщо повний перелік 3 182 432 товарів завантажено за 2.834 с. на старій базі даних і завантажується за 0,920 с. у новій базі даних, враховуючи, що в обох випадках програма має порожній кеш, це виграш: нова база даних покращила ефективність вашого сайту щодо цього запиту.

Тепер, як і будь-який показник ефективності, він упереджений:

• Погоджено, новий запит швидше. Але зачекайте, ваша DBA не знала, як використовувати базу даних, яку ви мали раніше , тому запит, що завантажує всі продукти, не оптимізований . Якщо ви перепишете його так, ви зможете завантажити ці продукти за 0,855 с. замість 2.834.

• Гаразд, у вас кращий результат. Але ви не вважаєте, що несправедливо порівнювати базу даних зі свіжими даними, щойно розгорнулися, з 10-річною базою даних, для якої останній план технічного обслуговування був виконаний три роки тому? До речі, ви не вважаєте, що вам слід було оновити продукт бази даних хоча б раз протягом останніх чотирьох років?

• Деякі запити швидше. Деякі - повільніше. Як ви обчислюєте середній результат, щоб знати, що ви загалом отримали продуктивність при переході до нової бази даних? Гаразд, час завантаження всіх 3 182 432 продуктів швидше. Але чи має значення, хоча запит виконується на веб-сайті лише у рідкісних випадках, коли адміністратор виконує якесь конкретне завдання, яке він виконував лише два рази за останні десять років? З іншого боку, виконання всіх запитів на домашній сторінці для нового користувача витрачає 0,281 с. з новою базою даних, коли вона становила 0,207 с. зі старою базою даних. Цей результат має значення набагато більше, тим більше, що ці запити не можна кешувати тривалий час, і виконуються десятки тисяч разів на день.

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

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

Найстрашніша помилка - це взяти ці висновки з орієнтирів і зробити деяку дурість на кшталт "Microsoft SQL Server втричі швидше, ніж Oracle": сказати це так, як сказати, що "Java краща за PHP". Визначте краще. Краще в яких випадках? Для якого типу додатків? Для якої команди розробників?

Чим більше ви інтерпретуєте та узагальнюєте, тим більше річ стає нерелевантною та безглуздою.

Запит, який select [...]ви можете знайти у версії файлу № 832 у ProductFactory.csрядку 117, виконується за 0,5 с. з новою базою даних при тестуванні в умовах, визначених у додатку M, нефункціональних вимог, випадок 3. Це дозволяє передати нефункціональну вимогу 527 (див. стор. 80, редакція 9). Цією ж вимогою не було задоволено попередню базу даних, коли результати тестування були в діапазоні 0,9..1,3 с. в тих же умовах.

є важливим для розробника та достатньо точним, щоб знати, що було протестовано, як і які були результати. Це відповідає на ваше запитання №2.

На жаль, це не має сенсу для управління. Замість цього:

Перенесення нашого продукту з MySQL на найновішу версію Microsoft SQL Server покращило загальну продуктивність нашого продукту на п’ять, зменшивши при цьому витрати на два та екологічний слід на три. Ми віримо, що перенесення всіх наших програм на Microsoft SQL Server в наступному році дасть ще кращі результати та підвищить конкурентоспроможність нашого ринку.

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

Нарешті, чи можемо ми порівняти різні типи баз даних? Я б сказав, що це цілком можливо. Скажімо, у мене є веб-сайт, на якому розміщені великі фотографії. Ці фотографії зберігаються в varbinary(max)Microsoft SQL Server 2005 (тому я не можу використовувати filestream). Мене турбує ефективність при завантаженні цих фотографій, тому я вирішую зберігати фотографії як файли, використовуючи файлову систему як свою нову базу даних. По-перше, ці файли зберігаються на тій же машині, що і база даних. Я профілюю нове рішення та отримую результат, який показує, що в моєму випадку файли завантажуються на 4% швидше з файлової системи, ніж з Microsoft SQL Server. Орієнтир дуже зрозумілий. Тепер я можу подумати про розгортання виділеного сервера, оптимізованого для прямого зберігання файлів, а не про використання сервера, оптимізованого для Microsoft SQL Server.

1. Коли всі гроші ставлять під сумнів великі компанії з базами даних та велика група розробників для додатків з відкритим кодом db, якби був спосіб це зробити, вони б уже зараз це зрозуміли (І результати отримали по всьому Інтернету. ).

2. Я б не став. Натомість створіть конкретні орієнтири для конкретних потреб та середовищ.

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

Ні, різниці між ними такі, що будь-який один орієнтир був би упередженим.

Однак, розробка такого сайту, як Computer Computer Benchmark Game , що включає широкий спектр тестів і дозволяє легко порівнювати тести (або конкретні тести з мови на мову, або з композиційних композицій на багатьох мовах), буде корисною (на принаймні в моїх очах), особливо якщо це було створено, щоб громада могла подавати рішення та покращувати будь-які недоліки в схемах чи запитах.

У випадку з базовим сайтом БД, замість реалізації алгоритмів (як у випадку з мовою розстрілу), тести можуть складатися із необроблених даних, які потрібно зберігати та потім отримувати відповідно до конкретних обмежень. Наприклад, можливо, є набір необроблених даних, що містить інформацію, яка представляє просту схему, що відображає те, що бібліотека спільноти може використовувати для відстеження меценатів та книг. Кожна БД повинна зберігати всі 1 мільйон записів, а потім отримувати деякі підмножини даних, що відповідають обмеженням. Тоді також може бути набір даних, який представляє деяку дуже просту структуру / взаємозв'язок (можливо, система коментарів, зазвичай використовується для таких сайтів, як ESPN тощо), що містить 100 мільйонів записів, і він має власний набір запитів, які необхідно виконати . І т.д.

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

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

1. Є два основні напрямки систем баз даних: OLAP та OLTP (див. Порівняння ).

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

Коротше кажучи: Ви б не заперечували, що Lamborghini - найкращий автомобіль у світі . Подумайте про об’єм багажника, кількість місць або пробіг.

Як додаткове зауваження: Ось орієнтир для систем баз даних OLTP.