2013-07-03 7 views
7

Wiem, że podczas używania pola typu tekstowego w tabeli MySql dane nie są przechowywane w linii, ale tylko wskaźnik jest przechowywane w rzędzie. Chcę tylko nieczęsto pobierać pole tekstowe, więc czy lepiej trzymać je w tej samej tabeli, ale pomijać je w wynikach zapytania lub przechowywać w oddzielnej tabeli i dołączać do tego stołu, gdy chcę go przeczytać?Czy bardziej wydajne jest utrzymywanie pól tekstowych w wierszu tabeli MySql lub w osobnej tabeli i dołączenie

Ta tabela może mieć potencjalnie miliardy wierszy, być podzielona na partycje i mieć duże (100k -> 1Mb) wartości pól tekstowych.

+0

Chcesz dołączyć do pól tekstowych? –

+0

Cóż, jeśli to tylko wskaźnik, to myślę, że lepiej być w tym samym stole. tak długo, jak go nie wybierzesz, nie sądzę, że wpłynie to na twoje zapytania. a jeśli oddzielisz to po prostu więcej "wyszukiwań" dla db zrobić przed dając wynik. –

+0

Brak łączenia w polach tekstowych, mam na myśli dołączenie do tabeli zawierającej tylko pole tekstowe. –

Odpowiedz

0

My się na nim:

Normalnie powiedziałbym, że nie jest konieczne skomplikowane mieć odniesienie do wskaźnika do tekstu, zwłaszcza gdy mamy do czynienia z wieloma łączy, potencjalny partycjonowania itp

na z drugiej strony, to potworny stół. Jeśli kiedykolwiek zapomnisz wyłączyć pole tekstowe lub masz kogoś, kto nie jest dobrze poinformowany o twojej strukturze danych, pracuje w tej samej bazie danych, kto może wydać prosty SELECT * FROM monstertable ... dobrze, w zależności od serwera, może zabić/przeciągnij to przez jakiś czas.

W skrócie: dla wydajności, jeden stół powinien być nieco lepszy, bo bezpieczeństwa/stabilność może lepiej byłoby rozdzielić.

sidenode: chciałbym zapytać się, czy MySQL lub nawet relacyjnej bazy danych w ogóle jest odpowiednim narzędziem do tego zadania (i spędzają długie godziny szukając alternatyw, dostać krzyknął i po prostu korzystać z MySQL, ponieważ jest już zainstalowane wszędzie i dobrze zintegrowane;))

1

Milion wierszy z polem o wielkości 100 tys. To przychodzi do 100 Tbajtów danych (używając amerykańskiej definicji "terabajta"). Według documentation: silnik składowania

InnoDB utrzymuje tabel InnoDB obrębie tabel , które mogą być utworzone z kilku plików. Dzięki temu tabela może przekroczyć maksymalny indywidualny rozmiar pliku. Przestrzeń tabel może zawierać partycje z nieprzetworzonymi dyskami , co pozwala na bardzo duże tabele. Maksymalny rozmiar obszaru tabel wynosi 64 TB.

Innymi słowy, możesz mieć większe problemy niż wydajność. Prawdopodobnie będziesz rozprzestrzeniać tabelę na wiele partycji.

Jeśli od czasu do czasu pobierasz tekst i nigdy nie używasz go do wyszukiwania, proponuję, aby zapisać go w osobnej tabeli. W ten sposób możesz dostosować tę tabelę, aby uzyskać dostęp do tych rekordów. Będziesz miał klucz podstawowy używany do odniesienia i wszystkie referencje będą przez ten identyfikator.

Jeśli używasz tekstu do wyszukiwania, w szczególności wyszukiwania w połączeniu z "ustalonymi" danymi, wówczas moją preferencją architektoniczną byłoby włączenie go do tabeli podstawowej w celu ułatwienia wyszukiwania w różnych polach.

Jednak nawet przy tej preferencji prawdopodobnie bezpieczniej jest umieścić ją w innej tabeli. Na przykład MySQL tworzy instancje. Bardzo typowe jest używanie podzapytania przy użyciu *.Rozważmy prosty przykład: kwerenda, aby uzyskać 1000 najnowsze zapisy uporządkowane według identyfikatora:

select t.* 
from (select t.* 
     from t 
     order by createddate 
     limit 1000 
    ) t 
order by userid 

Zastosowanie t.* oznacza, że ​​kolumna tekst zostanie również pobrana. Tak więc zapytanie, które może zająć ułamek sekundy (z indeksem), musiałoby odczytać i zapisać 1000 * 100k = 100 MB danych (przynajmniej). To prawdopodobnie potrwa nieco dłużej.

Podsumowując, zalecałbym umieszczenie kolumny tekstowej w tabeli, w której często jest wyszukiwana z innymi kolumnami - na przykład w bazie danych streszczeń artykułów naukowych. W przypadku naprawdę dużych danych umieściłbym je w osobnym polu, dzięki czemu mogłem lepiej zarządzać pamięcią w ekstremalnych przypadkach.

Powiązane problemy