Проблемы при использовании текстовых файлов вместо СУБД?

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

S_Flash писал:

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

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

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

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

Код: [развернуть]

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

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

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

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

rickdeckard писал:

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

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

rickdeckard писал:

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

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

rickdeckard писал:

file_put_contents($file, $person, FILE_APPEND | LOCK_EX);[/code]

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

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

Lexikon писал:

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

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

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

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

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

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

DF™ писал:

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

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

Ailk писал:

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

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

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

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

ibiz писал:

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

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

Ailk писал:

И почему кстати не сделать 1 табличку в мускуле?

С файлами, я сам себе phpMyAdmin

Lexikon писал:

т.к. на данный момент есть PDO.

Пдо уже больше 10 лет

Lexikon писал:

Быть "школьником" с такими знаниями не стыдно!

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

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

Ailk писал:

Но когда планируешь рабочий сайт для людей... нынче это уже как-то странно выглядит.

Тут бесспорно.

Ailk писал:

Пдо уже больше 10 лет

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

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


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

DF™ писал:

Для каждой задачи надо применять свои методы, для этой файлы самое оно - 10 строк кода.

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

DF™ писал:

Конечно можно и в mysql или sqlite фигачить

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

Цитата:

SQLite does not compete with client/server databases. SQLite competes with fopen().

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

Oswell E. Spencer писал:

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

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

S_Flash писал:

Чем хуже, если они скопировали директорию с проектом и она уже работает без прописывания конфигов и создания базы?

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

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

S_Flash писал:

Пользователи скрипта не хотят привязываться к MySQL или sqlite.

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

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

Oswell E. Spencer писал:

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

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

Ailk писал:

Как думаешь, почему люди придумывают всякие PDO, DBAL'ы и прочие абстракции?

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

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

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

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

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

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

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

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

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

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

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

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