Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Уточни 19.05.03 03:37 Число просмотров: 1040
Автор: amirul <Serge> Статус: The Elderman
|
> Возник вопрос о скорости работы скрипта, читаеющего данные
> из плоской текстовой базы.
> Ситуация: есть четыре файла (6К, 4К, 0.4К, 0.5К) читаемые
> скриптом.
> Альтернативная ситуация: есть один файл (10К) читаемый
> скриптом.
> Что быстрее четыре обращения к диску за файлами за !уже
> подготовленными данными или открывать один файл и только
> потом обрабатывать данные?
Как подготовленными, как хранится, в чем отличие между четырьмя файлами и одним (простая конкатенация или еще что-то).
Общий ответ: храни свою базу хоть в одном файле хоть в нескольких с уже подготовленными данными (мож когда уточнишь можно будет говорить точнее, но пока я не понимаю, зачем при каждом запуске скрипта выполнять подготовку, если ее можно сделать еще до создания самого скрипта).
Тут есть два варианта:
1) Все записи в базе имеют однородную структуру (размер всех записей одинаков), тогда для i-й записи достаточно размер записи умножить на номер записи.
2) База неоднородная (записи в базе могут иметь разный размер). Тогда для каждого ключевого поля (по которому собираешься производить поиск) создай отдельный индексный файл. Это будет типа однородная база, содержащая записи одинаковой длины: i-я запись будет хранить смещение i-й записи в основном файле (для которого выполнено индексирование) в отсортированном по этому ключу порядке. Ну или вырожденный случай: хотя бы просто хранить файл со смещениями всех записей в том порядке, в котором они есть в базе.
ЗЫ: быстрое нахождение i-й записи в базе может понадобиться например для бинарного поиска (с логарифмическим временем от размера базы).
ЗЗЫ: Если логарифмическое время не подходит, можно хранить хеш-таблицу для каждого ключевого поля. Время константное, но и необходимый размер памяти на несколько порядков больше.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
