Cloud Vendor Deep-Dive:PostgreSQL na AWS Aurora

Jak hluboko bychom s tím měli jít? Začnu tím, že v době psaní tohoto článku jsem na Amazonu mohl najít pouze 3 knihy o PostgreSQL v cloudu a 117 diskuzí na e-mailových konferencích PostgreSQL o Aurora PostgreSQL. To se nezdá moc a mně, zvědavému koncovému uživateli PostgreSQL, to nechává oficiální dokumentaci jako jediné místo, kde bych se mohl skutečně dozvědět více. Vzhledem k tomu, že nemám schopnost ani znalosti k tomu, abych se dobrodružně hlouběji zabýval, existuje AWS re:Invent 2018 pro ty, kteří hledají tento druh vzrušení. Mohu se spokojit s Wernerovým článkem o kvorech.

Abych se zahřál, začal jsem z domovské stránky Aurora PostgreSQL, kde jsem si všiml, že benchmark ukazující, že Aurora PostgreSQL je třikrát rychlejší než standardní PostgreSQL běžící na stejném hardwaru, pochází z PostgreSQL 9.6. Jak jsem se později dozvěděl, 9.6.9 je aktuálně výchozí možností při nastavování nového clusteru. To je velmi dobrá zpráva pro ty, kteří nechtějí nebo nemohou upgradovat hned. A proč pouze 99,99% dostupnost? Jedno vysvětlení lze nalézt v článku Bruce Momjiana.

Kompatibilita

Podle AWS je Aurora PostgreSQL náhradní náhradou za PostgreSQL a dokumentace uvádí:

Kód, nástroje a aplikace, které dnes používáte se svými stávajícími databázemi MySQL a PostgreSQL, lze použít s Aurorou.

To je posíleno Aurora FAQ:

Znamená to, že většinu kódu, aplikací, ovladačů a nástrojů, které již dnes používáte se svými databázemi PostgreSQL, lze s Aurorou používat s malými nebo žádnými změnami. Databázový stroj Amazon Aurora je navržen tak, aby byl drátově kompatibilní s PostgreSQL 9.6 a 10, a podporuje stejnou sadu rozšíření PostgreSQL, které jsou podporovány s RDS pro PostgreSQL 9.6 a 10, což usnadňuje přesouvání aplikací mezi těmito dvěma motory.

„většina“ ve výše uvedeném textu naznačuje, že neexistuje 100% záruka, v takovém případě by ti, kdo hledají jistotu, měli zvážit nákup technické podpory buď od AWS Professional Services, nebo od partnerů Aamazon Aurora. Jako vedlejší poznámku jsem si všiml, že žádný z profesionálních poskytovatelů hostingu PostgreSQL zaměstnávajících hlavní přispěvatele komunity není na tomto seznamu.

Ze stránky Aurora FAQs se také dozvídáme, že Aurora PostgreSQL podporuje stejná rozšíření jako RDS, což zase uvádí většinu komunitních rozšíření a pár doplňků.

Koncepty

Jako součást Amazon RDS přichází Aurora PostgreSQL s vlastní terminologií:

• Cluster:Primární instance DB v režimu čtení/zápisu a nula nebo více replik Aurora. Primární DB je často označena jako Master v `AWS diagramech`_ nebo Writer v AWS Console. Na základě referenčního diagramu můžeme učinit zajímavé pozorování:Aurora píše třikrát. Vzhledem k tomu, že latence mezi AZ je obvykle vyšší než v rámci stejného AZ, transakce je považována za potvrzenou, jakmile je zapsána na datovou kopii ve stejném AZ, jinak dojde k latenci a potenciálním výpadkům mezi AZ.
• Svazek clusteru:Objem úložiště virtuální databáze zahrnující více AZ.
• Adresa URL Aurory:Pár „hostitel:port“.
• Koncový bod klastru:Aurora URL pro primární DB. Existuje jeden koncový bod clusteru.
• Koncový bod čtečky:Aurora URL pro sadu replik. Abychom vytvořili analogii s DNS, je to alias (CNAME). Požadavky na čtení jsou vyrovnány zatížením mezi dostupnými replikami.
• Vlastní koncový bod:Aurora URL pro skupinu sestávající z jedné nebo více instancí DB.
• Koncový bod instance:Aurora URL do konkrétní instance DB.
• Verze Aurora:Verze produktu vrácená `SELECT AURORA_VERSION();`.

