Temat: Hurtownia Danych - Baza Open Source
Bartłomiej G.:
Adam O.:
[...]
Ideałem dla mnie byłoby mieć bazę danych z zestawem standardowych procedur, taki gotowy framework, na bazie którego w szybki, bezbolesny i tani sposób możnaby zaimplementować hurtownię danych niewielkich rozmiarów, która będzie działać. Jeśli do tego będzie wymagany support/maintenance, to bardzo dobrze - z czegoś trzeba żyć ;-)
Netezza? Nie wiem o niej za dużo, ale jak widzę "gotowy framework" i "hurtownia" w jednym zdaniu to mi się samo narzuca.
Czy Netezza jest open source? Nie sądzę :)
Moim ulubionym narzędziem ETL jest Informatica, niestety nie miałem przyjemności z niej korzystać od dosyć dawna. My mówimy jednak o sytuacji, gdy firma ma problem z zapłaceniem licencji za SQL Server 2012 Enterprise :) bo wydaje im się to zbyt drogim rozwiązaniem.
Co licencji - SQL Server 2012 Enterprise to 6.5kUSD za core -
min. 4 trzeba kupić. Robi się całkiem sporo. Wiem, że Oracle,
czy DB2 są sporo droższe. No ale dla małej firmy? Zwłaszcza,
że pewnie system transakcyjny trzeba robić osobno...
PostgreSQL do mniejszych rzeczy nadaje się całkiem fajnie.
Można zrobić przechowywanie i wstępne przetwarzanie obok
głównego, transakcyjnego procesu. Nawet w ramach samej
bazy też coś tam się da zrobić - pojedyncza wartość może mieć
4GB. Tablicę array - trzymana jest jak w Ansi C. Czyli, od biedy
można pójść w stronę bazy kolumnowej. Tyle, że... pod spodem
baza szatkuje te dane i w praktyce już tak fanie nie wygląda.
Dlatego, jak zajmowałem się takimi wynalazkami - ETL był
poza PG, natomiast dopytywanie szło czystym SQLem. Następny
krok to wstępne przefiltrowanie już na poziomie dostępu do
danych. Funkcje okienkowe są super, nawet działa to optymalnie.
Tyle, że problemem jest seqscan po ogromnym zbiorze danych.
Oracle pozwala na zrobienie tego przez kilka równoległych
procesów - każdy swój kawałek. Hadoop ma tak, że chunk
danych ma 64MB i każdy z nich może być obskoczony przez
osobny proces. Postgres jedzie od początku do końca. To, co
sam z siebie potrafi optymalizować - równoległe seqscany spina
w jeden.
To co piszę, to trochę naginanie rozwiązania czysto transakcyjnego
do zastosowania, które jest mu obce. Słyszałem, że jakaś polska
firma przerobiła PG, żeby trzymał dane kolumnowo, nie wierszowo.
Niby da się, ale z drugiej strony - może prościej pójść w stronę
rozwiązań, które z miejsca odrzucają transakcyjność i cały związany
z nią narzut? Chętnie bym zobaczył jak SIMD działa w takim czymś,
ale ilość roboty trochę mnie odstrasza :D
No i zastosowanie w realnych zagadnieniach - jest osobną sprawą.
Dobra - posumować da się, ale tu by trzeba umieć zastosować jakieś
wyrażenie do danej - krok za krokiem - no a to już raczej CUDA. No i
robi się problem, o którym wiem, że nie pociągnę...