Каковы различные способы доступа к действительно большим CSV-файлам? - PullRequest
0 голосов
/ 15 января 2019

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

Я натолкнулся на ссылку: https://nelsonslog.wordpress.com/2015/02/26/python-csv-benchmarks/, где автор оценил различные способы доступа к CSV и время, затраченное на каждый шаг. Он использовал процесс catdevnull с кодом, как показано:

def catDevNull():
    os.system('cat %s > /dev/null' % fn)

Время, затрачиваемое в этом случае, является наименьшим. Я полагаю, что это не зависит от версии Python, так как время чтения файла остается неизменным. Затем он использует теплую боль, как показано ниже:

def wc():
    os.system('wc -l %s > /dev/null' % fn)

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

Установка x = os.system('cat %s > /dev/null % fn) и проверка типа данных - это строка.

Как os.system читает файл, что время намного меньше? Кроме того, есть ли способ получить доступ к файлам после того, как они прочитаны os.system для дальнейшей обработки?

Мне также было любопытно, почему чтение файла намного быстрее в пандах по сравнению с другими методами, доступными, как показано в приведенной выше ссылке?

Ответы [ 2 ]

0 голосов
/ 15 марта 2019

На основании моего тестирования.Я столкнулся с тем фактом, что гораздо быстрее выполнять запросы в кадре данных pandas, чем запрашивать в базе данных [проверено на sqlite3]

Таким образом, самый быстрый способ - получить csv в качестве кадра данных pandas, а затемзапрос в кадре данных, как требуется.Кроме того, если мне нужно сохранить файл, я могу выбрать кадр данных и использовать его по мере необходимости.Время для извлечения и отмены выбора файла и запросов намного меньше, чем хранение данных в sql и последующий запрос результатов.

0 голосов
/ 15 января 2019

os.system полностью отказывается от контроля, который вы имеете в Python. Нет способа получить доступ к чему-либо, что произошло в подпроцессе после его завершения.

Лучший способ иметь некоторый (но недостаточный) контроль над подпроцессом - использовать модуль Python subprocess. Это позволяет вам взаимодействовать с запущенным процессом, используя сигналы и ввод / вывод, но, тем не менее, невозможно повлиять на внутренние процессы процесса, если у него нет специального API, позволяющего вам это делать. (Linux предоставляет некоторые внутренние компоненты процесса в файловой системе /proc, если вы хотите изучить это.)

Не думаю, что вы понимаете, что означает тест. cat >/dev/null - это базовый уровень, который просто измеряет, насколько быстро система может прочитать файл с диска; Ваш процесс не может быть быстрее, чем позволяет канал ввода / вывода, поэтому это время, которое система тратит на бездействие вообще. В основном вы должны вычесть это время из последующих результатов, прежде чем сравнивать их относительные показатели.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...