Языком по умолчанию в данном форуме является русский. Имеются также украинская и английская локализации.
Немаловажно, что движок ExBB является полностью бесплатным. Он распространяется по лицензии GNU GPL.
История
История форума ExBB началась летом 2003 года. Его первая версия была выпущена 10 августа. Начиная с версии 1.9.1, которая вышла в мае 2004 года, автор прекратил работу над форумом. Эстафету разработки ExBB приняла команда сайта TvoyWeb.
В июле 2007 года вышел ExBB FM 1.0 Beta. От предыдущих версий его отличало применение концепции объектно-ориентированного программирования. Со временем в движок вносились значительные изменения, позволившие сделать ExBB более быстрым и безопасным.
Со временем TvoyWeb перестал заниматься разработкой новых версий. Поэтому в феврале 2009 года открылся новый официальный сайт проекта — ExBB.org. 10 февраля, спустя полтора года после выхода бета-версии, состоялся релиз ExBB FM 1.0 RC1.
29 марта 2011 года вышла сборка ExBB FM 1.0 RC1.01. Она представляет собой релиз ExBB FM 1.0 RC1, в который были добавлены все критические обновления, а также несколько модов.
В 2012 году сайт сменил адрес на ExBB.info. 1 мая вышла сборка ExBB FM 1.0 Final. Для ее работы требуется PHP версии 5.3.
На сегодняшний день последней версией форума является ExBB 1.1. Релиз состоялся 27 июля 2016 года. Данная версия была создана на основе сборки ExBB FM 1.0 Final. Ее главная особенность — поддержка новых версий PHP, начиная от 5.4 и заканчивая 7.0. Если версия PHP 5.3 и ниже, то форум установить не удастся.
4 августа 2016 года состоялся предварительный релиз ExBB 2.0.0. Для работы этого форума требуется интерпретатор PHP версии не ниже 5.5. Основными отличиями данной версии являются кодировка UTF-8, новая структура данных форума, а также новый установщик.
Обзор форума
Для обзора была выбрана версия ExBB FM 1.0 RC1.01 как наиболее стабильная и проверенная временем.
Установка форума производится с помощью пошагового инсталлятора, как у большинства современных движков. В ходе установки задаются такие параметры как название и описание форума, создается учетная запись администратора.
После установки можно приступать к созданию категорий и форумов. В каждом форуме можно создавать подфорумы. Для форумов и подфорумов можно назначать модераторов.
Внешне форум практически неотличим от Invision Power Board 1.3. Разве что иконки форумов без надписи «IPB». Это базовый стиль форума под названием InvisionExBB. Помимо него, на сайте ExBB можно скачать еще более 2-х десятков скинов от разных авторов.
У ExBB присутствуют все стандартные функции, свойственные популярным табличным форумам: возможность создавать темы и опросы, прикреплять файлы, просматривать список «Кто в on-line?», имеется система личных сообщений. Редактируя профиль, пользователи могут выбирать аватары из списка стандартных или загружать собственные.
Стоит отметить большую подборку смайлов, поделенную на категории: «Радость», «Злость, негодование», «Праздники», «Значки и таблички», «Я такой!» и т.д. Всего в стандартную установку форума входит около 200 смайликов-колобков в стиле IPB.
Также имеется возможность поиска по форуму. Поисковая система основана на движке «RiSearch PHP».
Форум предоставляет достаточно широкие возможности для модерирования. Так, помимо стандартных функций редактирования и удаления сообщений имеется возможность прикрепления сообщений в теме. Такие сообщения, вне зависимости от их даты написания, будут находиться вверху темы.
Модератор может делить тему на части или переносить сообщения из одной темы в другую. Однако первое сообщение темы переместить нельзя, поэтому полное объединение тем невозможно.
Управление форумом производится через центр администрирования. Внешне он напоминает административную панель phpBB.
Панель позволяет создавать и редактировать категории, форумы и подфорумы, редактировать различные настройки, добавлять и редактировать смайлики, управлять учетными записями пользователей.
Для обеспечения соблюдения пользователями порядка на форуме имеются такие функции, как автоматическая замена нецензурных слов, блокировка участников по IP-адресу.
Имеется возможность несколько расширить функциональность форума, используя модификации, представленные на сайте ExBB. Например, можно добавить чат, сделать тег для вставки спойлеров в сообщения и т.д.
Технические особенности
Как уже было сказано, все данные форум хранит в текстовых файлах. Но файлы эти не совсем обычные. Метод записи в файлы кардинально отличается от традиционного, с использованием разделителей (так хранят данные большинство форумных движков — например, UBB, YaBB, Ikonboard). ExBB превращает массивы в строку с использованием стандартной функции PHP serialize() и записывает ее в файл. Для преобразования сериализованной строки обратно в PHP-значение используется функция unserialize().
Благодаря своей простоте данный способ удобен с точки зрения разработчика движка. Однако решение создателя ExBB хранить данные в виде сериализированной строке менее удобно для администратора форума, поскольку не позволяет редактировать сохраненные данные в текстовом редакторе. Точнее, позволяет, но сделать это на порядок сложнее и требует большей квалификации от администратора.
Одним из преимуществ форума является то, что он не требует поддержки на хостинге функции конфигурирования веб-сервера посредством файлов .htaccess. При этом для безопасности хранения данных используется расширение .php, а вначале каждого файла перед сериализированной строкой записывается код <?die;?>, прерывающий вывод содержимого в браузер.
Для каждого форума создается отдельная папка вида forum1, forum2 и т.д. В папку записываются все темы, содержащиеся в данном форуме: 1-thd.php, 2-thd.php и т.д. Помимо этого, для каждого опроса создается дополнительный файл: например, для темы 3-thd.php будет создан 3-poll.php. Если в данной теме содержатся вложения, то сведения о них будут записываться в файл attaches-3.php, сами же вложения хранятся в папке uploads. Список тем в форуме находится в файле list.php. Количество просмотров тем записывается в отдельный файл views.php.
Учетные записи пользователей хранятся в папке members. Для каждого участника создаются файлы типа 1.php, 2.php и т.д., в которые записываются данные его профиля. Стоит отметить, что пароль пользователя хранится зашифрованным с использованием функции md5(). Благодаря этому даже администратор не может узнать, какие пароли используют пользователи на его форуме.
Серьезным недостатком ExBB является поддержка разными версиями форумов только строго определенных версий PHP. Например, ExBB FM 1.0 Final требует, чтобы на хостинге был установлен PHP версии 5.3, ExBB 1.1 — от 5.4 до 7.0, а ExBB 2.0.0 — не ниже 5.5. Отсутствие в новых версиях форума поддержки старых версий PHP создает неудобства для клиентов виртуального хостинга, не имеющих возможность установить необходимую версию PHP и, таким образом, вынужденных использовать на своих сайтах старые версии ExBB.
Распространенность
Стоит признать, что ExBB не может похвастаться большой популярностью. Так, согласно «Рейтингу форумов Рунета, Уанета и Байнета», его не использует ни один русскоязычный форум с количеством сообщений более 1 миллиона сообщений, украиноязычный с количеством сообщений более 50 тысяч или беларускоязычный с количеством сообщений более 2 тысяч.
Крупнейшими на сегодняшний день форумами, базирующимися на ExBB, являются:
- Военно-исторический форум (368 тыс. сообщений);
- Форумы портала PHP.SU (278 тыс. сообщений);
- ТвойWeb (59 тыс. сообщений);
- Jeep Garage.ru Forum (56 тыс. сообщений);
- Мурманский форум Арктиксити (41 тыс. сообщений);
- ExBB Community (31 тыс. сообщений).
Заключение
Функционал данного движка, конечно, несравним с ведущим программным обеспечением форумов — платными Invision, vBulletin, XenForo, и даже бесплатными phpBB и SMF. Но не стоит забывать, что данные движки требуют наличия на хостинге MySQL, а ExBB достаточно лишь поддержки PHP.
Есть еще достаточно функциональный форум на файлах, для которого также продолжается разработка новых версий — это YaBB (Yet another Bulletin Board). Но в отличие от ExBB он написан не на PHP, а на Perl.
Среди PHP-форумов на файлах у ExBB, пожалуй, нет конкурентов. И в этом его фишка.
Комментарии (63)
alexey-m-ukolov
18.01.2017 13:49+8Такой движок отлично подойдет для использования на бесплатных или недорогих платных хостингах, поддерживающих PHP, но не предоставляющих доступ к БД MySQL.
Кто-нибудь может поделиться ссылкой на такой хостинг?
4 августа 2016 года состоялся предварительный релиз ExBB 2.0.0. Для работы этого форума требуется интерпретатор PHP версии не ниже 5.5. Основными отличиями данной версии являются кодировка UTF-8, новая структура данных форума, а также новый установщик.
Но БД при этом не прикрутили? Я понимаю, чем это было вызвано в 2003 году, но сейчас делать новую мажорную версию (с поддержкой php 7) и не использовать БД — это очень и очень странное решение.
Среди PHP-форумов на файлах у ExBB, пожалуй, нет конкурентов. И в этом его фишка.
В области газового освещения улиц конкуренция тоже не особо активная. С чем бы это могло быть связано?
T-362
18.01.2017 14:05+1Не смотря на всю экстравагантность и неоднозначность подхода (с иронией говоря — да, вокруг 2017, кому нужен форум, да еще и на php, да еще и без базы данных, давайте лучше запилим новый js фреймворк) я, например, вообще не понимаю зачем прикручивать к принципиально безбазовому форуму работу с базами данных, будто так мало форумов работающих с базами.
Вот что было бы действительно интересно так реализовать работу с файловым хранилищем данных используя интерфейсы и несколько классов с разными реализациями (в фаил, в мемкеш, сериализацией, json, xml, base64 итд итп).
SerafimArts
18.01.2017 14:10Вот что было бы действительно интересно так реализовать работу с файловым хранилищем данных используя интерфейсы и несколько классов с разными реализациями (в фаил, в мемкеш, сериализацией, json, xml, base64 итд итп).
Flysystem для слабаков? Да и как бы Sqlite — это та же файловая система с поддержкой SQL синтаксиса.
SerafimArts
18.01.2017 14:28Upd. Немного не понял предложения по интерфейсу. Если разные драйвера (мемкеш, файл, что угодно), то Flysуstem, если разный способ хранения (сериализация, json, xml и проч), то зачем?
T-362
18.01.2017 14:33Flysystem конкретно нацеленно на работу с файлами, в идеале нужно сильнее абстрагироваться от файловой системы что-бы класс работы с ней сам реализовывал логику создания/удаления/обновления/сортировки по папкам. Но в принципе эту штуку можно юзать и добавить класс-обертку только с реализацией логики.
mwambanatanga
18.01.2017 14:36Да и как бы Sqlite — это та же файловая система с поддержкой SQL синтаксиса.
Автор не осилил sqlite: https://github.com/ExBBWeb/ExBB/issues/9
Bal
18.01.2017 15:28Не видел структуру файлов ExBB, но есть области, где sqlite не заменит чистые файлы. Скажем, если нужна синхронизация данных между нодами. SQLite тут мгновенно породит конфликт модификаций. Из популярных систем так в ZeroNet сделано. Там синхронизация данных идёт на уровне JSON-файлов. Правда, потом их контент грузится в локальный SQLite для ускорения и упрощения работы :)
alexey-m-ukolov
18.01.2017 14:22Если это интеллектуальное упражнение, то да, согласен. Но если это позиционируется как некий продукт, то принципиальность выглядит странно.
T-362
18.01.2017 14:38По жизни вообще очень большая инерция у технологий — тут лучше что-бы был, но не пригодился, чем понадобился но такого нет. Где-то тут был таг эзотерическое программирование — он бы сюда подошел.
а на самом деле...Я бы такой форум попробовал бы на какойнить ардуине развернуть для локального использования при необходимости, что-бы меньше процессов хвостом тащить.
bromzh
18.01.2017 14:14+2Стоит отметить, что пароль пользователя хранится зашифрованным с использованием функции md5()
Инновации. Скоро перейдут на нормальные хэш-функции и изобретут соль. Безопасность (как гласит картинка на сайте) тут вообще на уровне:
$_SESSION['iden'] = md5($user['name'].$user['pass']._SESSION_ID); #... и чуть ниже $fm->_setcookie('exbbp',md5($user['pass']));
Ну и конечно, то знаменитое пхпешное кодосмешение:
while (false !== ($file = $d->read())) { if (is_dir($styledir.'/'.$file) && $file != '.' && $file != '..') { $selected = ($file == strtolower(DEF_SKIN)) ? ' selected="selected"' : ''; $style_select .= '<option value="' . trim($file) . '"' . $selected . '>' . $file . '</option>'; } } # И так почти в каждом файле
На десерт, исходники в zip с кодировкой KOI8-R. Enjoy.
bromzh
18.01.2017 14:20+4Блин, самое вкусное-то:
# register.php $user['pass'] = $fm->input['password']; # А потом в 1-й ветке if есть такое $user['pass'] = md5($user['pass']); # А чуть ниже, в другой ветке if есть такое же $user['pass'] = md5($user['pass']);
Ну а потом уже
$fm->_setcookie('exbbp',md5($user['pass']));. Потому что двойной md5 в 2 раза безопаснее.
muxa_ru
18.01.2017 14:14+1Не мне Вас осуждать ( https://habrahabr.ru/post/312344/ ), но в 2017 году указывать как преимущество «работает на хостингах без СУБД» это странно.
Это и правда сейчас актуально?
Я прямо сейчас сделал поиск бесплатных хостингов с php и везде пишут про mysql.
jrip
18.01.2017 14:34+2В целом то преимущество не в возможности запускать там где Mysql нету, плюс в том, что его, например, можно тупо копированием перенести. Как показывает практика, для людей далеких от всякого технического без базы жить проще, да хотя бы из бекапа того же восстановиться.
bromzh
18.01.2017 15:03Это всё хорошо, если проект уровня личного бложека. Добавить аутентефикацию через соцсети, и можно даже многопользовательский блог/форум намутить. Комменты можно прикрутить через какой-нибудь disqus/vk/fb. На сервере в таком случае будут хранится только сами посты, никаких паролей и персональных данных. При желании, и комменты тоже можно хранить, вот только на этом моменте начинаются проблемы с консистентностью и актуальностью данных. Можно написать свой велосипед, как и сделал автор — написал некий корявый аналог СУБД, где очень много завязано на структуру ФС и имена файлов с папками.
А можно просто взять sqlite, если так уж хочется файлов и простоты переноса, оно хотя бы ACID-compliant.
azsx
18.01.2017 16:12Пока мне были нужны такие форумы я использовал wr-форум, который кстати по слухам более 1000 постов единовременно не потянул, а поломался. Сейчас мне и лучше не надо, но любопытно другое.
Почему современный тренд все данные сажать на БД? Какие недостатки файловой системы настолько велики, что Вы готовы юзать всё, только через базу?
Также интересно, Вы понимаете, что запросы к базе данных загрузят систему намного сильнее, чем чтение одного файла, в котором лежит сразу вся тема?lubezniy
18.01.2017 16:49+1Смотря какого размера тема и сколько пользователей одновременно к ней обращаются. И что с индексированием и поиском?
azsx
18.01.2017 17:18Смотря какого размера тема и сколько пользователей одновременно к ней обращаются. И что с индексированием и поиском?
https://habrahabr.ru/post/319232/ — 485 комментариев, 472 кб. Круто! Но в БД эти комментарии будут занимать намного больше места. А полмегабайта считаются в php одним кускокм и не заметит даже.
В файловой системе также есть кеширование, Скорость отдачи hdd винчестера около 150 мбайт в секунду, в то же время мы говорим о недорогих хостингах, там канал в 20 мбит в секунду уже редкость.
С поиском всё просто, на недорогом тарифе только google search обеспечит адекватный поиск.lubezniy
19.01.2017 10:57Когда тем (и соответственно файлов) будет хотя бы под сотню тысяч, тогда и посмотреть бы, сколько времени будет занимать выдача списка тем (правильно я понимаю, что это представляет собой список файлов в каталоге?). А 500 комментов — это ни о чём; по отдельным вопросам я видел темы и на 2-3 тысячи.
azsx
19.01.2017 11:09Когда тем (и соответственно файлов) будет хотя бы под сотню тысяч
https://habrahabr.ru/post/319836/#comment_10021438
А 500 комментов — это ни о чём; по отдельным вопросам я видел темы и на 2-3 тысячи.
472 кб. * 3 Круто! Но в БД эти комментарии будут занимать намного больше места. А полмегабайта *3 считаются в php одним куском и не заметит даже.
Ну и как бы корректнее сказать. Если к моим страницам будут писать по 1500 комментариев, то отличия в хостинге за 50 рублей и за 5000 рублей особо волновать меня не будут.
muxa_ru
18.01.2017 16:52> Вы понимаете, что запросы к базе данных загрузят систему намного сильнее, чем чтение одного файла, в котором лежит сразу вся тема?
Это если есть только один режим просмотра темы.
А есть ведь ещё сортировка. Есть разбиение на страницы. Есть просмотр отдельных постингов.azsx
18.01.2017 17:27Это если есть только один режим просмотра темы.
А есть ведь ещё сортировка. Есть разбиение на страницы. Есть просмотр отдельных постингов.
Сортировка — отдельный файл для разделов, который перезаписывается. Оптимально в сайдбар новые и комментируемые топики, по разделам сортировка по дате создания топика. Пагинация — префикс к имени файла. Отдельный пост — читаем всю страницу с темой и показываем только нужный пост.
Проблема не в том, что кое без чего можно обойтись. Трудность в другом, а в БД вы какие запросы напишите? Насколько Ваш запрос показа отдельного топика или группы топиков будет грузить хостинг? Меньше, чем чтение файла?bromzh
18.01.2017 17:47Сортировка — отдельный файл для разделов, который перезаписывается.
Это как? Вася сортирует посты по дате создания, а Петя — по кол-ву комментариев. Что, куда и как вы предлагаете записывать?
T-362
18.01.2017 17:58Если файлы копируют древо то проблем нет, сортировка по обновлениям тем —
$files = glob(); usort($files, function($a, $b) { return filemtime($a) < filemtime($b); });
По количеству постов примерно то-же самое только считаем содержимое папки, если 1 пост 1 файл.
Если 1 тема 1 фаил можно юзать грязный хак храня мета-фаил где номер строки — айди темы и строка содержит обзор информации. Потом элементарно, прочли в массив, usort. В качестве дальнейших грязных хаков — содержимое можно кешировать в память.
Правда я не особо упомню классических bb которые давали прямо так сортировать темы по количеству постов, или — не вспомню что-бы кто-то когда-то таким функционалом пользовался.muxa_ru
18.01.2017 21:13Если файлы копируют древо то проблем нет, сортировка по обновлениям тем
Дана тема в которой 11 постингов.
Разбиение по 10 постингов на странице.
Сколько файлов Вам понадобится что бы дать пользователям возможность сортировать её:
— сначала самые старые постинги
— сначала самые новые постинги
— сначала постинги с самым большим количеством «лайков»azsx
19.01.2017 02:31muxa_ru не удержался, могу ошибаться, поэтому предложу решение, вдруг ошибку укажете.
Для таких сортировок понадобится 1 файл. Допустим, url топика — это число (типа site.ru/forum/30.html). Тогда в один файл пишу url, date, like — 4 + 8 + 2 = 14 байт. 1 мбайт / 14 байт = 74900 записей. 74900 / 365 в среднем каждый день по 205 новых записей. Для многих интернет тематик — это очень много!
Так как у меня такой задачи не было, технически я её не решал (кода нет). Но в принципе решение верно?
ps
Вы не знаете пример форума (блога), который хостится на хостинге до 500 рублей в месяц, использует БД и имеет сортировки не только по новым постам, но и по старым постам и лайкам? Как бы в БД вы решили проблему с нагрузкой при обработке 80К записей? Индексами в оперативной памяти?muxa_ru
19.01.2017 12:1680 тысяч на хостинге за 500 рублей — прямо сейчас не вспомню.
30 тысяч на хостинге за 300 рублей — есть. Работает на голом форумном движке без каких либо дополнительных телодвижений. Там функционал как положено, с блэкджеком и шлюхами.
И если что, то я включу файловый кэш.
Скорость отдачи у меня будет даже больше чем в обсуждаемом решении, при той же управляемости и функционале.azsx
19.01.2017 12:34Отлично, значит Ваше решение лучше. Только никак не понимаю, почему у Вас скорость отдачи будет выше?
ps
1. пример просил так как интересно было число хитов оценить образно;
2. Я снимаю vds за 150 рублей в месяц только потому, что мне отдают 20 гб за эти деньги. А по процессору в среднем трачу 1-2%, БД нет совсем, памяти 512 мб даже свап не включаю (место экономлю). Сайт на этом хостинге не один, но число хитов не большое. На шареде есть и лучше тарифы.muxa_ru
19.01.2017 16:26Только никак не понимаю, почему у Вас скорость отдачи будет выше?
Потому что в кэше, как правило, хранят уже готовый html-код и не нужно тратить ресурсы на его формирование.
azsx
18.01.2017 18:01-2Петру не повезло.
Я понял, что сила sql в выборках (раньше тоже догадывался) и все выборки не в sql виде от лукавого.
Просто я достаточно часто делаю сайты на html (до нескольких сотен тысяч страниц, с пагинацией и выборками) и всегда интересовался зачем для комментариев нужна БД. Теперь, благодаря Вашим ответам, знаю. Спор на пустом месте мне не нужен.bromzh
18.01.2017 19:07+1Не только. Сильной стороной многих реляционных СУБД является реализация требований ACID. Если в двух словах — это позволяет вам особо не заботиться о согласованности данных (при условии, что база спроектирована правильно), это делает сама СУБД.
В случае велосипеда с файлами даже при двух пользователях и нескольких сущностях (пост, коммент, юзер) могут возникать ошибки и неточности при записи и чтении данных. Чтобы этого избежать, приходится по-сути реализовывать эти самые принципы самому, что довольно сложно сделать сразу правильно. Так что возникает большая вероятность получить вместо осмысленных данных непонятный набор байт. А подключить БД и хранить всё там порой гораздо быстрее и проще.
TicSo
18.01.2017 18:58Подскажите, пожалуйста, какой/ие на Ваш взгляд, движок форума заслуживает внимания? В статье привели:
… с ведущим программным обеспечением форумов — платными Invision, vBulletin, XenForo, и даже бесплатными phpBB и SMF.
При потребности под нагрузку и функционал, есть что-то достойное среди бесплатных?
muxa_ru
18.01.2017 21:10отдельный файл для разделов, который перезаписывается
То есть, в момент добавления постинга нужно создать или перезаписать много маленьких файликов под разные типовые запросы.
В итоге база разбухает из-за дублирования, становится неуниверсальной и возникают проблемы с поддержанием её в рабочем состоянии.
Трудность в другом, а в БД вы какие запросы напишите? Насколько Ваш запрос показа отдельного топика или группы топиков будет грузить хостинг? Меньше, чем чтение файла?
Если будет грузить, то я файловый кэш создам.
Ровно тоже самое что предлагаете Вы, только у меня это будет вспомогательная система которую можно будет удалять и пересоздавать при необходимости, а у Вас — основная система хранения.azsx
19.01.2017 02:42Ровно тоже самое что предлагаете Вы, только у меня это будет вспомогательная система которую можно будет удалять и пересоздавать при необходимости, а у Вас — основная система хранения.
Задачи у нас разные! То есть Вы прекрасно все понимаете как это делать, так как почти все cms имеют режимы агрессивного кеширования. Придирки к деталям. Например, у меня нет задач, по которым мне надо пересоздать все комментарии.muxa_ru
19.01.2017 12:18Я прекрасно понимаю что задачи бывают разные, потому я и поинтересовался действительно ли аргумент «дешёвый хостинг без mysql» настолько актуален что бы выносить его как главный аргумент.
bromzh
18.01.2017 17:45+3Почему современный тренд все данные сажать на БД?
Какие недостатки файловой системы настолько велики, что Вы готовы юзать всё, только через базу?Как при таком способе хранения мне найти все посты/комменты конкретного пользователя? Как найти все посты с тегом "python"? Как реализовать автоинкремент id постов и комментов? Как при удалении пользователя удалить и все его посты?
Пускай мне нужны комменты, как на хабре (в виде дерева). Как будет выглядеть добавление коммента к комменту и как потом будет выглядеть редактирование комментов в таком дереве? А если в короткий промежуток времени очень много людей внесут изменения в комменты, как обеспечить корректность запись данных?azsx
18.01.2017 18:13bromzh, извините, я не пишу форумов на файлах, у меня есть только комментарии к html страницам. По этой причине пояснять как я сделал или гадать как я мог бы сделать, если бы мне это понадобилось я не буду. могу отметить, что многие Ваши запросы хорошо так загрузят БД на хостинге за 50 рублей в месяц.
А если в короткий промежуток времени очень много людей внесут изменения в комменты, как обеспечить корректность запись данных?
Важный для меня вопрос, на который я не знаю ответа. Например, случилось счастье, у меня ежесекундно в один файл комментария добавляют по 10 новых сообщений. Я начинаю плясать и петь от счастья (шутка).
Извините, отвлёкся. Итак на тему напал хрумер или хуман, который в несколько десятков потоков пишет новый комментарий. Как я уже писал, по слухам даже wr-форум от такого падал и ломал текстовой файл. У меня такой проблемы нет, так как я провожу перед записью комментария множество проверок, чтобы роскомнадзор не банил, ресурсы закончатся раньше, чем будет самих записей. Тем не менее, всегда интересно.
Сколько потоков данных может записываться в один текстовой файл? Как избежать проблем при большом потоке комментариев? И есть ли вообще такая проблема или слухи всё?bromzh
18.01.2017 19:42Сколько потоков данных может записываться в один текстовой файл?
Одновременно — один. Если пишем в файл сами, то можно запросы на запись кидать в MessageQueue, оборачивая их в транзакции.
muxa_ru
19.01.2017 12:21могу отметить, что многие Ваши запросы хорошо так загрузят БД на хостинге за 50 рублей в месяц
А можно узнать о каком именно хостинге идёт речь? (я понял что это описка и имеется ввиду 500 рублей)
Очень похоже, что Вам просто попался кривой хостинг и Вы его кривизну проецируете на всю отрасль.azsx
19.01.2017 12:47Это не описка, рекламировать такие хостинги смысла не вижу, google «хостинг за 50 рублей».
Ориентируюсь сейчас на vds за 150 рублей, так как там 30 гб в https://habrahabr.ru/post/319836/#comment_10022060 не верно написал. Проценты нагрузки верные.
Но у меня нет форумов на файлах, у меня блоговая структура с комментариями на файлах. Тем не менее на 50 рублевых тарифах я работал.muxa_ru
19.01.2017 16:29у меня блоговая структура с комментариями на файлах
После установки на вордпресс кэширующих плагинов, скорость отдачи страницы почти сравнивается со скоростью отдачи статики. Ибо, по сути, это и есть отдача статики (за исключением тех случаев когда происходит формирование кэша)azsx
19.01.2017 18:19Потому что в кэше, как правило, хранят уже готовый html-код и не нужно тратить ресурсы на его формирование.
Ибо, по сути, это и есть отдача статики (за исключением тех случаев когда происходит формирование кэша)Отвечу на оба комментария сразу :)
Во первых, мы крутимся по кругу. Если идёт спор, пожалуйста, уточните предмет спора.
Вам нужен сайт на WP, который на хостинге от 300 рублей и выше при агрессивном кешировании бодрячком держится? Пожалуйста! Мне нужны сайты, которые в совокупности при нескольких сотнях тысяч (миллионах в мечтах) хитов в сутки не грузят ресурсы по процессору практически совсем и по дисковой подсистеме один в один. Тогда я упираюсь только в каналы. Напомню, я снимаю за 150 рублей 30 гбайт на одном из vds и использую 2% от процессора и реально считаю, сколько я прочитал данных с файла (кстати, что файл внешний открыл также считаю) и сколько в мир отдал по каналу.
Ваша логика железная, сперва на вопрос почему вы используете БД всегда, к месту и не к месту Вы пишите про 21 век, а теперь рассказываете, что если включить кеширование и почти не обращаться к БД, то можно значительно ускорить сайт на WP. При этом по моему мнению адекватно соперничать со мной по скорости вы сможете только включив кеширующий прокси перед сайтом, но явно не плагином!
Вдумайтесь, я не использую кеш совсем, то есть любой динамический контент (комментарии) я могу позволить загружать каждый раз при чтении страницы.
Есть недостатки в моих сайтах? Конечно, например, я не делаю сайтов более 200 тысяч страниц, так как с тегами, пагинацией и прочим хламом страниц становится безумно много. Я стараюсь не держать в каждом разделе (каталоге) слишком много страниц. И так далее.
Если мне нужна БД, то я её использую. Только мне БД нужна для сервисов, а вовсе не для html'ов.muxa_ru
19.01.2017 19:46уточните предмет спора.
Предмета спора нет, я ни в чём ни хочу Вас убедить.
Ваша логика железная, сперва на вопрос почему вы используете БД всегда, к месту и не к месту Вы пишите про 21 век, а теперь рассказываете, что если включить кеширование и почти не обращаться к БД, то можно значительно ускорить сайт на WP.
Да именно это я и пишу:
— информация хранится в СУБД обеспечивающей её целостность и гибкий универсальный интерфейс доступа
— формируется файловый кэш в виде готовых html-файлов
— посетителям отдаются html-файлы
Таким образом, у мен есть двухступенчатый механизм, где на первом этапе гибкая но прожорливая машинка служащая для управления контентом и формирования html, а на втором — негибкий но быстрый html-кэш.
Такая схема работы позволяет на первом этапе забить на быстродействие и реализовывать нужный мне функционал.
muxa_ru
19.01.2017 19:49Вам нужен сайт на WP, который на хостинге от 300 рублей и выше при агрессивном кешировании бодрячком держится?
Мне нужен сайт решающи мои задачи. WP, Bitrix, phpBB — пофиг.azsx
20.01.2017 02:23Мне нужен сайт решающи мои задачи. WP, Bitrix, phpBB — пофиг.
Раз спора нет, то вывод прежний. Вы (напомню, говорим о минимальной нагрузки на хостинги за 50-300 рублей) запускаете Bitrix, когда он решает ваши задачи. Вы умнее меня, я бы так не смог, Bitrix на хостинге за 50 рублей.
Моя задача иная, держать максимальное число хитов на заданных ресурсах. Некоторые другие задачи, которые прекрасно решаются в рамках html, css, js и точечными вставками php с чтением данных с файлов.
В результате я не буду ставить cms с БД, так как моих задач она не решает. Вам пофиг на мой метод, так как прежде всего вам нужен sql, которого у меня нет.
Будут те, кто форум на файлах поднимут, будут те, кто ipb купит. Мой вариант большого, посещаемого форума сейчас был бы иным.
Вкратце, я с Вами согласен. Во всём и сразу.
lubezniy
19.01.2017 12:26-1Автоинкремент, к слову, и с РСУБД может своих проблем насоздавать, если используется репликация.
oxidmod
19.01.2017 12:45например?
пробелмы если вы будете 2 бд сливать в одну, а какие с репликацией? ООlubezniy
19.01.2017 12:51Когда, например, какая-то вставка на slave по какой-то причине не пройдёт, и автоинкремент там собьётся.
oxidmod
19.01.2017 13:08вставки идут в мастер, а реплики используют для чтения.
lubezniy
19.01.2017 13:53В мастер вставку делает клиент. А затем на slave вставка идёт с мастера, чтобы клиенты могли что-то с реплики читать. И, если на slave вставка не пройдёт, могут начаться проблемы с консистентностью реплики.
oxidmod
19.01.2017 14:15+1это вопросто того как в конкретной субд реализована репликация, а не автоинкремента
lubezniy
19.01.2017 14:01И да. last_insert_id клиент также получает с мастера, прежде чем вставить данные в связанную таблицу. И, если на slave счётчик собьётся, может стать «весело».
Zhuravljov
22.01.2017 19:50+1Почему современный тренд все данные сажать на БД?
Почему вы так решили? В кастомных проектах под конкретного заказчика можно встретить целый зоопарк: что-то через СУБД, что-то в файлах, что-то в редис и т.д. Все зависит от уместности применения в том или ином случае.
А с точки зрения открытых CMS выбор очевиден. MySQL есть на каждом хостинге, и он по прежнему остается одним из самых удобных инструментом для хранения и выборки данных.
maxru
18.01.2017 18:21Шел 2017 год 21 века, самый дешевый VPS хостинг стоил чуть больше доллара в месяц, но ёжики продолжали есть кактус.
azsx
18.01.2017 18:54Ответ на Ваш вопрос:
1. Я встречал примеры, типа дедикейт за 5000 рублей в месяц, который контекст на сайте еле еле окупает. При этом на сайте всего несколько тысяч страниц и 50-70 тысяч хитов в сутки. К чему я, расскажите, сколько хитов вы удержите не свалившись на ipb в минуту на vds «чуть больше доллара»?
2. Shared — это хороший сервер, на котором Вам считают ресурсы заставляя переплачивать за перерасход (или морозят акк). vds — чаще просто ограничения. Плюсы у vds несомненно есть, минусов также хватает.
ps
баш на баш, теперь помогите мне https://habrahabr.ru/post/319836/#comment_10020702
alexey-m-ukolov
19.01.2017 07:52+1[придирки-тайм]Сейчас, совершенно определённо, не идёт две тысячи семнадцатый год двадцать первого века.[/придирки-тайм]
JhaoDa
19.01.2017 17:09Очень интересно, почему для скачивания надо регистрировать? У авторов какая-то неприязнь к гитхабу и прочим подобным сервисам?
alex6636
24.01.2017 19:17Уже давно даже на бесплатных хостингах есть mysql, а платный хостинг без неё это вообще нонсенс
Varim
Похоже на конкурс лучшей критики ExBB
johnfound
Использование MySQL, когда она есть, тоже не без проблем. Например часто на дешевых хостингах есть лимит на запросы в БД. И этот лимит часто небольшой. Например на мой хостинг это 100 000 запросов в час. Это выглядит очень много, но часто одно действие потребителя заканчивается десятками запросов в БД.
Но на количество файлов тоже есть лимит. Например у меня это 90000 файлов. И это ограничит размер форума ExBB до 90000 постов (или даже меньше).
Именно прикидывая все эти ограничения, в конце концов я написал свой движок форума на SQLite – файл только один, а лимит на запросов нет.