Хранение полей TEXT в больших объёмах в Mysql

Question

[johnny_s]

Имеется Mysql сервер и на нём таблица содержимого статей.

Структура: id (int), article_id (int), content (text)
Около 1.5млн записей. Объём таблицы 5Gb. Общий объём данных на Mysql 9Gb

В последнее время сервер стал медленнее работать
Имеет ли смысл выносить эти данные на MongoDB для уменьшения объёма данный Mysql и увеличения его производительности

Comments

[helions8]

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

[johnny_s]

Конкретно к этой большой таблице и запросов к ней вопросов нет. Работает относительно быстро, индексы стоят. Вопрос скорее такой: может ли наличие такой большой таблицы влиять на общую работу сервера?

[ShouldNotSeeMe]

Если к таблице никак не обращаться, то все влияние ее сведется к заниманию места на диске.

Answer 1

[Melkij]

9гб даже для mysql — небольшая величина. Ищите проблему в другом. Например, когда данных было немного, было незаметно отсутствие индекса по какому-нибудь более-менее часто используемому запросу.

Comments

[johnny_s]

Спасибо!

Answer 2

[ShouldNotSeeMe]

Не совсем понятны исходные данные. Кроме запросов еще важно, стоят ли PRIMARY-индексы.
Для уменьшения занимаемого места на диске при слабозагруженном CPU можно воспользоваться упаковкой текста на лету с помощью COMPRESS/UNCOMPRESS.

Answer 3

[Анатолий]

Имеет смысл иногда вынести поле текст в отдельную табличку, если дергаются данные из этой таблицы без этого поля.

Comments

[Melkij]

Зачем? Text'ы и Blob'ы и так хранятся отдельно.

[Анатолий]

Хранятся то отдельно, но такое действие помогает при больших обьемах данных

Answer 4

[Виталий Желтяков]

Хранить текст статей в базе глупо — правильнее хранить ссылку или напрямую обращаться по номеру ключа. Таким подходом вы снизите нагрузку на БД и повысите отзывчивость сервера, т.к. можно организовать кэшироание на уровне сервера и ФС. Для поиска необходимо использовать Sphinx.

Можете минусовать…

Comments

[egorinsk]

Если кратко, то чушь, так как БД хранит данные в той же самой ФС, только, как правило, более эффективно.

[Виталий Желтяков]

Да, СУБД хранит данные в тех же файлах, но:
— СУБД лишний посредник;
— Таблица с полями TEXT или BLOB не может быть fixed;
— Кэширование СУБД крайне плохо ведёт себя при работе с объёмными выборками.

Единственное критическое преимущество СУБД — это поиск. Но если используется Sphinx, то и это не проблема.

[lashtal]

Text/blob хранятся отдельно от самих строк, поэтому не должны влиять на скорость выборки. А вот запросы, использующие временные таблицы с участием этих типов создаются на диске, а не в памяти, поскольку движок memory не поддерживает эти типы. Но, судя по структуре таблицы, там только запросы по индексу должны быть, и на скорости отражаться не должно.

И, некоторое противоречие, не? — если «преимущество СУБД — это поиск», то зачем сфинкс? :) Как раз-таки полнотекстовый поиск в mysql — один из самых больших ее недостатков.

[Виталий Желтяков]

«Text/blob хранятся отдельно от самих строк, поэтому не должны влиять на скорость выборки. „
— Неужели? По моему вы очень ошибаетесь.

“Но, судя по структуре таблицы, там только запросы по индексу должны быть, и на скорости отражаться не должно.»
— Крайне маловероятно, что это полная структура таблицы.

«если «преимущество СУБД — это поиск», то зачем сфинкс?»
— Некоторые люди боятся сторонних решений.

[lashtal]

Хм, ну это общеизвестно. 10.5. Data Type Storage Requirements: […] For BLOB and TEXT data, the information is stored internally in a different area of memory than the row buffer. […]

Ну да, если это не полная структура таблицы, то и говорить не о чем.

Я к тому, что сфинкс в этом конкретном случае не должен быть нужен.

[Виталий Желтяков]

«Хм, ну это общеизвестно. 10.5. Data Type Storage Requirements: […] For BLOB and TEXT data, the information is stored internally in a different area of memory than the row buffer. […]»
— Я не об этом. Я про то, что СУБД проще вернуть несколько байт, чем десятки килобайт.

[Melkij]

Дык если вам нужен текст — вам его всё равно читать. Если не нужен — то и база его читать с диска не будет.

Answer 5

[boodda]

Так может просто база разрослась настолько, что индексы не стали влазить в key_buffer и теперь индексы мускулом просто перестали юзаться?