Выделение загрузок в отдельную таблицу

[movies]

По умолчанию информация о загруженных файлах хранится в ibf_posts. Оптимально ли это?

Большую часть на моем форуме составляют сообщения без присоединений (95%), и поэтому поля attach_ - пустые

Как вы думаете, может, стоит выделить присоединения в некую ibf_uploads?

[Sannis]

Вы можете сделать копию таблицы, удалить в ней столбцы аттачей и попробовать сделать несколько запросов, подобных запросам форума. Если разница в скорости будет колоссальна, может быть и стоит. Только не нужно забывать, что тогда вам нужно будет каким-то другим образом получать прикреплённые файлы, а значит будет ещё один запрос, хоть и легковесный. Имхо, учитывая размер поля post, эти колонки особой погоды не делают.

[movies]

значит будет ещё один запрос, хоть и легковесный

Можно ведь использовать Left Join

 

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

Спасибо за мнение

[Sannis]

Можно ведь использовать Left Join

В чём тогда, по вашему, получится ускорение? Записи из ibf_posts всегда выбираются по условию на индексированное поле, а значит размер самой таблицы не должен заметно на это влиять. Плюс join будет отнимать дополнительное время.

 

P.S. Это идеальная картина, может отличаться в зависимости от настроек сервера и проставленных индексов. Посмотрим что скажут более знающие люди

[Song]

Как вы думаете, может, стоит выделить присоединения в некую ibf_uploads?

Стоит, конечно.

Заодно появится возможность добавлять к посту не одно вложение, а сколько угодно.

[movies]

Стоит

Спасибо

[Sannis]

Как вы думаете, может, стоит выделить присоединения в некую ibf_uploads?

Стоит, конечно.

Заодно появится возможность добавлять к посту не одно вложение, а сколько угодно.

Song, расскажи заодно, почему Кроме как для мода мультиаттача.

 

Multiattach: http://www.ibresource.ru/forums/index.php?showtopic=36569.

[Song]

Есть такая штука - нормализация.

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

[Sannis]

Есть такая штука - нормализация.

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

Само собой Но заметно оптимальнее(с точки зрения скорости/нагрузки) это в данном случае не будет, я правильно понимаю?

[xRay]

Нормализация решает

[GiV]

Но заметно оптимальнее(с точки зрения скорости/нагрузки) это в данном случае не будет, я правильно понимаю?

оптимальнее будет занимаемое таблицей место на диске. А скорость конечно будет зависеть от конечного селекта по данной базе.

[Sannis]

Но заметно оптимальнее(с точки зрения скорости/нагрузки) это в данном случае не будет, я правильно понимаю?

оптимальнее будет занимаемое таблицей место на диске. А скорость конечно будет зависеть от конечного селекта по данной базе.

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

[Arhar]

оптимальнее будет занимаемое таблицей место на диске. ...

Слууууушай....

а если организовать для постов несколько таблиц

одна - ibf_posts_main, будет содержать все то же, что и сейчас, кроме поста, вместо него - номер таблицы и ид записи, в которой текст

а другие - ibf_posts_1 , ibf_posts_2 и т.д. - посты

 

хотя яваскрипт FatCat'а лучше, но сама идея то...

[Song]

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

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

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

 

одна - ibf_posts_main, будет содержать все то же, что и сейчас, кроме поста, вместо него - номер таблицы и ид записи, в которой текст

а другие - ibf_posts_1 , ibf_posts_2 и т.д. - посты

мошшшно..

Там даже есть тип таблиц такой - MERGE

 

но ИМХО одно и то же.

[Sannis]

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

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

Song, я не настолько глупый, не надейся А ТС наверняка захочет поставить мультиаттач, так что выбора у него не будет.

[FatCat]

