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

Бібліотека IBSurgeon

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

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

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

Читайте нашу статтю про ще більшу базу даних (1,7 терабайта): Детальніше про базу даних 1,7 терабайта.

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

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

Також важливою причиною, яку ми мали на увазі під час створення 1-терабайтної бази даних Firebird, було остаточне усунення поширеного уявлення про 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)

По суті, ми встановили HDD на 1,5 Тб в один із наших офісних настільних комп’ютерів без будь-яких інших модифікацій. Цей HDD було відформатовано з розміром кластера 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 байти, такий самий, як кластер HDD, щоб максимізувати пропускну здатність диска (читати/записувати 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 Viewer:

Індекси

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

Найбільший індекс було створено для таблиці 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))
------ Performance info ——
Prepare time = 15ms
Execute time = 79ms
Avg fetch time = 6.08 ms
Current memory = 272 264 476
Max memory = 272 514 048
Memory buffers = 16 384
Reads from disk to cache = 82
Writes from cache to disk = 0
Fetches from cache = 3 648		 Просте з’єднання таблиць із 12400 та 372000000 записів, без умов WHERE. «Avg fetch time = 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))
------ Performance info ——
Prepare time = 16ms
Execute time = 78ms
Avg fetch time = 6.00 ms
Current memory = 272 266 148
Max memory = 272 514 048
Memory buffers = 16 384
Reads from disk to cache = 88
Writes from cache to disk = 0
Fetches from cache = 3 656		 З’єднання тих самих таблиць з умовою, яка змушує вибирати останні записи. «Avg fetch time = 6.00 ms» — це для отримання першого рядка.
select count(*)
from WAREHOUSE, customer
where c_w_id = w_id and c_w_id = 10000
Result = 30000		 PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE))
------ Performance info ——
Prepare time = 0ms
Execute time = 453ms
Avg fetch time = 453.00 ms
Current memory = 272 263 844
Max memory = 272 514 048
Memory buffers = 16 384
Reads from disk to cache = 1 048
Writes from cache to disk = 0
Fetches from cache = 60 024		 Підрахунок записів для попереднього запиту
SELECT * FROM ORDER_LINE
WHERE OL_W_ID = 500		 Plan
PLAN (ORDER_LINE INDEX (ORDER_LINE_PK))
------ Performance info ——
Prepare time = 0ms
Execute time = 94ms
Avg fetch time = 7.23 ms
Current memory = 136 445 536
Max memory = 136 592 176
Memory buffers = 8 192
Reads from disk to cache = 150
Writes from cache to disk = 0
Fetches from cache = 2 402		 Запит до найбільшої таблиці (3.8B записів). «Avg fetch time = 7.23 ms» — це для отримання першого рядка.
<br>Plan<br>
<br>PLAN (ORDER_LINE INDEX (ORDER_LINE_PK))<br>
<br> <br>
<br>------ Performance info ------<br>
<br>Prepare time = 0ms<br>
<br>Execute time = 3s 438ms<br>
<br>Avg fetch time = 0.01 ms<br>
<br>Current memory = 136 445 496<br>
<br>Max memory = 136 592 176<br>
<br>Memory buffers = 8 192<br>
<br>Reads from disk to cache = 1 840<br>
<br>Writes from cache to disk = 0<br>
<br>Fetches from cache = 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))
------ Performance info ——
Prepare time = 0ms
Execute time = 125ms
Avg fetch time = 9.62 ms
Current memory = 272 270 824
Max memory = 272 514 048
Memory buffers = 16 384
Reads from disk to cache = 91
Writes from cache to disk = 0
Fetches from cache = 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)
Result = 59 970 000		 Plan
PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE))
------ Performance info ——
Prepare time = 0ms
Execute time = 13m 4s 718ms
Avg fetch time = 784 718.00 ms
Current memory = 272 268 532
Max memory = 272 514 048
Memory buffers = 16 384
Reads from disk to cache = 2 332 583
Writes from cache to disk = 0
Fetches from cache = 119 977 902		 Підрахунок записів для попереднього запиту

Підсумок

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

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

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

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

Контакти

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