Найти - Пользователи
Полная версия: Самый оптимальный вариант чтения из базы, обработки и записи в файл
Начало » Python для экспертов » Самый оптимальный вариант чтения из базы, обработки и записи в файл
1 2
Master_Sergius
Задача:

Прочитать данные из MySQL базы, где может быть много миллионов записей. Каждую запись надо обработать (некая трансформация или вообще пропускается в зависимости от “консистенции”), выходные данные записываются в JSON-файл.

Вопрос:
оптимальное решение?

Первое, что мне пришло на ум: один поток считывает базу кусками, второй поток обрабатывает и пишет в файл. Можно ли здесь прикрутить как-то асинхронный подход и если да, то как? Будет ли выигрыш? Или есть еще какие-то архитектурные готовые решения?

п.с. Python 2.6
ZerG
База данных как раз и нужна что бы обрабатывать данные когда их миллион!
Пока не вижу никаких проблем делать выборки и работать с полученными результатами!
Master_Sergius
Вот такие проблемы:

1) выборка миллиона записей из совокупности таблиц (используя UNION) и за неким критерием длится около 2-х минут;
2) когда же выборка закончена и на момент возвращения данных - cursor.fetchall, миллион записей забирает почти 400 МБ памяти, а это нехорошо;
3) итерирование по курсору (for record in cursor) вместо cursor.fetchall не дало изменений в потреблении памяти или скорости выполнения (или я где-то недопонимаю как работает курсор здесь и в чем тогда разница между итерированием и получением всех записей сразу)

Поэтому, хочется улучшить решение.
izekia
Master_Sergius
может со стороны запроса подойти, я не знаток мускула, как там с паджинацией обстоит?
Iskatel
Master_Sergius

1) Индексы проверь/настрой, EXPLAIN SELECT тебе в помощь.
2,3) cursor.fetchone пробовал?
doza_and
Master_Sergius
выходные данные записываются в JSON-файл.
1. Это непонятно. В один файл или файлов много?. Если в один то стандартными способами потребление памяти не снизить. Более того, потребители файла тоже будут ее жрать. И вообще выгружать данные из базы в json не самая лучшая идея, да и на самоцель тоже не тянет.
2. Время запроса зависит от запроса. Приведите текст. Но если вы собирались на максимальной скорости струячить данные с диска, то очевидно не надо было их в РСУБД класть. :) также как странная идея класть данные в json.
Master_Sergius
Немного поработал над запросом, удалось в 10 раз увеличисть скорость. А насчёт json - файла, это так надо. Потому как в таком формате полученный “пакет” разсылается на различные устройства и всё такое.

И всё же, хотелось бы здесь увидеть какие-то интересные архитектурные решения для подобных задач
Rodegast
> Каждую запись надо обработать (некая трансформация или вообще пропускается в зависимости от “консистенции”)

Хранимки не пробовал использовать?
Master_Sergius
Rodegast
> Каждую запись надо обработать (некая трансформация или вообще пропускается в зависимости от “консистенции”)Хранимки не пробовал использовать?

Ну, такая процедура будет выполняться раз в неделю, стоит ли?
Rodegast
Ну это тебе решать Просто тащить не нужные записи как-то не очень эффективно…
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB