Wpisy z kategorii 'ganglib'

Pyshards

Napisano Czerwiec 22, 2008 * Komentarze (0)

Natrafiłem niedawno na ciekawy projekt o nazwie Pyshards (http://code.google.com/p/pyshards/wiki/Pyshards).

Biblioteka jest projektem stosunkowo młodym, a cele które autorzy przed nim stawiają w dużej mierze pokrywają się z tymi które ma przed sobą nasz Ganglib.

Po krótce – pyshards zapewnia mechanizm partycjonowania poziomego – tworzenia shardów za pomocą Pythona i MySQL. Pyshards nie korzysta z mechanizmów ORM-o podobnych, a stara się zapewnić stosunkowo dużą zgodność ze standardowym sqlem.

Ciekaw jestem jak projekt się rozwinie i jakie będą jego docelowe możliwości (czy obsługa natywnego sqla będzie obejmowała także JOINy, subkwerendy i złączenia?).

ps. Z Gangliba korzysta pierwsza,  komercyjna witryna sporych rozmiarów (jeszcze w trakcie tworzenia – więcej informacji za jakiś czas ;) )

Ganglib pomoże wyszukiwać?

Napisano Maj 30, 2008 * Komentarze (0)

Wyszukiwanie pełnotekstowe nie jest trywialne, nie istnieje jego jedyne dobre rozwiązanie.

Widziałem już różne rozwiązania:

  • LIKE %%,

  • FULL TEXT w MyISAM,

  • Lucene,

  • Sphinx Search.

Często stosowane są strategie kolejnego przechodzenie przez powyższe.

  1. Mamy 100 – 200 artykulów? Nie jest problemem uzycie standardu SQL i składni LIKE – nie wymaga to od nas żadnej pracy.

  2. Jeśli to przestaje wystarczać, możemy dodac indeks FULL TEXT (o ile korzystamy z tabel MyISAM w mySQL) – wystarczy drobna modyfikacja kwerend (zamiast LIKE, MATCH AGAINST …). FULL TEXT działa bardzo szybko, niepozbawiony jest jednak wad. Przy tabelach obciążonych dużą ilością modyfikacji danych całe rozwiązanie zaczyna niebezpiecznie zwalniać (indeks przy każdej zmianie musi być przebudowywany)…

  3. Lucene i Sphinx (jest szybszy) to wyjścia zdecydowanie lepsze – które nie tracą na szybkosći wraz ze wzrostem ilości przetwarzanych danych i nie są zależne od charakteru operacji.

Niestety w tym momencie przestajemy korzystać z bazy danych a zwracamy się do dedykowanego indeksu wyszukiwania. Co za tym idzie musimy dosyć istotnie zmodyfikować modele pobierania danych.

Czy nie byloby pięknie napisać zapytania raz a wymieniać tylko mechanizmy które je przetwarzają.

Taki scenariusz jest możliwy przy wykorzystaniu naszego gangliba.

Proste zapytanie: $qr->select(‘*’)->from(‘articles’)->like(‘content’,’%napis%’);

  1. Początkowo może być wykonywane bezpośrednio na bazie danych korzystając ze strategii opartych na PDO.

  2. Jeśli napotkamy problem, możemy zmodyfikować strategię lub dialekt sql (budujący zapytania) aby zamiast LIKE wstawiał do zapytań MATCH AGAINST … Dokonujemy zmiany tylko w jednym miejscu, zmieniając kod kilku linijek kodu.

  3. Jeśli chcemy przenieść się na dedykowany indeks wyszukiwawczy – wystarczy, że utworzymy nową strategię (Div_Db_Distributor_Strategy_Sphinx? ;) ) i poprosimy dystrybutor danych aby z niej korzystał. W kodzie strategii definiujemy w jaki sposób ma być obsługiwana klauzula LIKE – tj. tłumaczona na odpowiednei wywołanie API sphinxa.

To wszystko :-)

ps. Korzystając ze sphinxa możemy emulować wykrozystanie wielu klauzul SQL nie tylko LIKE – np. ORDER BY, GROUP BY, WHERE (po wartościach liczbowych) – daje to naprawdę duże możliwości. Możemy przecież połączyć w jednej strategii sphinxa + pobieranie danych o zwróconych przezeń dokumentach z bazy danych i/lub cache.