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

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

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

В принципе если современный программист просто будет использовать только оперативную память
то никто ему не сможет ударить по рукам или подойти с какой-то метрикой и чего-то там измерив
сказать что он неправ. Тут уж только падения по OOM и потери информации и performance issues
могут быть каким-то значимым аргументом.
Ответ написан
@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 для скорости обработки и СУБД для долговременно энергонезависимого хранения, найдя приемлемый для своего приложения компромисс.
Ответ написан
Пригласить эксперта
Ответы на вопрос 6
Stalker_RED
@Stalker_RED
Память намного быстрее диска, даже если это SSD или рамдиск.
Но память намного дороже дисков, и если данных много, то возможно дешевле данные читать из файлов.
Сравните сколько стоит HDD на 18Тб и сколько стоит сервер с соответствующим объемом.

Что вы подразумеваете под эффективностью - вам виднее.
Ответ написан
@Wan-Derer
Зобанели на Хабре, волки́ ;((
Если возникает вопрос "память или файл?", это значит что есть какие-то проблемы хранения в памяти: данных много и памяти может не хватить, данные должны сохраниться при перезапуске приложения, данные должны быть доступны из других приложений/инстансов, что-то ещё.
В таком случае задачу хранения/записи/чтения данных лучше поручить отдельному сервису. Про базы данных уже сказали, я немного дополню. Если данные можно свести к такому представлению как пара ключ-значение, можно использовать базы данных NOSQL или сервисы типа Redis. Помимо стандартного интерфейса доступа и высокой скорости, они обладают хорошим качеством - их можно конфигурировать.
Допустим, ты поначалу настроил сервис на хранение данных в памяти, а потом решил что для надёжности надо отписывать данные на диск (все, не все, сразу, периодически и т.п.). Ты просто прописываешь соответствующий конфиг - и всё, сервис начинает работать по-другому. А для твоего приложения ничего не изменилось (ну, кроме скорости доступа).
Ответ написан
Комментировать
vabka
@vabka
Токсичный шарпист
Оба варианта применимы.
Нужно отталкиваться от конкретной задачи, чтобы сказать, какой будет лучше.
Иногда может даже будет эффективнее применить и то и другое одновременно.

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

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

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

Если нужно что-то специализированное для данных, то нужно уточнять какова структура данных. Тогда могут понадобиться NoSQL.
Ответ написан
DollyPapper
@DollyPapper
Спорный вопрос. Смотря что мы с данными хотим делать и как часто. Есть возьмем к примеру базы данных, и массив и захотим поискать данные, то вероятно файл (бд) окажется даже выгодней, поскольку поиск в массиве будет занимать O(n) а поиск на диске O(logn) при условии что ищем мы по индексу
Ответ написан
Griboks
@Griboks
Что эффективней

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы