ExBB Community ExBB Community
 Сайт проекта ExBB Общение объединяет!
Войдите на форум при помощиВойти через loginza
 Чат на форуме      Помощь      Поиск      Пользователи     BanList BanList


 Страниц (6): « 1 2 [3] 4 5 6 »   

> Описание: Тема для систематизации списка необходимых доработок и неисправленных багов ExBB
1Bot
Отправлено: 27 июля 2018 — 13:47
Post Id



Пользователь
Super Member


Покинул форум
Сообщений всего: 773
Дата рег-ции: Апр. 2009  
Откуда: Днепропетровск
Репутация: 69




Flat ,
С записями одинаковой структуры это замечательно. Есть вопрос как хранить структуры с переменным числом полей, наподобие ассоциативных массивов?

Еще вопрос - как редактировать/удалять записи из такой структуры?

(Отредактировано автором: 27 июля 2018 — 13:49)

 
 
Flat
Отправлено: 27 июля 2018 — 14:27
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




1Bot пишет:
Есть вопрос как хранить структуры с переменным числом полей, наподобие ассоциативных массивов?

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

123|1|igor|ссылка1&ссылка2&ссылка3&ссылка4|следующее поле

Здесь четвёртое поле представляет из себя массив каких-то, например, ссылок, которые разделены другим, отличным от | знаком, в данном случае &. Парсить это очень легко. Если массив превышает определённую длину, то расширяем его вышеописанным образом.
Так что, возможен любой вариант.
1Bot пишет:
Еще вопрос - как редактировать/удалять записи из такой структуры?

На данный момент вот такие соображения.
Например имеем базу с пользователями. Если надо удалить пользователя из базы, то возможны три варианта:
1) Если в каждой записи сделать дополнительное поле удалён/неудалён, то при удалении пользователя просто помечаем "удалён", а следующего зарегеного пользователя помещаем на место удалённого и присваеваем ему тот же номер.
2)Последовательно сдвигаем остаток базы с затиранием этой записи. Следующего зарегеного добавляем в конец базы.
3) Ничего не делаем(не удаляем физически).

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

(Отредактировано автором: 27 июля 2018 — 14:28)

 
 
Flat
Отправлено: 27 июля 2018 — 15:02
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




При редактировании сообщения сдвигаем "хвост" и вставляем текст.
 
 
1Bot
Отправлено: 27 июля 2018 — 15:27
Post Id



Пользователь
Super Member


Покинул форум
Сообщений всего: 773
Дата рег-ции: Апр. 2009  
Откуда: Днепропетровск
Репутация: 69




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

Реальную очистку производить по запросу VACUUM (в СУБД так и происходит).

При редактировании записи с текстом, если длина не увеличилась, то перезаписать на то же место, если увеличилась, то пометить текущую запись как удаленную и записать новую запись в конец файла.
Если это последняя запись в файле, то также переписываем.

Произвольную структуру в записи можно хранить в виде текста (использовать сериализацию или json).

(Отредактировано автором: 27 июля 2018 — 15:32)

 
 
Flat
Отправлено: 28 июля 2018 — 10:30
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




1Bot пишет:
Удаленные записи/части записей лучше помечать как удаленные, фактически оставляя удаленные блоки без изменений.

Согласен. Всё же, частый сдвиг - небезопасен.
1Bot пишет:
Реальную очистку производить по запросу VACUUM (в СУБД так и происходит).

Да, правильно. По необходимости вакуумируем через определённые промежутки времени. Если база большая, а лимит работы скрипта на сервере небольшой, то можно программно растянуть процесс вакуумирования, то есть при каждом новом запросе вакуумируем по частям.
1Bot пишет:
При редактировании записи с текстом, если длина не увеличилась, то перезаписать на то же место

Правильно. Один ум хорошо, а два лучше. Даже если после редактирования сообщения текст уменьшится, то оставляем как есть, ничего не сдвигая. Это правильное решение, спасибо что навели. Базу лучше не трогать, пусть себе лежит, как лежит.
1Bot пишет:
если увеличилась, то пометить текущую запись как удаленную и записать новую запись в конец файла.
Если это последняя запись в файле, то также переписываем.