Výkon a monitorování PostgreSQL na AWS Aurora

Dimenzování

Aurora PostgreSQL aplikuje konfiguraci nejlepšího odhadu, která je založena na velikosti instance DB a kapacitě úložiště, přičemž další ladění ponechává na DBA pomocí skupin DB Parameters.

Při výběru instance DB založte svůj výběr na požadované hodnotě pro max_connections.

Škálování

Aurora PostgreSQL nabízí automatické a manuální škálování. Horizontální škálování čtených replik je automatizováno pomocí výkonnostních metrik. Vertikální škálování lze automatizovat pomocí rozhraní API.

Horizontální škálování přepne na několik minut do režimu offline, zatímco vyměňuje výpočetní jádro a provádí jakékoli operace údržby (upgrady, opravy). Proto AWS doporučuje provádět takové operace během období údržby.

Změna měřítka v obou směrech je hračka:

Na úrovni úložiště se prostor přidává v krocích po 10G. Přidělené úložiště není nikdy vráceno zpět, viz níže, jak toto omezení vyřešit.

Úložiště

Jak bylo uvedeno výše, Aurora PostgreSQL byla navržena tak, aby využívala kvora za účelem zlepšení konzistence výkonu.

Vzhledem k tomu, že základní úložiště je sdíleno všemi instancemi DB v rámci stejného clusteru, nejsou vyžadovány žádné další zápisy na uzlech v pohotovostním režimu. Přidání nebo odebrání instancí DB také nemění základní data.

Zajímá vás, co ty IO průměr jednotek na měsíčním vyúčtování? Aurora FAQs znovu přichází na pomoc, aby vysvětlila, co je IO je v rámci sledování a účtování. Read IO jako ekvivalent 8KiB přečtení stránky databáze a Write IO jako ekvivalent 4KiB zapsaných do úložné vrstvy.

Vysoká souběžnost

Aby bylo možné plně využít design Aurora s vysokou souběžností, doporučuje se, aby byly aplikace nakonfigurovány tak, aby řídily velký počet souběžných dotazů a transakcí.

Aplikace navržené k přímému čtení a zápisu dotazů do pohotovostního a primárního databázového uzlu budou těžit z koncového bodu repliky čtečky Aurora PostgreSQL.

Spojení jsou mezi čtenými replikami vyvažována.

Pomocí vlastních koncových bodů lze instance databáze s větší kapacitou seskupit, aby bylo možné provozovat intenzivní pracovní zátěž, jako je analytika.

Koncové body DB Instance Endpoints lze použít pro jemné vyrovnávání zátěže nebo rychlé převzetí služeb při selhání.

Všimněte si, že aby koncové body aplikace Reader mohly vyvažovat jednotlivé dotazy, musí být každý dotaz odeslán jako nové připojení.

Ukládání do mezipaměti

Aurora PostgreSQL používá techniku ​​Survivable Cache Warming, která zajišťuje zachování data ve vyrovnávací paměti, čímž eliminuje potřebu opětovného naplnění nebo zahřívání mezipaměti po restartu databáze.

Replikace

Doba zpoždění replikace mezi replikami je udržována v rámci jedné číslice milisekundy. Ačkoli to není dostupné pro PostgreSQL, je dobré vědět, že zpoždění replikace mezi regiony se udržuje v rozmezí 10 s v milisekundách.

Podle dokumentace se zpoždění repliky zvyšuje během období velkých požadavků na zápis.

Plány provádění dotazů

Na základě předpokladu, že výkon dotazů v průběhu času klesá v důsledku různých změn databáze, je úlohou této komponenty Aurora PostgreSQL udržovat seznam schválených nebo zamítnutých plánů provádění dotazů.

Plány se schvalují nebo zamítají pomocí proaktivních nebo reaktivních metod.

Když je plán provádění označen jako zamítnutý, plán provádění dotazů přepíše rozhodnutí optimalizátoru PostgreSQL a zabrání provedení „špatného“ plánu.

Tato funkce vyžaduje Aurora 2.1.0 nebo novější.

Vysoká dostupnost a replikace PostgreSQL na AWS Aurora

Na vrstvě úložiště zajišťuje Aurora PostgreSQL odolnost tím, že každých 10 GB úložného prostoru replikuje šestkrát přes 3 AZ (každá oblast se obvykle skládá ze 3 AZ) pomocí fyzické synchronní replikace. To umožňuje, aby zápisy do databáze pokračovaly v práci, i když se ztratí 2 kopie dat. Dostupnost čtení přežije ztrátu 3 kopií dat.

Čtení replik zajišťuje, že neúspěšnou primární instanci lze rychle nahradit podporou jedné z 15 dostupných replik. Při výběru nasazení multi-AZ se automaticky vytvoří jedna čtená replika. Přepnutí při selhání nevyžaduje zásah uživatele a operace databáze se obnoví za méně než 30 sekund.

Pro nasazení single-AZ zahrnuje procedura obnovy obnovu z poslední známé dobré zálohy. Podle Aurora FAQs je proces dokončen za méně než 15 minut, pokud je potřeba obnovit databázi v jiném AZ. Dokumentace není tak konkrétní a tvrdí, že dokončení procesu obnovy trvá méně než 10 minut.

Pro připojení k nové instanci DB není vyžadována žádná změna na straně aplikace, protože koncový bod clusteru se během povýšení repliky nebo obnovy instance nemění.

Krok 1:Odstraňte primární instanci, abyste vynutili převzetí služeb při selhání:

Krok 2:automatické převzetí služeb při selhání dokončeno

U zaneprázdněných databází se doba obnovy po restartu nebo zhroucení výrazně zkrátí, protože Aurora PostgreSQL nemusí znovu přehrávat protokoly transakcí.

V rámci plně spravované služby jsou chybné datové bloky a disky automaticky nahrazeny.

Přepnutí při selhání, pokud existují repliky, trvá až 120 sekund, často pod 60 sekund. Rychlejších časů obnovy lze dosáhnout tím, že jsou předem určeny podmínky převzetí služeb při selhání. V takovém případě lze replikám přiřadit priority převzetí služeb při selhání.

Aurora PostgreSQL se dobře hraje s Amazon RDS – instance Aurora může fungovat jako čtená replika pro primární instanci RDS.

Aurora PostgreSQL podporuje logickou replikaci, kterou lze stejně jako v komunitní verzi použít k překonání omezení vestavěné replikace. Neexistuje žádná automatizace ani rozhraní konzoly AWS.

Zabezpečení pro PostgreSQL na AWS Aurora

Na úrovni sítě využívá Aurora PostgreSQL základní komponenty AWS, VPC pro izolaci cloudové sítě a skupiny zabezpečení pro řízení přístupu k síti.

Neexistuje žádný superuživatelský přístup. Při vytváření clusteru Aurora PostgreSQL vytvoří hlavní účet s podmnožinou oprávnění superuživatele:

[email protected]:5432 postgres> \du+ postgres
                               List of roles
 Role name |          Attributes               |    Member of       | Description
-----------+-------------------------------+-----------------+-------------
 postgres  | Create role, Create DB           +| {rds_superuser} |
            | Password valid until infinity  |                 |

Pro zabezpečení dat při přenosu poskytuje Aurora PostgreSQL nativní podporu SSL/TLS, kterou lze nakonfigurovat pro každou instanci DB.

Všechna data v klidu lze šifrovat s minimálním dopadem na výkon. To platí také pro zálohy, snímky a repliky.

Autentizace je řízena zásadami IAM a značkování umožňuje další kontrolu nad tím, co mohou uživatelé dělat a na jakých zdrojích.

Volání API používané všemi cloudovými službami jsou protokolována v CloudTrail.

