Комментарии 63
Использование MySQL, когда она есть, тоже не без проблем. Например часто на дешевых хостингах есть лимит на запросы в БД. И этот лимит часто небольшой. Например на мой хостинг это 100 000 запросов в час. Это выглядит очень много, но часто одно действие потребителя заканчивается десятками запросов в БД.
Но на количество файлов тоже есть лимит. Например у меня это 90000 файлов. И это ограничит размер форума ExBB до 90000 постов (или даже меньше).
Именно прикидывая все эти ограничения, в конце концов я написал свой движок форума на SQLite – файл только один, а лимит на запросов нет.
Такой движок отлично подойдет для использования на бесплатных или недорогих платных хостингах, поддерживающих PHP, но не предоставляющих доступ к БД MySQL.Кто-нибудь может поделиться ссылкой на такой хостинг?
4 августа 2016 года состоялся предварительный релиз ExBB 2.0.0. Для работы этого форума требуется интерпретатор PHP версии не ниже 5.5. Основными отличиями данной версии являются кодировка UTF-8, новая структура данных форума, а также новый установщик.Но БД при этом не прикрутили? Я понимаю, чем это было вызвано в 2003 году, но сейчас делать новую мажорную версию (с поддержкой php 7) и не использовать БД — это очень и очень странное решение.
Среди PHP-форумов на файлах у ExBB, пожалуй, нет конкурентов. И в этом его фишка.В области газового освещения улиц конкуренция тоже не особо активная. С чем бы это могло быть связано?
Вот что было бы действительно интересно так реализовать работу с файловым хранилищем данных используя интерфейсы и несколько классов с разными реализациями (в фаил, в мемкеш, сериализацией, json, xml, base64 итд итп).
Вот что было бы действительно интересно так реализовать работу с файловым хранилищем данных используя интерфейсы и несколько классов с разными реализациями (в фаил, в мемкеш, сериализацией, json, xml, base64 итд итп).
Flysystem для слабаков? Да и как бы Sqlite — это та же файловая система с поддержкой SQL синтаксиса.
Upd. Немного не понял предложения по интерфейсу. Если разные драйвера (мемкеш, файл, что угодно), то Flysуstem, если разный способ хранения (сериализация, json, xml и проч), то зачем?
Не видел структуру файлов ExBB, но есть области, где sqlite не заменит чистые файлы. Скажем, если нужна синхронизация данных между нодами. SQLite тут мгновенно породит конфликт модификаций. Из популярных систем так в ZeroNet сделано. Там синхронизация данных идёт на уровне JSON-файлов. Правда, потом их контент грузится в локальный SQLite для ускорения и упрощения работы :)
Стоит отметить, что пароль пользователя хранится зашифрованным с использованием функции 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.
Блин, самое вкусное-то:
# 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 раза безопаснее.
Это и правда сейчас актуально?
Я прямо сейчас сделал поиск бесплатных хостингов с php и везде пишут про mysql.
Это всё хорошо, если проект уровня личного бложека. Добавить аутентефикацию через соцсети, и можно даже многопользовательский блог/форум намутить. Комменты можно прикрутить через какой-нибудь disqus/vk/fb. На сервере в таком случае будут хранится только сами посты, никаких паролей и персональных данных. При желании, и комменты тоже можно хранить, вот только на этом моменте начинаются проблемы с консистентностью и актуальностью данных. Можно написать свой велосипед, как и сделал автор — написал некий корявый аналог СУБД, где очень много завязано на структуру ФС и имена файлов с папками.
А можно просто взять sqlite, если так уж хочется файлов и простоты переноса, оно хотя бы ACID-compliant.
del
Почему современный тренд все данные сажать на БД? Какие недостатки файловой системы настолько велики, что Вы готовы юзать всё, только через базу?
Также интересно, Вы понимаете, что запросы к базе данных загрузят систему намного сильнее, чем чтение одного файла, в котором лежит сразу вся тема?
Смотря какого размера тема и сколько пользователей одновременно к ней обращаются. И что с индексированием и поиском?
https://habrahabr.ru/post/319232/ — 485 комментариев, 472 кб. Круто! Но в БД эти комментарии будут занимать намного больше места. А полмегабайта считаются в php одним кускокм и не заметит даже.
В файловой системе также есть кеширование, Скорость отдачи hdd винчестера около 150 мбайт в секунду, в то же время мы говорим о недорогих хостингах, там канал в 20 мбит в секунду уже редкость.
С поиском всё просто, на недорогом тарифе только google search обеспечит адекватный поиск.
Когда тем (и соответственно файлов) будет хотя бы под сотню тысяч
https://habrahabr.ru/post/319836/#comment_10021438
А 500 комментов — это ни о чём; по отдельным вопросам я видел темы и на 2-3 тысячи.
472 кб. * 3 Круто! Но в БД эти комментарии будут занимать намного больше места. А полмегабайта *3 считаются в php одним куском и не заметит даже.
Ну и как бы корректнее сказать. Если к моим страницам будут писать по 1500 комментариев, то отличия в хостинге за 50 рублей и за 5000 рублей особо волновать меня не будут.
Это если есть только один режим просмотра темы.
А есть ведь ещё сортировка. Есть разбиение на страницы. Есть просмотр отдельных постингов.
Это если есть только один режим просмотра темы.
А есть ведь ещё сортировка. Есть разбиение на страницы. Есть просмотр отдельных постингов.
Сортировка — отдельный файл для разделов, который перезаписывается. Оптимально в сайдбар новые и комментируемые топики, по разделам сортировка по дате создания топика. Пагинация — префикс к имени файла. Отдельный пост — читаем всю страницу с темой и показываем только нужный пост.
Проблема не в том, что кое без чего можно обойтись. Трудность в другом, а в БД вы какие запросы напишите? Насколько Ваш запрос показа отдельного топика или группы топиков будет грузить хостинг? Меньше, чем чтение файла?
Сортировка — отдельный файл для разделов, который перезаписывается.
Это как? Вася сортирует посты по дате создания, а Петя — по кол-ву комментариев. Что, куда и как вы предлагаете записывать?
$files = glob();
usort($files, function($a, $b) {
return filemtime($a) < filemtime($b);
});
По количеству постов примерно то-же самое только считаем содержимое папки, если 1 пост 1 файл.
Если 1 тема 1 фаил можно юзать грязный хак храня мета-фаил где номер строки — айди темы и строка содержит обзор информации. Потом элементарно, прочли в массив, usort. В качестве дальнейших грязных хаков — содержимое можно кешировать в память.
Правда я не особо упомню классических bb которые давали прямо так сортировать темы по количеству постов, или — не вспомню что-бы кто-то когда-то таким функционалом пользовался.
Если файлы копируют древо то проблем нет, сортировка по обновлениям тем
Дана тема в которой 11 постингов.
Разбиение по 10 постингов на странице.
Сколько файлов Вам понадобится что бы дать пользователям возможность сортировать её:
— сначала самые старые постинги
— сначала самые новые постинги
— сначала постинги с самым большим количеством «лайков»
Для таких сортировок понадобится 1 файл. Допустим, url топика — это число (типа site.ru/forum/30.html). Тогда в один файл пишу url, date, like — 4 + 8 + 2 = 14 байт. 1 мбайт / 14 байт = 74900 записей. 74900 / 365 в среднем каждый день по 205 новых записей. Для многих интернет тематик — это очень много!
Так как у меня такой задачи не было, технически я её не решал (кода нет). Но в принципе решение верно?
ps
Вы не знаете пример форума (блога), который хостится на хостинге до 500 рублей в месяц, использует БД и имеет сортировки не только по новым постам, но и по старым постам и лайкам? Как бы в БД вы решили проблему с нагрузкой при обработке 80К записей? Индексами в оперативной памяти?
30 тысяч на хостинге за 300 рублей — есть. Работает на голом форумном движке без каких либо дополнительных телодвижений. Там функционал как положено, с блэкджеком и шлюхами.
И если что, то я включу файловый кэш.
Скорость отдачи у меня будет даже больше чем в обсуждаемом решении, при той же управляемости и функционале.
ps
1. пример просил так как интересно было число хитов оценить образно;
2. Я снимаю vds за 150 рублей в месяц только потому, что мне отдают 20 гб за эти деньги. А по процессору в среднем трачу 1-2%, БД нет совсем, памяти 512 мб даже свап не включаю (место экономлю). Сайт на этом хостинге не один, но число хитов не большое. На шареде есть и лучше тарифы.
Я понял, что сила sql в выборках (раньше тоже догадывался) и все выборки не в sql виде от лукавого.
Просто я достаточно часто делаю сайты на html (до нескольких сотен тысяч страниц, с пагинацией и выборками) и всегда интересовался зачем для комментариев нужна БД. Теперь, благодаря Вашим ответам, знаю. Спор на пустом месте мне не нужен.
Не только. Сильной стороной многих реляционных СУБД является реализация требований ACID. Если в двух словах — это позволяет вам особо не заботиться о согласованности данных (при условии, что база спроектирована правильно), это делает сама СУБД.
В случае велосипеда с файлами даже при двух пользователях и нескольких сущностях (пост, коммент, юзер) могут возникать ошибки и неточности при записи и чтении данных. Чтобы этого избежать, приходится по-сути реализовывать эти самые принципы самому, что довольно сложно сделать сразу правильно. Так что возникает большая вероятность получить вместо осмысленных данных непонятный набор байт. А подключить БД и хранить всё там порой гораздо быстрее и проще.
… с ведущим программным обеспечением форумов — платными Invision, vBulletin, XenForo, и даже бесплатными phpBB и SMF.
При потребности под нагрузку и функционал, есть что-то достойное среди бесплатных?
отдельный файл для разделов, который перезаписывается
То есть, в момент добавления постинга нужно создать или перезаписать много маленьких файликов под разные типовые запросы.
В итоге база разбухает из-за дублирования, становится неуниверсальной и возникают проблемы с поддержанием её в рабочем состоянии.
Трудность в другом, а в БД вы какие запросы напишите? Насколько Ваш запрос показа отдельного топика или группы топиков будет грузить хостинг? Меньше, чем чтение файла?
Если будет грузить, то я файловый кэш создам.
Ровно тоже самое что предлагаете Вы, только у меня это будет вспомогательная система которую можно будет удалять и пересоздавать при необходимости, а у Вас — основная система хранения.
Ровно тоже самое что предлагаете Вы, только у меня это будет вспомогательная система которую можно будет удалять и пересоздавать при необходимости, а у Вас — основная система хранения.
Задачи у нас разные! То есть Вы прекрасно все понимаете как это делать, так как почти все cms имеют режимы агрессивного кеширования. Придирки к деталям. Например, у меня нет задач, по которым мне надо пересоздать все комментарии.
Почему современный тренд все данные сажать на БД?
Какие недостатки файловой системы настолько велики, что Вы готовы юзать всё, только через базу?
Как при таком способе хранения мне найти все посты/комменты конкретного пользователя? Как найти все посты с тегом "python"? Как реализовать автоинкремент id постов и комментов? Как при удалении пользователя удалить и все его посты?
Пускай мне нужны комменты, как на хабре (в виде дерева). Как будет выглядеть добавление коммента к комменту и как потом будет выглядеть редактирование комментов в таком дереве? А если в короткий промежуток времени очень много людей внесут изменения в комменты, как обеспечить корректность запись данных?
А если в короткий промежуток времени очень много людей внесут изменения в комменты, как обеспечить корректность запись данных?
Важный для меня вопрос, на который я не знаю ответа. Например, случилось счастье, у меня ежесекундно в один файл комментария добавляют по 10 новых сообщений. Я начинаю плясать и петь от счастья (шутка).
Извините, отвлёкся. Итак на тему напал хрумер или хуман, который в несколько десятков потоков пишет новый комментарий. Как я уже писал, по слухам даже wr-форум от такого падал и ломал текстовой файл. У меня такой проблемы нет, так как я провожу перед записью комментария множество проверок, чтобы роскомнадзор не банил, ресурсы закончатся раньше, чем будет самих записей. Тем не менее, всегда интересно.
Сколько потоков данных может записываться в один текстовой файл? Как избежать проблем при большом потоке комментариев? И есть ли вообще такая проблема или слухи всё?
Сколько потоков данных может записываться в один текстовой файл?
Одновременно — один. Если пишем в файл сами, то можно запросы на запись кидать в MessageQueue, оборачивая их в транзакции.
могу отметить, что многие Ваши запросы хорошо так загрузят БД на хостинге за 50 рублей в месяц
А можно узнать о каком именно хостинге идёт речь? (я понял что это описка и имеется ввиду 500 рублей)
Очень похоже, что Вам просто попался кривой хостинг и Вы его кривизну проецируете на всю отрасль.
Ориентируюсь сейчас на vds за 150 рублей, так как там 30 гб в https://habrahabr.ru/post/319836/#comment_10022060 не верно написал. Проценты нагрузки верные.
Но у меня нет форумов на файлах, у меня блоговая структура с комментариями на файлах. Тем не менее на 50 рублевых тарифах я работал.
у меня блоговая структура с комментариями на файлах
После установки на вордпресс кэширующих плагинов, скорость отдачи страницы почти сравнивается со скоростью отдачи статики. Ибо, по сути, это и есть отдача статики (за исключением тех случаев когда происходит формирование кэша)
Потому что в кэше, как правило, хранят уже готовый html-код и не нужно тратить ресурсы на его формирование.
Ибо, по сути, это и есть отдача статики (за исключением тех случаев когда происходит формирование кэша)
Отвечу на оба комментария сразу :)
Во первых, мы крутимся по кругу. Если идёт спор, пожалуйста, уточните предмет спора.
Вам нужен сайт на WP, который на хостинге от 300 рублей и выше при агрессивном кешировании бодрячком держится? Пожалуйста! Мне нужны сайты, которые в совокупности при нескольких сотнях тысяч (миллионах в мечтах) хитов в сутки не грузят ресурсы по процессору практически совсем и по дисковой подсистеме один в один. Тогда я упираюсь только в каналы. Напомню, я снимаю за 150 рублей 30 гбайт на одном из vds и использую 2% от процессора и реально считаю, сколько я прочитал данных с файла (кстати, что файл внешний открыл также считаю) и сколько в мир отдал по каналу.
Ваша логика железная, сперва на вопрос почему вы используете БД всегда, к месту и не к месту Вы пишите про 21 век, а теперь рассказываете, что если включить кеширование и почти не обращаться к БД, то можно значительно ускорить сайт на WP. При этом по моему мнению адекватно соперничать со мной по скорости вы сможете только включив кеширующий прокси перед сайтом, но явно не плагином!
Вдумайтесь, я не использую кеш совсем, то есть любой динамический контент (комментарии) я могу позволить загружать каждый раз при чтении страницы.
Есть недостатки в моих сайтах? Конечно, например, я не делаю сайтов более 200 тысяч страниц, так как с тегами, пагинацией и прочим хламом страниц становится безумно много. Я стараюсь не держать в каждом разделе (каталоге) слишком много страниц. И так далее.
Если мне нужна БД, то я её использую. Только мне БД нужна для сервисов, а вовсе не для html'ов.
muxa_ru, извините, про век другой писал.
уточните предмет спора.
Предмета спора нет, я ни в чём ни хочу Вас убедить.
Ваша логика железная, сперва на вопрос почему вы используете БД всегда, к месту и не к месту Вы пишите про 21 век, а теперь рассказываете, что если включить кеширование и почти не обращаться к БД, то можно значительно ускорить сайт на WP.
Да именно это я и пишу:
— информация хранится в СУБД обеспечивающей её целостность и гибкий универсальный интерфейс доступа
— формируется файловый кэш в виде готовых html-файлов
— посетителям отдаются html-файлы
Таким образом, у мен есть двухступенчатый механизм, где на первом этапе гибкая но прожорливая машинка служащая для управления контентом и формирования html, а на втором — негибкий но быстрый html-кэш.
Такая схема работы позволяет на первом этапе забить на быстродействие и реализовывать нужный мне функционал.
Вам нужен сайт на WP, который на хостинге от 300 рублей и выше при агрессивном кешировании бодрячком держится?
Мне нужен сайт решающи мои задачи. WP, Bitrix, phpBB — пофиг.
Мне нужен сайт решающи мои задачи. WP, Bitrix, phpBB — пофиг.
Раз спора нет, то вывод прежний. Вы (напомню, говорим о минимальной нагрузки на хостинги за 50-300 рублей) запускаете Bitrix, когда он решает ваши задачи. Вы умнее меня, я бы так не смог, Bitrix на хостинге за 50 рублей.
Моя задача иная, держать максимальное число хитов на заданных ресурсах. Некоторые другие задачи, которые прекрасно решаются в рамках html, css, js и точечными вставками php с чтением данных с файлов.
В результате я не буду ставить cms с БД, так как моих задач она не решает. Вам пофиг на мой метод, так как прежде всего вам нужен sql, которого у меня нет.
Будут те, кто форум на файлах поднимут, будут те, кто ipb купит. Мой вариант большого, посещаемого форума сейчас был бы иным.
Вкратце, я с Вами согласен. Во всём и сразу.
Почему современный тренд все данные сажать на БД?
Почему вы так решили? В кастомных проектах под конкретного заказчика можно встретить целый зоопарк: что-то через СУБД, что-то в файлах, что-то в редис и т.д. Все зависит от уместности применения в том или ином случае.
А с точки зрения открытых CMS выбор очевиден. MySQL есть на каждом хостинге, и он по прежнему остается одним из самых удобных инструментом для хранения и выборки данных.
Шел 2017 год 21 века, самый дешевый VPS хостинг стоил чуть больше доллара в месяц, но ёжики продолжали есть кактус.
1. Я встречал примеры, типа дедикейт за 5000 рублей в месяц, который контекст на сайте еле еле окупает. При этом на сайте всего несколько тысяч страниц и 50-70 тысяч хитов в сутки. К чему я, расскажите, сколько хитов вы удержите не свалившись на ipb в минуту на vds «чуть больше доллара»?
2. Shared — это хороший сервер, на котором Вам считают ресурсы заставляя переплачивать за перерасход (или морозят акк). vds — чаще просто ограничения. Плюсы у vds несомненно есть, минусов также хватает.
ps
баш на баш, теперь помогите мне https://habrahabr.ru/post/319836/#comment_10020702
А можете сказать на каком хостинге находится ExBB.info?
И некоторые технические подробности насчет движка – например потребление памяти, время генерации страницы?
Уже давно даже на бесплатных хостингах есть mysql, а платный хостинг без неё это вообще нонсенс
ExBB — PHP-форум на файлах