Polskie "google" jaka baza pod to, teoria projektowania wyszukiwarki typu google Opcje

[www.aukcje.fm]

Teoria projektowania wyszukiwarki typu google

Witam serdecznie,

Teoryzując i zakładając że ktoś posiada słownik z kilkoma milionami słów (odmian i synonimów) i ten ktoś chciałby stworzyć "małe polskie google" dla większości polskich wartościowych stron www, indexując ok. 100 - 500 milionów stron to jakiej bazy należało by tutaj użyć i jakiego języka dla wyszukiwania pełnotekstowego?

Czy baza relatywna czy nierelatywna. Czy ten ktoś powinien użyć sprawdzonej bazy typu mysql lub postgres czy jakiejś nowo opracowanej typu cassandra, memsql, lub jakaś inna?

Czy lepiej użyć do tego php czy może phyton a może java? Który język był by najlepszy dla robota indexującego strony a który dla wyszukiwania.

Czy powinien być jakiś system ograniczania lub cachowania wyników?

Wszytko by się działo na serwerach z 4 rdzeniowymi xeonami, każdy po 16 GB, system Debian 64 (możliwość użycia dysków SSD np Crucial M4).

Oczywiście nikt nie chce indexować takiej ilości danych co google ale taka miniaturka sprawnie działająca na cz mogła by się opierać...(IMG:style_emoticons/default/questionmark.gif) ?

[xdev]

Każdy kto choć raz miał styczność z mongo i bazami SQL wie, że bazy nie nadają się na środowiska zwirtualizowane. Obojętnie czy to VPS czy Cloud. Ten cały benchmark, przeprowadzony z resztą koszmarnie ma pewnie udowodnić z góry założoną tezę. Właściwie nie widziałem dawno tak źle przeprowadzonego porównania.

Nie da się przeprowadzić testów wydajności na podstawie pomiaru czasu jednego zapytania. Bo równie dobrze można by po prostu zrobić to samo używając funkcji RAND. Trzeba wyłączyć cache i zmierzyć czas wykonywania 1000, 2000 zapytań a nie jednego. Na nieobciążonym systemie a nie na jakimś VPS-ie gdzie inni wpływają na wyniki pomiarów.

Benchmarków się w ogóle nie przeprowadza na maszynach zwirtualizowanych, są zbyt niestabilne i wyniki mogą się różnic w czasie o kilka tysięcy %. Tutaj mamy zdaje się nawet nie maszynę wirtualną, tylko obciążony hosting VPS. I widać jakie głupoty wychodzą, count(*) szybsze pod innodb niż pod myisam((IMG:style_emoticons/default/exclamation.gif) !). Przecież to woła o pomstę do nieba. W myisam się po prostu bierze wartość z pamięci a w innoDB trzeba przeprowadzić full table/index scan czyli "przelecieć" wszystkie wiersze albo cały index. Równie dobrze gość mógłby przetestować szybkość indeksów i by mu wyszło że szybsze jest skanowanie całej tabeli(!). Połowa tego testu to nie pomiar wydajności rozwiązań bazodanowych, co pomiar bezwładności dociążonej maszyny wirtualnej.

mysql ma być szybki i niezawodny (ACID). mongo elastyczne i skalowalne. To są zupełnie inne systemy i zupełnie inne założenie, mongo się nadaje na VPS-y czy chmurę, bazy SQL - w żadnym wypadku. Bo nawet jeśli dołożyć warstwę wirtualizacji i przydzielić całe dostępne zasoby jednemu użytkownikowi to i tak wydajność baz zmniejsza się o 30-40%, nie mówiąc już o testach gdy na maszynie są inni ludzie zamulający I/O czy bardzo wolne I/O po sieci (NAS).

Najśmieszniejsze jest to, że zła konfiguracja mysql w tym teście doprowadziła do tego, że trzeba było ubić serwer. To już po prostu magia. Stare wersje mysql-a mogą chodzić na serwerze bez problemów przez kilka lat(!) tu się wysypał prosty SELECT .. WHERE. I te koszmarne wyniki postgresa. Od razu widać, że coś jest nie tak z konfiguracją, proste kwerendy nie mają PRAWA tak długo się wykonywać. Gdyby SELECT na paru rekordach w PG zajmował pół sekundy to ten projekt zdechłby 10 lat temu, bo to 10 lat temu był wynik nie do przyjęcia.

Dodatkowo wiersz w mysql to czyste dane. mongo musi przechowywać 16 bajtowy(!) UID + całą strukturę danych, bo wszystko jest zapisywane przy użyciu JSON i identyfikatorów unikalnych globalnie które są po prostu OGROMNE. Oznacza to często, że pojedyncze rekordy zajmują od kilku do kilkudziesięciu razy więcej pamięci niż to samo zapisane w klasycznej bazie danych. Akurat przeprowadzałem jakiś czas temu tekst z importem tabeli 1GB (ID + słowo) do mongo. Po zaimportowaniu 10% dane w mongo zajmowały już 2GB. Z polskiego na nasze - mongo się nie nadaje do zastosowań gdzie występują duże ilości rekordów. Chyba że mamy dużo zapisów i już absolutnie inaczej tego nie można przeskalować. To ostateczność. Bo jeśli w mysql wystarczy 1 serwer a w mongo potrzeba 10, żeby przechować to samo, to logiczne że ktoś wybierze mongo tylko wtedy, jeśli niemożliwa jest replikacja albo sharding w klasycznej bazie danych.

Więc to się w ogóle nie nadaje do czegoś takiego jak wyszukiwarka, zwłaszcza, że dane indeksera będziesz prawdopodobnie w 99% przypadków czytał a nie uaktualniał więc nawet w SQL-u się to da prosto skalować używając prefixów.

Ważnym jest również to ile danych będzie w bazie, jeżeli będzie ich np. miliard

To masz 16GB na same UID-y + 16GB na strukturę rekordu w mongo. Czyli 32GB śmietnika, zanim jeszcze cokolwiek zapiszesz (i to dla samego indeksera). Reverse index ma większy sens... mniejszy narzut. Tylko przechowywanie 128 bitowego UUID dla każdego słowa to głupota, trzeba ograniczać ilość bajtów dla RI. Bo tak to masz 16bajtów x miliard wierszy (a mogłyby być 4 bajty x miliard wierszy). Więc teoretycznie można by zaimplementować rozproszony reverse index w nodejs (jakieś 2 godziny roboty), przeszukiwanie z wildcard na końcu wyrazów jako rozproszone bazy mysql.

>To bardzo ważna kwestia, która chyba przesądza na korzyść bazy nierelacyjnej.
Tylko problem jest taki, że AFAIK nie ma bardziej nieefektywnej bazy nierelacyjnej niż mongo. Można by od biedy wykorzystać jakiś REDIS (bo wspiera listy i AFAIR nie pakuje do pamięci tyle niepotrzebnego syfu) jako reverse index ID=>DOCID1, DOCID2, DOCIDx i zrobić wyszukiwanie wyrazów w mysql (słowo => ID) a całość podzielić na kilkaset tabel używając prefixów.

Ten post edytował xdev 8.10.2012, 15:13:35