Omezená správa hesel na straně klienta je dostupná prostřednictvím parametru rds.restrict_password_commands.

PostgreSQL Backup and Recovery na AWS Aurora

Zálohy jsou ve výchozím nastavení povoleny a nelze je zakázat. Poskytují obnovu v určitém okamžiku pomocí úplného denního snímku jako základní zálohy.

Obnova z automatické zálohy má několik nevýhod:doba obnovy může být několik hodin a ztráta dat může být až 5 minut před výpadkem. Amazon RDS Multi-AZ Deployments řeší tento problém podporou čtení repliky na primární, bez ztráty dat.

Snímky databáze jsou rychlé a nemají vliv na výkon clusteru. Lze je zkopírovat nebo sdílet s ostatními uživateli.

Pořízení snímku je téměř okamžité:

Obnovení snímku je také rychlé. Porovnejte s PITR:

Zálohy a snímky jsou uloženy v S3, který nabízí jedenáct 9 odolnosti.

Kromě záloh a snímků umožňuje Aurora PostgreSQL klonovat databáze. Jedná se o efektivní metodu pro vytváření kopií velkých datových sad. Například klonování mnoha terabajtů dat trvá jen několik minut a nemá žádný dopad na výkon.

Aurora PostgreSQL – ukázka obnovy bodu v čase

Připojování ke clusteru:

~ $ export PGUSER=postgres PGPASSWORD=postgres PGHOST=s9s-us-east-1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
~ $ psql
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

Naplňte tabulku daty:

[email protected]:5432 postgres> create table s9s (id serial not null, msg text, created timestamptz not null default now());
CREATE TABLE

[email protected]:5432 postgres> select * from s9s;
id | msg  |            created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
7 | test | 2019-06-25 07:59:59.5233+00
8 | test | 2019-06-25 08:00:00.318474+00
9 | test | 2019-06-25 08:00:11.153298+00
10 | test | 2019-06-25 08:00:12.287245+00
(10 rows)

Spusťte obnovu:

Po dokončení obnovy se přihlaste a zkontrolujte:

~ $ psql -h pg107-dbt3medium-restored-cluster.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

[email protected]:5432 postgres> select * from s9s;
id | msg  |            created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
(6 rows)

Doporučené postupy

Monitorování a audit

• Integrujte proudy databázových aktivit s monitorováním třetích stran, abyste mohli sledovat databázovou aktivitu z hlediska souladu a regulačních požadavků.
• Plně spravovaná databázová služba neznamená nedostatek odpovědnosti – definujte metriky pro sledování CPU, RAM, místa na disku, připojení k síti a databází.
• Aurora PostgreSQL se integruje se standardním monitorovacím nástrojem AWS CloudWatch a také poskytuje další monitory pro metriky Aurora, vylepšené metriky Aurora, počítadla statistik výkonu, replikaci Aurora PostgreSQL a také pro metriky RDS, které lze dále seskupovat podle dimenzí RDS.
• Sledování průměrného zatížení DB aktivních relací čekáním na známky režie připojení, dotazy SQL, které vyžadují ladění, soupeření o zdroje nebo poddimenzovanou třídu instance DB.
• Nastavte upozornění na události.
• Nakonfigurujte parametry protokolu chyb.
• Monitorujte změny konfigurace komponent databázového clusteru:instance, skupiny podsítí, snímky, skupiny zabezpečení.

Replikace

• Používejte nativní rozdělení tabulek pro pracovní zátěže, které překračují maximální třídu instance DB a kapacitu úložiště

Šifrování

• Šifrovaná databáze musí mít povoleno zálohování, aby bylo zajištěno obnovení dat v případě zrušení šifrovacího klíče.

Hlavní účet

• Nepoužívejte psql ke změně hlavního uživatelského hesla.

Dimenzování

• Zvažte použití různých tříd instancí v clusteru, abyste snížili náklady.

Skupiny parametrů

• Dolaďte pomocí skupin parametrů, abyste ušetřili $$$.

Ukázka skupin parametrů

Aktuální nastavení:

