실시간 작업을 위해 절차 언어 성능으로 PostgreSQL 사용자 정의 함수에 대한 정보를 찾으려고 합니다.
관련 결과 :
답변:
해석 언어의 UDF는 C 또는 내장 함수로 작성된 UDF보다 항상 느리지 만 다른 모든 것은 동일합니다.
각 언어 바인딩에는 PostgreSQL을 언어에 연결하는 코드가 다르며 최적화 수준, 데이터 형식을 전달하는 방법 등이 다릅니다. 따라서 변형이 존재합니다. 한 언어에서 다른 언어로 처리가 다른 데이터 유형을 전달하지 않는 한 (예 : 하나는 hstore문자열로 전달하고 다른 하나는 데이터 유형을로 변환하지 않는 한) 크지 않아야합니다 dict.
"컨텍스트"가 무엇인지 확실하지 않습니다. "실시간 데이터 매핑"에 사용할 수 있습니까? 기능이 수행하는 작업과 실행중인 서버, 클라이언트 및 요구 사항에 따라 속도가 빠른지 여부에 따라 다릅니다. 끈의 길이는 얼마입니까? 기준.
PL / PgSQL은 쓰기가 더 쉽고 SQL에 더 빠르게 액세스 할 수 있습니다. 일반적으로 많은 SQL 주위에 작은 논리를 감쌀 필요가있을 때 더 좋습니다. 수학 연산과 복잡한 알고리즘의 경우 속도가 매우 느리므로 C 또는 빠른 절차 언어를 선호하는 경우 PL / PgSQL의 순수한 계산 코드를 피해야합니다.
C에서 PL / PgSQL 코드를 다시 구현할 때의 속도 향상은 무시할 수있는 수준에서 1000 배 이상까지 다양합니다. 그것은 모두 코드가 실제로 무엇을하고 있는지에 달려 있습니다.
(이러한 종류의 다중 질문은 명확한 대답을하기가 어렵 기 때문에 Stack Exchange에는 적합하지 않습니다)
이것은 말하기 어렵습니다. 그것은 당신이 무엇을하고 있는지에 달려 있습니다. 예를 들어, PL / pgSQL은 큰 SQL 문을 가지고 있다면 훌륭합니다. 모든 종류의 분기, 하위 문자열 관리 및 모든 것을 가지고 있다면 정말 미친 듯이 보입니다.
실제로 사례마다 테스트해야합니다.
컨텍스트가 큰 오버 헤드입니까? 실시간 데이터 매핑에 사용할 수 있습니까 (1000 쿼리 /하자)
성능은 하드웨어 및 기능의 복잡성에 따라 다릅니다. 작은 12 코어 서버와 FusionIO 카드 (총 유로 10000)에서 실행되는 어플라이언스를 만들고 동시 사용자 20 명과 함께 초당 약 2500 개의 트랜잭션을 수행했습니다. 각 트랜잭션은 데이터를 처리하고 유용한 정보를 클라이언트에 반환하기 위해 29 개의 저장 프로 시저를 호출합니다. 일부 함수는 하나의 쿼리 만 실행하고 다른 함수는 몇 개의 쿼리를 실행합니다. 전체적으로 초당 약 200000 개의 INSERT, SELECT 및 UPDATE 문을 실행합니다.
이것은 모두 PL / SQL, PL / pgSQL 및 PL / PerlU로 작성되었습니다. 그리고 C로 (일부) 기능을 다시 쓸 때 시스템이 더 빠르게 실행될 수 있다고 확신합니다.
이 어플라이언스에서 대부분의 성능은 SSD 카드에서 비롯됩니다. 회전하는 단일 디스크에서는 결코이 성능을 얻지 못할 것입니다. 저렴한 SSD 드라이브도 실패합니다. (레이드 카드의 캐싱으로 인해) 한 시간 동안 작동 한 다음 게임이 끝났습니다. FusionIO 카드는 비싸지 만 IO에 바인딩 할 때 매우 좋은 투자입니다.