zaprojektować bardzo dużą bazę danych do wyszukiwania tekstu

Question

Musimy zaprojektować system, który pozwoli użytkownikom wyszukiwać według różnych słów kluczowych w dużych tekstach, a także, w przyszłości, tworzyć podstawowe raporty dotyczące częstotliwości tego słowa kluczowego we wszystkich artykułach Kropka.

Będziemy mieć:

• około 200.000 artykułów dodawane każdego dnia
• każdy tekst artykuł jest o 2kB
• artykuły są przechowywane przez 6 miesięcy

Aby to zrobić, doszliśmy z następującym rozwiązaniem:

• stworzenie repozytorium SOLR do przechowywania artykułów
• używać bazy danych MySQL do przechowywania artykułu Dodatkowe informacje

system wyszuka SOLR za pomocą słów kluczowych, a następnie będzie spojrzeć na wyniki w MySQL, aby pobrać dodatkowe informacje.

Czy to byłoby dobre podejście?

Jeśli większość wyszukiwań dotyczy tylko artykułów dodanych w ostatnim miesiącu, czy byłoby dobrze zachować dwie bazy danych, jedną z artykułami dodanymi w ostatnim miesiącu dla większości wyszukiwań, a drugą ze wszystkimi artykułami?

Jeśli masz jakieś wskazówki/wskazówki, jak to poprawić, byłoby to bardzo cenne.

Z góry dziękuję!

Answer 1

Myślę, że twoje rozwiązanie jest całkiem dobre. Oceniam umieszczanie instancji memcache przed SOLR, jeśli chcesz uzyskać szybsze odpowiedzi na typowe zapytania.

Nie mam pewności co do dwóch baz danych, trzeba byłoby zobaczyć, jakie są korzyści związane z wydajnością w porównaniu do obciążenia przenoszeniem rekordów z pierwszego do drugiego DB w miarę ich starzenia. Wątpię, by była ogromna korzyść, ale to tylko przeczucie, nie bierz moich słów i nie prowadź eksperymentów.

Czy bierzesz pod uwagę fakt, że możesz potrzebować rozwiązania skalowalnego poziomo, jeśli zbiór danych stanie się bardzo duży?

Answer 2

Zamiast przechowywania danych w MySQL i Solr warto rozważyć wypróbowanie MySQL w wersji 5.6. Powinieneś być w stanie użyć jednego silnika do przechowywania wszystkich swoich wymagań.

MySQL w rzeczywistości obsługuje wyszukiwanie pełnotekstowe przez lata, ale tylko na przestarzałym silniku tabeli MyISAM. MySQL 5.6 obsługuje tę funkcję dla tabel InnoDB, co czyni ją bardziej odpowiednią dla frameworków takich jak na przykład Ruby on Rails.

Dokumentacja dla wyszukiwania pełnotekstowego MySQL jest pod adresem:

http://dev.mysql.com/doc/refman/5.6/en/fulltext-search.html

składni kwerendy, które mogą być szczególnie interesujące dla tych, porównując go do funkcji SOLR, znajduje się pod adresem:

http://dev.mysql.com/doc/refman/5.6/en/fulltext-boolean.html

Answer 3

Tak naprawdę, nie mam pojęcia o korzystaniu z Solr Search Platform, ale moim zdaniem można użyć Java Content Repository JCR, pozwoli to uzyskać dane w bazie danych n format drzewa. W ten sposób wyszukiwanie będzie wykładniczo szybkie niż zwykle. Musisz spojrzeć na ten link, aby uzyskać więcej informacji o tym

http://onjava.com/onjava/2006/10/04/what-is-java-content-repository.html

nadzieję, że pomoże

Answer 4

Chcesz dla każdej z kolumn (Kolumna1, Kolumna2, kolumna3) mieć wygląd indeksu do góry, a nie do skanowania tabeli na tak dużym stole.

Problem polega na tym, że jedno zapytanie użyje jednego indeksu.

Jeśli utworzysz jeden indeks (Kolumna1, Kolumna2, Kolumna3), będzie on nadal wykonywał skanowanie tabeli dla każdego wyszukiwania, ponieważ gdy używa indeksu dla np. Kolumny1, musi jeszcze sprawdzić, czy Słowo kluczowe wyszukiwania w Kolumnie 2 i Kolumnie 3 też w tym samym czasie i nie są one zamówione. - indeks jest zamawiany tylko w kolumnie 1; Kolumna2 i kolumna2 są w losowej kolejności

Masz więc 2 rozwiązania: albo zmieniasz układ tabeli, żeby nie mieć kolumn 1, kolumny 2 i kolumny 3, ale masz tylko jedną kolumnę z słowem kluczowym wyszukiwania: cname, a jeśli potrzebujesz aby dowiedzieć się, czy była to kolumna 1, 2 czy 3, dodaj inną kolumnę z liczbą całkowitą, która mówi 1,2 lub 3. Umieść indeks na tej kolumnie cname, a twoje wyszukiwania będą szybko wykonywane. Ale w zależności od innych kolumn, które masz, może to oznaczać, że duplikujesz niektóre dane.

Oto co bym zrobił. Jeśli to nie wystarczy, to nawet podziel tabelę, aby mieć tylko tabelę (id, cname) i używając identyfikatora, możesz wyszukać inne kolumny z innej tabeli. Jeśli tabela staje się zbyt długa, możesz ją nawet podzielić, utworzyć cnameAM zawierający słowa zaczynające się od A do M i cnameNZ, która zawiera resztę.

Jeśli nie możesz zmienić układu tabeli: zamiast używać 1 zapytania , użyj wielu zapytań

Umieść indeks na każdej z kolumn i użyj 3 zapytań. więc złożyć indeks (id, Kolumna1), złożyć indeks (id, Kolumna2) i (Id, kolumna3) i zrobić:

SELECT * FROM 'SearchTable' WHERE Column1='$SearchKeyword' 
SELECT * FROM 'SearchTable' WHERE Column2='$SearchKeyword' 
SELECT * FROM 'SearchTable' WHERE Column3='$SearchKeyword' 

te 3 wybiera pójdzie bardzo szybko, ponieważ każdy zrobić sprawdź ich konkretny indeks , a następnie dołącz do 3 zestawów wyników do dalszego przetwarzania lub wyszukaj więcej kolumn, używając identyfikatorów, które pobrałeś.