удаление строки из середины файла

[clevel]

удаление строки из середины файла

Пока мучался со статистикой - через файлы или мускул, возник вопрос: а можно вырезать часть данных(строку) из середины файла со смещением всей нижележащей информации?
to RomikChef:
спасибо за понимание в предыдущем топики этого раздела...

 

[Novice]

Мне сразу представилась картина как чувак берет ножницы и начинает вырезать сектора на fdd

 

[Larson]

Читаешь файл в массив, вырезаешь, записываешь.

 

[Larson]

Novice:

 

[clevel]

Читаешь файл в массив, вырезаешь, записываешь.

не катит.. файл могут в это время читать/записывать другие юзеры... при этом размер файла растет... если речь о 5-10 Кб, то да, а если это в результатет выльется в пару мегов?

 

[.des.]

flock на время чтения

 

[clevel]

flock на время чтения

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

 

[RomikChef]

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

Исходя из этих принципов, и планируй свои желания и вопросы.

Теперь ты понимать начинаешь, почему ВСЕ делают такие вещи в базе данных?

 

[.des.]

а почему он пару мегов???
то есть другими словами мне непонятно что там хранится может что набирается пара метров!?? заказы всех юзеров за все время?
у тебя все задачи на пределе вычислительных мощностей
планируй алгоритмы так тебе самому легче будет

 

[clevel]

а почему он пару мегов???
то есть другими словами мне непонятно что там хранится может что набирается пара метров!?? заказы всех юзеров за все время?
у тебя все задачи на пределе вычислительных мощностей
планируй алгоритмы так тебе самому легче будет

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

 

[clevel]

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

Исходя из этих принципов, и планируй свои желания и вопросы.

Теперь ты понимать начинаешь, почему ВСЕ делают такие вещи в базе данных?

логика перехода с БД на файловую систему такая:
есть 10 сайтов, по 10тысяч записей для каждого(статистика)... итого 100тысяч записей... если БД, то для выборки ей надо все эти 100 тысяч пройти....
если мы используем файлы, то может разнести по папкам для каждого юзера свои записи, причем можно еще помеясцчно сгруппировать - для каждого месяца(статистика) в свой файл+для предыдущих месяцев спец. скиптом из крон-таба сформировать статистику по определнным параметрам и закинуть в дополнителбные спец. файлы.
таким образом, чтение 10-ка строк из заранее подготовленных файлов+1000 строк из месячного файла статистики - все затраты файловой системы.. это только считывание...
если мне надо найти пользователей, которые зашли повторно через 10 мин после последней просмотренной страницы, то при использовании мускула для этих целей запрос содержит три left join->temporarry table, из которой при помощи groub by,count выдает уже нужные данных... при этом таких операции надо 4... в файловой же системе - 4 массива, которые формируются в процессе считывания файлов...
что быстрее?

 

[Chek]

А не лучше ли так:
Ты вот в эти ААГРОМЯННЫЕ файлики будешь просто скидывать инфу которой не надо критической скорости обработки и так: 1инфа+2инфа+3инфа+Nинфа. Тяжеловатые получаются, но так быстрей. А корзину делаешь в сессиях, с использованием куков. Хроном потов раз в час или два делаешь обработку этих ТЯХАЛЕННЫХ файликов. Ну?

 

[Макс]

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

У тебя корзины всех юзеров в одном файле хранятся? Разнеси по разным файлам. Имя файла - логин или ID юзера

если мне надо найти пользователей, которые зашли повторно через 10 мин после последней просмотренной страницы, то при использовании мускула для этих целей запрос содержит три left join->temporarry table, из которой при помощи groub by,count выдает уже нужные данных

нифига не понял. Зачем временную таблицу создавать? И left join зачем? ИМХО БД неправильно организована

 

[clevel]

нифига не понял. Зачем временную таблицу создавать? И left join зачем? ИМХО БД неправильно организована

таблица статистики:
hit(время,юникс)
owner(владелец сайта)
user(пользователь)
page(страница)
все поля - int(10) unsigned
left join применяется два раза, для того, чтобы найти соседние записи по when group by user where owner=... при условии разницы в 10 мин между соседними записями одного юзера...
не думаю, что что-то не так организовал...

про временную таблицу... при помощи left joins я вычленяю "разрывы" посещений, номера страниц и помещаю их вов временную таблицу... из которой потом и формирую сводные данные по точкам входа и выхода посетителей...

 

[clevel]

А корзину делаешь в сессиях, с использованием куков. Хроном потов раз в час или два делаешь обработку этих ТЯХАЛЕННЫХ файликов. Ну?

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

 

[RomikChef]

тема из серии - не знаешь на что отвечть.
такая мешанина из обрывков сведений.

клевел.
такие вещи на файлах не делаются.
такие вещи на файлах не делаются.
такие вещи на файлах не делаются.
такие вещи на файлах не делаются.
такие вещи на файлах не делаются.
такие вещи на файлах не делаются.
такие вещи на файлах не делаются.

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

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

ВСЕ, ЧТО ТЫ НАПИСАЛ ПРО ФАЙЛЫ, МОЖНО СДЕЛАТЬ И СПОСОЩЬЮ БАЗЫ!
И разные табицы для разных сайтов, и отдельная статистика.
кто тебя заставляет делать все одним запросом?
сделай простой запрос, потом в цикле оброаботки его делай еще запросы.
все будет летать.

Но при этом у тебя не будет заморочек с обновлением информации.
понял?

 

[clevel]

1.если я буду делать на каждого юзера на каждый месяц свою таблицу, это будет глупо
2.если я делаю в цикле запросы, разве это будет быстрее, чем один запрос, который выдает в результате сводные данные? или left join сильнее тормозин, чем несколько коннектов к БД?

 

[RomikChef]

1. уж не глупее, чем делать файлы на тех же условиях.
считай базу данных файлом, в котором можно сдвигать строки.
2. ДА!
ДА! да да да!
Наконец-то до тебя начало доходить!!!
Запросы в цикле работают быстре!!! (примечание для тупых буквоедов, которое тебе запрещено читать: не все и не всегда)
При запросе в цикле таблица просматривается один раз, ну два.
при плохом джойне - количество записей в квадрате, а то и больше!
От этого тормоза!

еще дело в оптимизации запросов. муська - не оракл. Это бесплатная система для веба.
у оракла скорость на сложных запросах не падает.
у муськи - падает.