Здравствуйте! Уважаемые пользователи данного ресурса.

У меня есть определенная задача по сбору, хранению и обработке спарсинных данных больших объемов, однако я до сих пор не могу определиться в каком виде эти данные хранить.

Задача подразумевает табличный вид (причем таблица может быть не одна, а несколько связанные между собой).

Среди возможных вариантов хранения данных рассматриваю csv или mdb. Серверная база MySQL не подходит, так как планируется обрабатывать спарсенные данные локально на desktop под управлением Windows.

Собственно сам вопрос вот в чем. Есть ли серьезная разница в производительности между форматом хранения данных csv и mdb если в базе предположительно будет содержаться 300 000 позиций записанных в 50 столбцов в месте со своими свойствами. То есть одна строка в csv это позиция а столбцы ее свойства. По сравнения с хранением того же объема данных в mdb?

Я конечно понимаю, что все очень сильно зависит от алгоритмов извлечения и обработки, но давайте представим, что алгоритмы самые простецкие, не сильно оптимизированные, в общем до тупого простые.

Мне больше по душе конечно csv так как с ним легче работать. Однако с другой стороны к этой задаче больше подходит mdb, но насколько я знаю с ним придется поиграться настраивая драйвер, да и потом та еще пляска с бубном. Или может кто знает библиотеку по работе с mdb которая сводит все запарки на нет?

А может я чего-то еще не догоняю и есть альтернативные пути. Буду признателен за любую помощь и подсказку.

FanTech
Среди возможных вариантов хранения данных рассматриваю csv или mdb. Серверная база MySQL не подходит, так как планируется обрабатывать спарсенные данные локально на desktop под управлением Windows.

Как обрабатывать? Что подразумевается?

Есть легковесная БД из каробки. sqllite. Тем более, что Вы сами написали, что хранение в таблицах.
Что дает база:
1. Нормальный механизм поиска.
2. Нормальный механизм сортировки.
3. Нормальный механизм получения связанных данных.

Для простоты можно использовать ORM. Рекомендую sqlalchemy…

4kpt_III
Как обрабатывать? Что подразумевается?

Производить выборку из базы для выполнения математических расчетов. Результат этих расчетов заноситься в базу не будет.

База нужна для удобного хранения и выборки данных. Принципе все те пункты которые вы описали.

4kpt_III
Есть легковесная БД из каробки. sqllite

А ее можно как-то запаролить или зашифровать? И есть ли библиотека для работы с ней?

FanTech
А ее можно как-то запаролить или зашифровать?

Можно, естественно. Куда уж без этого

FanTech
И есть ли библиотека для работы с ней?

Есть встроенная в питоне, но там нужно хардкорить SQL. Но мы живем в современном мире, поэтому можно использовать готовый ORM (sqlalchemy {выше порог входа, но круче} или pewee {ниже порог входа, но менее крутой + редко используется => меньше профита в дальнейшем}). От ОРМа него и профита будет больше и привязки к БД не будет жесткой. Т.е. захотели - поменяли БД. В этом случае просто изменили драйвер и весь код остался рабочим.

P.S. О каком примерно объеме данных идет речь?

4kpt_III
P.S. О каком примерно объеме данных идет речь?

Предположительно вес будет порядка 300 МБ я думаю.

sqlalchemy не имеет стабильной версии. Что реально напрягает.

Наверное стоит обратить внимание на sqllite. Так как проект рассчитан на длительное время и на постоянное увеличение базы. Необходима стабильность.

FanTech
sqlalchemy не имеет стабильной версии.

Интересно что вы имеете ввиду.

FanTech
Так как проект рассчитан на длительное время и на постоянное увеличение базы. Необходима стабильность.

Если нужна стабильность то точно не mdb. Микрософт не та фирма которая отличается стабильностью.
Написав код на Алхимии вы получаете не просто базу в sqlite а возможность работать с десятком популярных Субд практически без изменения кода.

FanTech
База нужна для удобного хранения и выборки данных.

Задачу хранения и выборки решают хранилища данных, а не СУБД. Базы данных предполагают, что вы будете постоянно их пополнять в произвольном порядке. И запрашивать данные будете в произвольном порядке. Это накладывает ограничения на их организацию, которая ведет к распуханию файлов базы и снижению скорости выборки.

Однако заморачиваться надо если вас не удовлетворяют параметры которые вы получили. Так что озвучте требования к времени на выборку и тип запросов. Как именно вы будете искать данные по которым собираетесь вести расчеты?

doza_and
Интересно что вы имеете ввиду.

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

sqllite при каждом релизе проходит через ряд серьезнейших автоматических тестов (проводится ~ 2 млн тестов), покрытие кода тестами 100% (с августа 2009). По этому можно утверждать о стабильности.

doza_and
Если нужна стабильность то точно не mdb. Микрософт не та фирма которая отличается стабильностью.

Полностью согласен. Этот выбор диктовался не сколько практичностью сколько безысходностью если не найду замены. Просто я не силен в sqllite. Не приходилось с ней работать. Ранее все в вэб было на MySQL.

doza_and
Задачу хранения и выборки решают хранилища данных, а не СУБД.

А здесь можно поподробней? О чем идет речь?

FanTech
Я имею ввиду, что тесты на стабильность этой технологии на сколько я знаю никто особо не проводил.

Алхимия не база и даже не API для доступа к базам, это ОРМ. Данные как были в базах так там и остаются.

FanTech
А здесь можно поподробней? О чем идет речь?

Об этом бесполезно говорить пока вы не заявите задачи. Поле слишком большое.
Начиная с классического https://ru.wikipedia.org/wiki/OLAP
Отдельный класс базы для временных рядов. https://en.wikipedia.org/wiki/Time_series_database
OLAP Для бедных http://www.h5py.org/
Есть еще графовые БД, NoSQL, и проч и проч…. Каждое имеет свою область применения.

FanTech
если база будет таких больших размеров

FanTech
Предположительно вес будет порядка 300 МБ я думаю.

Побойтесь бога. Это большой размер? Такое можно одним пиклом хранить. Файл прочитается за единицы секунд. Получите все данные в памяти и максимальное быстродействие, и сниженную устойчивость к отказам оборудования в придачу.

FanTech
Наверное стоит обратить внимание на sqllite. Так как проект рассчитан на длительное время и на постоянное увеличение базы.

FanTech
То есть не возможно понять какие глюки могут произойти если база будет таких больших размеров.

Да выдерживает она несколько гигабайт. Просто она не оптимальна, так как всё хранится в одном файле.

FanTech
Просто я не силен в sqllite. Не приходилось с ней работать. Ранее все в вэб было на MySQL.

Это как MySQL только немного хуже по возможностям (многих операций нет). MySQL лучше SQLite, потому что там всё есть. Если есть А, то есть и Б, тогда как в SQLite может быть А, но не быть Б.

А от csv это отличается тем, что в одну базу SQLite можно засунуть несколько разных csv, а потом ещё и связать их между собой.

FanTech
sqlalchemy не имеет стабильной версии. Что реально напрягает.

Посмеялся от души. Спасибо.