FRED & PostgreSQL. CZ.NIC, z.s.p.o. Jaromír Talíř

FRED & PostgreSQL CZ.NIC, z.s.p.o. Jaromír Talíř <[email protected]> 13. 2. 2008 http://www.nic.cz/ http://fred.nic.cz

1

Obsah ●

FRED – co to je?

●

Architektura systému, datový model, transakční model

●

Komunikace s databází - PL/pgSQL, Python, C++

●

Migrace z Informixu do PostgreSQL

●

Použité doplňkové nástroje (Slony, PgPool, PgFouine)

●

Běhové statistky

●

HW konfigurace

2

FRED – co to je? ● ●

Free Registry for ENUM and Domains Evidence domén, kontaktů a skupin DNS serverů (nsset)

●

Generování zónového souboru

●

Mailové upozorňování držitelů

●

●

Stahování banky, práce s kreditem, fakturace registrátorům Technické kontroly evidovaných DNS serverů

3

Architektura systému (1/3)

4

Architektura systému (2/3) ●

C++ a Python aplikační backend nad databází

●

Funkcionalita exportovaná přes technologii CORBA

●

Frontendy jako CORBA klienti –

EPP rozhraní pro registrátory

–

Unixový a webový WHOIS pro veřejnost

–

Webové administrační rozhraní pro helpdesk

–

Generátor zónového souboru

●

Vysoká distribuovanost komponent

●

Další řádkové nástroje linkované s knihovnami backendu

5

Architektura systému (3/3) ●

●

Přistup k databázi pouze zprostředkovaně (až na vyjímky) –

Generování offline statistik registru

–

SQL skripty kontrolující integritu dat

–

Replikace

–

Já :-)

Fyzicky se jedná o dvě duplicitní lokality –

Databáze a aplikační server na jednom stroji

–

EPP XML parser a generátor na samostatném stroji

–

Veřejné služby WHOIS na samostatném stroji

6

Datový model (1/2) ●

94 tabulek, 155 indexů, 47 sekvencí, 6 pohledů

●

16 uložených procedur (6 triggerů)

●

Normalizovaný model založený na dědičnosti

●

–

Např. doména ve třech tabulkách

–

Hodně tabulek v SELECT dotazech

Plná historie změn –

●

Při změně se do historie odrolují kompletní data objektu

Časové údaje jako timestamp bez TZ v UTC –

column::timestamptz AT TIME ZONE 'CET'

7

Datový model (2/2) ●

Dokumenty registru (PDF faktury, výpisy z bank atd...) uloženy na filesystému, v databázi pouze evidence

●

Mailová komunikace s držiteli uložena v databázi

●

XML komunikace s registrátory uložená v databázi –

Aktuálně generuje největší objem dat

–

XML jsou příliš malá na TOAST

8

Transakční model a zámky ● ●

Transakční model READ COMMITED pro všechny transakce Zamykání pouze ROW LEVEL pomocí SELECT FOR UPDATE –

●

Možnost použití jako synchronizačního primitiva

Optimistické vkládání dat –

Duplicitní záznam je chráněn přes constraint (např unique)

–

Není nutné zamykat na TABLE LEVEL

–

Problém jak se vyhnout ROLLBACKu – odchycení vyjímky

9

Programování v SQL a PL/pgSQL ●

Pomocné funkce např. atomická registrace nového objektu

●

Triggery na aktualizaci stavů objektů

●

Generování offline statistik provozu registru

●

Migrace starého datového modelu do nového

10

Python SQL komunikace ●

Dobrá podpora, implementace DB-API rozhraní

●

PygreSQL, Psycopg2

●

Django framework na weby s ORM mappingem

11

C++ SQL komunikace (1/2) ●

●

Vlastní C++ API nad libpq knihovnou –

Jednoduchost, objektovost, mapování typů

–

SQL konstruktor

ORM mapping (dynamické generování SQL pro různá funkční volání) –

DomainFilter f;

–

f.addExpirationDateFilter(DateInterval(DI_LAST_MONTH);

–

f.addRegistrarFilter().addHandleFilter(„REG-TEST“);

–

f.addSelect(„name“);

–

Result r = connection.execute(f.makeQuery());

–

for(r.begin(),r.hasNext(),r.setNext()) cout << r.getValue(); 12

C++ SQL komunikace (2/2) ●

●

Výběry a výsledky propojené přes TEMPORARY tabulky –

Způsob jak načíst seznam strukturovaných objektů

–

Komplikovaný SELECT vytvoří dočasnou tabulku obsahující pouze ID odpovídajících objektů

–

Několik dalšich SELECT volání incializuje seznam objektů

Třídění mimo databázi –

Absolvovat celý SELECT proces kvůli změně uspořádání je neefektivní

13

Problémy? Náměty? ●

Distribuované transakce?

●

Exception handling na úrovni SQL?

●

Prioritizace spojení?

●

Monitoring?

14

Migrace ●

Originální data z Informixu v podobě SQL dumpu

●

Sed magic - transformace typů v DDL scriptu

●

Vytvoření struktury a potom import dat přes COPY

●

SQL a PL/pgSQL skripty pro transformaci datového modelu

●

Duální transformace do SQLite + kontrola přes EPP

●

Domigrování BLOBů pomocí python skriptů

15

Nástroje (1/2) ●

Replikaci zajišťuje Slony

●

Master-slave asynchronní replikace

●

Triggery zachytávají změny a ty se pak propagují na duální (r/o) databázi

●

Nutnost vypnout aplikační triggery na duální databázi

●

Při každé změně schématu nutnost upravit proces replikace

●

Problémy s velkými tabulkami

●

Testování synchronní replikace pomocí WAL

16

Nástroje (2/2) ●

●

PgPool –

Nástroj na connection pooling

–

Zpočátku velmi slibně vypadající zrychlení

–

Problémy v případě chybných spojení

–

Nakonec odstraněn

PgFouine –

Analyzátor logů

–

Detailní statistiky četnosti a délky dotazů

–

Náročné na místo na disku

17

Hardwarová konfigurace ●

HP PowerEdge

●

CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz

●

HDD: 5x FUJITSU MAX3147RC 140 GB, PERC 5/i RAID 1+0

18

Dotazy? Děkuji za pozornost...

19