Чтение и запись данных их очень большого файла

rommer, ты загнался похерне. и себе и другим мозг пытаешь помять.

форумом ошибся с "быть или не быть". найми любого ламера тебе всё сделают [любой программист школьник разобьет тебе файлы по уму с минимальной нагрузкой и максимальной скоростью с учетом на рост объема инфы]

Anamnado добавил 17.12.2011 в 06:05

а если завтра война и выключат свет ?

ответ: на бумажке гвоздем царапай.

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

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

rommer, прошу прощения, не удержусь от оффтопа.

Сайты без БД, ворочащие гигабайтные файлы с данными — это что-то совсем нелепое. Химера какая-то.

"Возиться" - это значит "завести БД на хостинге". А любая блондинка ныне может установить тот же Вордпресс.

(А написать скрипт, создающий таблицы с данными даже начинающему кодеру - делов на 5-10 мин.)

Ты не поверишь - именно по этой причине и были придуманы БД. В БД данные занимают на порядок меньше места. + работа идет не совсем объёмом одновременно, а только с нужными данными.

Та же причина.

МуСуля на сайта и не бывает. Он бывает на хостинге. А ныне найти хостинг без базы - ещё нужно постараться.

имеено на это тебе и ответил cryptex:

Включи наконец свой мозг - кто тебе на хостинге (на котором к тому же нет БД) выделит > гига мозгов сервера?

файрбёрд\фокспро? ;)

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

И совсем не нравится, как он выбрал самую высокую колокольню, чтобы плевать на ответивших.

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

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

Вопрос в том, что в рамках описанной задачи удобнее будет использовать уже готовую БД, реляционную или нереляционную - это уже отдельный вопрос. А если делать это на плейнтекст файлах - это заставит реализовывать функционал, который уже есть в "фабричных" базах данных, чтобы ворочать теми объёмами данных, которые описывает ТС.

Сколько записей?

у меня на работе БД шесть гиг, причем только цифирьки разные, т.е. по вашей структуре только поля типа 1, 3, 4.

самая большая (из сотни где-то) таблица - 2 млн записей.

и да, это в мире БД это считается небольшой, ничем не примечательной базой.

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

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

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

ТС-у - почитать как писался ибей. он тоже сначала был на пхп+файлы. когда количество аукционов достигло 50К, он просто заткнулся. пришлось срочно прикручивать БД. Либо помедитировать на тему "почему фейсбук построен вокруг MySQL, а не на чистых файлах"

и да, не нужно изобретать очередной велосипед

iopiop добавил 17.12.2011 в 22:24

это как, БД их сжимает, что ли? ;-)

на самом деле все с точностью до наоборот, т.к. структура БД очень рыхлая + куча индексов, которые обычно занимают места больше чем собственно данные. Все в угоду скорости.

Вставлю свои 5 копеек.

Полностью согласен, давайте для начала отделим "мух от котлет"

Файлы так файлы. Допустим.

Идейка, скажем так, на уровне студента первого курса, без обид.

Для поиска по метаданным строим индекс. Вот по индексу уже и будем бродить.

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

Мороки конечно будет достаточно, но вполне реализуемо. Как устроены индексы я думаю понятно, в любом случае вопрос давно описан в массе литературы.

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

Можно ТАК построить индексы, что скорость наоборот упадет :) Извините за оффтоп.

Так же соглашусь с тем, что найти хостинг без БД надо еще суметь. Обычно БД уже предустановлена. А далее все что нужно - сделать скрипт типа install.(php, aspx и т.п.) который всю работу по инсталляции и сделает.

Как то так.

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