Python-сообщество

Добрый вечер.

Возникла необходимость в загрузке и обработке .csv файла из 3.5 миллиона строк.
Строки содержат дату, текстовые поля, поля с целыми и рациональными числами.
Некоторые элементы маркируются NaN (по аналогии с матлабовским NaN).

Собственно, вопрос: чем лучше считывать такие данные с целью последующей статистической обработки (данные модифицировать не надо)?

Пробовал loadtxt (из numpy).
В результате получаю одномерный массив картежей, что исключает лёгкое итерирование (например, надо получить i-ый столбец данных и уже не напишешь data).

Основной приоритет - быстрый доступ к данным с возможностью получать часть таблицы.
В дальнейшем планируется генерировать и обрабатывать подтаблицы по запросу (например, объединять в подтаблицы записи, имеющие одинаковые id, но разные временные теги).

Ну и хотелось бы, чтобы решение, по возможности, было масштабируемо на случай обработки файлов в 20-25 миллионов строк.

Засуньте данные в базу данных по вкусу, они для этого и существуют, или Вы хотите выдумать их заново?

Спасибо, думал об этом.

Смущают 2 вещи:
1. Поправьте, если ошибаюсь, но SQLite не поддерживает загрузку и обработку NaN.
2. Какова разница в скорости обработки данных тем же numpy и sqlite?

Рекомендую вам использовать mongodb. Смысл рекомендации простой, там практически нечего настраивать в плане производительности и вы из коробки получите неплохую скорость вставки и чтения записей. А в sqlite/postgres/mysql придётся повозиться с настройкой транзакций и буферов.

Также ещё можно в сторону редиса посмотреть, если все данные в RAM помещаются. Но redis это уже специфичная БД, зависит от того насколько сложная структура данных у вас и насколько сложные выборки.

lorien
Рекомендую вам использовать mongodb.

Автору нужно данные потом активно обрабатывать запросами.
Несмотря на самый развитый среди NoSQL язык Монги, он все таки слабоват.
Но все, конечно, зависит от сложности запросов.

lorien
А в sqlite/postgres/mysql придётся повозиться с настройкой транзакций и буферов.

Зачем?
Сейчас даже Постгри ставится и работает из коробки.
Для указанного объема данных вообще никаких настроек делать не нужно, 25млн строк - это мизер.

Vadimka
1. Поправьте, если ошибаюсь, но SQLite не поддерживает загрузку и обработку NaN.

Начиная с 3.4.0 SQLite при загрузке данных автоматически конвертировала NaN в NULL.
Для последующей обработки запросами NULL все таки удобнее и понятнее с точки зрения правил обработки.
Попробуйте загрузить и посмотреть на результат.
Только грузите с помощью консольной утилиты в batch режиме.
Естественно, это подойдет только, если данные у вас не могут иметь третье логически правильное значение - NaN, отличающееся от числа и NULL.

Lexander
Сейчас даже Постгри ставится и работает из коробки.

Ни ни ни. Постгресс и мускул из коробки шевелятся, не более того, во всяком случае на RHEL.

Блин, где вы такие дистры берете, что они не работают? :/
Впрочем, я все равно посоветовал выше SQLite, он то с полпинка заводится.

Lexander
Блин, где вы такие дистры берете, что они не работают? :/

Вполне себе индустриальный стандарт - Red Hat Enterprise Linux, ну или он же в виде Centos. Из коробки конфиги дают возможность запуститься на самой убогой железке. После тюнинга (ну если у железа есть ресурсы конечно), можно ускорить раз в десять (это личный опыт, с мускулом). Регулярно просматривая журнал медленных запросов можно выжать еще.

PooH
Из коробки конфиги дают возможность запуститься на самой убогой железке. После тюнинга (ну если у железа есть ресурсы конечно), можно ускорить раз в десять (это личный опыт, с мускулом). Регулярно просматривая журнал медленных запросов можно выжать еще.

А, в этом смысле.
Для меня описание “шевелятся, не более того” имеет другое значение.
По условию задачи ожидается рост до всего-то 25 млн строк. А сейчас вообще 3,5.
На таких объемах ничего настраивать не нужно ни в одной из указанных СУБД.