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) ?

[erix]

Sphinx.

[www.aukcje.fm]

Sphinx działa pod php i w phyton.

Jaka baza pod Sphinx? Nierelatywna?

Czy da się pod niego użyć słownik?

[mmmmmmm]

Zależy jakie informacje chcesz przechowywać. jeśli tylko tekst ze strony i tylko po to by znaleźć dane słowo (zdanie, zwrot etc.) to może być NIERELACYJNA. Ale widzę, że chyba o tym pojęcia nie masz... Podobnie jak sama propozycja użycia MySQL do 100-150 mln rekordów (IMG:style_emoticons/default/smile.gif)

[www.aukcje.fm]

Witam,

Wiem o co chodzi, mam kilka portali i wyszukiwarek. Po co nam relacje w tekście, ale ja pytam bardziej co lepsze. Odnośnie mysql dla 100 mln rekordów to np youtube działa na mysql i nie ma problemu. Nie interesują mnie przyjęte nieprawdziwe opinie ale opinie profesjonalistów jeżeli takowi tu są, ale raczej chyba każdy jest zatrudniony gdzieś a nie siedzi na forum.

[erix]

To po co piszesz na forum?

[www.aukcje.fm]

po to że chcemy mieć miliard rekordów stron w bazie dla wyszukiwarki dla dzieci i nie wiem jakiej bazy użyć aby się to nie zakleszczyło. laicy odwiedzają to forum chyba tacy jak jak.

[sowiq]

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

Miliard rekordów i MySQL? Buahaha (IMG:style_emoticons/default/biggrin.gif) Memsql, który trzyma wszystko w RAMie? Buahaha (IMG:style_emoticons/default/biggrin.gif)

IMO do takiej liczby rekordów najlepiej zacząć research od komercyjnych rozwiązań jak Oracle czy MS SQL, a nie jakiś MySQL. Co prawda z takimi liczbami rekordów nie miałem do czynienia (raczej rząd wielkości niżej), ale piszę to na zdrowy rozum i domyślam się, że sporo osób potwierdziłoby moją tezę.

[edit]

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).

Swego czasu pracowałem przy sklepie Magento z dosyć sporym katalogiem produktów (ale na pewno nie miliard rekordów w bazie, nawet sumarycznie dla wszystkich tabel). Z tego co pamiętam, baza danych (z braku innego wyjścia dla Magento - MySQL) stała na dwóch serwerach, po 16 rdzeni i 64 GB RAMu każdy, z dyskami SSD. Przy trochę cięższych operacjach nawet takie maszyny dostawały lekkiej zadyszki.

Ten post edytował sowiq 1.10.2012, 19:19:50

[www.aukcje.fm]

A baza postgers (IMG:style_emoticons/default/questionmark.gif) Podobno ma wbudowaną funkcję obsługi słowników i dobrze sobie radzi z dużymi bazami danych.

albo jakaś nierelacyjna baza danych. Oracle to nie te koszty, zresztą po co relacje w tekście (IMG:style_emoticons/default/smile.gif)

[sowiq]

Co do Postgresa, to się nie wypowiem, bo po prostu nie wiem, a nie chciałbym Cię wprowadzić w błąd.

Co do relacji, to nie myśl, że na tabelkach z miliardem rekordów zrobisz JOIN'a nie wykładając przy okazji serwera, a już na pewno takiego z 16GB RAMu (IMG:style_emoticons/default/smile.gif)

Ten post edytował sowiq 2.10.2012, 11:43:15

[xdev]

IMO do takiej liczby rekordów najlepiej zacząć research od komercyjnych rozwiązań jak Oracle czy MS SQL

Bazy SQL się nie nadają do efektywnego wyszukiwania więc to jakiej bazy użyjesz jest bez znaczenia.

Swego czasu pracowałem przy sklepie Magento z dosyć sporym katalogiem produktów

Bo Magento to źle napisana, przestarzała kobyła.

po to że chcemy mieć miliard rekordów stron w bazie dla wyszukiwarki dla dzieci i nie wiem jakiej bazy użyć aby się to nie zakleszczyło.

Drzewa patricia albo któraś z odmian B-drzew (akurat implementowałem podobny system na drzewach patricia) + prosta struktura tablicowa ID=>dokument.

Drzewo które tworzą słowa trzymasz w pamięci, dane czyli listy IDs na dysku. W ten sposób każde wyszukiwanie ma złożoność O(n) gdzie n to liczba znaków szukanego ciągu. To znaczy nie dość, że to ma dużo niższą złożoność niż B-drzewa używane w bazach SQL to jeszcze odpadają odczyty z dysku.

Miliard rekordów i MySQL? Buahaha

Gdybyś wiedział jak działa wyszukiwanie tesktowe to byś rozumiał, że te miliard rekordów można sobie rozbić po pierwszych literach szukanych ciągów na nieskończoną ilość tabel a żądania kierować do różnych serwerów (jeśli wystarczy wildcard na końcu wyrazów). A i wyszukiwanie pełnotekstowe działa w ten sposób dość dobrze (tutaj to lepiej od razu postawić większą ilość maszyn).

