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

Страниц (13): В начало « ... 5 6 7 8 9 10 [11] 12 13 »

> Найдено сообщений: 186
Flat Отправлено: 3 августа 2018 — 09:09 • Тема: ExBB 2.0.0-Pre • Форум: Релизы

Ответов: 138
Просмотров: 81219
Flat пишет:
Смотрим на число и сразу находим нужную строку

Кстати, так именно реализовано в yabb.
Flat Отправлено: 31 июля 2018 — 10:37 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

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

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

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

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

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

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

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

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

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

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

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

Тоже интересное предложение. Например в тех же ссылках могут быть символы-разделители, что неприемлемо. Поэтому вы правы, если имеем многомерную структуру, то её лучше загнать в поле в json или каком-либо другом общепринятом виде, например csv или сериализовать.
Flat Отправлено: 27 июля 2018 — 15:02 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 37868
При редактировании сообщения сдвигаем "хвост" и вставляем текст.
Flat Отправлено: 27 июля 2018 — 14:27 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

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

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

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

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

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

По первому варианту.
Тут возможно следующее: если имеем несколько записей одного пользователя, а новый не совпадает со старым, то придётся как-то сдвинуть или расширить остаток базы.
Второй вариант более предпочтителен. Ведь удаляем мы сообщения или юзеров не часто, поэтому не важен небольшой оверхэд при сдвиге элементов. Если сдвигать по одной записи, то это и безопасно, ибо если на сервере произойдёт сбой, то мы, по крайней мере, потеряем единственную запись. Если же сдвинуть остаток целиком, то мы потеряем этот остаток. Сдвиг даже большого числа записей происходит за приемлемое время. Тем более, что обычно удаляются новые юзеры или относительно новые сообщения, которые находятся в конце(внизу) базы. Поэтому эта операция довольно быстра.
Правда в этом варианте номера удалённых пользователей больше не используются..
Flat Отправлено: 27 июля 2018 — 13:31 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 37868
1Bot пишет:
Для текстовых данных это едва ли возможно без чрезмерных затрат места.

Я продумал и это.
Например каким образом добавлять в базу сообщения пользователя, которые имеют разную длину? Или в базе пользователей есть к примеру поле "о себе". Ведь они могут быть разной длины. Выделять жёстко заданное количество байт под поле? Не вариант, так как это ограничит длину текста, и к тому же, приведёт к потерям дискового пространства если длина текста небольшая.
Решение очень простое: создаём так называемые расширенные поля записей. Например имеем основную запись с сообщением пользователя:

123|01|igor|Привет, это текст моего сообщения

Первое число это id пользователя, затем идёт поле количества записей(об этом ниже) имя и сам текст. Если текст не влезает в отведённое ограниченное поле, то создаём дополнительную запись такого вида:

123|02|igor|Привет, это текст моего сообщения
123|c|,которое вы сейчас читаете.

Второе поле "с" означает, что расширяется поле сообщения. В первой записи цифра 02 теперь указывает на то, что запись состоит из двух записей под одним и тем же id.
Если остается неиспользуемое место, то оно заполняется пробелами.
Таким образом мы полностью уходим от проблемы потери места. Максимум потеряем несколько лишних десятков байтов. Также теперь возможны сообщения любой длины.
Flat Отправлено: 27 июля 2018 — 12:14 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 37868
1Bot пишет:
Что сказать, сами придумываем велосипеды, которые уже давно ездят в существующих СУБД.

Спасибо за инфо, это многим будет интересно. Я знаком с реляционными базами данных, так как читал соответствующую литературу, также немного знаю язык sql запросов.
Тут надо понять, что универсальные решения зачастую становятся не эффективны, когда применяются в специфических приложениях с ограниченным функционалом, который можно описать своим компактным языком.
Существующие СУБД это универсальные решения, со своим большим языком описаний на все случаи жизни. Большие проекты требуют мощных баз. К сожалению, такая универсализация приводит к отрицательным результатам, особенно что касается политики безопасности. Чем мощнее язык, тем больше в нём дыр. Чем компактней язык, чем больше он заточен на цель, тем меньше в нём лазеек.
Теперь про эффективность.
Я в курсе про индексацию. Знаю по крайней мере две попытки создания файловой базы данных прямой выборки. Это база некоего youROCK https://habr.com/post/70140/
в которой он применил поиск по б-деревьям. Б-деревья довольно сложная штука. На пыхе их можно реализовать но код превратится в абсолютно нечитаемую галиматью. Я ознакомился с кодом. Он пользуется специальными индексными файлами, что усложняет движок. он писал, что перевёл свой форум с sql на свою базу и не заметил потерь в скорости.
Также существует подобная база cms Rumba. Там тоже индексные файлы. Я нашёл простое решение, которое позволяет отказаться от индексных файлов. Вот в чём дело. Это намного упрощает базу и работу с ней без потерь эффективности.
1Bot пишет:
Приведу для сравнения примеры выборок из таблицы СУБД mysql c 2 242 208 записями (общим размером 2 ГБ), где каждая запись состоит из 47 полей
1Bot , что-то не впечатляет. Всё в районе 1 сек крутится. Так дело не пойдёт! Бинарный поиск сработает в десятки раз быстрее, хотя в базе 2 гига, хоть в 10 гигов. Это же бинарный поиск, который никому никогда не переплюнуть, программеры, которые в курсах, меня поймут.
1Bot пишет:
Просто попробуйте выполнить похожие операции на файлах прямого доступа для сравнения затрат времени

