Что эффективней, чтение из файла или массив?

Question

[Данила Румянцев]

Пишу курсовую работу и задумался, что будет эффективней, держать постоянно в памяти 5 больших массивов, чтобы искать по ним нужную информацию, или каждый раз искать по .txt файлу. Я знаю, может вопрос глупый, но подскажите пожалуйста. В курсовой конечно же и так и так будет нормально, но просто стало интересно

Comments

[Antonio Solo]

для начала надо определиться с критерием эффективности

[res2001]

Данила Румянцев, Нет однозначного ответа на этот вопрос. Выбор между памятью и диском будет зависеть от конкретной задачи. Вы, как программист, должны понимать плюсы и минусы обоих подходов и выбирать для решения задачи тот что будет оптимальным для данной конкретной задачи. Можно и комбинировать подходы.

Answer 1

[mayton2019]

Вопрос не глупый а вполне себе хороший.

Его плавное развитие приводит к концепции баз данных. Самое главное что можно сказать тезисно это
1) Пока памяти хватает (массив) - используй смело память
2) Диск - больше и дешевле памяти
3) С памятью работать легко. С диском - очень неудобно и надо обрабатывать IOExceptions почти всегда.
Диски внезапно полны сюрпризов. Могут быть сетевыми дисками.
4) Разные диски имеют скорость на порядки разную.
5) Диски ведут себя очень плохо на random access. От этого даже метрика IOPS появилась.
Ее очень любят обсуждать админы баз данных.
6) Существуют структуры данных которые спецом создавались только для дисков (B+Tree)
7) Диск - переживает выключение питания.
8) Самые разумные решения - сочетают в себе и диск и память в тех частях кода где это нужно.
9) Есть интерфейсы программирования которые виртуализирут диск как память. Этим пользуется
SQLite например.
10) Диск может достигать очень высокой последовательной скорости чтения или записи в файл
при условии отсутствия конкурирующих записей в данный момент. Этим пользуются в БД
для журналирования событий.

В принципе если современный программист просто будет использовать только оперативную память
то никто ему не сможет ударить по рукам или подойти с какой-то метрикой и чего-то там измерив
сказать что он неправ. Тут уж только падения по OOM и потери информации и performance issues
могут быть каким-то значимым аргументом.

Comments

[Antonio Solo]

современный программист

Если кто-то будет говнокодить тогда буду его называть современным программистом

[mayton2019]

Antonio Solo, не знаю о чем ты говоришь. Я этого нигде не утверждал.

[Everything_is_not_so_bad]

mayton2019, просто троллит. Скучно, наверное.

Answer 2

[dmshar]

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

Возможно многие и не слышали, но тем не менее существуют т.н. In-memory database (по-русски это, кажется, называется "Резидентная база данных", но я не уверен). Применяются такие системы как правило в высоконагруженных приложениях - в системах провайдеров телекоммуникационных услуг, когда-то читал - что в системах он-лайн биржевой торговли и пр. Там где данных очень много и доступ к ним нужен очень быстро. И главное - владелец таких данных оччччеееень богатенький, что-бы позволить себе приобрести оборудование с объемом оперативной памяти сопоставимым с объемом внешней памяти для "обычных" серверов баз данных. И вот тогда, для таких задач все данные СУБД, включая все индексы и другой служебно-вспомогательной информации, загоняются в оперативную память, обеспечивая и нужную скорость доступа и удобство доступа, которое обычно присуще СУБД.
Главнейшая проблема, которую решают разработчики таких систем - как обеспечить целостности базы данных при внезапной перезагрузке систем. Это влияет на производительность In-memory database, заставляя тратить часть вычислительных ресурсов на синхронизацию данных в ОП и резервных копий на внешней памяти.
Список таких систем можно, кстати, найти даже в Википедии:
https://en.wikipedia.org/wiki/List_of_in-memory_da...

Если же "спуститься" с небес на землю и учесть финансовые возможности "нормального" пользователя, то например, в языке программирования Python есть такой модуль - Pandas. По сути он дает удобство доступа к данным, почти такое-же (а может и еще большее) как SQL, сохраняя таблицы в ОП. А скорость обработки - сопоставимую с реализацией на "голых" массивах, а для сложных поисковых запросов - и еще большую. Естественно, что объем таблиц (DataFrame в терминологии Pandas) не может быть слишком большим. И не смотря на то, что есть прямой шлюз для перехода от DataFrame к SQL-структурам СУБД и обратно, скорость работы "в памяти" на много выше, чем скорость работы с теми-же данными, выгруженными в БД. Поэтом программист может комбинировать работу DataFrame для скорости обработки и СУБД для долговременно энергонезависимого хранения, найдя приемлемый для своего приложения компромисс.

Comments

[mayton2019]

У Pandas есть недостатки. Наши аналитики пытаются запускать pandas-скрипты в databricks кластере но использование кластера идет неэффективно. Pandas не умеет себя распараллеливать на вычислительных нодах. Фактически Пандас видит только driver-node (хост где изначально запускаются процессы биг-даты). Worker nodes - не видит. Да и не втом дело видит или не видит. Технологически не умеет делать партишенинг длинных операций. Поэтому где как только performance issue - мы панду выкидывает за ухо на улицу и затаскиваем Dataframes из технологии Spark .

[dmshar]

mayton2019 Охотно соглашусь с тем, что вы написали. Но Pandas и не предназначен для работы в режиме распараллеливания и сверхбольших объемов данных. Ну, как бы не стоит рассчитывать на то, что бусик заменит полноразмерный автобус для перевозки пассажиров в мегаполисе. Но на узких улочках даунтауна или на прямом современном автобане на бусике будет и удобнее и быстрее :-).
Со Spark никогда в живую дело не имел. Надо будет на досуге глянуть, если оборудование позволит. Но это мы забрались в дебри, которые ТС наверное уже не интересны.

Answer 3

[Stalker_RED]

Память намного быстрее диска, даже если это SSD или рамдиск.
Но память намного дороже дисков, и если данных много, то возможно дешевле данные читать из файлов.
Сравните сколько стоит HDD на 18Тб и сколько стоит сервер с соответствующим объемом.

Что вы подразумеваете под эффективностью - вам виднее.

Comments

[Данила Румянцев]

Под эффективностью я подразумеваю количество использованой памяти

[Василий Банников]

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

В сильно нагруженных приложениях (например в различных СУБД) часть данных кэшируется в оперативной памяти, то источником истины является диск - в него идёт запись и из него идёт чтение, когда кэши протухают или происходит cash miss.

Лучше уточни задачу, а то тебе сейчас всякого насоветуют.

[Stalker_RED]

Данила Румянцев, тогда лучше ее вообще не использовать :)

Обычно на практике никто не впадает в крайности и соблюдают какой-то баланс. Человеччество придумало довольно много всяких штук для хранения, чтения, поиска и обработки данных.
Базы данных с индексацией могут творить чудеса по сравнению с обычным чтением.

[Данила Румянцев]

Stalker_RED, Я понимаю, просто стало интересно и решил поинтересоваться у знающих людей как лучше :)

Answer 4

[Wan-Derer]

Если возникает вопрос "память или файл?", это значит что есть какие-то проблемы хранения в памяти: данных много и памяти может не хватить, данные должны сохраниться при перезапуске приложения, данные должны быть доступны из других приложений/инстансов, что-то ещё.
В таком случае задачу хранения/записи/чтения данных лучше поручить отдельному сервису. Про базы данных уже сказали, я немного дополню. Если данные можно свести к такому представлению как пара ключ-значение, можно использовать базы данных NOSQL или сервисы типа Redis. Помимо стандартного интерфейса доступа и высокой скорости, они обладают хорошим качеством - их можно конфигурировать.
Допустим, ты поначалу настроил сервис на хранение данных в памяти, а потом решил что для надёжности надо отписывать данные на диск (все, не все, сразу, периодически и т.п.). Ты просто прописываешь соответствующий конфиг - и всё, сервис начинает работать по-другому. А для твоего приложения ничего не изменилось (ну, кроме скорости доступа).

Answer 5

[Василий Банников]

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

Массив в оперативной памяти - быстро, но с выделением большого непрерывного участка оперативной памяти могут быть проблемы.
При этом её состояние будет сброшено после перезапуска программы.

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

Answer 6

[Everything_is_not_so_bad]

что будет эффективней, держать постоянно в памяти 5 больших массивов, чтобы искать по ним нужную информацию, или каждый раз искать по .txt файлу.

Эффективнее использовать язык запросов SQL к СУБД (например, SQLite).
Преимущество в централизованном хранении данных и стандарте доступа к ним.
Один-два запроса к СУБД могут заменять порой довольно приличное количество кода (порой даже нетривиального).

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

Если нужно что-то специализированное для данных, то нужно уточнять какова структура данных. Тогда могут понадобиться NoSQL.

Comments

[Antonio Solo]

эффективней для чего ?

[Everything_is_not_so_bad]

Antonio Solo, для типичных сценариев разработки. В особенности, для курсовых. Чтобы разработать решение, которое будет работать лучше, чем реализовано в SQLite или другой СУБД, потребуется вложить немало усилий. Создашь индекс по таблице и куда ещё эффективнее?
SQLite умеет работать с данными и в памяти (если вмещаются) или в файле своего формата. Можно импортировать из CSV, SQL...

[Antonio Solo]

Капитан Пронин, не припомню что бы мне ставили задание со ссылкой на "типичные сценариев разработки" подходы применяемые сильно зависят от конкретных условий.

не хочу вдаваться в детали, но давать совет что использовать не зная а) характер данных б) объем данных в) потенциальное оборудование г) критерий эффективности - это как минимум глупо

[Everything_is_not_so_bad]

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

Чтобы правильно задать вопрос, нужно знать бо́льшую часть ответа

Answer 7

[DollyPapper]

Спорный вопрос. Смотря что мы с данными хотим делать и как часто. Есть возьмем к примеру базы данных, и массив и захотим поискать данные, то вероятно файл (бд) окажется даже выгодней, поскольку поиск в массиве будет занимать O(n) а поиск на диске O(logn) при условии что ищем мы по индексу

Comments

[Владимир Коротенко]

Dude в памяти данные раскладываются тоже по разному.

[Antonio Solo]

поиск в словаре O(1)

[DollyPapper]

Antonio Solo, да, а при чем тут словари?

Answer 8

[Griboks]

Что эффективней

Эффективней для чего? Для скорости разработки эффективнее всего использовать глобальные переменные.