Za to przy dużych jak najbardziej.
tablica 40mb to nic dla MySQLa i tez nic dla Sphinxa , tutaj sprawdził się dużo lepiej MySQL.
Warto tez pamiętać iż sphinx jest tylko silnikiem do szukania po indexie odwołań do danych, a wiec i tak potem trzeba będzie odpytać mysqla… przy niewielkiej ilości danych kolejne połączenie do kolejnego demona, kawałek API do PHPa może okazać się znacznie wolniejsze.

Jeśli natomiast macie tablice wielkości 2.4GB to już wygląda to zupełnie inaczej.

MySQL robił mi FULLTEXT na jedno z dwóch pół (polowa wielkości tablicy) około 4h , należy też odliczyć fakt ze MySQL podczas przebudowywania indexów także przepisuje cala tablice , a następnie robi na nowo indexy. Sphinx po prostu odczytuje dane z MySQLa i generuje indexy. Tak wiec prędkość odczytu/zapisu dysku w moim laptopie sprawiła że trwało to 4h i nie powinno nikogo zdziwi ze pod Sphinxem pójdzie to znacznie szybciej.

A może jednak zaszokuje fakt ze trwało to około 5min ? Bylem pod wrażeniem!

Czas na konkrety. Testy przeprowadziłem identycznie jak w poprzednim benchmarku v0.1. Pościłem pierwszy test na sucho aby mysql zbuforował sobie indexy. Następnie  przy ilości 10k powtórzeń php sie timeoutowal, wiec zmniejszyłem ilość na tysiąc powtórzeń.  Oto wynik: 0.00472 s.

Następnie identycznie dla Sphinxa. Oto wynik: 0.0097 s.

W tym momencie jesli macie podobne wyniki to RTFM ;)

Po tuningu koniuracji searchd mamy wynik: 0.00079 s. czyli około 6 razy szybciej niż MySQL!

Warto pamiętać ze Sphinx nie jest alternatywa dla MySQL, jest aplikacja zastępująca pewną funkcjonalność MySQL-a lecz bez bazy danych jest zupełnie nie przydatny.

Dodam też że prócz samego szybszego wyszukiwania znacznie odciąża budowanie indexów w MySQL (wywoływanie z cron) można go clustrować lub wydzielać na osobne maszyny.

Polecam wszystkim gdzie są przeszukiwane duże tablice FULLTEXT.

Edit: Jutro pojawi sie drugi benchmark, który jednak pokaże moc Sphinxa.

Pierwsze test mysql.php:

<?
$start=getmicrotime();
for($i=0;$i<10000;$i++)
$q = mysql_query("SELECT mailText,COUNT(*) FROM gl_members_mail WHERE MATCH(mailText) AGAINST('test') GROUP BY mailOwner ORDER BY COUNT(*) DESC LIMIT 0,10");

$end=getmicrotime();
$diff = ($end-$start)/10000;
echo $diff."<br>\n";

?>

Drugi test sphinx.php:

<?

include('sphinxapi.php');

$cl = new SphinxClient();
$cl->SetServer( "localhost", 3312 );
$cl->SetMatchMode( SPH_MATCH_ANY  );
$cl->setGroupBy("mailOwner",SPH_GROUPBY_ATTR,"@count desc");
$cl->setLimits(0,10);
$start=getmicrotime();
for($i=0;$i<10000;$i++)
$result = $cl->Query( 'test' );
$end=getmicrotime();
$diff = ($end-$start)/10000;
echo $diff."<br>\n";
?>

Mysql : 0.00036 s.

Sphinx: 0.00147 s.

Sprawa by była rozstrzygnięta, ale Sphinx zwraca nam ilość trafień, wiec trzeba by było zmienić zapytanie i dodać drugie:

SELECT SQL_CALC_FOUND_ROWS mailText,COUNT(*) FROM members_mail WHERE MATCH(mailText)
AGAINST('test') GROUP BY mailOwner ORDER BY COUNT(*) DESC LIMIT 0,10;

SELECT FOUND_ROWS()

Dorzucenie drugiego zapytania i przeliczanie ilości wyników da nam efekt : 0.00042 s.

Jednak jedna rzecz nie pasuje mi podczas tych testów.

Benchmark sphinx.php zjada prawie 100% jednego rdzenia dla procesu PHP, a w mysql.php zjada MySQLa (czyli dobrze). Doszedłem do wniosku że obsługa mysqla jest wkompilowana , a sphinx ma swoje API napisane w PHP, ale ma tez dodatek PECL który udało mi się prawie zmusić do działania. Prawie ponieważ PECL nie wspiera chyba wszystkich możliwości.

Z niewiadomych przyczyn ustawianie limitu nie dziala setLimits(0,10); Całe szczęście w default wyświetla 20 wyników, więc pominę ten parametr.

Drugi problem to segfaulty… cały projekt widać jest dość niestabilny. Dopiero przy probie 10 pętli PHP się nie wywrócił i dal wynik: 0.00142 s. czyli trochę lepiej. Obciążenie PHP znacznie spadło, searchd miał średnie obciążenie na 10-20 %.

Jak na razie benchmark pokazuje ze Sphinx może kiedyś się będzie nadawał… Jednak na razie go jeszcze nie skreślę.

Kolejny benchmark przedstawię w nadchodzącym tygodniu przy większej ilości danych , oraz na dedykowanych maszynach tak by PHP nie kolidowało z demonami.

P.S.

Polecam zapoznać się z tą publikacją : sphinx merb vs ferret rails

W najbliższym czasie przeprowadzę testy wydajnościowe, jak na razie poinformuje ze czas który podaje result z query sphinxa nie uwzględnia przesłania danych do skryptu. Sprawia to ze jak narazie podczas testów na moim laptopie czas nie jest aż taki świetny. Jednak niestety nowe laptopy są na tyle szybkie ze 400k rekordów to za mało na porównanie z MySQL Fulltext-search (FTS)