Oczywiście nigdy to nie będzie tak szybkie jak napisanie binarnego indexera od 0 na którejś z podstawowych struktur danych. Kwestia czy się bardziej opłaca dzierżawić 3-4 serwery zamiast jednego, czy znaleźć gościa który to umie napisać.

Co do baz nierelatywnych. To nie ma działać szybko i wydajnie tylko się prosto skalować. Jeśli coś można postawić na mySQL czy postgre i działa ok na jednym serwerze to przy takim mongo może wymagać 4-5 maszyn, żeby działać z podobną wydajnością. Tu chodzi o coś innego, jak masz mysql to bardzo trudno się skaluje cokolwiek powyżej 2 serwerów bazodanowych... z mongo możesz sobie postawić 200 maszyn i przyrost wydajności powinien być ~liniowy.

Akurat pisałem pracę inżynierską z takich systemów. Indexer napisany w C działa ok 2-3 razy szybciej niż bazy sql kiedy dane są trzymane w pamięci. Podobnie ma się sprawa z danymi na dysku. No i czasy odpowiedzi są względnie stałe (nie tak, jak przy wyszukiwaniu pełnotekstowym np. w mysql gdzie na jedną kwerendę możesz czekać 3 sekundy a na inną 20ms).

Ten post edytował xdev 2.10.2012, 11:51:59

[erix]

Nie rozumiem jednego - czemu upieracie się przy SQL, skoro można spokojnie korzystać z indekserów a'la Sphinx/ElasticSearch i potem wyciągasz tylko IDki z SQL?

[sada]

NoSQL: HBase, może Mongo

[www.aukcje.fm]

http://www.progresowi.pl/2011/11/10/porown...vs-mongodb.html

Tutaj jest porównanie baz danych. Ewidentnie wygrywa MongoDB.

Należy pamiętać iż będziemy przechowywać tekst i głównie korzystać z niego w postaci wyszukiwania pełnotekstowego. Interesuje nas jedynie maxymalne rozwiązanie co do szybkości wyszukiwania (wyświetlania danych) wraz z jak najdokładniejszym odwzorowanie poszukiwanych fraz co do wyników podawanych przez wyszukiwarkę. Wszystko powinno współpracować z naszym słownikiem opierając się na rozwiązania pobierane z gotowych cyklicznych procesów wyszukiwawczych przynajmniej dla najpopularniejszych i najczęściej poszukiwanych kilkuset tysięcy fraz oraz wszystkich słów ze słownika.

Na razie przewidywana jest praca na jednym lub dwóch serwerach danych lecz nie wiadomo czy nie będzie tych serwerów kilka.

Ważnym jest również to ile danych będzie w bazie, jeżeli będzie ich np. miliard lub może i więcej, należy tutaj zaplanować iż projekt może się rozwinąć lub stale rozwijać. To bardzo ważna kwestia, która chyba przesądza na korzyść bazy nierelacyjnej. Jeżeli się mylę to proszę o poradę lub wskazanie jak by to mogło działać.

Dziękuję za wcześniejsze odpowiedzi na moje zapytanie i pozdrawiam

mały damian

Poczytałem trochę o tym Elastic Search hmm jak to działa (to baza czy system wyszukiwania). Czy daje radę w wyszukiwaniu fulltext we współpracy z MongoDB? Co to wogóle jest (IMG:style_emoticons/default/smile.gif)

(IMG:style_emoticons/default/questionmark.gif) (IMG:style_emoticons/default/questionmark.gif) ?

hmm

Ten post edytował www.aukcje.fm 6.10.2012, 11:44:08

[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

[darko]

Solr, polecam. Ma wiele gotowych mechanizmów, jakie możemy spotkać w google.

[www.aukcje.fm]

Hmm mongo chyba odpada. Do wyszukiwania będzie prawdopodobnie solr. Ale jaka baza pod to? Teraz boty indexują polski internet do bazy mysql. Na jeden dysk 512 GB SSD wejdzie ok 8 miliardów rekordów. To już trochę spore liczby chyba dla mysql (IMG:style_emoticons/default/smile.gif) (IMG:style_emoticons/default/questionmark.gif)

[darko]

Solr nie korzysta z żadnej bazy danych (i m.in. dlatego jest taki szybki). Solr ma własne mechanizmy indeksowania danych na dysku twardym. Dane najlepiej wysłać w postaci pliku bądź plików xml o odpowiedniej strukturze, zgodnej ze schema.xml, na podstawie tych danych Solr zbuduje indeks wyszukiwania i słowniki.

[erix]

Strukturę pól ustawia się w konfiguracji engine'u per projekt. A obsługa bazy danych dotyczy tylko indeksatora (czyt: materiał źródłowy).

Zapytania budujesz najczęściej na bazie REST-owego API, które - wg kryteriów użytkownika - zwraca klucze podstawowe wyszukanych obiektów i - chyba, bo dobrze nie pamiętam - kawałki tekstu, które pasują do frazy.

Jeśli mając gotowe IDki wyciąganie z bazy zajmuje ruski miesiąc, to ewidentnie z bazą jest coś nie tak. (IMG:style_emoticons/default/biggrin.gif)