Производительность функций MySql Xml?

Question

Я очень рад новым функциям Mysql XMl .

Теперь я наконец-то могу встраивать что-то вроде "объектно-ориентированных" документов в мою реляционную базу данных oldschool.

В качестве примера использования рассмотрим пользователя, который поет на вашем сайте, используя Facebook connect.Вы можете получить объект для пользователя, используя график API, и получить полезную информацию.Эта информация, однако, может сильно различаться.Некоторые поля могут быть или не быть установлены, некоторые могут быть добавлены с течением времени и т. Д.

Что ж, если вы просто интересуетесь очень специальными полями (например, отношения с друзьями, пол, фильмы ...), выможет проецировать их в вашу схему реляционной базы данных.

Однако, используя функции XMl, вы можете сохранить весь объект внутри поля, и тогда ваши разные модели смогут получить доступ к данным с помощью функции ExtractValue .Вы можете хранить все сразу, не беспокоясь о том, что вам понадобится позже.

Но какова будет производительность?

Например, у меня есть таблица с 50 000 записей, которые представляют пользователей.У меня есть поле enum, в котором указано "male", "female "(или различные другие полы должны быть политкорректными).

Производительность, например, выборки всех мужчин будет очень быстрой.

• Но как насчет чего-то вроде WHERE ExtractValue(userdata, '/gender/') = 'male'?

• Как изменится производительность, если объект станет больше?

• Могу ли я поболтать?каким-то образом поместить индекс в выбранный выбор xpath?

• Как типы полей работают вместе с этой функцией / производительностью. Varchar / blob?

• DoМне нужны полнотекстовые индексы?

Подводя итог моему вопросу:

Функции Mysql XML выглядят великолепно. И я уверен, что они действительно хороши, если вы просто хотите хранить структурированныеданные, которые вы извлекаете и анализируете в своем приложении.

Но как они будут противостоять процедурам, в которых выполняются внутренние проверки / сортировка / сравнение / вычисления?

Может ли Mysql заменить документ?ориентированные базы данных, такие как CouchDB /Сезам?

Каковы преимущества и недостатки функций XML?

Как и почему они лучше / хуже динамического приложения, которое хранит различные данные в качестве атрибутов?

Например, таблица ключ / значение с xpath в качестве ключа и значением в качестве значения, связанного с сущностью документа.

Кто-нибудь сталкивался с этим другим или заметил что-то упомянутое?

Answer 1

Я склонен делать комментарии, похожие на комментарии Пекки, но я думаю, что причиной, по которой мы не можем смеяться над этим, является ваше утверждение «Эта информация, однако, может сильно различаться».Это означает, что нереально планировать анализ всего этого и проецирование его в базу данных.

Я не могу ответить на все ваши вопросы, но могу ответить на некоторые из них.

В первую очередь яне могу рассказать вам о производительности на MySQL.Я видел это в SQL Server, протестировал его и обнаружил, что SQL Server выполняет в памяти XML извлечения очень медленно, мне казалось, что он читает с диска, но это немного преувеличение,Другие могут оспорить это, но это то, что я нашел.

"Может ли Mysql заменить ориентированные на документы базы данных, такие как CouchDB / Sesame?"Этот вопрос немного чрезмерно широк, но в вашем случае использование MySQL позволяет поддерживать соответствие ACID для этих фрагментов XML, предполагая, что вы используете InnoDB, чего нельзя сказать автоматически для некоторых из этих ориентированных на документы баз данных.

"Как и почему они лучше / хуже динамического приложения, которое хранит различные данные в виде атрибутов? "Я думаю, что это действительно вопрос стиля.Вам предоставляются фрагменты XML, которые (предположительно) задокументированы, и MySQL может перемещаться по ним.Если вы просто сохраните их как таковые, вы сохраните шаг.Что можно получить, преобразовав их во что-то еще?

Документы MySQL предполагают, что файл XML перейдет в поле clob.Производительность может пострадать на больших документах.Возможно, тогда вы определите поддокументы, которые вы хотите регулярно разбирать и помещать в дочернюю таблицу.

В том же духе, если есть определенные поддок, о которых вы знаете, о которых вы хотите знать, выможет создать дочернюю таблицу «HasDocs», выполнить небольшую предварительную обработку и заполнить ее именами дочерних документов с их количеством.Это ускорило бы статистический анализ, а также позволило бы быстрее находить документы с определенными вложенными документами.

Хотел бы я сказать больше, надеюсь, это поможет.