Masywna baza danych z wyszukiwaniem pełnotekstowym - Sphinx, Lucene, Cassandra, MongoDB, CouchDB

Question

Nasza firma pracuje nad projektem, który wymaga bazy danych zawierającej 30-50 milionów wierszy danych produktu. Wiersze te zawierają tekst, który należy przeszukiwać równoczesnie tysiące razy na sekundę. Co więcej, każde przeszukiwanie musi zająć mniej niż jedną sekundę.

W sumie mamy bazę danych 50M, która musi być przeszukiwana tysiące razy na sekundę. Pamiętaj, że są to wyszukiwania pełnotekstowe. Wiem, że MySQL lub jakakolwiek relacyjna baza danych sama nie może obsłużyć tego typu pracy. Szukamy więc kogoś, kto może zaprojektować dla nas odpowiednią konfigurację i pomóc nam ją wdrożyć za określoną cenę.

Po pierwsze, chcielibyśmy wiedzieć, jakie są nasze najlepsze opcje. Osobiście badałem rzeczy takie jak Sphinx, Lucene, Cassandra, MongoDB, CouchDB, Solr, itp., Ale tak naprawdę nie wiem, które powinny być używane w połączeniu z innym, aby dać nam najbardziej wydajną konfigurację.

Tak więc, jeśli ktoś mógłby po prostu dać radę lub skorzystać z naszej oferty pracy, byłoby to bardzo cenne.

Możesz skontaktować się ze mną przez PM tutaj, a dam ci mój e-mail/IM/numer telefonu do dalszej dyskusji.

Dzięki!

Answer 1

Paul, witamy w SO. To naprawdę nie jest właściwe miejsce, aby spróbować kogoś zatrudnić, ale oto moja rada:

Prawdę mówiąc, w zależności od rodzaju wyszukiwań, które robisz, pisanie MySql off może być nieco przedwczesne.

Ponieważ chodzi o dane produktów, wyobrażam sobie, że Twoje wyszukiwania są wyszukiwaniem pełnotekstowym, więc zapisanie MySql nie jest przedwczesne. Sphinx jest świetny, ale trochę trudny do skonfigurowania. Zaletą jest to, że ma on możliwość indeksowania bezpośrednio z mysql, a także można się z nim komunikować za pomocą dowolnego złącza/powiązań mysql, z których korzystasz w swojej aplikacji, ponieważ wie, jak mówić o protokole mysql.

Powiedziałbym, że kassandra, kanapa i mongo nie są tym, czego szukacie, żadne z nich nie indeksu tekstu tak jak sfinks. Możesz rzucić się na nich, ale byłoby to całkiem nieproduktywne.

Nigdy nie pracowałem z lucene, ale słyszałem dobre rzeczy, to podobne rozwiązanie do Sphinx Afaik.

powodzenia

Answer 2

Przechowywanie danych i wyszukiwanie to dwie różne rzeczy. Jeśli spojrzeć na architektur takich jak eBay, mają oddzielne usługi & serwerów do operacji wyszukiwania. 50m wierszy to nic, możesz przechowywać je w każdym z datastore, żaden z nich nie jest idealny, więc różnica polega na przypadkach użycia. Np .: kasandra ma najszybszą wydajność wkładania przy dowolnym rozmiarze danych, może skalować do petabajtów z setkami maszyn w łatwy sposób (bez potrzeby odłamywania), ma lucandra (integracja cassndra-lucene, dobrze się skaluje z masywnymi danymi, ale zabawka w porównaniu do elastycznego wyszukiwania) , wysoka wytrzymałość, ... MongoDB ma więcej opcji zapytań (używa btree jako dbms), ma autosharding niedawno, może indeksować wszystkie pola, ale słaba wytrzymałość, ... Postgresql jest najbardziej zaawansowanym DBMS opensource tam, ma wbudowany master/replikacja slave ostatnio, może skalować przez sharding, acid & sql zgodny ... couchdb nie ma żadnej przewagi w porównaniu do innych w przypadku użycia Myślę, że cholernie wolno, jeśli potrzebuję kwasu prawdopodobnie używam postgresql. Wbudowane funkcje wyszukiwania pełnotekstowego w tych magazynach danych mają pewne problemy i nie są skalowalne.

Najbardziej zaawansowana wyszukiwarka open source o dużej przepustowości danych, wysokiej wydajności, prostej, rozproszonej, odpornej na awarie i odpoczynku, to elasticsearch, można ją uznać za rozprowadzoną lucenę. Solr jest lagecy w porównaniu do elascticsearch. użycie surowego lucenu/sfinksa nie jest skalowalne.

Gdybym był tobą, prawdopodobnie wybrałbym jeden z datastore i użyłbym elasticsearh do zindeksowania i zsynchronizowania ich na mojej warstwie dostępu do danych (trzeba zmodyfikować indeksy na db insert/update/delete).

Pozdrowienia