К сожалению, сейчас не смогу создать подобную базу и произвести сравнение,так как сначала нужны API для работы с моей базой, да и саму базу надо эмулировать. Потом, когда сделаю достаточно функций, проверим обязательно на огромных базах, чтобы ни у кого не осталось никаких сомнений в том, что наша доморощенная может не просто конкурировать на равных с мускульными, но и в некоторых моментах и превосходить их.
По делам текущим.
Вчера доработал функцию бинарного поиска и сделал обёрточную функцию. Так что дело идёт полным ходом, Следите за новостями)))
Flat Отправлено: 26 июля 2018 — 10:27 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 37868
NordWest пишет:
Вы можете пояснить, что такое "текстовая база на прямом доступе"?

Сейчас популярно обьясню))
Например имеем такую базу данных, в которой каждая строка это одна запись, а отдельные поля записи отделены каким-либо редко используемым знаком. Зачастую для этой цели используется знак |(вертикальная черта):
0000001| admin|password|ad@kuku.com|ad
0000002| masha|password|gg@zuzu.com|me
0000003|grisha|password|ff@bubu.com|me
и т.д
Естественно, что вертикальную черту в текстах необходимо заменить на html сущности.
Каждое поле имеет определённую длину, которая прописана в скрипте, а общая длина записи постоянна.
Чтобы получить отдельную запись или отдельное поле при прямом доступе, ненужно качать всю базу в память, а необходимо, просто напросто, подвести считывающую головку(виртуальную, ибо сейчас уже используют твёрдотельные накопители) непосредственно к записи и считать её в память. Делается это очень просто. Вчера написал функцию, которая ищет в такой базе отдельную запись и считывает какое-то её поле. Эта функция не предназначена для форумного движка, это просто тестовая функция. Она ищет по принципу прямого перебора(а не бинарного поиска) элементов, используя принцип прямого доступа:
CODE:
function find($fl, $val, $field, $fieldLen)
{
$Len=156;
$numFields=100000;
if(!($f = fopen($fl, "rb")))die();
flock ($f,LOCK_SH);
$buf='';
for($s=0; $s<$numFields; ++$s)
{
fseek($f, $s*$Len+$field, SEEK_SET);
$buf=fread($f, $fieldLen);
if(strcmp($buf, $val)==0)
{
flock ($f,LOCK_UN);
fclose($f);
return true;
}
}
flock ($f,LOCK_UN);
fclose($f);
return false;
}

Проверял скорость на прямом переборе потому, что это будет необходимо при удалении и редактировании записей. Создал базу из записей по 156 байтов, записей 100 000, вес базы 15 мегабайт с лишним. Так вот, скорость поиска последнего элемента такой базы составила 0,2 секунды. База в 1 миллион записей будет иметь скорость 2 сек. Это в 2 раза меньше, чем качать всю базу в память посредством функции file, а потом разбивать её при помощи explode.
Затем протестировал бинарный поиск по такой базе, при помощи моей функции бинарного поиска:
CODE:
function DbFindRecord($fl, $login, $recordLen, $numRecords)
{
global $dbLastFind;
if(!($f = fopen($fl, "rb")))die();
flock ($f,LOCK_SH);
$low = 0; $mid=0; $midval=''; $ind=0; $c=0;
$high = $numRecords-1;
while($low <= $high)
{
$mid = (int)($low + (($high - $low) / 2));
$ind = (int)($mid*$recordLen);
fseek($f, $ind, SEEK_SET);
$midVal = fread( $f, 2);
$c=strcmp($midVal, $login);
if ( $c < 0)
{$low = $mid + 1;}
else if ($c > 0)
{$high = $mid - 1;}
else
{
flock ($f,LOCK_UN);
fclose($f);
$dbLastFind=$ind;
return $ind;
}
}
$dbLastFind=$ind;
flock ($f,LOCK_UN);
fclose($f);
return -1;
}

