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

[FatCat]

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

MYI - индекс

MYD - данные

frm - структура

И при "подрезке" базы пропорционально уменьшаются как MYD, так и MYI.

[l-k]

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

Опять не соглашусь. Полнотекстовый индекс меняется всякий раз при изменении значений полей, входящих в этот индекс. В обработке FatCat-а эти значения изменяются - заменяются на ссылку на javascript или совсем стираются (сорри, не вчитывалась в подробности). Значит, и полнотекстовый индекс меняется.

 

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

Смотря что ты подразумеваешь под обработкой Если это поиск нужного блока внутри индексного файла, то, когда мы обращаемся к одному из индексов, при чем тут количество и размер других индексов этого файла? это все равно что утверждать, что если у нас в папке 10 файлов, то работа с одним будет тем медленнее, чем больше размер соседних файлов.

 

Что-то вы, товарищи, заблудились в трех соснах

[FatCat]

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

Для того жесткий диск и разбит на кластере, чтобы не было медленнее.

На СиДишнике именно так и будет: при одинаковом числе файлов на диске время доступа к одинаковому файлу будет тем больше, чем больше размер других файлов.

Причина в том, что искать приходится не кластеры, а начало и конец части потока. Чем длинней поток, тем дольше искать.

 

Аналогично и с файлом индекса. Он же не разбит на физические кластеры; ячейки таблицы имеют начало и конец в потоке данных.

Чем меньше будет размер файла - тем быстрее нахождение.

 

А лучше не мудрить теориями, а поставить копию форума на локалку и проверить.

Я когда увидел, насколько быстрее стал форум грузиться после подрезки БД - меня никакими теориями не переубедишь, что от размера БД скорость не зависит.

Да, именно загрузка страниц топиков ускорилась, а не только поиск по форуму.

[GiV]

Опять не соглашусь. Полнотекстовый индекс меняется всякий раз при изменении значений полей, входящих в этот индекс. В обработке FatCat-а эти значения изменяются - заменяются на ссылку на javascript или совсем стираются (сорри, не вчитывалась в подробности). Значит, и полнотекстовый индекс меняется.

Написано было "(за исключением FULLTEXT)." Что означает, что я его просто не рассматривал.

 

И при "подрезке" базы пропорционально уменьшаются как MYD, так и MYI.

правильно, FULLTEXT индекс перестраивается.

[l-k]

А лучше не мудрить теориями, а поставить копию форума на локалку и проверить.

не забудь только mysql настроить. Т.е. в тестах надо исключать посторонние факторы.

 

На СиДишнике именно так и будет: при одинаковом числе файлов на диске время доступа к одинаковому файлу будет тем больше, чем больше размер других файлов.

а индексный файл mysql - не сидишник. Индексы не считываются целиком. Они считываются блоками (аналог "кластеров").

[FatCat]

А лучше не мудрить теориями, а поставить копию форума на локалку и проверить.

не забудь только mysql настроить. Т.е. в тестах надо исключать посторонние факторы.

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

Ставил денвер, ничего в нем не менял; как встал по умолчанию, так и тестировал.

Потом в онлайне повторил подрезку, и увидел даже больший эффект, чем под денвером. На провайдера мне грех жаловаться, на недорогом тарифе форум с чатом не тормозят и при 200-250 тысячах просмотров страниц в сутки.

[PALADIN+]

FULLTEXT индекс перестраивается

А где смотреть, Фуллтекст у меня или нет?

 

(Скриптег у меня кстати что-то не запустился на Денвере. Просто как бы тупо обновляется, ничего не делая)

[FatCat]

(Скриптег у меня кстати что-то не запустился на Денвере. Просто как бы тупо обновляется, ничего не делая)

Попробуй мой: http://pharm-forum.ru/uploads/sqlexport.zip

Просто кинь в корень форума и запускай. Настройки БД он сам подсосет из conf_global.php

[Sannis]

А где смотреть, Фуллтекст у меня или нет?

Выполнить запрос

SHOW CREATE TABLE ibf_posts

, если в результате в запросе будет FULLTEXT KEY `post` (`post`), то фултекст.

 

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

[Song]

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

Смотря что ты подразумеваешь под обработкой

Что-то вы, товарищи, заблудились в трех соснах

 

А я ж написал:

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

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

Вот именно эта операция и станет быстрей.

 

Опять не соглашусь. Полнотекстовый индекс меняется всякий раз при изменении значений полей, входящих в этот индекс. В обработке FatCat-а эти значения изменяются - заменяются на ссылку на javascript или совсем стираются (сорри, не вчитывалась в подробности). Значит, и полнотекстовый индекс меняется.

Бред.

Полнотекстовый индекс - это индекс слов, входящих в конкретный пост.

Если слов в посте становится меньше, то и индекс становится меньше. Он перестраивается.

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

 

Кстати.

Модификация давно сделана, поэтому переезжаем в Tips&Tricks

[l-k]

Если слов в посте становится меньше, то и индекс становится меньше. Он перестраивается.

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

Именно это я и имела в виду - что полнотекстовый индекс уменьшается при удалении значений. Где у меня написано обратное?

 

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

Вот именно эта операция и станет быстрей.

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

 

На провайдера мне грех жаловаться

мне бы такой не подошел. Если он от ibf_posts размером в 60 мб начинает тормозить, то с моими 1.4 гб (данные + индекс) он вообще бы не справился.

 

Больше не хочу мешать пусть этим модом пользуются те, кто считают его полезным.

Изменено 24 Ноября 2007 пользователем l-k

[FatCat]

Для модификации от theIggs добавил возможность архивации в файлы с последующим инклайдом на страницы.

Кроме , проблем с отображением топиков нет.

 

http://www.ibresource.ru/forums/index.php?...st&p=294581

[Unico]

мдя.. везет вам проггерам...

соображаете во всём этом ))

 

вот у меня тоже свой сервер..... 2 гига оперативы...

под мускуль определено 512 мб + 128 мб....

 

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

Данные 397,220 КБ

Индекс 267,948 КБ

Всего 665,168 КБ

 

вся база форума чуть больше 700 мб...

 

-----------

 

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

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

 

мне объясняли так, что вся табличка помещается в оперативную память... т.е. она весит 700 мб и оперативной памяти стало быть желательно иметь не меньше 700 мб... это так??? в самом упрощенном виде - это так??

 

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

 

l-k

 

то с моими 1.4 гб (данные + индекс)

 

скажите, пожалуйста, какая у вас конфигурация сервера? интересует прежде всего оперативная память...

 

-------

 

люди, скажите мне...

 

вот у товарища Экслера

http://forum.exler.ru/arc/

 

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

[FatCat]

вот у товарища Экслера

http://forum.exler.ru/arc/

 

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

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

[PALADIN+]

А статистика интересно как от этого считается?.. Всё дело в статистике. Иначе я бы и сам уже 3 форума поставил в разные папки)

[Sannis]

Технически со статистикой понятно. Статистика хранится в ibf_stats, так что при перемещении постов в архивный форум информация в ней не изменится. Единственное, при пересчёте сообщений через админку нужно дописать в код обращение к другой БД и учёт сообщений в ней.

[Song]

Да может просто другие разделы.

Переносится из раздела в раздел, а таблица одна.

[l-k]

скажите, пожалуйста, какая у вас конфигурация сервера? интересует прежде всего оперативная память...

Очень хорошая Сейчас-то у нас два сервера (почему так - отдельная история ). На одном из них только mysql и немного статики, памяти 4Гб. Там не только индексы в памяти, там 3Гб данных закэшировано, т.е. фактически вся БД в памяти. Но год назад все, и php, и mysql работали на одном сервере с 2Гб памяти, ibf_posts был где-то 900 тыс. сообщений, и ничего, mysql работал довольно шустро, НО без fulltext. Был обычный поиск внутри отдельных тем, поиск по названиям тем, и был поиск от Гугля.

 

У нас сейчас есть "архив", это просто еще одна таблица с такой же структурой, как ibf_posts, но без того самого полнотекстового индекса. Там сейчас 560 тыс. записей, в основной ibf_posts - 1200 тыс. На нашем форуме много длинных тем "с продолжениями". Когда очередная часть такой темы закрывается, сообщения этой темы сносятся в этот архив. Запись с темой остается в ibf_topics, там есть поле "archived", 0 - обычная тема, 1 - "архивная". Что такая схема дает? Уменьшение fulltext и других индексов. Архив просматривается редко, поиск по всему архиву не нужен, от гостей (и поисковиков) закрыт.

 

тормоза не при поиске, а именно при открытии страниц в больших темах..

У вас какая версия форума - 1.3? Не знаю, какие там запросы при просмотре тем. В 2.0, действительно, чем больше тема, тем дольше открывается, т.к. при этом mysql должен сперва выбрать все записи, относящиеся к теме, отсортировать по pid (или post_date, в зависимости от выбранного типа сортировки), затем выбрать нужную страницу. Это в 2.0 вылечивается добавлением еще одного поля в индекс topic_id - изначально там topic_id,queued, надо добавить pid (или post_date). И в запросах заменить "queued<>1" на "queued=0"

 

мне объясняли так, что вся табличка помещается в оперативную память

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

 

Судя по тому, что на форуме Экслера время от времени "идет перенос данных в архив" и форум при этом недоступен, то у них там отдельная БД для архива, куда из основной БД время от времени сносятся закрытые темы и сообщения. Статистика у архива и форума там разная.

[Unico]

вот как я трахаюсь с уменьшением БД ))

 

Скачиваю все странички флешгетом...

И во фронтпейдже по алгоритму массово меняю куски кодов

 

к примеру:

 

=========================================== 4. заменить

 

"); cur_page = 1;

if ( total_posts % per_page == 0 ) { pages = total_posts / per_page; }

else { pages = Math.ceil( total_posts / per_page ); }

msg = "Введите номер страницы, к которой хотите перейти." + " " + pages;

if ( cur_st > 0 ) { cur_page = cur_st / per_page; cur_page = cur_page -1; }

show_page = 1;

if ( cur_page < pages ) { show_page = cur_page + 1; }

if ( cur_page >= pages ) { show_page = cur_page - 1; }

else { show_page = cur_page + 1; }

userPage = prompt( msg, show_page );

if ( userPage > 0 ) {

if ( userPage < 1 ) { userPage = 1; }

if ( userPage > pages ) { userPage = pages; }

if ( userPage == 1 ) { start = 0; }

else { start = (userPage - 1) * per_page; }

window.location = url_bit + "&st=" + start;

}

}

//-->

</script>

 

<!--IBF.BANNER-->

 

на

 

//-->

 

<!--IBF.BANNER-->

 

=========================================== 5. заменить

 

процедура трудоемкая... требует корректировки постоянной в кодах....

около получаса где-то...

 

на выходе получаем

http://yarportal.ru/arc/ooorsu/topic6869s0.html

через ssi вставляю нужные мне баннеры и счетчики на все полученны хтмл-страницы

 

тему из базы можно грохнуть....

 

------

 

вот автоматизировать бы этот процесс....

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

тысячи 3 нормальная цена этому срипту

[FatCat]

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

тысячи 3 нормальная цена этому срипту

У меня сделано поболее.

 

1. Большие посты хранятся не в БД, а в файле. Причем, файл на лету жмется в gZ и разжимается при показе; поэтому и места на диске занимает не много. Заодно это позволяет при необходимости править текст сообщения по ФТП. Примеры:

http://vesvalo.net/index.php?showtopic=2964 - сообщение;

http://vesvalo.net/arc/69/585.arc.gz - файл текста сообщения.

 

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

http://vesvalo.net/index.php?showtopic=205 - архивированный топик;

http://vesvalo.net/index.php?act=Print&amp...p;f=6&t=205 - он же в принтверсии;

http://vesvalo.net/arc/5/115.arc.gz - файл.

 

3. Для "бесконечно продолжающихся" топиков в один клик из опций модератора выносится в архивный топик первая сотня старых ответов; линк на архив добавляется в старт топика. Примеры:

http://vesvalo.net/index.php?showtopic=777 - холивар с кучей ссылок (звездочки) на архивы в топикстарте;

http://vesvalo.net/index.php?act=Print&amp...f=10&t=9065 - одно из архивированных по ссылке;

http://vesvalo.net/arc/189/725.arc.gz - файл.

 

Таким образом, сейчас при 200 000 сообщений в форуме, у меня вес таблицы ibf_posts составляет меньше 50 мб; плюс 27 мб зипок в файлах от архивированных топиков.

 

 

Оно может не так красиво... Зато за час работы я элементарно ужимаю в архив полторы сотни топиков. Да и то бОльшую часть времени отнимает не само ужимание, а принятие решения какой топик будем ужимать, а какой оставить несжатым.

Изменено 26 Июня 2009 пользователем FatCat

[Unico]

разрабочки ipb странные люди...

все что-то там улучшают косметически...

принципиально нового ничего нет...

 

а вот решение проблемы разраст. базы так и не делают официально...

думают, что форумы вечно мелкие будут

[WildRAID]

Эта проблема, по-хорошему, должна решаться кластером.

Кроме того, форумов 500.000+ постов от силы 1-2% от общего числа.

[Ritsuka]

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

 

И потом, раз уж решили вынести, почему именно таким образом - через JavaScript? Что мешает чуть-чуть подредактировать скрипты форума, и через fopen вычитывать содержимое внешних файлов сразу в код страницы?

 

Конечно, память и производительность отрисовки просто страницы чуть выигрывает в случае с JS, но, и это важно, каждый визит пользователя будет вызывать еще 30-50 HTTP-запросов за скриптами с контентом... На больших форумах и на старых ПК у пользователей это трудно не почувствовать.

 

Если хочется разгрузить таблицу ibf_posts, логично сделать систему таблиц ibf_archive_{$forum_id}, куда автоматически перемещать записи из ibf_posts для определенных форумов. Придется подправить только mysql-выражения(!), перенаправив запросы на соответствующую форуму таблицу, и можно будет вообще сохранить весь функционал форума. Разве такое решение не выглядит рациональнее?

[WildRAID]

Разве такое решение не выглядит рациональнее?

 

На практике - нужно будет переписать огромное количество кода, чтобы всё работало. На такое кол-во человеко-часов проще купить несколько современных серверов.

[FatCat]

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

 

И потом, раз уж решили вынести, почему именно таким образом - через JavaScript?

Сударыня, посмотрите дату первого сообщения топика: 2 года назад.

И посмотрите мое вчерашнее сообщение #95 на этой же странице всего двумя сообщениями выше Вашего.

Если после этого останутся "почемуки" и "зачемки", я охотно выслушаю Ваши идеи по улучшению.

 

 

На практике - нужно будет переписать огромное количество кода, чтобы всё работало. На такое кол-во человеко-часов проще купить несколько современных серверов.

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

Проблема выбора двух тупиков:

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

- если разрешить - лавинообразное увеличение нагрузки на php, на больших тредах потери производительности php будут превышать выигрыщ в sql...