1 TB bazy danych Firebird: wstępny raport
Dmitry Kuzmenko, ostatnia aktualizacja 31-03-2014
Tłumaczenia tego dokumentu: portugalski rosyjski chiński
Przeczytaj nasz artykuł o jeszcze większej (1,7 terabajta) bazie danych: Więcej szczegółów na temat bazy danych o rozmiarze 1,7 terabajta.
Po co tworzyć terabajtową bazę danych Firebird?
Wiele firm pracuje z dużymi bazami danych Firebird i polega na nich przy wspieraniu ważnych operacji biznesowych. Niektóre bazy Firebird mają już setki gigabajtów i nadal rosną (patrz sekcja „Kto jest duży?”), więc łatwo przewidzieć moment, kiedy staną się 2, 3 lub 5 razy większe. Dlatego administratorzy baz danych i dostawcy oprogramowania są zainteresowani zbadaniem zachowania Firebirda z dużymi bazami danych oraz uzyskaniem zaleceń dotyczących ich zarządzania.
Ważnym powodem, który mieliśmy na uwadze podczas tworzenia bazy Firebird o rozmiarze 1 Tb, było ostateczne wyeliminowanie powszechnego postrzegania Firebirda jako silnika baz danych „dla małych baz”. Ten mit wydaje się już martwy, ale niektórzy analitycy i dziennikarze regularnie go wskrzeszają, i mamy nadzieję, że w końcu skończymy z tym absurdalnym postrzeganiem.
| ## Sprzęt |
Firebird jest znany z niesamowitej skalowalności, a to badanie potwierdziło to po raz kolejny. Początkowym celem tego eksperymentu było po prostu utworzenie bazy danych Firebird o rozmiarze 1 Tb, więc użyliśmy zwykłego komputera stacjonarnego:
Tabela 1: Sprzęt
| Komponent | Parametry |
| CPU | AMDAthlon 64 x2 5200 |
| RAM | 4GB |
| Płyta główna | MSI K9N Platinum |
| HDD1 (system operacyjny i temp) | ST3160815AS, 160GB, SATA II |
| HDD2 (pomocniczy) | HDT721064SLA360, 640GB, SATAII |
| HDD2 (pomocniczy) | HDS728080PLA380, 80GB, SATA I |
| HDD3 (baza danych) | ST31500341AS, 1.5TB, SATA II (Firmware CC1H) |
W zasadzie włożyliśmy dysk twardy 1.5Tb do jednego z naszych biurowych komputerów stacjonarnych, bez żadnych innych modyfikacji. Ten dysk twardy został sformatowany z rozmiarem klastra 16Kb (takim samym jak rozmiar strony bazy danych, jak widać poniżej).
Oprogramowanie
Ponieważ jest to komputer stacjonarny, systemem operacyjnym jest Windows XP Professional SP3, 32bit. Do faktycznego przeprowadzenia testu użyliśmy loadera z zestawu narzędzi opartego na TPC (pobierz go z http://ibdeveloper.com/tests/tpc-c/, dostępne są zarówno pliki binarne, jak i źródła).
Chcielibyśmy podkreślić, że loader wstawia dane tak, jak byłyby wstawiane w rzeczywistym scenariuszu: rekordy są wstawiane i umieszczane w bazie danych (oraz na fizycznych obszarach dysku) w kilku tabelach master-detail-subdetail, a nie tabela po tabeli.
Tabela 2: Oprogramowanie
| Oprogramowanie | Wersja |
| System operacyjny | Windows XP Professional SP3, 32bit |
| Firebird | 2.1.3 SuperServer (snapshot) |
| Loader | Niestandardowy loader z testu opartego na tpc |
Plan
Mieliśmy bardzo prosty plan tego eksperymentu:
- Utwórz bazę danych i załaduj do niej 1Tb danych, bez indeksów
- Utwórz klucze podstawowe i odpowiednie indeksy (więc faktyczny rozmiar bazy danych to ponad 1Tb)
- Zbierz statystyki bazy danych
- Uruchom kilka zapytań SQL i oceń wydajność bazy danych
Konfiguracja bazy danych i serwera Firebird
Baza danych ma rozmiar strony 16384 bajtów, taki sam jak klaster dysku twardego, aby zmaksymalizować wydajność dysku (odczyt/zapis 1 strony w jednym cyklu I/O).
W konfiguracji Firebirda skonfigurowaliśmy dodatkowy katalog na przestrzeń tymczasową i wskazaliśmy go na dysk o pojemności 640Gb (gdzie ~300Gb było wolne).
Etap ładowania
Dane zostały załadowane do tej bazy danych w kilku krokach. Komputer był używany podczas operacji ładowania jak zwykły komputer stacjonarny (mieliśmy MS Office, Firefox, IBAnalyst itp. - około 8-12 programów działało jednocześnie). Gdybyśmy poświęcili sprzęt tylko do tego zadania, prawdopodobnie byłoby szybciej, więc proszę traktować te wartości tylko jako przykład niskiej klasy; na pewno nie są to najlepsze wyniki.
Tabela 3: Operacje ładowania
| |
| Opis | Wartość |
| Czas ładowania | ~70 godzin |
| Łączna liczba wstawionych rekordów | 6,2 miliarda |
| Średnia prędkość wstawiania | 24500 rekordów/sekundę |
| Średni rozmiar rekordu | 146 bajtów (min 13 bajtów, max - 600 bajtów) |
| Transakcje | 646489 |
Spędziliśmy ~4 dni na ładowaniu, a po tym mieliśmy bazę danych Firebird o dokładnym rozmiarze 1Tb (tj. 1 099 900 125 184 bajtów).
Poniżej możesz zobaczyć wzrost bazy danych i dynamikę transakcji w przeglądarce FBDataGuard Viewer:
Indeksy
Tworzyliśmy indeksy jeden po drugim i mierzyliśmy czas ich tworzenia oraz odpowiedni rozmiar pliku tymczasowego używanego do sortowania.
Największy indeks został utworzony dla tabeli ORDER_LINE. Jego klucz podstawowy zawiera cztery pola (Smallint, Smallint, Integer i Smallint). Plik tymczasowy dla tego indeksu sortującego miał 182Gb, a ostateczny rozmiar indeksu w bazie danych to 29.3Gb.
Interesujące jest to, że nawet indeks dla tabeli z 3,8 miliardami rekordów ma głębokość = 3, ponieważ rozmiar strony wynosił 16384 bajtów, więc nie ma narzutu podczas wyszukiwania danych przy użyciu klucza podstawowego dla tej tabeli.
Statystyki
Następnie zebraliśmy statystyki bazy danych. Zajęło to 7 godzin 32 minut 45 sekund.
Umieściliśmy kluczowe informacje statystyczne w jednej tabeli i dołączyliśmy niektóre zapytania oraz pomiary czasu:
Tabela 4: Skonsolidowane statystyki dla bazy danych 1Tb
| Nazwa tabeli | Liczba rekordów | Rozmiar, gb | Czas wykonania select count(*) | Czas tworzenia indeksu | Rozmiar pliku tymczasowego, Gb | Rozmiar indeksu, Gb |
| 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 |
Statystyki bazy danych można pobrać stąd.
Możesz użyć darmowego FBDataGuard Community Edition Viewer, aby zinterpretować dane tekstowe i zobaczyć nie tylko metryki wydajności bazy danych, ale także zużycie CPU i pamięci.
Zapytania
Przede wszystkim uruchomiliśmy zapytania select count(*) na kilku tabelach (patrz 4. kolumna w Tabeli 4 powyżej). Jak wiadomo, ze względu na wielowersyjną naturę Firebirda select count(*) dla całej tabeli jest kosztowną operacją dla serwera, ponieważ wymaga odwiedzenia każdej strony, a doświadczeni programiści Firebirda nie używają select count(*), ale użyliśmy go, aby zademonstrować ogólny stosunek wydajności bazy danych i sprzętu.
Po zapytaniach select count uruchomiliśmy zapytania z rzeczywistego scenariusza i, szczerze mówiąc, byliśmy zdumieni tak dobrymi wynikami. Zobacz sam:
| Zapytanie | Statystyki | Opis |
| 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)) ------ Informacje o wydajności —– Czas przygotowania = 15ms Czas wykonania = 79ms Średni czas pobierania = 6.08 ms Bieżąca pamięć = 272 264 476 Maksymalna pamięć = 272 514 048 Bufory pamięci = 16 384 Odczytów z dysku do pamięci podręcznej = 82 Zapisów z pamięci podręcznej na dysk = 0 Pobrań z pamięci podręcznej = 3 648 |
Proste połączenie tabel z 12400 i 372000000 rekordami, bez warunków WHERE. „Średni czas pobierania = 6.08 ms” dotyczy pobrania pierwszego wiersza. |
| 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)) ------ Informacje o wydajności —– Czas przygotowania = 16ms Czas wykonania = 78ms Średni czas pobierania = 6.00 ms Bieżąca pamięć = 272 266 148 Maksymalna pamięć = 272 514 048 Bufory pamięci = 16 384 Odczytów z dysku do pamięci podręcznej = 88 Zapisów z pamięci podręcznej na dysk = 0 Pobrań z pamięci podręcznej = 3 656 |
Połączenie tych samych tabel z warunkiem, który wymusza wybór ostatnich rekordów. „Średni czas pobierania = 6.00 ms” dotyczy pobrania pierwszego wiersza. |
| select count(*) from WAREHOUSE, customer where c_w_id = w_id and c_w_id = 10000 Wynik = 30000 |
PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE)) ------ Informacje o wydajności —– Czas przygotowania = 0ms Czas wykonania = 453ms Średni czas pobierania = 453.00 ms Bieżąca pamięć = 272 263 844 Maksymalna pamięć = 272 514 048 Bufory pamięci = 16 384 Odczytów z dysku do pamięci podręcznej = 1 048 Zapisów z pamięci podręcznej na dysk = 0 Pobrań z pamięci podręcznej = 60 024 |
Policz rekordy dla poprzedniego zapytania |
| SELECT * FROM ORDER_LINE WHERE OL_W_ID = 500 |
Plan PLAN (ORDER_LINE INDEX (ORDER_LINE_PK)) ------ Informacje o wydajności —– Czas przygotowania = 0ms Czas wykonania = 94ms Średni czas pobierania = 7.23 ms Bieżąca pamięć = 136 445 536 Maksymalna pamięć = 136 592 176 Bufory pamięci = 8 192 Odczytów z dysku do pamięci podręcznej = 150 Zapisów z pamięci podręcznej na dysk = 0 Pobrań z pamięci podręcznej = 2 402 |
Zapytanie do największej tabeli (3.8B rekordów). „Średni czas pobierania = 7.23 ms” dotyczy pobrania pierwszego wiersza. |
<br>Plan<br><br>PLAN (ORDER_LINE INDEX (ORDER_LINE_PK))<br><br> <br><br>------ Informacje o wydajności ------<br><br>Czas przygotowania = 0ms<br><br>Czas wykonania = 3s 438ms<br><br>Średni czas pobierania = 0.01 ms<br><br>Bieżąca pamięć = 136 445 496<br><br>Maksymalna pamięć = 136 592 176<br><br>Bufory pamięci = 8 192<br><br>Odczytów z dysku do pamięci podręcznej = 1 840<br><br>Zapisów z pamięci podręcznej na dysk = 0<br><br>Pobrań z pamięci podręcznej = 598 636<br> |
| SELECT * FROM ORDER_LINE
WHERE OL_W_ID = 500 | To samo zapytanie do największej tabeli (3,8 mld rekordów), ale tym razem pobraliśmy wszystkie rekordy (pobrano 299 245 rekordów). |
| | |
| 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))
------ Informacje o wydajności ——
Czas przygotowania = 0ms
Czas wykonania = 125ms
Średni czas pobierania = 9,62 ms
Bieżąca pamięć = 272 270 824
Maksymalna pamięć = 272 514 048
Bufory pamięci = 16 384
Odczytów z dysku do pamięci podręcznej = 91
Zapisów z pamięci podręcznej na dysk = 0
Pobrań z pamięci podręcznej = 3 659 | Łączenie tabel z 1240 rekordami i 372 mln rekordów. |
| select count(*)
from WAREHOUSE, customer
where c_w_id = w_id and (c_w_id > 8000) and (c_w_id < 10000)
Wynik = 59 970 000 | Plan
PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE))
------ Informacje o wydajności ——
Czas przygotowania = 0ms
Czas wykonania = 13m 4s 718ms
Średni czas pobierania = 784 718,00 ms
Bieżąca pamięć = 272 268 532
Maksymalna pamięć = 272 514 048
Bufory pamięci = 16 384
Odczytów z dysku do pamięci podręcznej = 2 332 583
Zapisów z pamięci podręcznej na dysk = 0
Pobrań z pamięci podręcznej = 119 977 902 | Zliczanie rekordów dla poprzedniego zapytania |
Podsumowanie
W tym eksperymencie Firebird wykazał następujące wyniki
-
Niewątpliwa zdolność do obsługi dużych baz danych. Jesteśmy dość pewni, że możliwe jest utworzenie i używanie bazy danych o rozmiarze 32 Tb na odpowiednim sprzęcie, a Firebird będzie wykazywał taką samą wysoką wydajność, jak w przypadku mniejszych baz danych (tj. 1 Tb i poniżej).
-
Dobra skalowalność i zadziwiająco mały ślad pamięciowy. Baza danych o rozmiarze 1 Tb została utworzona na zwykłym komputerze stacjonarnym i, co ważniejsze, może być używana do wykonywania ogólnych zapytań: jeśli nie pobierasz milionów rekordów, szybkość zapytań jest taka sama jak w przypadku baz danych o umiarkowanym rozmiarze (10-15 Gb).
To nie jest koniec tego eksperymentu: zamierzamy uruchomić kilka zapytań, zebrać dodatkowe statystyki i wkrótce opublikować bardziej szczegółowy raport. Prosimy o pozostanie z nami.
Kontakt
Wszystkie pytania i zapytania prosimy kierować na adres [email protected]