PostgreSQL TDE jest wersją PostgreSQL typu Open Source, która szyfruje dane przed ich bezpiecznym przechowywaniem na dysku. Jest to zatem bezpieczniejsza, a tym samym bardziej gotowa do zastosowania w przedsiębiorstwie odmiana bazy danych. Dlatego CYBERTEC PostgreSQL Enterprise Edition (PGEE) również w dużym stopniu opiera się na szyfrowaniu.
Analiza wydajności PostgreSQL
Ludzie często pytają o różnice w wydajności między zaszyfrowanym i nieszyfrowanym PostgreSQL. Aby odpowiedzieć na to pytanie, przeprowadziliśmy kompleksową analizę wydajności, aby rzucić nieco światła na ten ważny temat i dać użytkownikom możliwość porównania różnych ustawień PostgreSQL i ich wydajności. Nasze testy wydajności zostały przeprowadzone przy użyciu następujących komponentów sprzętowych i programowych:
Konfiguracja sprzętu
CPU: AMD Ryzen 5950X — 16 cores / 32 thread, 72MB cache, support for AES-NI
MEMORY: 64GB RAM — DDR4 2666 ECC dual channel
STORAGE: SSD Samsung 980 PRO — nvme, PCIe v4 ×4
prosty wolumin lvm, system plików XFS, wyłączne użycie
Oprogramowanie w użyciu
OS: Linux Centos 7.9.2009, kernel 5.10.11-1.el7.elrepo.x86_64
PostgreSQL: postgresql13-13.1-3PGDG.rhel7.x86_64 from PGDG repo
PostgreSQL 13.1 TDE: zbudowany lokalnie ze standardowymi opcjami kompilacji używanymi dla pakietów PGDG przy użyciu podstawowej bazy GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
PostgreSQL 13.1 TDE: zbudowany lokalnie ze standardowymi opcjami kompilacji używanymi dla pakietów PGDG przy użyciu kolekcji oprogramowania devtoolset-9 GCC 9.3.1 20200408 (Red Hat 9.3.1-2) i -march=znver2
Użyliśmy kilku skryptów, aby uruchomić te testy w sposób zautomatyzowany. Można pobrać narzędzia za darmo z naszego Githuba.
Notatki boczne
Ponieważ wyniki zostały wykonane na dysku półprzewodnikowym bez odpowiedniego zarządzania TRIM, przygotowywana jest druga wersja wszystkich tych analiz, z odpowiednim TRIM (opcja montażu odrzucanego -o) i skalami dostosowanymi, aby lepiej podkreślić wpływ zestawu danych na dostępne pamięć:
- małe (rząd wielkości mniejszy niż wspólne bufory) – skala 12
- tuż poniżej limitu wspólnych buforów (90% wspólnych buforów) – skala 900
- większe niż bufory współdzielone, ale nadal mieści się w pamięci RAM (120% buforów współdzielonych) – skala 1600
- większa niż RAM (120% RAM) – skala 5000
Pozostałe parametry i oprzyrządowanie będą takie same.
Metodologia benchmarkingu dla PostgreSQL
Wszystkie testy zostały wykonane lokalnie przy użyciu świeżo zainicjowanego, pustego klastra (świeży initdb). Dlatego efekty buforowania po stronie PostgreSQL nie mają znaczenia.
Przetestowano następujące konfiguracje:
- stock — standardowa instalacja PostgreSQL przy użyciu binariów z pakietów PGDG.
- TDE-4 — Instalacja PostgreSQL TDE z wyłączonym szyfrowaniem, przy użyciu binariów skompilowanych za pomocą gcc 4.8
- TDE-9 — Instalacja PostgreSQL TDE z wyłączonym szyfrowaniem, przy użyciu binariów skompilowanych z gcc 9.3 i zoptymalizowanych dla znver2
- TDE-4-e — Instalacja PostgreSQL TDE z włączonym szyfrowaniem, przy użyciu binariów skompilowanych za pomocą gcc 4.8
- TDE-9-e — Instalacja PostgreSQL TDE z włączonym szyfrowaniem, przy użyciu binariów skompilowanych z gcc 9.3 i zoptymalizowanych dla znver2
Prosimy zauważyć, że nie tylko porównaliśmy standardowy PostgreSQL z PostgreSQL TDE, ale także wypróbowaliśmy różne wersje kompilatorów. Można się przekonać, że kompilator rzeczywiście ma duży wpływ, co dla wielu może być zaskoczeniem.
Konfiguracja PostgreSQL
Użyto następującej konfiguracji PostgreSQL (postgresql.conf). Zmienne te zostały określone za pomocą wzoru CYBERTEC configurator:
max_connections = 100 unix_socket_directories = '/var/run/postgresql' port = 15432 shared_preload_libraries = 'pg_stat_statements' shared_buffers = 16GB work_mem = 64MB maintenance_work_mem = 620MB effective_cache_size = 45GB effective_io_concurrency = 100 huge_pages = try track_io_timing = on track_functions = pl wal_level = logical max_wal_senders = 10 synchronous_commit = on checkpoint_timeout = '15 min' checkpoint_completion_target = 0.9 max_wal_size = 1GB min_wal_size = 512MB wal_compression = on wal_buffers = -1 wal_writer_delay = 200ms wal_writer_flush_after = 1MB bgwriter_delay = 200ms bgwriter_lru_maxpages = 100 bgwriter_lru_multiplier = 2.0 bgwriter_flush_after = 0 max_worker_processes = 16 max_parallel_workers_per_gather = 8 max_parallel_maintenance_workers = 8 max_parallel_workers = 16 parallel_leader_participation = on enable_partitionwise_join = on enable_partitionwise_aggregate = on jit = on
Rozmiary baz danych podczas testu były następujące:
- 15: 244–287MB
- 20: 332–404MB
- 25: 400–458MB
- 30: 479–543MB
- 35: 557–629MB
- 50: 793–880MB
- 500: 7849–8028MB
- 5000: 78409–78756MB (exceeds total available memory)
Dla każdego współczynnika skali zmierzono następujące punkty odniesienia (przy użyciu opcji domyślnych):
- standardowy test porównawczy tylko do odczytu (wbudowany pgbench)
- standardowy benchmark odczytu/zapisu podobny do TPC (wbudowany pgbench) – przed każdym uruchomieniem TPC baza była ponownie indeksowana, aby uniknąć wpływu wykorzystania indeksu na wyniki
Współbieżność jest głównym czynnikiem, jeśli chcesz przeprowadzić benchmark w środowisku zawodowym. Zastosowano następujące ustawienia:
- 12
- 16 — liczba rdzeni fizycznych
- 20
- 24
- 28
- 32 —liczba wątków sprzętowych
- 36
- 40
- 44
- 48
Wyniki testów porównawczych PostgreSQL
Testy porównawcze tylko do odczytu dla PostgreSQL TDE
Poniższa sekcja zawiera wyniki naszego dochodzenia. Zacznijmy od testu porównawczego tylko do odczytu i współczynnika skali 50, co przekłada się na 880 MB danych (mała baza danych):
| R-O | |||||
| 50 | |||||
| connections | stock | TDE-4 | TDE-4-e | TDE-9 | TDE-9-e |
| 12 | 598.004,94 | 652.870,65 | 640.867,94 | 651.161,67 | 668.317,19 |
| 16 | 717.080,83 | 806.152,21 | 795.300,37 | 794.494,71 | 821.915,21 |
| 20 | 735.584,04 | 813.589,44 | 801.139,14 | 807.197,44 | 829.891,65 |
| 24 | 757.834,24 | 818.350,37 | 809.893,87 | 817.332,59 | 832.810,15 |
| 28 | 865.626,22 | 911.020,73 | 896.977,27 | 909.858,10 | 916.804,18 |
| 32 | 1.095.158,47 | 1.212.918,76 | 1.175.538,12 | 1.182.331,49 | 1.233.930,94 |
| 36 | 885.519,57 | 958.732,55 | 931.091,56 | 967.514,37 | 986.631,16 |
| 40 | 847.388,93 | 943.701,45 | 915.369,45 | 919.076,23 | 964.899,29 |
| 44 | 830.018,15 | 914.696,79 | 901.860,60 | 913.789,27 | 954.813,04 |
| 48 | 818.142,23 | 916.199,48 | 894.018,17 | 901.936,11 | 964.656,08 |
Spójrz na pierwszy rząd (12 połączeń). Standard PostgreSQL will yield 598.000 read-only transactions per second which is a good number. Ogólnie stwierdziliśmy, że obecnie procesory AMD są naprawdę wydajne i znacznie przewyższają IBM POWER9 i wiele innych. Zauważyliśmy, że kompilator robi prawdziwą różnicę. 651 tys. TPS vs. 598 tys. TPS to imponująca 9% poprawa, która w zasadzie jest „za darmo”. gcc 9 radzi sobie tutaj naprawdę dobrze.
Poniższy obrazek przedstawia podstawową architekturę PostgreSQL TDE:
Ważne jest również, aby zobaczyć, że zasadniczo nie ma różnicy między przebiegami zaszyfrowanymi i niezaszyfrowanymi. Powód tego jest prosty: PostgreSQL szyfruje 8k bloków przed wysłaniem ich na dysk i odszyfrowuje je, gdy blok jest pobierany z systemu operacyjnego. Dlatego nie ma różnicy między wydajnością zaszyfrowaną i nieszyfrowaną. To, co widzicie, to zasadniczo fluktuacje, których można się całkowicie spodziewać.
Przyjrzyjmy się tym samym danym. W tym przypadku używamy współczynnika skali 500, co przekłada się na 8 GB danych
| R-O | |||||
| 500 | |||||
| connections | stock | TDE-4 | TDE-4-e | TDE-9 | TDE-9-e |
| 12 | 583.003,70 | 623,487,99 | 611.303,93 | 615.277,51 | 628.507,18 |
| 16 | 723.460,41 | 772.852,04 | 750.083,11 | 761.129,07 | 782.628,12 |
| 20 | 750.054,44 | 782.333,97 | 770.649,65 | 778.393,73 | 795.200,14 |
| 24 | 755.796,29 | 792.365,30 | 773.744,79 | 787.903,80 | 802.164,80 |
| 28 | 842.270,11 | 890.584,06 | 872.163,41 | 886.265,42 | 895.721,71 |
| 32 | 1.087.753,87 | 1.166.292,93 | 1.124.810,04 | 1.133.026,80 | 1.170.395,10 |
| 36 | 881.376,33 | 926.521,14 | 901.508,03 | 914.466,29 | 948.293,12 |
| 40 | 860.762,15 | 911.308,67 | 875.478,96 | 911.961,05 | 912.369,46 |
| 44 | 857.354,28 | 895.126,03 | 863.349,07 | 878.027,97 | 916.855,40 |
| 48 | 853.062,65 | 881.192,84 | 858.566,69 | 882.463,09 | 910.616,50 |
Obraz jest bardzo podobny do tego, który zaobserwowaliśmy w przypadku małej bazy danych. Nadal jesteśmy w 100% w pamięci RAM i dlatego nie ma rzeczywistej różnicy w wydajności między PostgreSQL TDE z włączonym lub wyłączonym szyfrowaniem. To, co widzicie, to głównie wahania:
Ostateczny test został przeprowadzony przy współczynniku skali 5000. Ważną częścią jest to, że baza danych urosła tak duża, że nie ma już możliwości przechowywania jej w pamięci RAM. W ten sposób możemy zaobserwować znaczny spadek wydajności:
| R-O | |||||
| 5000 | |||||
| connections | stock | TDE-4 | TDE-4-e | TDE-9 | TDE-9-e |
| 12 | 78.858,92 | 75.226,39 | 74.968,65 | 80.913,53 | 82.063,75 |
| 16 | 104.880,27 | 99.974,75 | 99.921,82 | 106.414,78 | 107.763,35 |
| 20 | 126.328,88 | 120.898,40 | 119.139,41 | 124.199,94 | 125.980,44 |
| 24 | 143.740,06 | 139.041,17 | 134.917,30 | 136.937,95 | 140.407,50 |
| 28 | 156.813,58 | 152.443,32 | 147.754,62 | 148.286,04 | 152.065,41 |
| 32 | 170.999,35 | 162.929,84 | 156.527,94 | 157.810,55 | 164.181,20 |
| 36 | 180.937,04 | 171.578,25 | 165.513,33 | 167.660,63 | 172.848,70 |
| 40 | 189.501,24 | 180.439,46 | 173.084,98 | 174.142,58 | 179.936,11 |
| 44 | 196.615,29 | 187.607,67 | 178.765,27 | 179.044,87 | 185.212,72 |
| 48 | 201.491,30 | 192.716,50 | 183.124,81 | 183.379,49 | 190.149,00 |
Należy pamiętać, że przejście na dysk jest wielokrotnie droższe niż wykonanie jakiejś arytmetyki wskaźników w pamięci współdzielonej. Do każdego indywidualnego zapytania dodawane jest duże opóźnienie, co prowadzi do niskiego TPS, jeśli nie ma wystarczającej liczby połączeń. Na dyskach SSD efekt ten można nieco zredukować, dodając nieco więcej współbieżności. Jednak dodawanie współbieżności działa tylko do pewnego momentu, dopóki pojemność dysku nie zostanie przekroczona.
Testy porównawcze odczytu i zapisu dla PostgreSQL TDE
Po tym krótkim wprowadzeniu do testów porównawczych tylko do odczytu możemy skupić się na obciążeniach odczytu i zapisu. Używamy tutaj standardowych mechanizmów dostarczanych przez pgbench.
Pierwszą rzeczą, jaką zauważamy, jest to, że wydajność jest znacznie niższa. Są ku temu dwa powodyt:
- Transakcja odczytu i zapisu w pgbench ma o wiele więcej poleceń
- PostgreSQL musi opróżnić (fsync) zmiany na dysku podczas zatwierdzania
Rzućmy okiem na dane:
| TPC | |||||
| 50 | |||||
| connections | stock | TDE-4 | TDE-4-e | TDE-9 | TDE-9-e |
| 12 | 3.580,13 | 3.520,69 | 2.014,56 | 2.014,16 | 2.024,19 |
| 16 | 4.537,57 | 4.493,65 | 2.548,15 | 2.565,76 | 2.547,17 |
| 20 | 5.311,45 | 5.374,37 | 3.002,80 | 5.091,04 | 2.995,52 |
| 24 | 6.192,00 | 6.208,62 | 3.432,04 | 4.998,44 | 3.420,59 |
| 28 | 6.904,77 | 6.766,71 | 3.784,67 | 4.923,47 | 3.803,69 |
| 32 | 7.626,48 | 7.473,48 | 4.134,59 | 4.725,00 | 4.139,35 |
| 36 | 8.040,79 | 7.838,61 | 4.456,76 | 5.474,01 | 4.463,35 |
| 40 | 8.389,51 | 8.408,85 | 4.697,79 | 7.043,24 | 4.713,90 |
| 44 | 8.971,14 | 8.853,69 | 4.983,57 | 4.982,57 | 4.965,51 |
| 48 | 9.246,47 | 9.085,38 | 5.191,75 | 7.751,70 | 5.170,42 |
Cena szyfrowania zaczyna mówić. Widzimy, że wydajność zaszyfrowanych wariantów może być znacznie niższa niż w przypadku konfiguracji nieszyfrowanej.
Obraz jest podobny w przypadku zwiększenia ilości danych do współczynnika skali pgbench wynoszącego 500:
| TPC | |||||
| 500 | |||||
| connections | stock | TDE-4 | TDE-4-e | TDE-9 | TDE-9-e |
| 12 | 4.088,59 | 4.098,60 | 2.201,37 | 3.106,54 | 3.080,33 |
| 16 | 5.417,76 | 5.372,61 | 2.818,17 | 3.400,99 | 3.278,76 |
| 20 | 6.716,89 | 6.688,04 | 3.437,78 | 3.712,33 | 3.672,65 |
| 24 | 7.792,77 | 7.903,35 | 4.021,37 | 4.484,28 | 4.576,07 |
| 28 | 9.061,49 | 7.850,11 | 4.631,35 | 4.926,10 | 5.150,77 |
| 32 | 10.399,70 | 10.428,75 | 5.235,09 | 5.515,01 | 5.818,24 |
| 36 | 11.631,82 | 11.737,26 | 5.811,99 | 6.056,26 | 6.381,50 |
| 40 | 12.998,91 | 12.986,14 | 6.349,06 | 6.911,43 | 6.526,33 |
| 44 | 14.201,98 | 14.301,64 | 6.913,72 | 7.360,12 | 7.472,31 |
| 48 | 14.908,41 | 15.259,67 | 7.489,46 | 8.097,42 | 7.650,18 |
Przyjrzyjmy się teraz testowi przy użyciu współczynnika skali 5000. Wyraźnie widzimy, że ogólna wydajność dramatycznie spada. Powodem jest oczywiście to, że wiele danych musi pochodzić z dysku. W związku z tym widzimy spory czas oczekiwania i opóźnień na dysku:
| TPC | |||||
| 5000 | |||||
| connections | stock | TDE-4 | TDE-4-e | TDE-9 | TDE-9-e |
| 12 | 4.232,58 | 4.350,82 | 2.176,31 | 2.183,95 | 2.167,18 |
| 16 | 5.466,42 | 5.259,30 | 2.908,34 | 2.960,76 | 2.908,90 |
| 20 | 4.791,08 | 6.854,99 | 3.385,01 | 3.415,35 | 3.381,12 |
| 24 | 4.676,96 | 5.967,64 | 3.983,86 | 3.993,32 | 3.994,85 |
| 28 | 4.568,79 | 4.544,86 | 4.514,53 | 4.547,60 | 4.537,21 |
| 32 | 5.151,62 | 5.085,77 | 5.058,35 | 5.087,52 | 5.029,79 |
| 36 | 5.658,66 | 5.718,43 | 5.507,31 | 5.616,75 | 5.511,39 |
| 40 | 6.138,71 | 6.167,15 | 5.952,18 | 5.948,25 | 6.007,10 |
| 44 | 6.437,95 | 6.569,21 | 6.453,01 | 6.356,46 | 6.432,60 |
| 48 | 6.968,81 | 7.012,23 | 6.807,95 | 6.845,92 | 6.791,73 |
Warto pamiętać, że wszystkie wyniki należy traktować z przymrużeniem oka. Czasy działania zawsze mogą się nieznacznie różnić. Jest to szczególnie ważne, jeśli używane są dyski SSD. Widzieliśmy to w kółko. Poziom wydajności, którego możemy się spodziewać, będzie również w dużym stopniu zależał od wydajności pamięci podręcznej PostgreSQL. Należy pamiętać: za każdym razem, gdy blok jest wysyłany na dysk lub odczytywany do współdzielonych buforów, musi nastąpić magia szyfrowania/deszyfrowania. Dlatego może mieć sens uruchamianie PostgreSQL TDE z wyższymi ustawieniami shared_buffers niż normalnie, w celu zmniejszenia wpływu na bezpieczeństwo.
SKONTAKTUJ SIĘ Z NAMI
Jeśli dążycie do lepszej wydajności bazy danych PostgreSQL, zapraszamy do zapoznania się z naszą ofertą usług konsultingowych. Pomożemy Ci znacznie przyspieszyć twoją bazę danych. Oferujemy terminową dostawę, profesjonalną obsługę i ponad 20-letnie doświadczenie w PostgreSQL.
Skontaktuj się z nami>>
Również: zachęcamy do sprawdzenia PostgreSQL Transparent Data Encryption, aby uzyskać przejrzyste i bezpieczne kryptograficznie szyfrowanie danych na poziomie klastra. TDE pomaga zabezpieczyć najcenniejszy zasób: Państwa dane.
Sprawdź TDE >>