powiem-ci-kim-jestes
Trafiłem na artykuł o pozyskiwaniu danych z serwisów społecznościowych.
Niby nic odkrywczego, ale warto mieć świadomość, że wszystkie te zasoby mogą łatwo być przeszukane - lub przy odrobinie wysiłku zgromadzone w jednym miejscu i zapamiętane NA ZAWSZE.
Co ciekawe, jest (i jeszcze przez jakiś czas będzie) wiele osób które nie dostrzegają równoważności między opublikowaniem czegoś na swoim profilu a naklejeniem tego na słupie ogłoszeniowym w centrum miasta - a przecież w pierwszym przypadku potencjalne audytorium jest o wiele szersze i co gorsza dla "ofiar" - wobec rosnącej penetracji internetu - ma niezerową część wspólną z tym drugim.
Sortowanie w PostgreSQL
Jarek napisał ciekawy artykuł o sortowaniu napisów w PostgreSQL (i nie tylko, w zasadzie rzecz dotyczy localesów w glibc).
explain analyze totals
Same as depesz and Greg, but using user-defined function:
CREATE FUNCTION ea_totals(text) RETURNS text AS $body$
my $result;
my $com = shift;
$com =~ /^\s*explain\s+/i or die qq{Not an explain query\n};
my $rv = spi_exec_query($com);
$rv->{status} eq 'SPI_OK_UTILITY' or die qq{Not a proper explain?\n};
for (map { $_->{'QUERY PLAN'} } @{$rv->{rows}}) {
my $string = ' ' x 10;
if ( /actual time=\d+\.\d*\.\.(\d+\.\d*) rows=\d+ loops=(\d+)/ ) {
$string = sprintf("%10.1f", $1 * $2);
}
$result .= "$string $_ \n";
}
return $result;
$body$ LANGUAGE plperl;
Usage:
SELECT * FROM ea_totals( $$ explain analyze query here $$);
SQL przyszłości
Funkcje odpytywania tekstów w standardzie SQL
Ponieważ w pracy zajmuję się ostatnio trochę wyszukiwaniem pełnotekstowym (zwłaszcza dodatkiem tsearch2 do PostgreSQL), zastanawiałem się, czy doczekamy się kiedyś powszechnego standardu SQL dla odpytywania tekstów.
Tak żeby znający SQL człowiek, który podchodzi do swojego pięknego nowiutkiego "wypasionego" serwera nie musiał się zastanawiać co napisać, aby zmusić go do czarnej roboty.
Okazuje się, że już od jakiegoś czasu istnieje standard SQL/MM, który m.in. opisuje rozszerzenia pełnotekstowe.
Podaję przykłady zapytań, bo mówią same za siebie.
Tworzymy tabelę z polem pełnotekstowym:
CREATE TABLE dokumenty (
id INTEGER,
body FULLTEXT
)
Szukamy dokumentów, w których wyraz brzmiący podobnie do parboiled pojawia się w tym samym zdaniu, co słowo rice:
SELECT id
FROM dokumenty
WHERE body.CONTAINS(
' SOUNDS LIKE "parboiled"
IN SAME SENTENCE AS "rice" '
)
Szukamy dokumentów zawierających terminy bliskoznaczne do kontrola błędów (np. obsługa wyjątków):
SELECT id
FROM dokumenty
WHERE body.CONTAINS(
' THESAURUS "informatyka" EXPAND SYNONYM TERM OF "kontrola błędów" '
)
Standard definiuje też konstrukcje, których implementacja jest co najmniej nietrywialna:
SELECT id FROM dokumenty
WHERE body.CONTAINS( ' IS ABOUT "analiza leksykalna" ' )
ORDER BY body.SCORE( ' IS ABOUT "analiza leksykalna" ' )
Ładne, prawda? No w każdym razie dla mnie wygląda to bardzo sympatycznie.
Zachęcam do zerknięcia na cały dokument, jest do pobrania na stronie www.wiscorp.com.
Jednak nie wpadajmy w euforię.
Po pierwsze, SQL/MM Full-Text na razie jest tylko w ułamkowej części implementowany przez niektóre silniki bazodanowe.
Po drugie, relacyjne bazy danych mają swoje ograniczenia. Widoczne są one także na polu wyszukiwania "ze zrozumieniem" - bo w sumie do tego dążymy jak się chwilę zastanowić. Pisze o tym np. Curt Monash w artykule Relational DBMS versus text data.
zmiany w mysql
Porównywałem ostatnio funkcjonalność postgresa i mysql w zakresie replikacji, i mam kilka obserwacji.
Jak wiadomo, mysql posiada wbudowaną obsługę replikacji.
Posiada ona taką główną zaletę, że jest wbudowana >;)
Z drugiej strony - ma poważne ograniczenia, ponieważ jest oparta na logowaniu zapytań, a nie zmian w danych tak jak np. Slony.
Tutaj można znaleźć więcej informacji.
Jednak mysql przechodzi poważne zmiany...
W wersji 5.0, która jest obecnie stabilna pojawiły się procedury składowane oraz triggery. oba te "ficzery" działają w dosyć ograniczonym zakresie.
Problemy jakie autorzy mysql mieli z nimi dobrze widać, gdy czyta się dokumentację - cały rozdział o procedurach składowanych i triggerach najeżony jest ostrzeżeniami dotyczącymi logu binarnego (binlog), który jest czymś w rodzaju logu transakcji - a zarazem podstawą systemu replikacji w mysql.
Nic dziwnego - idea replikacji "statement-based" jest z natury słaba. Jest to prymitywne podejście zastosowane bez specjalnych sukcesów m.in. w pgpool.
Odpowiedzią na te problemy ze strony mysql jest wprowadzony w wersji 5.1.x nowy format binlog. Loguje on zmiany już "po bożemu" czyli per rekord.
Umożliwia to prawidłową replikację nawet gdy korzysta się z triggerów i procedur modyfikujących dane.
Podsumowując:
mysql próbuje przesunąć się w stronę dużych RDBMS.
niewykluczone że za parę lat zmieni się w system bazodanowy z prawdziwego zdarzenia.
