Narzuty języków proceduralnych PostgreSQL (plpython / plsql / pllua…)

Próbuję znaleźć informacje na temat funkcji zdefiniowanych przez użytkownika PostgreSQL w działaniu języków proceduralnych do zadań w czasie rzeczywistym.

1. Jak porównują się do wbudowanych funkcji?
2. Czy jest jakaś różnica (narzutowa) w jaki sposób Postgres wywołuje / zarządza funkcjami plpython vs.
3. Czy kontekst jest dużym narzutem? Czy mogę go używać do mapowania danych w czasie rzeczywistym (powiedzmy 1000 zapytań / s)
4. Czy jest jakaś korzyść z pisania funkcji zdefiniowanych przez użytkownika w plpgsql niż w innym języku pg / języku? W dokumentacji wymieniają zalety, ale myślę, że dotyczą wszystkich języków proceduralnych postgresql.

Powiązane ustalenia:

• Szybkość języków PL do nietypowych zastosowań
• Funkcja języka PostgreSQL Wydajność: C vs PL / PGSQL

1. UDF w interpretowanych językach są prawie zawsze wolniejsze niż UDF napisane w C lub wbudowane funkcje, wszystkie inne rzeczy są takie same.

2. Każde powiązanie języka ma inny kod do połączenia PostgreSQL z językiem, z różnymi stopniami optymalizacji, różnymi sposobami przekazywania niektórych typów danych itp. Tak więc z pewnością istnieje zmienność. Nie powinno być duże, chyba że podajesz typ danych, który różni się obsługą jednego języka niż inny, np. Jeden przekazuje hstoreciąg znaków, a inny konwertuje go na dict.

3. Niejasny jest „kontekst”. Czy możesz go użyć do „mapowania danych w czasie rzeczywistym” ... cóż, zależy to od tego, co robi funkcja i czy jest wystarczająco szybka na serwerze, na którym działa, dla klientów, do których się bierze, i twoich wymagań. Jak długi jest kawałek sznurka? Reper.

4. PL / PgSQL jest prostszy w pisaniu i oferuje szybszy dostęp do SQL. Zasadniczo lepiej jest, gdy trzeba zawrzeć trochę logiki wokół dużej ilości SQL. Jest bardzo powolny w przypadku operacji matematycznych i złożonych algorytmów, dlatego w miarę możliwości należy unikać kodu czysto obliczeniowego w PL / PgSQL na korzyść C lub szybszego języka proceduralnego.

Przyspieszenia przy ponownym wdrażaniu kodu PL / PgSQL w C mogą różnić się od pomijalnych do ponad 1000 razy. Wszystko zależy od tego, co faktycznie robi kod.

(Ten rodzaj wielu pytań nie jest odpowiedni dla Stack Exchange, ponieważ trudniej jest uzyskać ostateczną odpowiedź)

trudno to powiedzieć. to naprawdę zależy od tego, co robisz. na przykład: PL / pgSQL jest wspaniały, jeśli masz w nim duże instrukcje SQL - to naprawdę szaleje, jeśli masz wszelkiego rodzaju rozgałęzienia, zarządzanie podciągami i tak dalej.

naprawdę musisz testować od przypadku do przypadku.

Czy kontekst jest dużym narzutem? Czy mogę go używać do mapowania danych w czasie rzeczywistym (powiedzmy 1000 zapytań / s)

Wydajność zależy od sprzętu i złożoności twoich funkcji. Stworzyłem urządzenie, które działało na małym 12-rdzeniowym serwerze i karcie FusionIO (całkowity koszt 10000 euro) i wykonałem około 2500 transakcji na sekundę z 20 jednoczesnymi użytkownikami. Każda transakcja wywołuje 29 procedur przechowywanych w celu przetworzenia danych i zwrócenia klientowi użytecznych informacji. Niektóre funkcje wykonują tylko jedno zapytanie, inne kilka zapytań. W sumie wykonuje około 200 000 instrukcji INSERT, SELECT i UPDATE na sekundę.

Wszystko to jest napisane w PL / SQL, PL / pgSQL i PL / PerlU. I jestem prawie pewien, że system może działać jeszcze szybciej, gdy (niektóre) funkcje zostaną przepisane w C.

W tym urządzeniu większość wydajności pochodzi z karty SSD. Na pojedynczym dysku obrotowym nigdy nie uzyskalibyśmy takiej wydajności. Tanie dyski SSD również nie działają, działa przez godzinę (z powodu buforowania karty rajdowej), a następnie gra się kończy. Karta FusionIO jest droga, ale bardzo dobra inwestycja, gdy jesteś związany IO.