, и оказалось , что скорость увеличилась где-то в 500 раз.. То есть не 0,2 сек., а 0,2/500 = тут сами подсчитайте на калькуляторе сколько это будет: просто один миг.. То есть поиск по миллионной базе займёт доли секунды..
Эта функция тоже тестовая и будет переделана.
Guyver пишет:
Надеюсь, у Flat не пропадёт интузиазм и в итоге он не слиняет, как предшествующие товарищи ;о)

Интузиазм не пропадёт. Будем надеяться, что всё будет хорошо. Что не отключат электроэнергию, или интернет, или с компом вся будет в порядке, да и со здоровьем.))
Flat Отправлено: 25 июля 2018 — 13:01 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 37868
NordWest пишет:
Делитесь - будем пробовать внедрять.

Пока нечем делится, вот в чём дело. Есть функция бинарного поиска по такой базе. Работает, ну, если не сказать быстро, то ничего не сказать: ураган. Бинарный поиск нужен при упорядоченной по какому либо признаку записей базы, а не по индексу. Если по индексу, то сложно реализовать удаление записей. Есть понимание как это должно работать без излишних сложностей. Сейчас занимаюсь дополнительным тестированием некоторых моментов. Затем сразу приступаю к созданию первого модуля - db, по работе с базой. Придётся полностью отдать себя работе, иначе ничего не выйдет.
Почему я бросил эту идею с базой такого вида:
'id' => 1,
'name' => 'admin', и т.д.
Сравнил с базой такого вида:
1|admin
и получилось, что в среднем перерасход памяти вылетает в 2-5 раз. Вот не понимаю, зачем держать весь этот мусор в базе? База должна иметь только то, что должна, ничего лишнего. Если у вас хостинг резиновый и денег куры не клюют, то можно оставить всё как есть, но что-то мне подсказывает, что цены тоже не стоят на месте, и лучше иметь компактную базу, которую легко бэкапить, чем постоянно таскать с собой воз ненужного мусора.
Такую базу можно править в ручном режиме. Правда пользуясь при этом некоторыми соглашениями. Чтобы база работала быстро длина записей выбрана постоянной. Для хранения сообщений пользователей записи клонируются под таким же id, это позволит не перерасходовать в пустую дисковое пространство. Потом покажу код.
Flat Отправлено: 24 июля 2018 — 10:25 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 37868
Чем больше знакомлюсь с кодом, тем больше возникает вопросов. Особенно что касается основы основ - работы с базой данных.
В коде используются велосипеды, которые давно решены штатными средствами.
Структуры массивов-таблиц непродуманны.
Юрий предлагал сделать текстовую базу на прямом доступе. Это позволило бы иметь форум, который не тормозил бы и при миллионе пользователей, причём без всяких "мускулов". Однако он предлагал этот вариант на платной основе, видимо хотел так заработать. Зарабатывать надо на модах и услугах пользователям, а не продавая готовый двиг, который всё равно отпиратят.
У меня есть наработки по такой базе.
Кто-то может сказать: зачем это, если есть sqlite? Скажу: сейчас модуль sqlite работает только через драйвер pdo, таким образом полностью "кинуты" те пользователи, кои хотят сидеть на процедурщине. Дискриминация на лицо, а что будет дальше..
Далее, представьте себе ситуацию, когда на сервере происходит сбой а ваша база повреждена. "Вылечить" базу sqlite трудно даже продвинутым программерам, а обычным юзверям вообще не под силу, ибо она не текстовая а бинарная со многими зависимостями..
Так что не вариант.
Нужна текстовая база прямого доступа.
Flat Отправлено: 22 июля 2018 — 10:28 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 37868
Или вместо конфигурационных файлов в каждом модуле, ввести некий общий реестр всех модулей в системе, некую общую память системы по аналогии с конфигом форума. Это позволит избавится от многочисленных инклюдов. Core-модуль загружает реестр, а все остальные модули пользуются общим реестром. Это как в операционной системе, где есть свой общий реестр - общая память системы. Форумный движок по сути и есть операционная система в миниатюре. Должно быть микроядро и компоненты вокруг него, а также реестр. Больше по сути ничего не нужно. Каждый модуль работает с другими через общий реестр и интерфейс, который предоставляет каждый модуль..

Страниц (13): В начало « ... 5 6 7 8 9 10 [11] 12 13 »

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

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

[Script Execution time: 0.0627]     [ ]