Ограничивает файловая система. Можно создавать тома таблицы.

Мда давно нужно с кем то пообщаться на данную тему

Общаться вообще дело полезное Но и самому тоже вглубь проблемы копать. Тебе надо время чтобы проникнуться новым подходом. А ошибки всегда бывают.

Я уже проник немного уже думаю каким макаром организовать к этому поиск. Примерно поэкспериментировал интересно пока разница только в кол. файлов а дальше посмотрю чего выйдет. Зделал примерные наброски на запирание файла.
(Добавление)
[quote=avtor.fox][/quote] Каждому своё кто то хлеб покупает, а кто то дома печёт.

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

С помощью fread можно читать в собственный буфер приемлемого для сервера размера не одну запись за раз, а фрагмент файла.

Запирания для начала можно на уровне файла, а потом все равно надо делать на уровне записи или даже поля записи.

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

Функциональное задание выглядит так Это пригодиться о и это добавим и вот это пригодиться а сюда удаление добавим вот и вся х.
А по выборке файлов скажем поиск будет быстрее чем по одному большому файлу
У меня записи раскидывает так: аб.дат, ав.дат и т.д. в данном случаем из запроса мы узнаем нужный нам файл в котором искать а достигнуть там большое количество записей будет довольно тяжело + невозмоэжно получить много совпадений по запросу лично я так думаю.

Такая экстремальная хаотчиная разработка конечно не для меня Предпочитаю подробно формализовать цели, поставить задачу в виде набора функций оставив их код черный ящик, а потом уже реализация. А то вот ты заморочился на этом быстром поиске. Ну и что, вот сделал ты мегадерево на файлах. А нужно ведь чтобы все операции выполнялись примерно с одинаковыми затратами: insert, select, update, delete.

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

Уверены?
Зависит от задач. В вебе характерно сильное преобладание чтения над записью, разница доходит до порядка и больше.
Если вы можете читать в 2 раза быстрее, хотя при этом писать в 5 раз медленнее - это окажется выигрышной стратегией.
А любая транзакционная среда принципиально не делает update, это всегда insert + delete - очевидно, что update не может выполняться с той же скоростью, но СУБД отлично при этом живёт.

Но не о том спорите. Что делать на конкурентном r/w? Как не дать читать данные, которые ещё пишутся? Ставить эксклюзивный лок? Тогда имейте в виду, что этой штуке даже до тупого mysql как до луны пешком.
Как разбирать, что корректно, а что нет, если в момент записи блока (а пуще того - перезаписи!) оборвали электричество? И случайный объём файла состоит из новых данных, а остаток - из старых?


Если известен offset - то вы не правы. Как ни парадоксально, поиск по известному смещению быстрее поиска по пути ФС. Такой подход практикуется как минимум одним хайлоадом (но не помню, каким) - писать загружаемые файлы в датафайл, в базу - смещение от начала и длину. Потом по смещению указанное число байт читать.


Если это делается для понимания всей той кухни, что за 4 десятилетия работы наработали РСУБД и с пониманием, что весь этот код никогда не будет использоваться - то отличное начинание. Вооружайтесь книгам по транзакционности и ACID. Наработано много всего, и на то есть причины. Грабель весьма много, начиная с банального вопроса "как безопасно изменить данные в строке".

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

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

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

А если сбой произошёл в момент записи резервной копии? Её восстанавливать нельзя, эта запись ещё неконсистентна.


Алгоритм не поможет против прогретого кэша вкупе с ещё более сложными алгоритмами, вплоть до генетики (планировщик постгреса умеет, серьёзно).


Тем самым приходим к выводу - postgree.

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

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

Нужно писать без рамок, эксперементировать. man1 правильно пишеш за бекап файл я ищо добавил сессию для очереди на запись и от зацыкленость функции на запись. А своя бд для своих проэктов а потом паблик без возгласов "БД НОВОГО ПОКОЛЕНИЯ"