[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
10112136kB
(1 row)

Vytvořte novou skupinu parametrů a nastavte novou hodnotu pro celý cluster:

Přidružte skupinu vlastních parametrů ke clusteru:

Restartujte zapisovač a zkontrolujte hodnotu:

[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
1GB
(1 row)

• Nastavte místní časové pásmo

Ve výchozím nastavení je časové pásmo v UTC:

[email protected]:5432 postgres> show timezone;
TimeZone
----------
UTC
(1 row)

Nastavení nového časového pásma:

A pak zkontrolujte:

[email protected]:5432 postgres> show timezone;
TimeZone
------------
US/Pacific
(1 row)

Všimněte si, že seznam hodnot časových pásem, které Amazon Aurora přijímá, nejsou sady časových pásem nalezené v upstream PostgreSQL.

• Zkontrolujte parametry instance, které jsou přepsány parametry clusteru
• Použijte nástroj pro porovnání skupin parametrů.

Snímky

• Vyhněte se dalším poplatkům za úložiště sdílením snímků s jinými účty, abyste je mohli obnovit do příslušných prostředí.

Údržba

• Změňte výchozí okno údržby podle plánu organizace.

Přepnutí při selhání

• Zkraťte dobu obnovy konfigurací správy mezipaměti klastru.
• Snižte hodnoty udržování TCP jádra na klientovi a nakonfigurujte aplikační mezipaměť DNS a TTL a připojovací řetězce PostgreSQL.

DBA Pozor!

Kromě známých omezení se vyvarujte nebo si uvědomte následující:

Šifrování

• Jakmile byla databáze vytvořena, nelze stav šifrování změnit.

Aurora Serverless

• V současné době je PostgreSQL verze Aurora Serverless k dispozici pouze v omezené verzi.

Paralelní dotaz

• Amazon Parallel Query není k dispozici, ačkoli funkce se stejným názvem je dostupná od PostgreSQL 9.6.

Koncové body

Z Amazon Connection Management:

• 5 vlastních koncových bodů na cluster
• Názvy vlastních koncových bodů nesmí přesáhnout 63 znaků
• Názvy koncových bodů clusteru jsou jedinečné v rámci stejné oblasti
• Jak je vidět na výše uvedeném snímku obrazovky (aurora-custom-endpoint-details) READER a ŽÁDNÉ vlastní typy koncových bodů nejsou k dispozici, použijte CLI
• Vlastní koncové body si nejsou vědomy toho, že by repliky byly dočasně nedostupné

Replikace

• Při propagaci repliky na primární mohou být připojení přes koncový bod Reader i nadále na krátkou dobu směrována do propagované repliky.
• Repliky napříč oblastmi nejsou podporovány
• Přestože byla ukázka Amazon Aurora Multi-Master vydána na konci listopadu 2017, stále není k dispozici pro PostgreSQL
• Dejte si pozor na snížení výkonu, když je v clusteru povolena logická replikace.
• Logická replikace vyžaduje publikovaný běžící PostgreSQL engine 10.6 nebo novější.

Úložiště

• Maximální přidělené úložiště se po odstranění dat nezmenšuje a ani se neobnovuje místo obnovením ze snímků. Jediným způsobem, jak získat zpět místo, je provedení logického výpisu do nového clusteru.

Zálohování a obnovení

• Pokud je cluster zastaven, uchovávání záloh se neprodlužuje.
• Maximální doba uchování je 35 dní – pro delší dobu uchování použijte ruční snímky.
• Obnova v určitém okamžiku se obnoví do nového clusteru DB.
• krátké přerušení čtení během převzetí služeb při selhání do replik.
• Scénáře obnovy po havárii nejsou dostupné napříč regiony.

Snímky

• Obnovením ze snímku se vytvoří nový koncový bod (snímky lze obnovit pouze do nového clusteru).
• Po obnovení snímku je nutné znovu vytvořit vlastní koncové body.
• Obnovení ze snímků obnoví místní časové pásmo na UTC.
• Obnovení ze snímků nezachová vlastní skupiny zabezpečení.
• Snímky lze sdílet s maximálně 20 ID účtů AWS.
• Snímky nelze sdílet mezi regiony.
• Přírůstkové snímky se vždy kopírují jako úplné snímky mezi oblastmi a v rámci stejné oblasti.
• Kopírováním snímků napříč oblastmi se nezachovají jiné než výchozí skupiny parametrů.

Fakturace

• Účet za 10 minut se vztahuje na nové instance i po změně kapacity (výpočet nebo úložiště).

Ověření

• Použití ověřování databáze IAM omezuje počet připojení za sekundu.
• Hlavnímu účtu byla odebrána určitá oprávnění superuživatele.

Spouštění a zastavování

Z přehledu zastavení a sledování Aurora DB Cluster:

• Clustery nelze nechat zastavené na dobu neurčitou, protože se spouštějí automaticky po 7 dnech.
• Jednotlivé instance DB nelze zastavit.

Upgrady

• Přímé upgrady hlavních verzí nejsou podporovány.
• Změny skupiny parametrů pro instanci DB i cluster DB se projeví nejméně 5 minut.

Klonování

• 15 klonů na databázi (originál nebo kopie).
• Klony nejsou při mazání zdrojové databáze odstraněny.

Škálování

• Automatické škálování vyžaduje, aby byly k dispozici všechny repliky.
• Může existovat pouze `jedna zásada automatického škálování`_ na metriku a cluster.
• Horizontální škálování primární instance DB (třídy instance) není plně automatické. Před škálováním cluster spustí automatické převzetí služeb při selhání jedné z replik. Po dokončení škálování musí být nová instance ručně povýšena ze čtenáře na zapisovač:Nová instance zůstala v režimu čtečky po změně třídy instance DB.

Monitorování

• Publikování protokolů PostgreSQL na CloudWatch vyžaduje minimální verzi databázového stroje 9.6.6 a 10.4.
• V konzole RDS jsou k dispozici pouze některé metriky Aurora a další metriky mají jiné názvy a jednotky měření.
• Ve výchozím nastavení jsou protokoly Enhanced Monitoring uchovávány v CloudWatch po dobu 30 dnů.
• Metriky Cloudwatch a Enhanced Monitoring se budou lišit, protože shromažďují data z hypervizoru, respektive agenta běžícího na instanci.
• Performance Insights_ agreguje metriky napříč všemi databázemi v rámci instance DB.
• Příkazy SQL jsou při zobrazení pomocí rozhraní CLI a API AWS Performance Insights omezeny na 500 znaků.

Migrace

• V klidu lze šifrovat pouze nešifrované RDS snímky DB.
• Migrace pomocí techniky Aurora Read Replica trvá několik hodin na TiB.

Dimenzování

• Nejmenší dostupná třída instance je db.t3.medium a největší db.r5.24xlarge. Pro srovnání, engine MySQL nabízí db.t2.small a db.t2.medium, avšak v horním rozsahu žádný db.r5.24xlarge.
• horní limit max_connections je 262 143.

Správa plánu dotazů

• Příkazy uvnitř funkcí PL/pgSQL nejsou podporovány.

Migrace

Aurora PostgreSQL neposkytuje služby přímé migrace, ale úloha je přenesena na specializovaný produkt AWS, konkrétně AWS DMS.

Závěr

Amazon Aurora PostgreSQL jako plně spravovaná drop-in náhrada za upstream PostgreSQL využívá technologie, které pohánějí cloud AWS, k odstranění složitosti potřebné k nastavení služeb, jako je automatické škálování, vyrovnávání zatížení dotazů, data na nízké úrovni. replikace, přírůstkové zálohy a šifrování.

Architektura a konzervativní přístup k upgradu enginu PostgreSQL poskytuje výkon a stabilitu, které organizace od malých po velké hledají.

Přirozená omezení jsou jen důkazem toho, že vybudování rozsáhlé databáze jako služby je složitý úkol a ponechává vysoce specializovaným poskytovatelům hostingu PostgreSQL mezeru na trhu, na kterou mohou proniknout.