Покинул форум
Сообщений всего: 57
Дата рег-ции: Апр. 2012
Помог: 0 раз(а)
Саня_1991 пишет:
Интересно. php ограничевает по размеру файла?
Ограничивает файловая система. Можно создавать тома таблицы.
Саня_1991
Отправлено: 01 Марта, 2014 - 00:08:54
Новичок
Покинул форум
Сообщений всего: 28
Дата рег-ции: Февр. 2014 Откуда: Первомайск Украина
Помог: 0 раз(а)
Мда давно нужно с кем то пообщаться на данную тему
man1
Отправлено: 01 Марта, 2014 - 00:13:25
Новичок
Покинул форум
Сообщений всего: 57
Дата рег-ции: Апр. 2012
Помог: 0 раз(а)
Саня_1991 пишет:
Мда давно нужно с кем то пообщаться на данную тему Огорчение
Общаться вообще дело полезное Но и самому тоже вглубь проблемы копать. Тебе надо время чтобы проникнуться новым подходом. А ошибки всегда бывают.
avtor.fox
Отправлено: 01 Марта, 2014 - 00:15:14
Постоянный участник
Покинул форум
Сообщений всего: 2083
Дата рег-ции: Март 2012 Откуда: Воронеж
Помог: 50 раз(а)
Чем бы дитя не тешилось, лишь бы СУБД не писала.
Саня_1991
Отправлено: 01 Марта, 2014 - 00:16:34
Новичок
Покинул форум
Сообщений всего: 28
Дата рег-ции: Февр. 2014 Откуда: Первомайск Украина
Помог: 0 раз(а)
Я уже проник немного уже думаю каким макаром организовать к этому поиск. Примерно поэкспериментировал интересно пока разница только в кол. файлов а дальше посмотрю чего выйдет. Зделал примерные наброски на запирание файла. (Добавление)
[quote=avtor.fox][/quote] Каждому своё кто то хлеб покупает, а кто то дома печёт.
man1
Отправлено: 01 Марта, 2014 - 09:43:56
Новичок
Покинул форум
Сообщений всего: 57
Дата рег-ции: Апр. 2012
Помог: 0 раз(а)
Саня_1991 пишет:
Я уже проник немного уже думаю каким макаром организовать к этому поиск. Примерно поэкспериментировал интересно пока разница только в кол. файлов а дальше посмотрю чего выйдет. Зделал примерные наброски на запирание файла.
Надо стремиться получать необходимые данные с минимальным количеством обращений к жесткому диску. Представь если бы ты на файлах делал выборку нескольких сот записей (например, новостей), то тебе пришлось бы открывать все эти несколько сот файлов, а процедура подключения к файлу для работы с ним очень прожорливая.
С помощью fread можно читать в собственный буфер приемлемого для сервера размера не одну запись за раз, а фрагмент файла.
Запирания для начала можно на уровне файла, а потом все равно надо делать на уровне записи или даже поля записи.
Ты там опять начал уже пробовать что-то, но по хорошему хотелось бы увидеть функциональное задание того, что ты хочешь сделать. Подробно расписать как это все будет использоваться программистом, а потом уже реализацией заниматься.
Саня_1991
Отправлено: 01 Марта, 2014 - 12:23:46
Новичок
Покинул форум
Сообщений всего: 28
Дата рег-ции: Февр. 2014 Откуда: Первомайск Украина
Помог: 0 раз(а)
Функциональное задание выглядит так Это пригодиться о и это добавим и вот это пригодиться а сюда удаление добавим вот и вся х.
А по выборке файлов скажем поиск будет быстрее чем по одному большому файлу
У меня записи раскидывает так: аб.дат, ав.дат и т.д. в данном случаем из запроса мы узнаем нужный нам файл в котором искать а достигнуть там большое количество записей будет довольно тяжело + невозмоэжно получить много совпадений по запросу лично я так думаю.
man1
Отправлено: 01 Марта, 2014 - 12:32:58
Новичок
Покинул форум
Сообщений всего: 57
Дата рег-ции: Апр. 2012
Помог: 0 раз(а)
Саня_1991 пишет:
Функциональное задание выглядит так Это пригодиться о и это добавим и вот это пригодиться а сюда удаление добавим вот и вся х.
А по выборке файлов скажем поиск будет быстрее чем по одному большому файлу
У меня записи раскидывает так: аб.дат, ав.дат и т.д. в данном случаем из запроса мы узнаем нужный нам файл в котором искать а достигнуть там большое количество записей будет довольно тяжело + невозможно получить много совпадений по запросу лично я так думаю.
Такая экстремальная хаотчиная разработка конечно не для меня Предпочитаю подробно формализовать цели, поставить задачу в виде набора функций оставив их код черный ящик, а потом уже реализация. А то вот ты заморочился на этом быстром поиске. Ну и что, вот сделал ты мегадерево на файлах. А нужно ведь чтобы все операции выполнялись примерно с одинаковыми затратами: insert, select, update, delete.
Что касается того подхода что я описывал, туда надо просто добавить еще третий файл my_table.ind - индексный файл, и вот в нем уже храни сортированные первые 1-10 букв полей записей и по ним делай поиск.
Мелкий
Отправлено: 01 Марта, 2014 - 13:46:25
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
man1 пишет:
нужно ведь чтобы все операции выполнялись примерно с одинаковыми затратами
Уверены?
Зависит от задач. В вебе характерно сильное преобладание чтения над записью, разница доходит до порядка и больше.
Если вы можете читать в 2 раза быстрее, хотя при этом писать в 5 раз медленнее - это окажется выигрышной стратегией.
А любая транзакционная среда принципиально не делает update, это всегда insert + delete - очевидно, что update не может выполняться с той же скоростью, но СУБД отлично при этом живёт.
Но не о том спорите. Что делать на конкурентном r/w? Как не дать читать данные, которые ещё пишутся? Ставить эксклюзивный лок? Тогда имейте в виду, что этой штуке даже до тупого mysql как до луны пешком.
Как разбирать, что корректно, а что нет, если в момент записи блока (а пуще того - перезаписи!) оборвали электричество? И случайный объём файла состоит из новых данных, а остаток - из старых?
Саня_1991 пишет:
А по выборке файлов скажем поиск будет быстрее чем по одному большому файлу
Если известен offset - то вы не правы. Как ни парадоксально, поиск по известному смещению быстрее поиска по пути ФС. Такой подход практикуется как минимум одним хайлоадом (но не помню, каким) - писать загружаемые файлы в датафайл, в базу - смещение от начала и длину. Потом по смещению указанное число байт читать.
Если это делается для понимания всей той кухни, что за 4 десятилетия работы наработали РСУБД и с пониманием, что весь этот код никогда не будет использоваться - то отличное начинание. Вооружайтесь книгам по транзакционности и ACID. Наработано много всего, и на то есть причины. Грабель весьма много, начиная с банального вопроса "как безопасно изменить данные в строке".
----- PostgreSQL DBA
man1
Отправлено: 01 Марта, 2014 - 14:27:47
Новичок
Покинул форум
Сообщений всего: 57
Дата рег-ции: Апр. 2012
Помог: 0 раз(а)
Мелкий пишет:
Как не дать читать данные, которые ещё пишутся? Ставить эксклюзивный лок? Тогда имейте в виду, что этой штуке даже до тупого mysql как до луны пешком.
Как разбирать, что корректно, а что нет, если в момент записи блока (а пуще того - перезаписи!) оборвали электричество? И случайный объём файла состоит из новых данных, а остаток - из старых?
...
Грабель весьма много, начиная с банального вопроса "как безопасно изменить данные в строке".
Логично не давать читать только те данные, которые в данный момент изменяются (перезаписываются). Для этого лока вполне достаточно. Но вообще можно придумать механизм сохранения изменений до внесения этих изменений в реальный файл данных, тем самым не задерживать очередь. Придумать можно еще что-нибудь.
На ситуацию обрыва электричества, есть решение - сохранять перед записью бэкап той записи которую собрались перезаписать, потом если запись успешна, то удалить бэкап, если нет, то восстановить из бэкапа и удалить бэкап.
Есть ограничения у файловой системы, есть у интерпретатора пхп, остальное в нашей власти - то есть скорость субд можно обеспечить только за счет хорошего алгоритма, над коим и предстоит задуматься.
Мелкий
Отправлено: 01 Марта, 2014 - 15:03:39
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
man1 пишет:
сохранять перед записью бэкап той записи которую собрались перезаписать, потом если запись успешна, то удалить бэкап, если нет, то восстановить из бэкапа и удалить бэкап.
А если сбой произошёл в момент записи резервной копии? Её восстанавливать нельзя, эта запись ещё неконсистентна.
man1 пишет:
скорость субд можно обеспечить только за счет хорошего алгоритма
Алгоритм не поможет против прогретого кэша вкупе с ещё более сложными алгоритмами, вплоть до генетики (планировщик постгреса умеет, серьёзно).
man1 пишет:
Придумать можно еще что-нибудь.
Тем самым приходим к выводу - postgree.
----- PostgreSQL DBA
man1
Отправлено: 01 Марта, 2014 - 15:17:12
Новичок
Покинул форум
Сообщений всего: 57
Дата рег-ции: Апр. 2012
Помог: 0 раз(а)
Мелкий пишет:
А если сбой произошёл в момент записи резервной копии? Её восстанавливать нельзя, эта запись ещё неконсистентна.
...
Тем самым приходим к выводу - postgree.
Ну можно еще контрольную сумму файла сохранять и потом сверять. А вообще если обрыв появится, то скрипт пхп будет прерывать операцию, а не пытаться продолжать ее, зная что предыдущее атомарное действие не было завершено.
Странный вы какой-то, я же не говорил что субд на файлах должна стать заменой каких либо других субд. Я хочу чтобы она просто существовала параллельно с другими. Никакой категоричности в этом вопросе я никогда не выражал
Саня_1991
Отправлено: 01 Марта, 2014 - 15:49:40
Новичок
Покинул форум
Сообщений всего: 28
Дата рег-ции: Февр. 2014 Откуда: Первомайск Украина
Помог: 0 раз(а)
Нужно писать без рамок, эксперементировать. man1 правильно пишеш за бекап файл я ищо добавил сессию для очереди на запись и от зацыкленость функции на запись. А своя бд для своих проэктов а потом паблик без возгласов "БД НОВОГО ПОКОЛЕНИЯ"
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.