Song Опубликовано 14 Октября 2007 Жалоба Поделиться Опубликовано 14 Октября 2007 хрена себе мелковат..Ты знаешь что такое полнотекстовый индекс?Это индексированные все слова во всех постах! Он и называется FULLTEXT -> полный текст -> вест текст -> весь текст всех постовДаже если ничего не понимаешь, можно взять англо-русский словарь и помыслить логически. всего 1 - количество элементов....логика у тебя железная количество элементов - это количество колонок таблицы, которые собраны в этом индексе.Конечно косвенно ты прав, предполгая размер индекса по количеству элементов, но типы колонок принимать в расчёт нужно в первую очередь. И если у тебя будет например два индекса:1) один элемент - строка2) два элемета - оба целочисленных значения даже не сомневайся занимать больше будет строковый, хотя состоит из одного элемента. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
FatCat Опубликовано 14 Октября 2007 Автор Жалоба Поделиться Опубликовано 14 Октября 2007 я вообще слабо представляю, из чего состоит индекс....Практические наблюдения по подрезке БД:8 Мб сброшенных файлов, при этом БД уменьшилась в размере на 10 Мб. Про функционал:Архивированная страница и неархивированная страница в одном и том же топике.Подтенение архивированных сообщений я делал специально для себя, чтобы было наглядно видно где сархивировано. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Unico Опубликовано 28 Октября 2007 Жалоба Поделиться Опубликовано 28 Октября 2007 Объясните, пожалуйста... табличка posts была такая... Данные 372,205 КБ Индекс 251,458 КБ Накладные расходы 804,920 Байт Эффективность 622,877 КБ Всего 623,663 КБ грохнул тему с 20 страницами... посты средние по размеру... и стало так.. Данные 372,205 КБ Индекс 251,458 КБ Накладные расходы 1,008 КБ Эффективность 622,655 КБ Всего 623,663 КБ почему ничего в графе "данные" и "индекс" не уменьшилось? а только накладные расходы возросли, но снизилась "эффективность" в кб...статистика на мускуле пересчитывается в определенное время чтоли? объясните, пожалуйста Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Sannis Опубликовано 28 Октября 2007 Жалоба Поделиться Опубликовано 28 Октября 2007 Может тема в корзину ушла? Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Unico Опубликовано 28 Октября 2007 Жалоба Поделиться Опубликовано 28 Октября 2007 в какую корзину.... тема удалилась полностью безвозвратно...количество элементов уменьшилось... спустя 20 минут Данные 372,205 КБ Индекс 251,486 КБ Накладные расходы 986 КБ Эффективность 622,705 КБ Всего 623,691 КБ люди, скажите, плиз... почему "данные" не меняются....?индекс чуток подрос..."накладные" стали 1 мег почти... были 1 кб....."эффективность" подросла.... Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Sannis Опубликовано 28 Октября 2007 Жалоба Поделиться Опубликовано 28 Октября 2007 А если сделать REPAIR ничего не изменится? P.S. Не спец я по БД Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Unico Опубликовано 28 Октября 2007 Жалоба Поделиться Опубликовано 28 Октября 2007 не repair, а оптимизировать наверное.....возможно изменится.... подожду мнения спецов )) т.е. проблема в чем.... я сброшу посты в файлы...а размер базы у меня не уменьшится...... во всяком случае, так система покажет... так чтож делать? оптимизировать табличку после каждого подрезания базы? -------------- такую штуку всё ж закажу у проггеров наверное...... 1. выбираем тему...2. жмем "сгенерировать html"3. сгенерируются html-файлы темы... пролинкованные, разбитые на страницы.... названия и описания архивных тем заносятся в отдельную мускульную таблицу и линкуются на хтмл-файлы.... страница с выбором тем по дизу не отличается от основного форума...4. диз тот же, что у форума... шаблоны вверху и внизу, чтобы баннеры повесить, если надо....5. архивных разделов может быть несколько... после того как всё сгенерируем... смотрим нормально ли сгенерировано.... и если всё путем.... удаляем тему из бд стандартными средствами...тем самым разгружаем базу... тема отправляется в архив... Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Song Опубликовано 29 Октября 2007 Жалоба Поделиться Опубликовано 29 Октября 2007 Unico при удалении данных данные из таблицы физически не удаляются, а только помечаются как удалённые.Следующая вставка в таблицу произойдёт уже на их место.Сделано для того, чтобы не загружать серв файловыми операциями. Если ты хочешь "применить удаление" нужно сделать оптимизацию таблицы (запрос OPTIMIZE TABLE tbl) т.е. проблема в чем.... я сброшу посты в файлы...а размер базы у меня не уменьшится...... во всяком случае, так система покажет...При сбросе постов файл (по крайней мере способом, описанным в сабже) делается запрос update, который приводит к немедленному изменению данных в таблице (перезапись). Индекса могут не сразу перестроиться, зависит от настройки MySQL. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Unico Опубликовано 29 Октября 2007 Жалоба Поделиться Опубликовано 29 Октября 2007 Спасибо, Song глянул табличку щас...данные стали меньше....накладных расходов, нет вообще... Данные 371,814 КБ Индекс 251,955 КБ Всего 623,769 КБ вчера данные были больше.... значит, оптимизация таблицы прошла без меня как-то? Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Song Опубликовано 29 Октября 2007 Жалоба Поделиться Опубликовано 29 Октября 2007 Всё зависит от того какие работы проводятся над базами хостером. "Накладные расходы 986 КБ" - это и были те удалённые данные.То что они исчезли просто означает, что возместились добавленными сообщениями. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
FatCat Опубликовано 29 Октября 2007 Автор Жалоба Поделиться Опубликовано 29 Октября 2007 Добавил чтение настроек sql из форумного файла конфигурации conf_global.php. Последнюю версию можно взять все там же: http://pharm-forum.ru/uploads/exportsql.zip Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
PALADIN+ Опубликовано 17 Ноября 2007 Жалоба Поделиться Опубликовано 17 Ноября 2007 А после отправки топика в архив, если сделать пересчёт постов юзера, его счётчик постов уменьшится? В списке последних постов найти сархивированный пост найти будет нельзя? Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
GiV Опубликовано 17 Ноября 2007 Жалоба Поделиться Опубликовано 17 Ноября 2007 Нет, сообщение в базе остается, только его контент меняется на подключение JS. Найти можно будет. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Song Опубликовано 18 Ноября 2007 Жалоба Поделиться Опубликовано 18 Ноября 2007 А вот по поиску уже не найти.. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
FatCat Опубликовано 18 Ноября 2007 Автор Жалоба Поделиться Опубликовано 18 Ноября 2007 А вот по поиску уже не найти.. Поисковки индексируют.http://vesvalo.net/index.php?act=Search - внизу привинтил гугловую поисковку по форуму. Механизм простой: запрос отдается гугле, но в запрос приписывается: syte:vesvalo.net Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
PALADIN+ Опубликовано 20 Ноября 2007 Жалоба Поделиться Опубликовано 20 Ноября 2007 А это серьёзно снизит нагрузку на базу данных? Ну допустим я даже половину форума так заархивирую. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Song Опубликовано 20 Ноября 2007 Жалоба Поделиться Опубликовано 20 Ноября 2007 Размер её снизит.Ну и запросы соответтсвенно убыстрит. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
PALADIN+ Опубликовано 20 Ноября 2007 Жалоба Поделиться Опубликовано 20 Ноября 2007 С моей ламерской точки зрения, это больше от количества записей зависит, если смотреть по всему форуму вцелом.Как пример, когда мы пользуемся поиском на компе, по имени файла, то размер начинки файла ведь не играет роли. Получается выигрываем мы когда только смотрим именно сархивированные топики. А апач при этом то не будет кушать ресурсов настолько же больше, насколько мы экономим на SQL'e?(Думаю что конечно будет круче, но хотелось бы уточнить =) Всё-таки вынос постов из БД и свои минусы имеет.. Есть же форумы работающие вобще без БД. А не пользуются ими.. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
l-k Опубликовано 20 Ноября 2007 Жалоба Поделиться Опубликовано 20 Ноября 2007 Согласна с PALADIN+. Этот мод ускоряет только поиск (за счет ухудшения его работы - ведь по "сброшенным в файлы" записям уже не поищешь). Немного ускоряет вставку и удаление записей в ibf_posts за счет того, что полнотекстовый индекс становится меньше (если он есть), а значит, быстрее обновляется. Немного ускоряет обработку страницы за счет того, что меньше текста надо парсить, но это компенсируется возросшей нагрузкой на апач или что там у нас. Т.к. количество записей в ibf_posts после архивации остается прежним, то все остальные операции не ускоряются - с чего бы? Важно количество записей в таблице. А сколько текста при этом хранится в полях типа "text" - неважно. Все индексы, кроме полнотекстового, остаются прежними. Ну, еще и бэкап становится меньше. Вот еще один плюс. Других не вижу. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
FatCat Опубликовано 20 Ноября 2007 Автор Жалоба Поделиться Опубликовано 20 Ноября 2007 Получается выигрываем мы когда только смотрим именно сархивированные топики.Наоборот: выигрыш происходит, когда мы смотрим все топики, и прежде всего неархивированные. Таблица 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 сек. Скоро опять буду подрезать. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
l-k Опубликовано 20 Ноября 2007 Жалоба Поделиться Опубликовано 20 Ноября 2007 (изменено) Да ну.. что значит "считывает с диска"? Это же индексный файл. Он сканируется в поисках нужного индекса, далее - нужного блока. Если поставить key buffer size достаточно большим, то все необходимые индексы будут в памяти, и правильно построенные (т.е. использующие индексы) запросы будут очень быстрыми. Я, правда, не знаю, как там на shared хостингах живется - может ли пользователь там настраивать mysql (нельзя, наверно). Там наверняка своя специфика. У меня ipb 2.0, ibf_posts раз в 20 больше, общее время запросов при просмотре страницы темы - 0.02 сек. А вот сама страница формируется по 0.2-0.5 сек. Изменено 20 Ноября 2007 пользователем l-k Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
GiV Опубликовано 21 Ноября 2007 Жалоба Поделиться Опубликовано 21 Ноября 2007 А апач при этом то не будет кушать ресурсов настолько же больше, насколько мы экономим на SQL'e?Не вопрос, вешаем фронтэнд для балансировки и отдаем через него всю статику. Т.к. количество записей в ibf_posts после архивации остается прежним, то все остальные операции не ускоряются - с чего бы?Ну почему, если используете полнотекстовый индекс, то очень даже облегчит его перестроение ) Уменьшится индекс - MySQL будет жрать меньше памяти, будет жрать меньше памяти будет легче работать (и вероятно когото спасет от вываливания в своп ака оверхеад =)) Таблица ibf_posts - это кроме всего прочего и файл ibf_posts.MYI в файловой системе компьютера.Ты открываешь страницу топика, и майэскуэль начинает читать файл ibf_posts.MYI с диска. Время считывания файла прямо пропорционально его размеру.Грамотно настроенный MySQL не должен дергать индексы с диска при каждом использования той или иной таблицы =) Слушайте l-k, она дело говорит. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
l-k Опубликовано 21 Ноября 2007 Жалоба Поделиться Опубликовано 21 Ноября 2007 Ну почему, если используете полнотекстовый индекс, то очень даже облегчит его перестроение а я про это упомянула. "Все остальные операции" = "не использующие полнотекстовый индекс". В общем, вся эта тема на самом деле - про недостатки fulltext индекса и FatCat придумал очень нетрадиционный метод борьбы с этими недостатками В клиентском разделе есть интересная тема про отказ от fulltext индекса и замену его на sphinx (это стороняя search engine для mysql). Вот это - радикальное решение! К сожалению, у меня сисадмин бездельник и не желает ничего нового устанавливать, пока и так все работает И, опять-таки, это не для shared хостинга. Еще хочу добавить, что в качестве "решения для бедных", когда настроить mysql нет возможности, этот мод, наверно, может принести пользу... А если у вас свой сервер - то лучше не надо. Хотя я бы скорее отказалась от полнотекстового поиска, запретила бы поиск по всему форуму, оставила бы только внутри тем (чтобы искать в них через LIKE), и внутри подфорумов (если не слишком тормозить будет), а по всему форуму пусть через google ищут. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Song Опубликовано 22 Ноября 2007 Жалоба Поделиться Опубликовано 22 Ноября 2007 Т.к. количество записей в ibf_posts после архивации остается прежним, то все остальные операции не ускоряются - с чего бы? Важно количество записей в таблице. А сколько текста при этом хранится в полях типа "text" - неважно. Все индексы, кроме полнотекстового, остаются прежними.База MySQL - это грубо говоря сборище файлов (как и любая БД впрочем), и каждый запрос к базе - это оптимизированный специальным образом доступ к файлам этой базы данных.Как ты думаешь, если файл станет меньше по размеру в n раз скорость его обработки не уменьшится? Это же индексный файл. Он сканируется в поисках нужного индекса, далее - нужного блока.Правильно. Ключевая фраза "в поисках нужного блока" после того как блок станет известным из индекса.Поиск блока - это открытие файла с данными и перешагивание к нужному сегменту.Эта операция выполняетя тем быстрей, чем меньшн размер файла с данными. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
GiV Опубликовано 22 Ноября 2007 Жалоба Поделиться Опубликовано 22 Ноября 2007 Поиск блока - это открытие файла с данными и перешагивание к нужному сегменту.В случае поиска по LIKE видимо (LIKE abc% использyет обычный индекс. LIKE %abc не использyет никакого индекса так как префикс может быть любым!). В случае работы с ключами aka индексами - работает с индексным файлом. Так вот в процессе "сархивирования" тем форума, индексы не меняются. Они как были так и остаются. Другими словами таблица в MySQL представлена тремя файламиMYI - индексMYD - данныеfrm - структура В индексе особым образом хранятся значения ключей. В данных - собственно все что есть в таблице. Теперь ближе к IP.B. Таблица постов не имеет индекса по полю post (за исключением FULLTEXT). Следовательно изменение данных в post в процессе "сархивирования" не приводит к изменению индекса, а лишь к изменению в данных. Итого получаем уменьшение MYD, при старом MYI. При любой работе с pid или датой сообщения, мы имеем дело с индексами, т.е. с MYI. Подводя общий итог: В общем, вся эта тема на самом деле - про недостатки fulltext индекса и FatCat придумал очень нетрадиционный метод борьбы с этими недостатками Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Рекомендуемые сообщения
Присоединиться к обсуждению
Вы можете ответить сейчас, а зарегистрироваться позже. Если у вас уже есть аккаунт, войдите, чтобы ответить от своего имени.