Перейти к контенту

Подрезаем БД: сброс постов в файлы


Рекомендуемые сообщения

хрена себе мелковат..

Ты знаешь что такое полнотекстовый индекс?

Это индексированные все слова во всех постах!

 

Он и называется FULLTEXT -> полный текст -> вест текст -> весь текст всех постов

Даже если ничего не понимаешь, можно взять англо-русский словарь и помыслить логически.

 

всего 1 - количество элементов....

логика у тебя железная :D

количество элементов - это количество колонок таблицы, которые собраны в этом индексе.

Конечно косвенно ты прав, предполгая размер индекса по количеству элементов, но типы колонок принимать в расчёт нужно в первую очередь.

 

И если у тебя будет например два индекса:

1) один элемент - строка

2) два элемета - оба целочисленных значения

 

даже не сомневайся занимать больше будет строковый, хотя состоит из одного элемента.

Ссылка на комментарий
Поделиться на других сайтах

  • Ответы 99
  • Создана
  • Последний ответ

Лучшие авторы в этой теме

Лучшие авторы в этой теме

я вообще слабо представляю, из чего состоит индекс....

Практические наблюдения по подрезке БД:

8 Мб сброшенных файлов, при этом БД уменьшилась в размере на 10 Мб.

 

Про функционал:

Архивированная страница и неархивированная страница в одном и том же топике.

Подтенение архивированных сообщений я делал специально для себя, чтобы было наглядно видно где сархивировано.

Ссылка на комментарий
Поделиться на других сайтах

  • 2 недели спустя...

Объясните, пожалуйста...

 

табличка posts была такая...

 

Данные 372,205 КБ

Индекс 251,458 КБ

Накладные расходы 804,920 Байт

Эффективность 622,877 КБ

Всего 623,663 КБ

 

грохнул тему с 20 страницами... посты средние по размеру...

 

и стало так..

 

Данные 372,205 КБ

Индекс 251,458 КБ

Накладные расходы 1,008 КБ

Эффективность 622,655 КБ

Всего 623,663 КБ

 

почему ничего в графе "данные" и "индекс" не уменьшилось? а только накладные расходы возросли, но снизилась "эффективность" в кб...

статистика на мускуле пересчитывается в определенное время чтоли?

 

объясните, пожалуйста

Ссылка на комментарий
Поделиться на других сайтах

Может тема в корзину ушла? :D
Ссылка на комментарий
Поделиться на других сайтах

в какую корзину....

тема удалилась полностью безвозвратно...

количество элементов уменьшилось...

 

спустя 20 минут

 

Данные 372,205 КБ

Индекс 251,486 КБ

Накладные расходы 986 КБ

Эффективность 622,705 КБ

Всего 623,691 КБ

 

люди, скажите, плиз... почему "данные" не меняются....?

индекс чуток подрос...

"накладные" стали 1 мег почти... были 1 кб.....

"эффективность" подросла....

Ссылка на комментарий
Поделиться на других сайтах

А если сделать REPAIR ничего не изменится?

 

P.S. Не спец я по БД :D

Ссылка на комментарий
Поделиться на других сайтах

не repair, а оптимизировать наверное.....

возможно изменится....

 

подожду мнения спецов ))

 

т.е. проблема в чем.... я сброшу посты в файлы...

а размер базы у меня не уменьшится...... во всяком случае, так система покажет...

 

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

 

--------------

 

такую штуку всё ж закажу у проггеров наверное......

 

1. выбираем тему...

2. жмем "сгенерировать html"

3. сгенерируются html-файлы темы... пролинкованные, разбитые на страницы.... названия и описания архивных тем заносятся в отдельную мускульную таблицу и линкуются на хтмл-файлы.... страница с выбором тем по дизу не отличается от основного форума...

4. диз тот же, что у форума... шаблоны вверху и внизу, чтобы баннеры повесить, если надо....

5. архивных разделов может быть несколько...

 

после того как всё сгенерируем... смотрим нормально ли сгенерировано.... и если всё путем....

удаляем тему из бд стандартными средствами...

тем самым разгружаем базу... тема отправляется в архив...

Ссылка на комментарий
Поделиться на других сайтах

Unico

 

при удалении данных данные из таблицы физически не удаляются, а только помечаются как удалённые.

Следующая вставка в таблицу произойдёт уже на их место.

Сделано для того, чтобы не загружать серв файловыми операциями.

 

Если ты хочешь "применить удаление" нужно сделать оптимизацию таблицы (запрос OPTIMIZE TABLE tbl)

 

т.е. проблема в чем.... я сброшу посты в файлы...

а размер базы у меня не уменьшится...... во всяком случае, так система покажет...

При сбросе постов файл (по крайней мере способом, описанным в сабже) делается запрос update, который приводит к немедленному изменению данных в таблице (перезапись). Индекса могут не сразу перестроиться, зависит от настройки MySQL.

Ссылка на комментарий
Поделиться на других сайтах

Спасибо, Song

 

глянул табличку щас...

данные стали меньше....

накладных расходов, нет вообще...

 

Данные 371,814 КБ

Индекс 251,955 КБ

Всего 623,769 КБ

 

вчера данные были больше....

 

значит, оптимизация таблицы прошла без меня как-то?

Ссылка на комментарий
Поделиться на других сайтах

Всё зависит от того какие работы проводятся над базами хостером.

 

"Накладные расходы 986 КБ" - это и были те удалённые данные.

То что они исчезли просто означает, что возместились добавленными сообщениями.

Ссылка на комментарий
Поделиться на других сайтах

Добавил чтение настроек sql из форумного файла конфигурации conf_global.php.

 

Последнюю версию можно взять все там же: http://pharm-forum.ru/uploads/exportsql.zip

Ссылка на комментарий
Поделиться на других сайтах

  • 3 недели спустя...
А после отправки топика в архив, если сделать пересчёт постов юзера, его счётчик постов уменьшится? В списке последних постов найти сархивированный пост найти будет нельзя?
Ссылка на комментарий
Поделиться на других сайтах

А вот по поиску уже не найти.. :D

Поисковки индексируют.

http://vesvalo.net/index.php?act=Search - внизу привинтил гугловую поисковку по форуму. Механизм простой: запрос отдается гугле, но в запрос приписывается:

 syte:vesvalo.net

Ссылка на комментарий
Поделиться на других сайтах

А это серьёзно снизит нагрузку на базу данных?

 

Ну допустим я даже половину форума так заархивирую.

Ссылка на комментарий
Поделиться на других сайтах

Размер её снизит.

Ну и запросы соответтсвенно убыстрит.

Ссылка на комментарий
Поделиться на других сайтах

С моей ламерской точки зрения, это больше от количества записей зависит, если смотреть по всему форуму вцелом.

Как пример, когда мы пользуемся поиском на компе, по имени файла, то размер начинки файла ведь не играет роли.

 

Получается выигрываем мы когда только смотрим именно сархивированные топики. А апач при этом то не будет кушать ресурсов настолько же больше, насколько мы экономим на SQL'e?

(Думаю что конечно будет круче, но хотелось бы уточнить =) Всё-таки вынос постов из БД и свои минусы имеет..

 

Есть же форумы работающие вобще без БД. А не пользуются ими..

Ссылка на комментарий
Поделиться на других сайтах

Согласна с PALADIN+.

 

Этот мод ускоряет только поиск (за счет ухудшения его работы - ведь по "сброшенным в файлы" записям уже не поищешь). Немного ускоряет вставку и удаление записей в ibf_posts за счет того, что полнотекстовый индекс становится меньше (если он есть), а значит, быстрее обновляется. Немного ускоряет обработку страницы за счет того, что меньше текста надо парсить, но это компенсируется возросшей нагрузкой на апач или что там у нас.

 

Т.к. количество записей в ibf_posts после архивации остается прежним, то все остальные операции не ускоряются - с чего бы? Важно количество записей в таблице. А сколько текста при этом хранится в полях типа "text" - неважно. Все индексы, кроме полнотекстового, остаются прежними.

 

Ну, еще и бэкап становится меньше. Вот еще один плюс. Других не вижу.

Ссылка на комментарий
Поделиться на других сайтах

Получается выигрываем мы когда только смотрим именно сархивированные топики.

Наоборот: выигрыш происходит, когда мы смотрим все топики, и прежде всего неархивированные.

 

Таблица ibf_posts - это кроме всего прочего и файл ibf_posts.MYI в файловой системе компьютера.

Ты открываешь страницу топика, и майэскуэль начинает читать файл ibf_posts.MYI с диска. Время считывания файла прямо пропорционально его размеру.

 

На практике имеем, что когда ibf_posts приближается к 50 Мб - время ответа сервера увеличивается так, что невооруженным глазом видно.

Полтора десятка небольших js-файлов апач отдаст несравнимо быстрее.

 

Из личной статистики:

Провайдер newhost.

Размер ibf_posts 60 Мб - время от запроса до начала загрузки страницы 9-10 сек.

Размер ibf_posts 30 Мб - время от запроса до начала загрузки страницы 1-2 сек.

 

Сейчас на http://pharm-forum.ru ibf_posts "весит" 43 Мб, среднее время до начала загрузки страницы топика около 4 сек. Скоро опять буду подрезать.

Ссылка на комментарий
Поделиться на других сайтах

Да ну.. что значит "считывает с диска"? Это же индексный файл. Он сканируется в поисках нужного индекса, далее - нужного блока. Если поставить key buffer size достаточно большим, то все необходимые индексы будут в памяти, и правильно построенные (т.е. использующие индексы) запросы будут очень быстрыми.

 

Я, правда, не знаю, как там на shared хостингах живется - может ли пользователь там настраивать mysql (нельзя, наверно). Там наверняка своя специфика. У меня ipb 2.0, ibf_posts раз в 20 больше, общее время запросов при просмотре страницы темы - 0.02 сек. А вот сама страница формируется по 0.2-0.5 сек.

