Чтение отдельной строки из большого файла

@romanrex · Регистрация: 04.01.2009

Студворк — интернет-сервис помощи студентам

Т.к. из-за ограничений объема в БД нельзя хранить нужное количество исходных данных (условно большие массивы в json), то их надо перенести в текстовые отдельные файлы. Чтоб не плодить больше количество файлов хочется сделать общие файлы, где построчно будут исходные поля из БД. Т.е. в базу делается запрос, а там указывается, из какого файла и какой строки считать данные. Т.к. весь файл считывать ресурсоемко, то вопрос, как считать лишь отдельную строку (может указав не строку, а номер начального символа и длины строки)?

@romanrex · 08.10.2021, 23:41 **[ТС]**

Сообщение от OpXiv

Это как лужу вычерпывать вилами.

Код можно сделать лучше (эффективнее)?

Сообщение от Camy

Какая ж версия php на сервере? Наверное, с нулевых не менялось ничего

На MySQLi переходить конечно надо. Особенно, когда сейчас пришлось делить одну базу на две. Но загвоздка в том, что надо переписать большое количество запросов, и не допустить ошибок, из-за которых сайт будет нерабочим. Сейчас пока выкрутился через переключение основной БД. Как более срочные задачи будут решены, будет постепенный переход на mysqli_query.

@OpXiv · 09.10.2021, 00:13

Сообщение от romanrex

Код можно сделать лучше (эффективнее)?

Почему изначально идея родилась, хранить всё в одном файле ? А что если, надо будет удалить 1 файл из файла ? Опять переписывать все offset-ы ? Лишний гемор на попу.

Добавлено через 1 минуту
Как по мне, лучше хранить путь к директории, в которой загружены файл 1Line.txt, 2Line.txt

И потом делать

PHP
1
2
3
4
$file = $dir . $id . 'Line.txt';
if(is_file($file)) {
   echo file_get_contents($file);
}

KingdaKa · 09.10.2021, 01:19

В пылу дискуссии все, кажется, забыли, что всё упирается в объем данных, не?

Зачем хранить в базе пути к файлам, если файлы всё равно отдаются скрипту? Надо сразу в базе данные хранить
Другое дело, что ежели это жысон, то может быть имеет смысл его распарсить в более компактный вид и загзипить.

P.S.: Никто не отменял удаленные хранилища, кстати, если хостинг менять не хочется. А для ускорения доступа есть кэширование.

@romanrex · 09.10.2021, 10:21 **[ТС]**

Сообщение от OpXiv

Почему изначально идея родилась, хранить всё в одном файле ? А что если, надо будет удалить 1 файл из файла ? Опять переписывать все offset-ы ? Лишний гемор на попу.

Если и будет, то только добавления.

По сути, на каждый продукт есть исходный массив данных. От 16 МБ до 1.5 ГБ. Это все находится оффлайн и с ним работает ПО на C#. Изначально ПО лишь создавало картинки графиков. Потом статичные страницы отчетов с картинками под сайт. В итоге, несмотря на "безлимитность" хостинга количество файлов в 1 300 000 оказалось, что все же превышают предел в 100 000 файлов. На тот момент это решилось через объединение картинок в спрайты (где-то 3500 картинок стало умещаться в 50 для "тяжелых" продуктов). Замену хостинга конечно рассматривал, но оказалось, что у всех есть предел и чаще он заявлен вообще в 10 000 файлов.

Далее постепенно часть графиков для возможности сравнения стали добавляться в БД в виде координат. Сейчас стоит задача все картинки графики перевести на построение из координат. С одной стороны для более гибкого построения конечных "картинок" и возможности прямых сравнений, с другой - не превысить количество файлов за 100 000, т.к. с ростом посещаемости можно упереться в ресурсы хостинга и уходить будет просто некуда (или слишком дорого).

Объем БД оказался лимитированным в 5 ГБ. Хотя заявляется, что количество БД неограничено, наверняка, если сделать 20-30 баз по 5ГБ, то нарисуется ограничение на общий объем...

Т.к. у каждого продукта есть свой ID то на него сейчас создается файл с таким номером. Т.е. выделена папка X, в ней папки с номерами ID и в каждой папке файл вида X_ID. Размер файлов получается от 6 МБ до 120 МБ на один продукт. Может быть потом будет еще дополнительный файл под кеш или что-то еще. В БД соответственно содержаться только Offset и Leight, а поле с JSON в БД условно пустое. Там же, где изначально JSON короткие, они подгружаются из БД.

Сейчас "продуктов" порядка 3000.

Новые блоги и статьи Все статьи Все блоги /
Thinkpad X220 Tablet — это лучший бюджетный ноутбук для учёбы, точка. Programma_Boinc 23.12.2025 Thinkpad X220 Tablet — это лучший бюджетный ноутбук для учёбы, точка. Рецензия / Мнение Это мой обзор планшета X220 с точки зрения школьника. Недавно я решила попытаться уменьшить свой. . .	PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Как объединить две одинаковые БД Access с разными данными VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .
От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .

@romanrex -8 / 1 / 2 Регистрация: 04.01.2009 Сообщений: 121

	Чтение отдельной строки из большого файла 06.10.2021, 23:42. Показов 2744. Ответов 23 Метки нет (Все метки) Т.к. из-за ограничений объема в БД нельзя хранить нужное количество исходных данных (условно большие массивы в json), то их надо перенести в текстовые отдельные файлы. Чтоб не плодить больше количество файлов хочется сделать общие файлы, где построчно будут исходные поля из БД. Т.е. в базу делается запрос, а там указывается, из какого файла и какой строки считать данные. Т.к. весь файл считывать ресурсоемко, то вопрос, как считать лишь отдельную строку (может указав не строку, а номер начального символа и длины строки)? 0

KingdaKa 1306 / 781 / 190 Регистрация: 19.09.2020 Сообщений: 1,993
	09.10.2021, 01:19
	В пылу дискуссии все, кажется, забыли, что всё упирается в объем данных, не? Зачем хранить в базе пути к файлам, если файлы всё равно отдаются скрипту? Надо сразу в базе данные хранить Другое дело, что ежели это жысон, то может быть имеет смысл его распарсить в более компактный вид и загзипить. P.S.: Никто не отменял удаленные хранилища, кстати, если хостинг менять не хочется. А для ускорения доступа есть кэширование. 0