Такс, а тут уже проблемы.. Ведь наша база, как предполагается должна быть упорядочена, например по id сообщения, то есть в конце будут самые последние сообщения, так мы их и выводим. Если записать отредактированное сообщение в конец файла, то порушится принцип упорядочености, и уже будет неприменим бинарный(двоичный) поиск по такой базе, то есть пропадёт основное её преимущество. В этом случае придётся применить некий принцип, который кстати используется при работе с файловыми системами и в базах данных.
Часть, которая влезает в редактируемое сообщение мы помещаем на место старого, а остаток, который не влезает, добавляем в конец файла, в запись, в которой в первом поле, где находится номер сообщения, записываем признак, того, что эта запись является продолжением другой записи, которая, в свою очередь, находится в другом месте, то есть, что данная запись разрывна. Например добавляем букву r в начало поля id:
r123|igor|привед медвед, это сообщение.
По букве r мы поймём, что это продолжение записи под номером 123 и не будем учитывать её при поиске по базе.
В первой же записи придётся записать индекс записи продолжения, для чего выделить своё поле. Такое поле будет и в записи продолжения, по которому мы поймём где искать дальнейшее продолжение. Это как в файловой системе, например такая система была в DOS. Да и в cqlite вроде используется.
Такая система несколько более сложная, однако позволит избавится о частого сдвига элементов.
1Bot пишет:
Произвольную структуру в записи можно хранить в виде текста (использовать сериализацию или json).

Тоже интересное предложение. Например в тех же ссылках могут быть символы-разделители, что неприемлемо. Поэтому вы правы, если имеем многомерную структуру, то её лучше загнать в поле в json или каком-либо другом общепринятом виде, например csv или сериализовать.

(Отредактировано автором: 28 июля 2018 — 10:33)

 
 
Flat
Отправлено: 28 июля 2018 — 12:34
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




Хочу обратить внимание ещё на один момент.
Система, которая используется в нынешнем exbb тоже имеет право на жизнь потому, что использует упрощённую иерархическую модель баз данных. А как известно иерархии очень эффективны что касается непосредственного доступа и лёгкости изменения, тем более, что данная модель поддерживается аппаратурой на низком уровне - это файловая система. Так что смысла полностью отказываться от данной модели нет. Просто она нуждается в переделке. Например: в данном движке одна папка, в которой находятся все файлы с юзерами. Известно, что файловая система начинает тормозить примерно от 1000 файлов в одной папке. Значит нельзя пихать туда большее их количество. Если следовать принципу иерархии, то имеет смысл разбить пользователей по разным папкам. В одной папке будут все пользователи на букву a, в другой на b и так далее. В этом случае тормозов не будет и при количестве пользователей несколько сотен тысяч. Или идёт разбивка по номерам пользователей: в одной папке все номера до 1000, в следующей от 1001 до 2000 и т.д.
Файлы с темами тоже имеет смысл разбить на отдельные страницы. Тогда редактирование сообщений будет относительно элементарной и быстрой операцией..

(Отредактировано автором: 28 июля 2018 — 12:36)

 
 
Flat
Отправлено: 28 июля 2018 — 13:48
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




К тому же, память файлам выделяется страницами. Обычная страница 4 килобайта. Если файл будет иметь размер например 250 байт, то истинный размер файла на диске всё равно будет 4 килобайта. Поэтому маленькие файлы не выгодны. Если наша база будет весить 100 мегабайт, то на диске она будет иметь 400 мегабайт, на лицо явный перерасход памяти(и денег). Однако именно такие файлы лежат в папке members.. Чтобы этого избежать необходимо в один файл записывать информацию о хотя бы 4-х пользователях..
Или использовать такую схему: оставить одну папку members, но файлы иметь по например 100 пользователей. Такой файл целиком качается в память и разбивается в массив очень быстро. Если файлов будет 1000, то пользователей будет 100000. Этого с лихвой достаточно для любого форума.

(Отредактировано автором: 28 июля 2018 — 13:54)

 
 
Flat
Отправлено: 29 июля 2018 — 01:58
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