Изменено пользователем l-k
Ссылка на комментарий
Поделиться на других сайтах

А апач при этом то не будет кушать ресурсов настолько же больше, насколько мы экономим на SQL'e?

Не вопрос, вешаем фронтэнд для балансировки и отдаем через него всю статику.

 

Т.к. количество записей в ibf_posts после архивации остается прежним, то все остальные операции не ускоряются - с чего бы?

Ну почему, если используете полнотекстовый индекс, то очень даже облегчит его перестроение ) Уменьшится индекс - MySQL будет жрать меньше памяти, будет жрать меньше памяти будет легче работать (и вероятно когото спасет от вываливания в своп ака оверхеад =))

 

Таблица ibf_posts - это кроме всего прочего и файл ibf_posts.MYI в файловой системе компьютера.

Ты открываешь страницу топика, и майэскуэль начинает читать файл ibf_posts.MYI с диска. Время считывания файла прямо пропорционально его размеру.

Грамотно настроенный MySQL не должен дергать индексы с диска при каждом использования той или иной таблицы =) Слушайте l-k, она дело говорит.

Ссылка на комментарий
Поделиться на других сайтах

Ну почему, если используете полнотекстовый индекс, то очень даже облегчит его перестроение
а я про это упомянула. "Все остальные операции" = "не использующие полнотекстовый индекс". В общем, вся эта тема на самом деле - про недостатки fulltext индекса и FatCat придумал очень нетрадиционный метод борьбы с этими недостатками ;)

 

В клиентском разделе есть интересная тема про отказ от fulltext индекса и замену его на sphinx (это стороняя search engine для mysql). Вот это - радикальное решение! К сожалению, у меня сисадмин бездельник и не желает ничего нового устанавливать, пока и так все работает :D И, опять-таки, это не для shared хостинга.

 

Еще хочу добавить, что в качестве "решения для бедных", когда настроить mysql нет возможности, этот мод, наверно, может принести пользу... А если у вас свой сервер - то лучше не надо.

 

Хотя я бы скорее отказалась от полнотекстового поиска, запретила бы поиск по всему форуму, оставила бы только внутри тем (чтобы искать в них через LIKE), и внутри подфорумов (если не слишком тормозить будет), а по всему форуму пусть через google ищут.

Ссылка на комментарий
Поделиться на других сайтах

Т.к. количество записей в ibf_posts после архивации остается прежним, то все остальные операции не ускоряются - с чего бы? Важно количество записей в таблице. А сколько текста при этом хранится в полях типа "text" - неважно. Все индексы, кроме полнотекстового, остаются прежними.

База MySQL - это грубо говоря сборище файлов (как и любая БД впрочем), и каждый запрос к базе - это оптимизированный специальным образом доступ к файлам этой базы данных.

Как ты думаешь, если файл станет меньше по размеру в n раз скорость его обработки не уменьшится?

 

Это же индексный файл. Он сканируется в поисках нужного индекса, далее - нужного блока.

Правильно. Ключевая фраза "в поисках нужного блока" после того как блок станет известным из индекса.

Поиск блока - это открытие файла с данными и перешагивание к нужному сегменту.

Эта операция выполняетя тем быстрей, чем меньшн размер файла с данными.

Ссылка на комментарий
Поделиться на других сайтах

Поиск блока - это открытие файла с данными и перешагивание к нужному сегменту.

В случае поиска по LIKE видимо (LIKE abc% использyет обычный индекс. LIKE %abc не использyет никакого индекса так как префикс может быть любым!). В случае работы с ключами aka индексами - работает с индексным файлом. Так вот в процессе "сархивирования" тем форума, индексы не меняются. Они как были так и остаются.

 

Другими словами таблица в MySQL представлена тремя файлами

MYI - индекс

MYD - данные

frm - структура

 

В индексе особым образом хранятся значения ключей. В данных - собственно все что есть в таблице.

 

Теперь ближе к IP.B. Таблица постов не имеет индекса по полю post (за исключением FULLTEXT). Следовательно изменение данных в post в процессе "сархивирования" не приводит к изменению индекса, а лишь к изменению в данных. Итого получаем уменьшение MYD, при старом MYI.

 

При любой работе с pid или датой сообщения, мы имеем дело с индексами, т.е. с MYI. Подводя общий итог:

 

В общем, вся эта тема на самом деле - про недостатки fulltext индекса и FatCat придумал очень нетрадиционный метод борьбы с этими недостатками
Ссылка на комментарий
Поделиться на других сайтах

Присоединиться к обсуждению

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

Гость
Ответить в этой теме...

×   Вы вставили отформатированный текст.   Удалить форматирование

  Допустимо не более 75 смайлов.

×   Ваша ссылка была автоматически заменена на медиа-контент.   Отображать как ссылку

×   Ваши публикации восстановлены.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

Зарузка...

×
×
  • Создать...

Важная информация

Находясь на нашем сайте, вы соглашаетесь на использование файлов cookie, а также с нашим положением о конфиденциальности Политика конфиденциальности и пользовательским соглашением Условия использования.