Новая тема   Ответить

 S_Flash
Есть задумка простенького проекта. У проекта есть простейшая форма регистрации пользователей. Из данныйх только: емейл, хеш пароля, имя, числовое поле. Никаких сортировок и особых выборок не требуется. Запись в файл будет предохранятся php локом, т.е. насколько я знаю два юзера одновременно не вызовут конфликта, просто попадут в очередь на запись.
Пусть в эту импровизированую базу попадёт 50 тысяч записей (4-5Mib). Какие проблемы могут быть при использовании подобного подхода в сравнении с SQL, noSQL базами?

 Чуи
S_Flash писал:
вопрос в том сколько запросов сразу будет, у меня когда-то один олень сдела sqlite и все просто упало. Решение использовать key-value бд (c переносом в файл?).

 rickdeckard
никаких проблем - т.к. все
nosql БД работают по этому принципу "добавление новой записи в файл" и выдерживают высокие нагрузки.

http://php.net/manual/ru/function.file-put-contents.php


file_put_contents($file, $person, FILE_APPEND | LOCK_EX);

главное закрыть доступ по http к этому файлу.

а для чтения периодически делаете копию файла - доступ к которой не блокируется и тем самым обеспечивается высокая скорость доступа для чтения.

в эпоху cgi скриптов на perl - даже целые форумы писали на текстовых файлах и все это прекрасно работало и сейчас работает.

 S_Flash
rickdeckard писал:
О, об этом я не подумал. Реально просто и сердито. Спасибо!


rickdeckard писал:
Я ж про то же. DTR - целый ротатор на тектсовых файлах. Trade Epert - вобще трейд скрипт на тектовых (я о том, что тапм нагрузка в реалтайме). SCJ, если не использовать редис, тоже кеширует межкроновую стату по кликам вроде в тектовый файл. Вот я и думаю, что для сверх малого проекта есть шанс уйти от лишней зависимости, но сцыкливо ибо тренды моды не те сегодня!

 Lexikon
rickdeckard писал:

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

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

 DF™
Lexikon писал:

Что-то не так делали, постоянно использую локи, не замечал таких проблем.
В FreeBSD есть особенность - надо открывать файл на r+ иначе LOCK_EX не сработает.

 Ailk
почему вас так тянет эта задрочка с файлами?
Ну возьми ты sqlite и делай через пдо запросы
http://php.net/manual/ru/ref.pdo-sqlite.php

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

 DF™

Для каждой задачи надо применять свои методы, для этой файлы самое оно - 10 строк кода.
Конечно можно и в mysql или sqlite фигачить, с классами всё оформить, раскидать по куче файлов - как любят делать крутые программисты! Нафига только - как из пушки по воробьям.

 S_Flash
Ailk: универсальность

 Ailk
DF™ писал: sqlite это 1 строка кода(подключение), при этом это ровно теже самые файлы. Еще аргументы?

 ibiz
Ailk писал:

страшно же, да и не везде есть sqlite, а вдруг в консль понадобится лезть инсталить, да и бд в файле в plain/text привычнее и понятнее школьнику

 Ailk
Действительно. Ради 50к записей мускул еще тянуть
А вдруг он тоже не везде есть?

И почему кстати не сделать 1 табличку в мускуле? Ему(мускулу) это вообще никак не помешает и никакой нагрузки не создаст. Это ж тоже файлы, просто не в папочке сайта.

 Lexikon
ibiz писал:
Да! Да! И тут ты прав! Я, к примеру, именно такой "школьник", не повод для гордости, но я за несколько лет работы с ПХП, только сейчас стал изучать базы данных, причем даже от части рад, т.к. на данный момент есть PDO.
Быть "школьником" с такими знаниями не стыдно!

 Lexikon
Ailk писал:
С файлами, я сам себе phpMyAdmin

 Ailk
Lexikon писал:
Пдо уже больше 10 лет
Lexikon писал:
да конечно не стыдно. В рамках обучения вполне норм пилить на файлах. Но когда планируешь рабочий сайт для людей... нынче это уже как-то странно выглядит.

S_Flash говорит не хочет лишних зависимостей. Щас эти зависимости упаковывают в контейнеры вообще
https://ru.wikipedia.org/wiki/Docker

 Lexikon
Ailk писал:
Тут бесспорно.

Ailk писал:
Я ни в одной книге не встретил даже упоминания об этом PDO, за mysqli пишут. Да и вообще во многих видеокурсах, наверное в основной массе, вообще о PDO не упоминают.

 Oswell E. Spencer