Итак, вот что я решил..
Делать вменяемую СУБД возможно, но на это уйдёт куча времени, да и база будет недружелюбна к простым пользователям, ибо сообщения будут разбиваться на куски, которые к тому же будут валяться в разных местах файла.. Просто есть уже cqlite, зачем изобретать велосипеды.. Таким образом мы уходим от в общем-то здравой концепции exbb, которой необходимо придерживаться, иначе это уже будет совершенно другой форум..
Итак, оставляем концепцию формата хранения типа:
123|1|igor|следующее поле
То есть без сериализации. Это сохранит нам много нервов и дискового пространства.
Далее, в папке members в каждом файле сохраняем по 100 пользователей. Это даст нам постоянную высокую(ибо файл то небольшой) скорость загрузки даже при большом числе пользователей(несколько сот тысяч), а также избегаем потери дискового пространства из-за страничной организации памяти в современных ОС.
Также это обеспечит нам простой механизм изменение полей записей. К тому же это позволит нам иметь базу, в которой АБСОЛЮТНО(до самого последнего символа) отсутствует лишнее пространство. Если сообщение имеет определённую длину, то оно будет иметь ту же длину в файле, при этом ничего делить не потребуется, сообщение будет цельное, а также легко редактируемое.
Вчера написал функцию, проверки есть ли такой пользователь в базе или нет имея в виду новый формат файловой организации. Извините, если кому внушил ложные надежды, но мне нужен форум, который устраивал бы лично меня, а там уж кому нужно будет использовать мои наработки или подключится к его развитию.

(Отредактировано автором: 29 июля 2018 — 02:01)

 
 
Flat
Отправлено: 30 июля 2018 — 08:29
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




Чувствую, последнее предложение ни у кого энтузиазма не вызывает..
Хорошо, - оставляем структуру папки members, как сейчас, то есть один файл на пользователя, но структуру записи делаем такую:
return array('id'=>1 ,'name'=>2,'pass'=>'21232f297a57a5a743894a0e4a801fc3');
Об этом я писал выше. Как видно здесь я избавился от лишних пробелов и переводов строки, которые оставляет функция var_export. Пусть занимает столько же места что и сериализация, однако место и так пропадает, и выделяется по сути с запасом на страницу памяти, так что ничего страшного. Зато легко сохранять многомерные структуры и база легко читаема и изменяема вручную. Не будем революционизировать движок. оставим концепцию в сохранности. Так будет легче конвертировать. Изменим общую структуру движка, сделав её более модульной. На том и порешили?
Написал новую более продвинутую функцию удаления непустой директории, а также функцию добавления в базу и функцию чтения из базы, которые позволяют уйти от проблемы обнуления. Юрий говорил, что проблема снята, однако судя по старым функциям проблема осталась на прежнем месте.

(Отредактировано автором: 30 июля 2018 — 08:30)

 
 
Yamaliya
Отправлено: 30 июля 2018 — 15:06
Post Id



Пользователь
Super Member


Покинул форум
Сообщений всего: 662
Дата рег-ции: Авг. 2012  
Откуда: Ямал
Репутация: 20




Flat , вот и правильно. Численность даже самых крупных форумов на exBB не превышает первых тысяч. И это при том, что очистка от неактивных пользователей далеко не на всех форумах делается.
 
 
Flat
Отправлено: 31 июля 2018 — 10:37
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




Yamaliya пишет:
вот и правильно. Численность даже самых крупных форумов на exBB не превышает первых тысяч.

Спасибо, что откликнулись, Yamaliya .
Да, так я и сам подумал. Зачем городить огород. Если нужен форум под миллион пользователей, то лучше выбрать воблу(вбюллетин)) или любой форум на mysql. Форум до ~50 000 пользователей может с успехом работать и на подобном этому движке.
Всё, нужно включаться в работу, поэтому писать буду только по делу, по делам текущим.

(Отредактировано автором: 31 июля 2018 — 10:39)

 
 
1Bot
Отправлено: 15 августа 2018 — 15:51
Post Id



Пользователь
Super Member


Покинул форум
Сообщений всего: 773
Дата рег-ции: Апр. 2009  
Откуда: Днепропетровск
Репутация: 69




Flat, как Ваши успехи с файлами прямого доступа?
 
 
Flat
Отправлено: 16 августа 2018 — 10:53
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




