Контакти
IBSurgeon
Цю сторінку перекладено машинним перекладом. Читайте англійський оригінал. English

Бібліотека IBSurgeon

1 Тб база даних Firebird: попередній звіт

Дмитро Кузьменко, останнє оновлення 31-03-2014

Переклади цього документа: Португальською Російською Китайською

Прочитайте нашу статтю про ще більшу (1,7 терабайта) базу даних: Більше деталей про базу даних Firebird SQL об’ємом 1,7 терабайта.

Навіщо створювати терабайтну базу даних Firebird?

Багато компаній працюють з великими базами даних Firebird і покладаються на них для підтримки важливих бізнес-операцій. Деякі з баз даних Firebird вже мають сотні гігабайт і продовжують зростати (див. розділ «Хто великий?»), і легко передбачити момент, коли вони стануть у 2, 3 або 5 разів більшими. Тому адміністратори баз даних і постачальники зацікавлені в дослідженні поведінки Firebird з великими базами даних та отриманні рекомендацій щодо їх управління.

Також важливою причиною, яку ми мали на увазі під час створення бази даних Firebird об’ємом 1 ТБ, було остаточне усунення поширеного сприйняття Firebird як рушія баз даних для «малих баз даних». Цей міф, здається, уже мертвий, але деякі аналітики та журналісти регулярно піднімають його з могили, і ми сподіваємося нарешті покінчити з цим безглуздим сприйняттям.
## Апаратне забезпечення

Firebird відомий своєю неймовірною масштабованістю, і це дослідження підтвердило це ще раз. Початковою метою цього експерименту було просто створення бази даних Firebird розміром 1 ТБ, тому ми використовували звичайний настільний комп’ютер:

Таблиця 1: Апаратне забезпечення
Компонент Параметри
CPU AMDAthlon 64 x2 5200
RAM 4GB
Материнська плата MSI K9N Platinum
HDD1 (операційна система та тимчасові файли) ST3160815AS, 160GB, SATA II
HDD2 (допоміжний) HDT721064SLA360, 640GB,SATAII
HDD2 (допоміжний) HDS728080PLA380, 80GB, SATA I
HDD3 (база даних) ST31500341AS, 1.5TB, SATA II (Firmware CC1H)

По суті, ми встановили жорсткий диск 1,5 ТБ в один із наших офісних настільних комп’ютерів без будь-яких інших модифікацій. Цей жорсткий диск було відформатовано з розміром кластера 16 КБ (тим самим, що й розмір сторінки бази даних, як ви можете побачити нижче).

Програмне забезпечення

