|
|
||||||
Как распарсить список словарей?28.09.2018, 11:37. Показов 5849. Ответов 66
Метки нет (Все метки)
Есть список словарей, объем любой, разграничиваются только по id
наборы данных тоже ...
нужно привести к удобочитаемому виду и подготовить данные к передаче в базу данных, для последующего анализа
0
|
||||||
| 28.09.2018, 11:37 | |
|
Ответы с готовыми решениями:
66
Массив: Создать БД как список словарей, получив информацию из файла
Список из словарей |
|
|
|
| 29.09.2018, 23:34 [ТС] | |
|
Кстати, для лучшего понимания вопроса по хранению данных в реляционных базах данных, можно почитать это: http://liberatum.ru/blog/mongodb
Кликните здесь для просмотра всего текста
На выходных сортировал свою библиотечку и надолго задержался на книге «MongoDB в действии». Кидать ее в раздел SQL было бы неправильно, так как Mongo — это как раз NoSQL, а создавать новый раздел из-за одной книги не хотелось. Я открыл книгу и стал листать. В конце предисловия была фраза, которая меня сначала насмешила, а потом заинтриговала: «Многие разработчики признавались, что при работе с ней [с Mongo] испытывают ощущения чуда и даже счастья». Я подумал, что и мне тоже чудо не помешает и уж тем более дополнительная порция счастья. И начал изучать, что же такое Mongo. Что же такое Mongo? Оказывается, это СУБД, которая в отличии от MySQL/SQLite/PostgreSQL и прочих SQL ориентирована на работу не с табличным представлением данных, а на работу с документами. Чтобы было понятнее, давайте сначала рассмотрим работу табличной СУБД на примере Либератума. Как хранятся данные в MySQL на примере работы Drupal Либератум работает на движке Drupal, который весьма интенсивно работает с MySQL. Для того, чтобы вы имели возможность увидеть произвольную web-страницу, Drupal проделывает следующее: 1. Из адреса страницы вычленяется виртуальный адрес и создается запрос к таблице url_alias, чтобы получить внутренний идентификатор материала (номер узла в терминологии Drupal). Например, пользователь запрашивает страницу http://liberatum.ru/exclusive/... hto-novogo. Тут же из адреса вычленятся необходимая для идентификации документа часть и делается запрос: SELECT src FROM url_alias WHERE dst='exclusive/windows-10-chto-novogo' Ответ будет таким: node/26254 2. Теперь по идентификатору узла (26254) можно извлечь заголовок статьи и идентификатор автора. Эти данные хранятся в таблице node: select title,uid from node where nid=26254 Ответ: title uid Что нового в Windows 10 1 В самой таблице node тело документа... отсутствует. Дело в том, что Drupal позволяет работать с ревизиями. То есть, каждая статья может иметь несколько версий. Поэтому для ревизий выделена отдельная таблица node_revision. В ней по идентификатору узла (nid) можно найти все версии данного документа и выбрать актуальную. Именно в этой таблице содержится тело документа и его анонс. Делаем еще один запрос: SELECT body,teaser,vid FROM node_revision WHERE nid=26254 Если получаем несколько копий, то выбираем последнюю. Думаете все, можно собрать и показать готовую страницу? Нет. Потребуется определить имя пользователя по его идентификатору (uid). Это запрос к таблице users. Потом нам потребуется найти все теги к статье. Это вообще отдельная история. Теги хуже всего вписываются в табличную модель представления данных, поэтому их хранение организовано через хитро закрученную жопу. Сейчас Билл Гейтс покажет вам как именно: Спасибо, Билл! Достаточно сказать, что для хранения тегов используется сразу 7 разных таблиц, а для их получения делаются запросы с объединением. Минус в том, что объединение таблиц — одна из самых медленных операций. Вот эти таблицы: term_data; term_hierarchy; term_node; term_relation; term_synonym; vocabulary; vocabulary_node_types. Хорошо, получили теги, но теперь-то всё? Опять нет. Нам нужно получить количество просмотров документа. Берется оно из таблицы node_counter (обновление этого значения пока не рассматриваем, но его нужно увеличивать каждый раз, когда пользователь запрашивает этот узел, а это еще один запрос). Потом нам надо из таблицы node_access проверить, а имеет ли вообще пользователь право просматривать этот документ. Всё? Опять нет! Комментарии. Для них есть отдельная таблица comments. Работать с комментариями на первый взгляд просто и тут видны достоинства табличного представления данных. Мы можем получить одним запросом сразу все комментарии к документу: SELECT cid,uid,comment FROM comments WHERE nid=26254 Получаем сами комментарии, идентификатор комментария (он нужен для ссылки) и идентификатор пользователя. Ой, постойте, как идентификатор пользователя? Неужели опять запросы к таблице users? А как же иначе получить не номер, а юзернэйм? А ведь помимо страницы с текстом есть еще боковые блоки с: новыми материалами; с самым читаемым; с последними комментариями; со статьями на похожие темы; и т.п. Даже переводы интерфейса хранятся в отдельной таблице. Нет, сразу в двух отдельных таблицах: locales_source и locales_target. Почему Drupal мертв Так как вы думаете, сколько всего MySQL приходится обработать запросов, чтобы предоставить данные для сборки всего одной страницы? От 300 до 1000 и больше. Да, с помощью хаков можно и нужно снизить количество запросов до минимума, но для этого нужно обладать глубокими знаниями Drupal и эту хакнутую копию движка потом будет очень трудно обновлять. Кто-то может сказать, что ничего страшного не происходит. Ведь СУБД на то и СУБД, чтобы трудиться. Какая разница, 5 запросов на страницу или 500? Для программиста это совершенно неважно. Для пользователя тоже — ну подождет на секунду или две дольше... И такая точка зрения имела право на существование, но только до одного очень важного момента — пока поисковики не стали считать время отдачи страницы одним из важнейших факторов ранжирования. Можно перефразировать это так: поисковик никогда не даст на сайт больше посетителей, чем сайт сможет обработать. Drupal всегда преподносился как CMS (система управления контентом), которая по максимуму использует возможности СУБД. Такой подход в сочетании с ориентированностью этих СУБД на работу с табличными данными привел к неприемлемым накладным расходам. Поэтому, выбирая Drupal вы либо негласно соглашаетесь с тем, что ваш сайт будет иметь непробиваемый потолок популярности, либо вы готовы к постоянным высоким тратам на высококлассных специалистов, либо у вас неограниченное количество денег на аппаратное обеспечение. В Drupal 8 нам обещают переход на ООП и следует полагать, что появится и ORM, который еще сильнее усугубит ситуацию. Можно ли испытывать в таких условиях ощущения чуда и даже счастья? Но что-то я увлекся похоронами любимой CMS. Наша задача не в том, чтобы поглубже закопать усопшего, а в том, чтобы показать, что табличная ориентированность не очень подходит для web-использования. Все же основа web — страница. Mongo — один запрос на страницу Разработчики Mongo выбрали другой подход. Вместо хранения кучи строк, раскиданных по разным таблицам, пользователь может сохранять, искать и извлекать документы целиком. Под документами подразумевается не ODF и даже не DOCX, а некие сущности на языке JSON. Например, на JSON можно описать документ, состоящий из заголовка, тела статьи, имени автора, туда же можно поместить теги и комментарии. Одна web-страница — один документ — один запрос. Конечно, так делать не рекомендуется, но теоретическая возможность есть. Другие приятные преимущества Mongo: нет таблиц — нет необходимости описывать схему базы данных; нет схемы базы данных — можно менять структуру документов как угодно и не предупреждать об этом СУБД; эта СУБД появилась относительно недавно и избавлена от старческих болезней MySQL/PostgreSQL и т.п. Например, Mongo изначально рассчитана на облачное применение и легко масштабируется как вертикально, так и горизонтально; и т.д. Работать с Mongo приятно. Вот примеры на Ruby: Подключение к базе: client = MongoClient.new Пароли, имена пользователей и т.п. не нужны, хотя при необходимости можно задать и их. Выбор базы данных: db = client.db("dbname") Выбор коллекции (совокупность документов одного типа): coll = db.collection("collectionName") Создание документа и помещение его в базу: doc = Hash.new doc["pid"] = 1 doc["title"] = "Заголовок статьи" doc["body"] = "Тело статьи" doc["path"] = "/path/to/page" coll.insert(doc) Извлечение документа по номеру статьи (pid): coll.find("pid" => 1) Следует отметить, что разработчики Mongo постарались сделать работу с базой максимально приятной для программистов. Например, зачем заставлять программиста создавать базу данных, если ее можно создать автоматически, когда появится запрос на подключение к ней. Или зачем заставлять программиста создавать коллекцию, если ее можно создать за него автоматически, сразу же, как только придет запрос на вставку новых данных в несуществующую ранее коллекцию. Программисту остается написать всего несколько строчек кода и можно отправляться пинать балду. В это время его коллеги, работающие с SQL-базами данных, будут вынуждены придумывать схемы размещения данных и постоянно актуализировать их с помощью миграций. А еще любители SQL должны насиловать свой мозг, изобретая хитрые многоэтажные объединения нескольких таблиц с помощью вложенных запросов и тормозных операций типа JOIN. Зачем все это? Программист, использующий Mongo напишет всего пару строк кода и пойдет в бухгалтерию за зарплатой. Все ли так прекрасно и где вообще тесты? В следующей части статьи о райском наслаждении от Mongo попытаемся сконвертировать базу данных Либератума из MySQL в MongoDB, запилим тестовый Либератум и сравним время генерации страниц. Чтобы было интереснее, для сравнения возьмем еще и SQLite. Источник: http://liberatum.ru/blog/mongodb
0
|
|
|
964 / 719 / 276
Регистрация: 10.12.2016
Сообщений: 1,764
|
|
| 29.09.2018, 23:41 | |
|
у тебя есть вложенные словари/списки, это структура типа дерево. в sql таблицу это непросто загнать
1
|
|
|
|
|
| 29.09.2018, 23:57 [ТС] | |
|
Следует отметить, что разработчики Mongo постарались сделать работу с базой максимально приятной для программистов. Например, зачем заставлять программиста создавать базу данных, если ее можно создать автоматически, когда появится запрос на подключение к ней. Или зачем заставлять программиста создавать коллекцию, если ее можно создать за него автоматически, сразу же, как только придет запрос на вставку новых данных в несуществующую ранее коллекцию. Программисту остается написать всего несколько строчек кода и можно отправляться пинать балду. В это время его коллеги, работающие с SQL-базами данных, будут вынуждены придумывать схемы размещения данных и постоянно актуализировать их с помощью миграций. А еще любители SQL должны насиловать свой мозг, изобретая хитрые многоэтажные объединения нескольких таблиц с помощью вложенных запросов и тормозных операций типа JOIN. Зачем все это? Программист, использующий Mongo напишет всего пару строк кода и пойдет в бухгалтерию за зарплатой.
Источник: http://liberatum.ru/blog/mongodb Добавлено через 40 секунд * * * vic5710, да, я это понимаю, именно это, меня и выбивает из колеи... Добавлено через 6 минут в чем я уже неоднократно убедился... MySQL уделывает всех на небольших наборах данных (до 50 тыс. записей в таблице). Потом на сцену выходит Postgres. Ну а для гигантских объемов слабоструктурированных данных по вашему совету, да и в сети рекомендуют: лучше подходит MongoDB. Только должно быть несколько выделенных под одну Монгу сервера, иначе профит будет незаметен.
0
|
|
|
1741 / 913 / 480
Регистрация: 05.12.2013
Сообщений: 3,074
|
||
| 30.09.2018, 00:15 | ||
|
Но вообще, нужно, конечно, попробовать с mongo, тем более особой обработки в базе данных не делается
1
|
||
|
|
|
| 30.09.2018, 01:59 [ТС] | |
|
vic5710, из всего этого, после анализа написанного, меня волнуют еще несколько вопросов:
1. Ассинхронность и неблокируемость при обработке запросов 2. Борьба с дублированием данных (чтобы собирать только обновления) и избегать дублей одной записи (с этим уже столкнулся) 3. Инвалидация сохраненных данных и параллельное добавление новых. В случае MongoDB это кеш, без долговременного согласованного хранилища, но в моем случае - хранилище есть. По-этому, третий вопрос, как-бы зависает =) Добавлено через 1 час 25 минут ТабуретY, да, я тоже пришел, после прочтения этого материала: https://habr.com/post/231213/ к тому, что если не делается обработки данных, а лишь "складирование", то целесообразно использовать именно mongodb, лить в нее со всех источников... а после, использовать export, для пуляния данных по запросам в постоянную базу. Выходит, теперь, нужно понять, как не допустить дублей в json и при записи в базу и как потом доливать только новое
0
|
|
|
964 / 719 / 276
Регистрация: 10.12.2016
Сообщений: 1,764
|
||||||
| 30.09.2018, 08:11 | ||||||
|
1. aiohttp сейчас в тренде
2. например по ключу date, это надо смотреть конкретную структуру
0
|
||||||
|
|
||
| 30.09.2018, 08:43 [ТС] | ||
|
а как потом извлекать, например, по owner_id и date ведь date нужно сконвертировать? Или нет? Добавлено через 18 минут * * * и нужно проверять, или как-то отслеживать, есть ли, в основной базе этот материал (перед экспортом) или нет
0
|
||
|
964 / 719 / 276
Регистрация: 10.12.2016
Сообщений: 1,764
|
||||||
| 30.09.2018, 08:44 | ||||||
|
ты почитай про монгу, там много инструментов для поиска/сортировки
походу у тебя time.ctime для даты используется https://metanit.com/nosql/mongodb/2.4.php
0
|
||||||
|
|
|||||||||||
| 30.09.2018, 12:37 [ТС] | |||||||||||
|
vic5710, вот, по примеру файла sqlite_core начал делать https://github.com/IRIP/postov... go_core.py
файл для работы с базой вынес в отдельный bases и пока застрал =) Добавлено через 9 минут и вот этот код нужно тоже переписать под новую функцию
0
|
|||||||||||
|
964 / 719 / 276
Регистрация: 10.12.2016
Сообщений: 1,764
|
||||||
| 30.09.2018, 13:09 | ||||||
|
ну и в чем траблы? создаешь sqlite с полями id,date,text и инсертишь из запроса
джанга до добра не доведет, я тебе говорил ![]()
из реквеста ты получаешь json - комбинация словарь/список, в монге исходная единица - словарь. ты привел пример списка словарей, его надо вставлять в БД поэлементно. если получаешь словарь - можно вставлять как есть
1
|
||||||
|
|
||
| 30.09.2018, 13:20 [ТС] | ||
|
vic5710, да то уже не django ... пока не до нее... каркас проекта написан еще в апреле, теперь работа ведется над сбором, классификацией и обработкой данных
вот как раз это все ... Меня "поля" выбешивают... или нужно как-то умудриться из vk_api выдирать фото, видео, файлы, текст, теги, дату, урл поста, дату и id (уникальные/универсальные для любого источника характеристики) Добавлено через 1 минуту но я пока не дошел умом до этого... ведь вставлять нужно с проверкой на дубли, ведь вставлять нужно только от старых к свежим, ведь вставлять нужно только свежее...
0
|
||
|
964 / 719 / 276
Регистрация: 10.12.2016
Сообщений: 1,764
|
||||||
| 30.09.2018, 14:16 | ||||||
|
в работе с БД лучше три дубля, чем потеря инфы
дубликаты удалить просто
0
|
||||||
|
964 / 719 / 276
Регистрация: 10.12.2016
Сообщений: 1,764
|
|
| 30.09.2018, 20:47 | |
|
скорее нет чем да. при обрыве связи транзакция не пройдет, если ты имеешь в виду БД клиент-сервер.
а если парсишь инет - возможно всякое. я делал так : накопитель->промежуточная фильтрация->коммит в БД
0
|
|
|
|
|
| 30.09.2018, 22:52 [ТС] | |
|
vic5710, вот еще столкнулся. Оказывается mongo нужно ставить дополнительно в систему...
а sqlite уже стоит, по умолчанию, рядом с python Добавлено через 15 минут что-то мне кажется, что не уйти от варианта записи в sqlite =(
0
|
|
|
964 / 719 / 276
Регистрация: 10.12.2016
Сообщений: 1,764
|
|
| 01.10.2018, 08:26 | |
|
ты получаешь json с реквеста.
если ты знаешь его структуру, можешь сразу извлекать нужные значения и писать хоть в БД, хоть в текстовый файл. если не знаешь - нужно анализировать json, у него формат может быть произвольный. я так понял что у тебя проблемы с парсингом json. можешь использовать mongodb-compass для визуализации. в монге используется JS скрипты, в принципе можешь и без питона обойтись.
0
|
|
|
|
||||||
| 01.10.2018, 09:24 [ТС] | ||||||
|
vic5710, вот я и не понимаю, как писать =(
В моем случае: https://github.com/IRIP/postov/blob/master/main.py
и вкладывать из main.py - posts только выбранные данные. какие, чуть ниже напишу
0
|
||||||
|
964 / 719 / 276
Регистрация: 10.12.2016
Сообщений: 1,764
|
|||||||||||
| 01.10.2018, 10:49 | |||||||||||
|
чот я не понимаю твоих страданий
1. анализ json 2. создание БД с нужными полями 3. получение JSON (posts) и запись в БД
или так
0
|
|||||||||||
|
|
||
| 01.10.2018, 10:54 [ТС] | ||
|
ТЕКСТОВАЯ ТАБЛИЦА post table
post_id - текущий id для избежания дублей и ссылки на вложения id - уникальный идентификатор записи, предназначенный для предотвращения повторной отправки одинаковой записи. date - дата размещения сообщения post_type text lat - long (lng) - координаты place_id post_source - источник profiles АТТАЧИ - attachments table post_id photo — фотография; video — видеозапись ; audio — аудиозапись; doc — документ; page — wiki-страница; note — заметка; poll — опрос; album — альбом; market — товар; market_album — подборка товаров; audio_playlist — плейлист с аудио. url owner_id - ссылка на владельца (авторские права) * * * Чего еще не хватает? Каких полей? Добавлено через 59 секунд
0
|
||
|
964 / 719 / 276
Регистрация: 10.12.2016
Сообщений: 1,764
|
|
| 01.10.2018, 10:57 | |
|
ну тогда пункт 1
как записывать по известным ключам я тебе описал
0
|
|
| 01.10.2018, 10:57 | |
|
Список, состоящий из словарей Список словарей. Групповая обработка
Удаление пустых словарей и список из структуры Не могу правильно отфильтровать список словарей Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
10 сукцессия. Питон код войны грибов и растений
anaschu 27.06.2026
import numpy as np
class PlantAgent:
def __init__(self, name, strategy, initial_biomass):
self. name = name
self. strategy = strategy # "greedy" (широколиственные) или. . .
|
сукцессия 9. Математика подлости: как растения предали грибных друзей
anaschu 27.06.2026
Статья 2. Глобальная фосфорная война: эволюционно-экономические механизмы распределения биомов Земли
Введение: Экологический рынок как игра с нулевой суммой
Традиционная экология долгое время. . .
|
сукцессия 8. Как я спорил с ИИ, которые - агенты растений и ненавистники грибов!
anaschu 27.06.2026
Статья 1. Хроники грибного восстания: как Сократов диалог разрушил академические догмы ИИ
Введение: Синдром «цифрового учебника»
Современные большие языковые модели (LLM) обладают колоссальным. . .
|
Главный вопрос моделирования сукцессии
anaschu 27.06.2026
главный вопрос.
Если эктомикориза лучше добывает недоступный фосфор. И ее масса максимальна из всех.
А широколиственный лес тоже имеет самую крутую биомассу.
То почему не возникло их симбиоза? Это. . .
|
|
сукцессия 6. Питон реализация энилоджиковской модели, картинка про Центральную часть будущей модели
anaschu 26.06.2026
Етить. ИИ мне на основе моего старого файла R создал вот эту вот хмерь на пайтоне.
Это уже новая модель, модель сукцессии грибной.
потоки фосфора, азота. Углерода.
5 видов организмов.
Я даже. . .
|
Как замкнутый ядерный цикл решит проблему недостатки фосфора? Био миграция фосфора со дна океана
anaschu 26.06.2026
Биологический лифт: Концепция подъема фосфора со дна океана с помощью ЗЯТЦ
Предлагаю на обсуждение альтернативу тяжелому промышленному бурению океанического дна. Вместо сложной инженерии мы можем. . .
|
сукцессия 5
anaschu 26.06.2026
ПЛАН РАЗРАБОТКИ математической модели сукцессии микоризных систем
Переход AM → EcM (Endo + ErM) · Шумилов А. С. · ИФХиБПП РАН · Пущино · 2026
. . .
|
сукцессия 4
anaschu 25.06.2026
Более детализированный план разработки
План доработки модели динамики микоризных симбиозов (EcM с гистерезисом)
Цель: Реализовать логику переключения между эрикоидным (ErM) и эктомикоризным. . .
|