Wydajność funkcji MySql Xml?

Question

Jestem bardzo podekscytowany nowym Mysql XMl Functions.

Teraz mogę w końcu osadzić coś w rodzaju "obiektowo zorientowanych" dokumentów w mojej oldschoolowej relacyjnej bazie danych.

Przykładowo w przypadku użycia należy rozważyć użytkownika, który śpiewa w witrynie przy użyciu funkcji Facebook Connect. Możesz pobrać obiekt dla użytkownika za pomocą api wykresu i uzyskać ładne informacje. Informacje te mogą się jednak znacznie różnić. Niektóre pola mogą, ale nie muszą być ustawione, niektóre mogą być dodawane w miarę upływu czasu i tak dalej.

Cóż, jeśli jesteś po prostu zainteresowany specjalnymi dziedzinami (na przykład relacjami z przyjaciółmi, płcią, filmami ...), możesz wyświetlać je w swoim schemacie relacyjnej bazy danych.

Jednak przy użyciu funkcji XMl można przechowywać cały obiekt wewnątrz pola, a następnie różne modele mogą uzyskać dostęp do danych za pomocą funkcji ExtractValue. Możesz przechowywać wszystko od razu, bez potrzeby martwienia się o to, czego będziesz potrzebować później.

Ale jaki będzie występ?

Na przykład mam tabelę z 50 000 pozycji, które reprezentują użytkowych. Mam pole enum stwierdzający "male", "female "(lub różne inne płcie być politycznie poprawne).

wykonywania na przykład ściągam wszystkie samce będą bardzo szybko.

• Ale co o czymś takim WHERE ExtractValue(userdata, '/gender/') = 'male'?

• Jak będzie zmieniać się wydajność jeśli obiekt staje się większe?

• mogę maby jakoś umieścić indeksu na specyfi ed wybory xpath?

• Jak typy pól współpracują z tymi funkcjami/wydajnością. Varchar/blob?

• Czy potrzebuję pełnotekstowych indeksów?

Podsumowując moje pytanie:

functins Mysql XML wyglądają wspaniale. I jestem pewien, że są naprawdę świetne, jeśli chcesz tylko przechowywać dane strukturalne, które pobierasz i analizujesz dalej w swojej aplikacji.

Ale jak będą walczyć w procedurach, w których wykonywane są na nich wewnętrzne skany/sortowanie/porównanie/obliczenia?

Czy MySQL może zastąpić zorientowane na dokumenty bazy danych, takie jak CouchDB/Sesame?

Jakie są zyski i kompromisy funkcji XML?

Jak i dlaczego są lepsze/gorsze od dynamicznej aplikacji przechowującej różne dane jako atrybuty?

Na przykład tabela klucz/wartość z xpath jako kluczem i wartość jako wartość związana z jednostką dokumentu.

Ktoś zrobił z nią jakieś inne wrażenia lub zauważył coś godnego uwagi?

Answer 1

Mam tendencję do komentarzy podobnych do słów Pekki, ale myślę, że powodem, dla którego nie możemy tego uśmiać, jest stwierdzenie: "Ta informacja może się jednak znacznie różnić." Oznacza to, że nie jest realistyczne zaplanowanie przeanalizowania wszystkiego i wyświetlenia go w bazie danych.

Nie mogę odpowiedzieć na wszystkie pytania, ale mogę odpowiedzieć na niektóre z nich.

Przede wszystkim nie mogę powiedzieć o wydajności w MySQL. Widziałem to w SQL Server, przetestowałem i okazało się, że SQL Server wykonuje w ekstrakcjach XML pamięci bardzo powoli, wydawało mi się, że to czytanie z dysku, ale to trochę przesada. Inni mogą się temu sprzeciwić, ale to właśnie znalazłem.

"Czy MySQL może zastąpić zorientowane na dokumenty bazy danych, takie jak CouchDB/Sesame?" To pytanie jest nieco zbyt szerokie, ale w twoim przypadku używanie MySQL pozwala zachować zgodność ACID dla tych fragmentów XML, zakładając, że używasz InnoDB, co nie może być powiedziane automatycznie dla niektórych z tych zorientowanych na dokumenty baz danych.

"Jak i dlaczego są lepsze/gorsze od dynamicznej aplikacji przechowującej różne dane jako atrybuty?" Myślę, że to naprawdę kwestia stylu. Dostajesz fragmenty XML, które są (prawdopodobnie) udokumentowane i MySQL może nimi nawigować. Jeśli po prostu zachowujesz je jako takie, oszczędzasz krok. Co można zyskać, przekształcając je w coś innego?

Dokumenty MySQL sugerują, że plik XML trafi do pola typu clob. Wydajność może ucierpieć w przypadku większych dokumentów. Być może wtedy zidentyfikujesz pod-dokumenty, które chcesz regularnie wyłamywać i umieszczać w tabeli podrzędnej.

W tych samych liniach, jeśli istnieją określone pod-docs, o których wiesz, że będziesz chciał wiedzieć, możesz utworzyć tabelę podrzędną "HasDocs", przeprowadzić małe przetwarzanie wstępne i wypełnić je nazwami -docs z ich liczbą. Ułatwiłoby to szybszą analizę statystyczną, a także przyspieszyło wyszukiwanie dokumentów zawierających określone podwęzły.

Chciałbym móc powiedzieć więcej, mam nadzieję, że to pomoże.