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

123
Anamnado
На сайте с 08.02.2010
Offline
242
#11

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

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

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

rommer:

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

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

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

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

Dreammaker
На сайте с 20.04.2006
Offline
570
#12
rommer:
Что кто скажет?

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

DV
На сайте с 01.05.2010
Offline
644
#13

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

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

VDS хостинг ( http://clck.ru/0u97l ) Нет нерешаемых задач ( https://searchengines.guru/ru/forum/806725 ) | Перенос сайтов на Drupal 7 с любых CMS. ( https://searchengines.guru/ru/forum/531842/page6#comment_10504844 )
SeVlad
На сайте с 03.11.2008
Offline
1609
#14
rommer:
1. в первую очередь основное ограничение, что скрипт этот пишется под разных пользователей, и надо чтобы они не возились с его установкой.

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

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

rommer:
2. было сказано, что размер файл будет больше гига. Предлагаете все это хранить в таблице mysql?

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

rommer:
4. таких файлов может быть от одного до безконечности.

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

rommer:
сайты, на которых нету mysql,

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

rommer:
и память поберечь

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

cryptex:
что б гиговые файлы целиков в память не читать

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

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

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

Делаю хорошие сайты хорошим людям. Предпочтение коммерческим направлениям. Связь со мной через http://wp.me/P3YHjQ-3.
Spell
На сайте с 14.07.2006
Offline
72
#15

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

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

Dreammaker
На сайте с 20.04.2006
Offline
570
#16

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

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

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

LEOnidUKG
На сайте с 25.11.2006
Offline
1748
#17
уже довольно большой

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

✅ Мой Телеграм канал по SEO, оптимизации сайтов и серверов: https://t.me/leonidukgLIVE ✅ Качественное и рабочее размещение SEO статей СНГ и Бурж: https://getmanylinks.ru/ ✅ Настройка и оптимизация серверов https://getmanyspeed.ru/
I
На сайте с 23.12.2010
Offline
25
#18

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

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

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

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

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

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

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

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

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

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

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

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

SD
На сайте с 08.12.2011
Offline
5
#19

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

iopiop:
хранить метаданные вместе данными - зачем?

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

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

rommer:
У меня возникла следующая идейка:

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

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

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

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

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

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

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

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

Как то так.

N
На сайте с 06.05.2007
Offline
419
#20
iopiop:
Ты не поверишь - именно по этой причине и были придуманы БД. В БД данные занимают на порядок меньше места.

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

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

Кнопка вызова админа ()
123

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий