Temat: użycie SQL jako języka deklaratywnego do "obliczeń"
Michał Zaborowski.:
.. Jedna firma kiedyś stwierdziła, że jednak się da zrobić coś inaczej niż inni to robią. Google się nazywa. ..
Michale wiem, wiem - zerknij do mojej wcześniejszej wypowiedzi.
Adrian Olszewski:
Marek K.:Adrian O.:
Osobiście implementowałem zaawansowaną bibliotekę metod numerycznych dla statystyki w T-SQL swego czasu Wykorzystywana jest do dziś.
Można zapytać o przykład najbardziej skomplikowanego wykonywanego obliczenia? Ponieważ są doświadczenia z użytkowania, to można poprosić o pros and cons?
Regresja liniowa (dekompozycja QR), ANOVA, test jednorodności wariancji Levena, PCA metodą rozkładu na wartości osobliwe (SVD). Oczywiście z raportowaniem przedziałów ufności i p-value, więc oczywistym jest, że także całkowanie numeryczne oraz funkcje specjalne, jak gamma (za pomocą odpowiednich przybliżeń).
Brzmi dobrze, gratuluję - a jakie obserwacje za i przeciw? Czy dysponuje Pan jakimiś danymi, które obrazowały by jak przebiega np: liczene transformaty Fouriera, czy też przepuszczenie danych przez filtr cyfrowy z wygładzaniem?
Marek K.:
Myślę, że zadanie manipulowania dużą ilością danych jest wystarczająco złożonym powodem dla którego warto stosować 'separation of concerns'. Dodatkowo wykonywanie obliczeń jest na tyle samo w sobie skomplikowane, że wymaga indywidualnego potraktowania.
Jest dokładnie przeciwnie tam, gdzie nie chcemy pchać po sieci tysięcy rekordów tylko po to, by je policzyć lub policzyć średnią czy medianę w grupach.
Jest dokładnie przeciwnie przecież wymaganie indywidualnego potraktowania, to nie zalecenie pchania tysięcy rekordów po sieci.
Widziałem, jak ludzie dostawali solidny OPR za to, że aby policzyć określone statystyki w grupach pchali kilkaset tysięcy liczb po sieci, zamiast policzyć agregaty w bazie. W pełni się pod tym OPR podpisałem.
Chyba nie ma w tym sugestii, że ja bym się nie podpisał? Podpisał bym się bo agregacja to jedno z najważniejszych zadań do wykonania na danych. Jednakowóż nie czyni to z SQL języka do obliczeń.
Nieco poboczny wątek, bo nie dotyczy SQL bezpośrednio: między innymi z tego powodu Oracle, PostgreSQL i od 2016 Microsoft dodali do swoich baz bezpośrednią integrację z R - właśnie po to, by jak najwięcej obliczeń wykonać po stronie silnika bazy danych.
Poboczny i tak i nie, bo jeżeli już iść tropem obliczeń na danych, na dużej ilości danych to wypada stwierdzić, że w takim razie nie powinien nas interesować SQL jako język do obliczeń ale powinniśmy poszukiwać bazy, która z zadaniem obliczeń sobie poradzi.
Nie w SQL-a sedno ale w bazach danych, które obliczenia mają wbudowane w kernel, w root.
Tym samym moja odpowiedź mozę być tylko jedna. Masz problem z obliczeniami to dokładnie je zdefiniuj. Jeżeli obliczenia nie wykraczają poza standard jaki wbudowano w 'tradycyjne' bazy danych to użyj tego co masz/znasz.
Jeżeli jednak obliczenia są skomplikowane, to nie gwałć istniejącej bazy, a zainteresuj się takimi rozwiązaniami jak np: baza Vertica HP, która ma wbudowane w środku algorytmy obliczeniowe (bazujące na języku R) i nie ogranicza się do wywoływania zewnętrznych poleceń pisanych w języku obliczeniowym.
Albo zainteresuj się bazą Amazon Redshift, która 'is a fully managed, petabyte-scale data warehouse service in the cloud' - 1 Petabyte = 1000000 Gigabyte! Amazon koncentruje się na 'standardowych' poleceniach SQL i znanym bussiness inteligence ale używa 'massive parallel processing', co wbudowano w cluster, na którym baza jest postawiona.
Wymienione rozwiązania za duże, za drogie, to zrób 'po Bożemu'. Baza niech przechowuje dane a obliczeniami niech zajmie się język obliczeniowy.
I jak dla mnie, to jest właściwa droga do obliczeń na danych. :-)
Dziękuję za rozmowę.
пропозиції роботи
