Najlepsze podejście do bazy danych długich ciągów


12

Muszę przechowywać pytania i odpowiedzi w bazie danych. Pytania będą składały się z jednego do dwóch zdań, ale odpowiedzi będą długie, przynajmniej akapit, prawdopodobnie więcej.

Jedynym sposobem, w jaki wiem, że mogę to teraz zrobić, jest baza danych SQL. Jednak nie wydaje mi się, aby było to dobre rozwiązanie, ponieważ o ile widziałem, te bazy danych nie są używane do danych tego typu lub wielkości. Czy to jest właściwa droga, czy jest lepszy sposób na przechowywanie tych danych? Czy istnieje lepszy sposób niż przechowywanie surowych strun?


Czy szukałeś wyszukiwania pełnotekstowego? en.wikipedia.org/wiki/Full_text_search
FrustratedWithFormsDesigner

Proszę zdefiniować „długi” 1k, 5M, 1GB?
James Anderson

dlaczego nie lubisz „surowych” strun? Czy dane są w rzeczywistości łańcuchami, czy też są danymi strukturalnymi? Czy planujesz zrobić coś z tym, co nie działałoby dla łańcuchów? W twoim pytaniu nie ma wyraźnego powodu, dla którego baza danych byłaby nieodpowiednia. To samo dotyczy ciągów znaków (a może CLOBS, jeśli są zbyt duże i zależą od używanej bazy danych).
psr

Miałem na myśli jakiś sprytny sposób ich przechowywania, może poprzez jakiś rodzaj kompresji, a nie ciągi tekstowe. Martwię się o rozmiar bazy danych tutaj.
gsingh2011

1
Z którego RDBMS korzystasz? Oracle ma doskonałe wsparcie w zakresie obsługi i wyszukiwania tekstu.
Matthew Flynn

Odpowiedzi:


19

Mongodb jest świetny, ale znasz SQL. Nie ma nic złego w przechowywaniu długich odpowiedzi w polach. Możesz przechowywać obrazy, a nawet pliki w SQL. Myślę, że maksymalny rozmiar pola to 2 GB.

Jestem prawie pewien, że ta odpowiedź jest gdzieś przechowywana w polu tabeli.

Jeśli chodzi o tysiące, nie ma problemu. Nawet miliony nie powinny stanowić problemu. Możesz rozważyć zastosowanie indeksowania pełnotekstowego, jeśli szukasz w polu słów kluczowych lub czegoś takiego. Ale staram się nie optymalizować, dopóki nie zobaczę problemu. Komputery są tanie, pamięć jest w zasadzie darmowa.


11
+1 na brak optymalizacji, dopóki nie pojawi się problem!
GrandmasterB

4
Maksymalny rozmiar pola nie jest określony w ANSI SQL, zależy to od DBMS (i zwykle kilku innych czynników, takich jak zestaw znaków, typ danych kolumny, silnik pamięci, system operacyjny itp.).
tdammers

6

Nie ma problemu z przechowywaniem długiego tekstu w bazach danych (SQL lub w inny sposób). Tak właśnie jest przechowywany praktycznie każdy wpis na blogu (zdaniem Wordpress), artykuł prasowy i post na forum (zdaniem phpbb) w Internecie. Nie znam szczegółowych szczegółów konfiguracji wymiany stosów, ale jestem pewien, że twoje pytanie jest również zapisane w bazie danych. Większość baz danych SQL ma TEXTtyp pola lub odpowiednik tylko do przechowywania danych tekstowych o dowolnej długości. Wiele z nich ma również systemy wyszukiwania pełnotekstowego.

Podejmuj decyzje techniczne w oparciu o wiedzę techniczną i zrozumienie, a nie uczucia.


5

Tak, to właściwa droga. Przechowywanie ciągów w bazie danych SQL jest tym, co chcesz zrobić. Jedna z moich tabel w DB ma ponad gigantyczny tekst jawny i działa dobrze.

Jeśli martwisz się o miejsce do przechowywania - pamiętaj, że jest tanie!

Jeśli martwisz się wydajnością - nie martw się, dobra baza danych może być skalowana (lub zmniejszana) do dowolnej ilości danych, które chcesz w niej umieścić.

Ostatnią rzeczą, którą chcesz zrobić, to rozpocząć optymalizację teraz ze względu na to (kompresowanie łańcuchów przed umieszczeniem ich w DB lub czymś szalonym), zanim faktycznie stanie się to problemem. Po prostu dajesz sobie więcej pracy.


2

Nie ma problemu z przechowywaniem dużych ciągów lub danych binarnych. Pracowałem z bazą danych zawierającą więcej niż jeden terabajt danych binarnych i działałem bardzo dobrze (postgres), a jedyną złą rzeczą był czas tworzenia kopii zapasowej.

Główne pytanie brzmi: „Czy będziesz potrzebować ciągłego wyszukiwania w tym tekście?”

Jeśli chcesz wyszukać ciągi w tekście, możesz pomyśleć w jednym rozwiązaniu indeksu:

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.