1Bot пишет:
как Ваши успехи с файлами прямого доступа?

Постом выше я писал:
Цитата:
Чувствую, последнее предложение ни у кого энтузиазма не вызывает..

Однако идею не оставил. Похоже, что надо будет предусмотреть оба варианта: один на файлах прямого доступа, а другой традиционный подход - один файл-один пользователь. Соблазн велик, что ни говори.. Да это и правильно так сделать, одним словом: по-компьютерному, так как и должно быть.. Но сейчас я был занят авторизацией. Авторизация практически готова. Та что в движке, меня не устраивает. Там идёт раздельная обработка разных состояний, в зависимости от включённости кук у пользователя, наличия "старой" сессии или "новой" и т.п. Головной модуль, через который подключаются другие, тоже практически готов.
Сейчас сделаю основные модули, типа: авторизация, входа/выхода с форума, регистрации, а затем всё остальное.
Знакомясь с кодом движка exbb некоторые вещи вызывают недоумение. Например, в файле fm.class.php есть функция _CheckBannedIP(). В ней есть такая строчка:
CODE:
$banneddata = array_filter($this->_Read(FM_BANNEDIP),"Banned");

Функция array_filter вторым параметром принимает имя collback функции, которая вызывается на каждом элементе массива. Здесь указана функция "Banned", однако ни в одном файле движка я её так и не нашёл.. Выходит что IP не проверяется? Вэб-мастер может быть подскажет что тут не так. Вроде везде искал, в том числе и в новом 2.0 движке..
Далее, в файле common.php дублируется код
дубляж (Отобразить)

Что касается файлов прямого доступа.
Будет такой вариант, который подходит для больших форумов с огромным числом пользователей. Всё это реализовать несложно.

(Отредактировано автором: 16 августа 2018 — 10:59)

 
 
NordWest
Отправлено: 16 августа 2018 — 20:43
Post Id



Пользователь
Super Member


Покинул форум
Сообщений всего: 994
Дата рег-ции: Дек. 2011  
Откуда: Северо-Запад
Репутация: 76




В файле lib.php есть функция
CODE:
function Banned($n)
{
global $fm;
return (preg_match("#^".$n['regexp']."$#",$fm->_IP));
}
 
 
Flat
Отправлено: 17 августа 2018 — 10:23
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




NordWest пишет:
В файле lib.php есть функция

Про lib.php я и забыл.. Извиняюсь.
 
 
Страниц (6): « 1 2 [3] 4 5 6 »
Сейчас эту тему просматривают: 1 (гостей: 1, зарегистрированных: 0)
« Обсуждаем »

> Похожие темы: Доработки и исправления в ExBB
Темы Форум Информация о теме Обновление
Как вставить рекламу
на ExBB FM RC 1.0
Общие вопросы Ответов: 18
Автор темы: SmexotvoriN
10 февраля 2014 — 17:14
Автор: Zeg
Подфорумы
Имеется ли реально работающий мод «Подфорумы» для Exbb.FM.RC1
Обсуждение Ответов: 3
Автор темы: fdg
16 ноября 2009 — 07:03
Автор: fdg
Перспективы дальнейшего развития
Отказ от ExBB FM 1.0 и переход на ExBB FM 1.1 и ExBB 2.0
Новости Ответов: 217
Автор темы: yura3d
24 июля 2012 — 16:59
Автор: electron
Мод: Портал
Простая портальная система на основе ExBB
Модификации и дополнения Ответов: 29
Автор темы: igrok54
22 мая 2014 — 08:41
Автор: GreatALF
Мод: Похожие темы
Совместимость: ExBB FM 1.0 (версии: RC1, RC2 )
Модификации и дополнения Ответов: 37
Автор темы: Иван Петров
8 сентября 2012 — 14:27
Автор: wasp
 



Все гости форума могут просматривать этот раздел.
Только администраторы и модераторы могут создавать новые темы в этом разделе.
Только администраторы и модераторы могут отвечать на сообщения в этом разделе.
 




Яндекс.Метрика   

Powered by ExBB
ExBB FM 1.0 RC1 by TvoyWeb.ru
InvisionExBB Style converted by Markus®

[Script Execution time: 0.1023]     [ ]