[хотя яваскрипт FatCat'а лучше, но сама идея то...

Сейчас еще лучше сделано:

В functions.php добавил 2 функции:

	function extract_archived_post($pid, $j_type)
{
	global $ibforums;

	$arc_path = ($pid-$pid%1000)/1000;
	$arc_path = $ibforums->vars['base_dir']."arc/".$arc_path."/";
	$arc_file = $pid%1000;
	$arc_file = $arc_path.$arc_file.".".$j_type;
	if(is_writeable( $arc_file ))
	{
		@ob_start();
		include( $arc_file );
		$archived_post = @ob_get_contents();
		@ob_end_clean();
	}
	else
	{
		$archived_post = "";
	}
	return $archived_post;
}

function create_archived_post($pid, $j_type, $txt)
{
	global $ibforums;

	$arc_path = ($pid-$pid%1000)/1000;
	$arc_path = $arc_path = $ibforums->vars['base_dir']."arc/".$arc_path."/";
	$arc_file = $pid%1000;
	$arc_file = $arc_path.$arc_file.".".$j_type;
	if(file_exists($arc_file))unlink($arc_file);
	if($txt != "")
	{
		if(!file_exists($arc_path))mkdir($arc_path, 0777);
		$fh = fopen($arc_file, "w");
		fwrite($fh, $txt);
		fclose($fh);
	}
}

 

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

 

Во всех файлах, где посты пишутся в базу, добавлена конструкция:

if(strlen($this->post['post']) > 4000)
{
$std->create_archived_post($this->post['pid'], "arc", $this->post['post']);
$this->post['post'] = " ";
}

 

Во всех файлах, где посты читаются, добавлена конструкция:

if ( strlen($out['post']) < 3 )$out['post'] = $std->extract_archived_post($out['pid'], "arc");

 

 

Во всех файлах, где посты удаляются, добавлена конструкция:

$std->create_archived_post($post['pid'], "arc", "");

 

 

 

Таким образом, средний размер таблицы ibf_posts составляет меньше 1 Мб на каждую 1000 сообщений.

 

 

Аналогично сделано для журналов.

В итоге имеем 200 000 сообщений, общий вес БД 80 Мб; и почти 100 Мб в файлах.

[movies]

Для выделения аттачей в отдельную таблицу пришлось перелопатить довольно много кода - Topics.php, Moderate.php, Post.php, lib/pos_*.php, misc/attach.php.

Но, это еще не конец...

[FatCat]

Навскидку, что помню:

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

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

Если не ошибаюсь, в sources/lib ТРИ файла работают с аттачами: для нового топика, для нового сообщения и для редактирования сообщения.

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

[Song]

Song, я не настолько глупый, не надейся

О, я это и не говорил!

[Sannis]

Song, я не настолько глупый, не надейся

О, я это и не говорил!

Если не сложно, скажи сколько у тебя сейчас записей в posts и сколько всего/уникальных_по_посту записей в таблице аттачей, я тогда промоделирую и удовлетворю своё любопытство относительно экономии места.

[Song]

145400/4233

[Sannis]

Спасибо

[movies]

использовать Left Join

Вот я и поиспользовал

Столкнулся с ошибкой: The SELECT would examine more rows than MAX_JOIN_SIZE.

[Song]

Такого быть не может.

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

[Sannis]

Запрос покажите, вопросы пропадут

[movies]

просто перевели в другую таблицу

 

Я джойню еще третью таблицу. Она хранит оценки пользователей, выставленные приложениям. Если пользователь уже выставил оценку, она отобразится.

 

Выходит, в Topics.php к имеющимся

			FROM	ibf_posts p
			LEFT JOIN ibf_members m ON (p.author_id=m.id)
				LEFT JOIN ibf_groups g ON (g.g_id=m.mgroup)

добавляется

				LEFT JOIN ibf_uploads u ON (u.pid=p.pid)
				LEFT JOIN ibf_upl_vote v ON ( (v.upl_id=u.upl_id) AND (v.member_id = '".$ibforums->member['id']."') )