Ailk: какой докер, ты что? посмотри какие вопросы у специалистов пишуших на php по несколько лет. там git то с трудом заходит, а докер так вообще что-то инопланетное


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

 Mika
DF™ писал:
Ну да, поэтому при необходимости забить гвозди стоит взять готовый молоток, а не пытаться смастерить его самому (разве что в образовательных целях).

DF™ писал:
Некорректно ставить на одну ступень СУБД enterprise-класса (mysql) и embedded (sqlite). Последний как раз таки и служит в частности заменой собственных файловых велосипедов.
http://sqlite.org/whentouse.html
Цитата:

 ibiz
по сути спор о методах и "правильности" работы - это спор ниочем, каждый дрочет (в пределах своей квартиры), как он хочет
лично я не могу слезть с HeidiSQL со времен виндов иногда захожу, чтоб базу редактнуть по быстрому
но при этом от своих работников в обязательном порядке требую использовать Workbench для стандартизации хотябы внутри команды и таких мелочей много
комфорт одних кончается там, где начинается комфорт других

 S_Flash
Oswell E. Spencer писал:
Пользователи скрипта не хотят привязываться к MySQL или sqlite. При чём тут разработчик? Чем хуже, если они скопировали директорию с проектом и она уже работает без прописывания конфигов и создания базы?

 Oswell E. Spencer
S_Flash писал:

sqlite так и работает как раз.

sqlite / pdo sqlite доступны в php нормальных версий по умолчанию.

 Ailk
S_Flash писал:
А к файлам хотят?
Как думаешь, почему люди придумывают всякие PDO, DBAL'ы и прочие абстракции?
Откуда взяли все эти PSR'ы? http://www.php-fig.org/psr/ (3, 6, 7, да и остальные с интерфейсами)

Как мне кажется, эти люди не хотят привязываться к конкретным реализациям, оставляя право выбора клиента\разработчика на свое усмотрение. Это, заметь, не тоже самое, что отказаться от всего вообще. Буддийские монахи в мире пхп

 S_Flash
Oswell E. Spencer писал:
sqlite - это модуль, другое дело если он стоит по дефолту в 90% сборок php.
Опять же файлы тоже работают как и этот модуль, только без прослойки.


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

 Ailk
Ну тогда стоит наверное писать еще и кросплатформенного клиента до кучи. + делать поддержку всех языков на свете, для пущей универсальности.

Многим например пхп категорически не нравится. Надо альтернативу на питоне. Или ноде. А вдруг они заядлые рубисты?

 localhost
я делал подобную реализацию лет ндацть назад.
типо база данных для постов + генерируемые комменты.
все хранилось в текстовом файле. каждой записи выдавался блок на N байт
таким образом по номеру записи можно вычислить смещение откуда читать блок размером N байт

для ускорения можно сделать хэш на все записи, тупо поблочно (размер 20байт) записать все смещения в файле.
Это все работает норм, если:
1) не нужно читать-писать в базу слишком часто
2) не нужно делать хитровыебанные выборки

значит, если просто тупо писать в текстовый файл строки типа:
логин;пароль;емейл;размер_хуя;телефон

то через 100к записей примерно все начнет тормозить.
почему? потому что нужно открыть файл, прочитать все строки, найти искомое значение, считать

чтобы такой херни не было, нужно под каждую запись давать фиксированный размер блока, скажем
255 байт на одну строчку + перевод строки (ну чтоб визуально удобно смотреть)

далее, чтобы поиск по файлу был быстрее, нужно писать в начало строки типа такого:
логин.....;емейл.....;пароль......;какая-то другая инфа если надо.... - то есть первыен три записи строго фиксированного размера, скажем 64 байта каждая (остаток добивается пробелами

тогда будет проще искать.
скажем читаем из файла по 256 байт, делим на строку на четыре части (три первые части - логин, пароль, емейл, к примеру, остальное для поиска не нужно)
ищем вхождение через strpos (работает быстрее всего) в трех блоках, если найдено - логин существует, можно чото-то еще сделать со всей инфой далее
если не найдено,
идем на следующую строку.
повторить, пока файл не кончится.

все это начнет ощутимо тормозить либо на трафе, либо при размере от 1м строк
почему БД лучше? там реализованы все этим механизмы, что привел выше более грамотно и быстрее.

если нужно только читать из файла конкретный блок (по номеру записи скажем) - там хоть 1м записей можно держать, будет работать быстро, пока файл умещается в файловый кеш линукса.
если нужен поиск, тогда будет тормозить. если есть хороший траф, будет тормозить ощутимее.