Оскільки це настільний комп’ютер, операційна система - Windows XP Professional SP3, 32-бітна. Для фактичного виконання тесту ми використовували завантажувач із набору інструментів на основі TPC (завантажте його з http://ibdeveloper.com/tests/tpc-c/, доступні як бінарні файли, так і вихідні коди).

Ми хочемо підкреслити, що завантажувач вставляє дані так, як вони вставлялися б у реальному сценарії: записи вставляються та розміщуються всередині бази даних (і на фізичних областях диска) у кількох таблицях master-detail-subdetail, а не таблиця за таблицею.

Таблиця 2: Програмне забезпечення
Програмне забезпечення Версія
Операційна система Windows XP Professional SP3, 32bit
Firebird 2.1.3 SuperServer (snapshot)
Завантажувач Власний завантажувач із тесту на основі tpc

План

У нас був дуже простий план для цього експерименту:

  1. Створити базу даних і завантажити її даними об’ємом 1 ТБ, без індексів
  2. Створити первинні ключі та відповідні індекси (тому фактичний розмір бази даних перевищує 1 ТБ)
  3. Зібрати статистику бази даних
  4. Виконати кілька SQL-запитів і оцінити продуктивність бази даних

Конфігурація бази даних і сервера Firebird

База даних має розмір сторінки 16384 байти, такий самий, як кластер жорсткого диска, щоб максимізувати продуктивність диска (читати/записувати 1 сторінку за один цикл введення-виведення).

У конфігурації Firebird ми налаштували додатковий каталог для тимчасового простору та вказали на диск об’ємом 640 ГБ (де було вільно ~300 ГБ).

Етап завантаження

Дані завантажувалися в цю базу даних кількома етапами. Комп’ютер використовувався під час операцій завантаження як звичайний настільний ПК (у нас були MS Office, Firefox, IBAnalyst тощо - одночасно працювало близько 8-12 програм). Якби ми виділили апаратне забезпечення лише для цього завдання, ймовірно, було б швидше, тому розглядайте ці значення лише як приклад нижньої межі; вони, безумовно, не є найкращими результатами.

Таблиця 3: Операції завантаження

| |
Опис Значення
Час завантаження ~70 годин
Загальна кількість вставлених записів 6,2 мільярда
Середня швидкість вставки 24500 записів/секунду
Середній розмір запису 146 байт (мін. 13 байт, макс. - 600 байт)
Транзакції 646489

Ми витратили ~4 дні на завантаження, і після цього мали базу даних Firebird розміром рівно 1 ТБ (тобто 1 099 900 125 184 байти).

Нижче ви можете побачити зростання бази даних і динаміку транзакцій у переглядачі FBDataGuard:

Індекси

Ми створювали індекси один за одним і фіксували час їх створення та відповідний розмір тимчасового файлу, використаного для сортування.

Найбільший індекс було створено для таблиці ORDER_LINE. Його первинний ключ містить чотири поля (Smallint, Smallint, Integer і Smallint). Тимчасовий файл для цього індексу сортування становив 182 ГБ, а кінцевий розмір індексу в базі даних - 29,3 ГБ.

Цікаво бачити, що навіть індекс для таблиці з 3,8 мільярда записів має глибину = 3, оскільки розмір сторінки становив 16384 байти, тому немає жодних накладних витрат під час пошуку даних за первинним ключем для цієї таблиці.

Статистика

Після цього ми зібрали статистику бази даних. Це зайняло 7 годин 32 хвилини 45 секунд.

Ми зібрали ключову статистичну інформацію в одну таблицю та включили деякі запити та вимірювання часу:

Таблиця 4: Зведена статистика для бази даних 1 ТБ
Назва таблиці Кількість записів Розмір, ГБ Час виконання select count(*) Час створення індексу Розмір тимчасового файлу, ГБ Розмір індексу, ГБ

| WAREHOUSE | 1240 | 0.002 | 0s | 0 | 0 | 0.0 | | ITEM | 100000 | 0.012 | 0.7s | - | - | 0.0 | | DISTRICT | 124000 | 0.017 | 0.7s | 6 | - | 0.0 | | NEW_ORDER | 111600000 | 32 | 20m 00s | 23m 00s | 4.56 | 0.8 | | CUSTOMER | 372000000 | 224 | - | 41m 00s | - | 2.6 | | customer_last | | | | 1h 52m 32s | 12.4 | 2.3 | | fk_cust_ware | | | | 2h 10m 51s | - | 2.3 | | HISTORY | 372000000 | 32 | - | - | - | - | | ORDERS | 372000000 | 25 | 32m 00s | 45m 41s | 15.2 | 2.5 | | STOCK | 1240000000 | 404 | - | 3h 34m 44s | 41.5 | 9.2 | | ORDER_LINE | 3720051796 | 359 | - | 12h 6m 18s | 182.0 | 29.3 |

Статистику бази даних можна завантажити звідси.

Ви можете використовувати безкоштовний FBDataGuard Community Edition Viewer для інтерпретації текстових даних та перегляду не лише показників продуктивності бази даних, але й споживання CPU та пам’яті.

Запити

Перш за все, ми виконали select count(*) запити до кількох таблиць (див. 4-ту колонку в Таблиці 4 вище). Як відомо, через багатоверсійну природу Firebird, select count(*) для всієї таблиці є дорогою операцією для сервера, оскільки вимагає відвідування кожної сторінки, і досвідчені розробники Firebird не використовують select count(*), але ми використали його, щоб продемонструвати загальне співвідношення продуктивності бази даних та апаратного забезпечення.

Після запитів select count ми виконали запити з реального сценарію, і, чесно кажучи, ми були вражені такими хорошими результатами. Переконайтеся самі:
Запит Статистика Опис
select w_id, w_name, c_id, c_last
from WAREHOUSE, customer
where c_w_id = w_id		 PLAN JOIN (WAREHOUSE NATURAL, CUSTOMER INDEX (FK_CUST_WARE))
------ Інформація про продуктивність —–
Час підготовки = 15ms
Час виконання = 79ms
Середній час вибірки = 6.08 ms
Поточна пам’ять = 272 264 476
Максимальна пам’ять = 272 514 048
Буфери пам’яті = 16 384
Читання з диска в кеш = 82
Записи з кеша на диск = 0
Вибірки з кеша = 3 648		 Просте з’єднання таблиць з 12400 та 372000000 записами, без умов WHERE. «Середній час вибірки = 6.08 ms» - це час отримання першого рядка.
select w_id, w_name, c_id, c_last
from WAREHOUSE, customer
where c_w_id = w_id and c_w_id = 10000		 PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE))
------ Інформація про продуктивність —–
Час підготовки = 16ms
Час виконання = 78ms
Середній час вибірки = 6.00 ms
Поточна пам’ять = 272 266 148
Максимальна пам’ять = 272 514 048
Буфери пам’яті = 16 384
Читання з диска в кеш = 88
Записи з кеша на диск = 0
Вибірки з кеша = 3 656		 З’єднання тих самих таблиць з умовою, яка змушує вибірку останніх записів. «Середній час вибірки = 6.00 ms» - це час отримання першого рядка.
select count(*)
from WAREHOUSE, customer
where c_w_id = w_id and c_w_id = 10000
Результат = 30000		 PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE))
------ Інформація про продуктивність —–
Час підготовки = 0ms
Час виконання = 453ms
Середній час вибірки = 453.00 ms
Поточна пам’ять = 272 263 844
Максимальна пам’ять = 272 514 048
Буфери пам’яті = 16 384
Читання з диска в кеш = 1 048
Записи з кеша на диск = 0
Вибірки з кеша = 60 024		 Підрахунок записів для попереднього запиту
SELECT * FROM ORDER_LINE
WHERE OL_W_ID = 500		 Plan
PLAN (ORDER_LINE INDEX (ORDER_LINE_PK))
------ Інформація про продуктивність —–
Час підготовки = 0ms
Час виконання = 94ms
Середній час вибірки = 7.23 ms
Поточна пам’ять = 136 445 536
Максимальна пам’ять = 136 592 176
Буфери пам’яті = 8 192
Читання з диска в кеш = 150
Записи з кеша на диск = 0
Вибірки з кеша = 2 402		 Запит до найбільшої таблиці (3.8B записів). «Середній час вибірки = 7.23 ms» - це час отримання першого рядка.
<br>Plan<br>
<br>PLAN (ORDER_LINE INDEX (ORDER_LINE_PK))<br>
<br> <br>
<br>------ Інформація про продуктивність ------<br>
<br>Час підготовки = 0ms<br>
<br>Час виконання = 3s 438ms<br>
<br>Середній час вибірки = 0.01 ms<br>
<br>Поточна пам'ять = 136 445 496<br>
<br>Максимальна пам'ять = 136 592 176<br>
<br>Буфери пам'яті = 8 192<br>
<br>Читання з диска в кеш = 1 840<br>
<br>Записи з кеша на диск = 0<br>
<br>Вибірки з кеша = 598 636<br>
SELECT * FROM ORDER_LINE
WHERE OL_W_ID = 500		 Той самий запит до найбільшої таблиці (3.8B записів), але цього разу ми отримали всі записи (299245 записів отримано).
select w_id, w_name, c_id, c_last
from WAREHOUSE, customer
where c_w_id = w_id and (c_w_id > 8000) and (c_w_id < 10000)		 Plan
PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE))
------ Інформація про продуктивність —–
Час підготовки = 0ms
Час виконання = 125ms
Середній час вибірки = 9.62 ms
Поточна пам’ять = 272 270 824
Максимальна пам’ять = 272 514 048
Буфери пам’яті = 16 384
Читання з диска в кеш = 91
Записи з кеша на диск = 0
Вибірки з кеша = 3 659		 З’єднання таблиць з 1240 записами та 372M записів.
select count(*)
from WAREHOUSE, customer
where c_w_id = w_id and (c_w_id > 8000) and (c_w_id < 10000)
Результат = 59 970 000		 Plan
PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE))
------ Інформація про продуктивність —–
Час підготовки = 0ms
Час виконання = 13m 4s 718ms
Середній час вибірки = 784 718.00 ms
Поточна пам’ять = 272 268 532
Максимальна пам’ять = 272 514 048
Буфери пам’яті = 16 384
Читання з диска в кеш = 2 332 583
Записи з кеша на диск = 0
Вибірки з кеша = 119 977 902		 Підрахунок записів для попереднього запиту

Підсумок

У цьому експерименті Firebird показав наступні результати

  1. Безсумнівна здатність працювати з великими базами даних. Ми впевнені, що можна створити та використовувати базу даних 32 Tb на відповідному апаратному забезпеченні, і Firebird покаже таку ж високу продуктивність, як і для менших баз даних (тобто 1Tb і нижче).

  2. Хороша масштабованість та напрочуд малий слід. База даних 1Tb була створена на звичайному настільному комп’ютері, і, що більш важливо, її можна використовувати для виконання загальних запитів: якщо ви не отримуєте мільйони записів, швидкість запитів така ж, як і для баз даних середнього розміру (10-15Gb).

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

Контакти

Надсилайте всі ваші запитання та звернення на [email protected]