Тогда условный «Яндекс» тоже должен платить налог на прибыль от показов рекламы жителям, допустим, Свердловской области в бюджет оной… Кстати, в Екатеринбурге вроде и офис есть: как вариант, можно платить в местный бюджет долю налога на прибыль, пропорциональную численности сотрудников в этом офисе. Местные даже больше будут рады.
Но это мелочи, места уплаты налогов многих крупнейших налогоплательщиков федерального и московского бюджетов тогда тоже следовало бы перераспределить. Тем более что многие из них уже сейчас называют себя «ИТ-компаниями», другие же стремительно «цифровизуются».
Обычно бизнес-приложения принято разделять на два контура: OLTP и OLAP.
В OLTP люди обычно принимают оперативные решения и отражают уже произошедшие события, OLAP же используется для принятия стратегических решений.
Смотря что за бизнес, где и чей… Вот Gartner всем предсказывает операционализацию аналитики и аналитизацию операционной деятельности; сontinuous intelligence взамен business intelligence.
Там, где это счастье уже наступило, хотят не отдельных OLTP и OLAP, а того, что называют HTAP и «translytical».
С этой точки зрения верным путем идут товарищи. Только пару терабайт какой-нибудь NVRAM этому СКД добавить, конечно, бы.
Мне это кажется жизнеспособным, правдоподным и интересным. Возможно, что-нибудь похожее когда-нибудь стихийно сложится, даже хотелось бы надеяться. Может быть, перечисляемые вами трендовые технологии будут сочетаться и какими-то другими способами.
Но, к сожалению, не могу сходу вспомнить случаев из истории ИТ, когда объединение двух больших идей давало бы большую третью. Кажется, что обычно получается пересечение размером в пару стартапов. Впрочем, каждый стартап требует много работы… Раз у вас тут идеи для дюжины стартапов, давайте побуду в роли ментора.
Зачем семантической сети блокчейн?
В Semantic Web Layer Cakе есть до сих пор не испеченный коржик под названием «Trust». Блокчейн-то бы туда, быть может. И наверняка что-то написано на этот счет, но больше глядят не в сторону блокчейна.
Что касается использования блокчейна как хранилища для RDF, а не как некоей верифицирующей обертки. Помимо «страниц на бесплатном хостинге» бывают специализированные RDF-хранилища, позволяющие делать к этому RDF нетривиальные запросы. Сделать triplestorе поверх какой-то ledger database наверняка можно, но вызывает вопросы производительность.
Про обратное, семантизацию блокчейна, тоже какие-то статьи есть.
Где, как не в семантическом графе, можно найти...
Кстати, вот коллективное письмо 20+ гуглеров примерно о том же (вокруг него потом еще публицистика была). Неплохо бы, дескать, научить ML работать с графами. А то больно много «defining characteristics of human intelligence» пока что «remain out of reach for current approaches».
С другой стороны, а что лучше нейронной сетки проанализирует граф...
Насколько знаю, сейчас тут доминирующий подход — это graph embedding, т. е. как word embedding, но для графов. Дескать, давайте похерим всю внутреннюю структуру графа: лучший KR-формализм — линейное пространство достаточно большой размерности… Мне это ваше утверждение кажется большим авансом.
ОК, согласен. Правда, хранение логов тоже можно организовать по-разному: хранить их более сырыми или менее сырыми. Например, в Firefox в базе places.sqlite в таблице moz_places есть предвычисляемый столбец rev_host, позволяющий облегчить типовые тяжелые запросы.
Но я, конечно, слабо представляю себе характер и масштаб задач Яндекс.Метрики. Кажется, возможные подходы к организации хранения данных в ней были рассмотрены в этой статье.
o6CuFl2Q, а можно попросить вас добавить в бенчмарки что-нибудь на тему джойнов? А то правда производит впечатление какой-то строкогрызки.
— Алекс, это ведь будет LPG-граф. Так давайте и будем хранить его в графовой СУБД, а коэффициенты преобразований вычислять запросами. Что у вас там есть развернутого? Neo4, говорите… Ну тогда так:
MATCH (foot:Unit {name:'foot'}), (meter:Unit {name:'meter'})
WITH shortestPath ((foot)-[:RATIO*]-(meter)) AS p
WITH nodes(p) AS ns, relationships(p) AS rs
WITH [i IN range(0, length(rs)-1) |
CASE
WHEN ns[i] = startNode(rs[i])
THEN rs[i].ratio
ELSE 1/rs[i].ratio
END
] AS ratios
RETURN reduce (acc = 1, r IN ratios | acc * r)
Да, согласен… Думаю, графовая СУБД с поддержкой правил вывода позволила бы последовательно вычислить наилучшие с точки зрения точности попарные коэффициенты. Конечно, по соображениям производительности лучше не выводить их при каждом запросе, а единожды материализовать.
— Добро пожаловать в Google Knowledge Graph, сынок.
(упс, промахнулся, а тем временем уже написали; еще здесь было про то, что люблю иногда умышленно пощелкать по баннерам с целью нанесения ущерба рекламным бюджетам, к чему, видимо, и относился ответ на этот коментарий)
А что, всемогущий ML пока не может дать ответ на вопрос, почему минусуют?
За собой заметил, что на Stack Overflow плюсую довольно много и минусую совсем мало, здесь же плюсую много и минусую тоже довольно много. Вряд ли причина только в различии «жанров» материалов тут и там. Может быть, дело еще и в том, что там есть и другие способы «воздействия», помимо +1 и -1.
Здесь минусую примерно по тем же причинам, что и все, если судить по комментариям и результатам опроса. Из отличий:
иногда ставлю «-1» тексту явно новостного характера, если он размещен не в разделе «Новости»;
бывает, меланхолично минусую заплюсованные с первых секунд статьи в корпоративных блогах.
Впервые в России на одной площадке форум объединит тех, кто определяет стратегию работы с корпоративными данными, и всех, кто воплощает ее в жизнь с помощью конкретных технологий, решений и инструментов.
Организатор: CNews Conferences Когда: 19 сентября 2019 Где: уточняйте у организаторов Стоимость: бесплатное для представителей заказчиков (при подтверждения регистрации организаторами), 18000 для представителей вендоров и системных интеграторов.
Тема очередной конференции CNews — «„Цифровая экономика“ в действии».
О ходе программы «Цифровая экономика» и ее результатах за первый год, о законодательных инициативах, цифровизации регионов, крупных проектах и кейсах расскажут участники конференции. CNews Conferences приглашает принять участие в мероприятии представителей министерств, ведомств, органов госвласти, а также представителей российского рынка ИТ, системных интеграторов.
Neo4j я указал бы по той причине, что самая популярная. Дальше для полноты картины хочется указать что-то с поддержкой Gremlin в противоположность Cypher; что-то с поддержкой модели RDF наряду или в противоположность поддержке LPG; что-то облачное в противоположность on-premise. А позиция всего одна осталась. Но вот Neptune позволяет проиллюстрировать все эти «альтернативы» одним примером.
Если облачность читателю заведомо неинтересна, можно указать AnzoGraph. Он правда, скорее OLAP-решение (кстати, вот еще одна «координата»), создан выходцами из IBM Netezza и Amazon Redshift, но это современный такой OLAP, ближе к HTAP даже.
Короче говоря, выбор обусловлен сугубо дидактическими соображениями. Из этих же соображений не стал бы указывать CosmosDB, OrientDB, ArangoDB, которые следуют сразу за Neo4j на DB-engines. «На самом деле» они документные, как пишу об этом здесь.
Если же пытаться рекомендовать…
В плане производительности Neo4j обычно «сакральная жертва» во всех бенчмарках. Но раз у вас не что-то «высоконагруженное», может, и хватит. Кстати, совсем «встраиваемое» не рассматриваю, раз вы все-таки хотите team-версию.
Разные enterprise-характеристики (та же горизонтальная масштабируемость) вам тоже, видимо, не очень нужны будут, да? Тогда круг кандидатов расширится. Если требуется с возможностью бесплатного использования в коммерческом продукте или опенсорсное, естественно, сузится.
Мультимодельность и развитые API (language integrated queries и пр.) в перспективе сокращают время разработки. «В перспективе» — это чаще в «следующем проекте», конечно, но как знать, может, успеется и в текущем. Так что ArangoDB и OrientDB я бы вернул в список кандидатов.
Тут интереснее ваша задача. Я-то, конечно, не удивлен, нынче повсюду «connected datа» и пр., но все же интересно узнать больше конкретики о вашем проекте, требующем использования графовой СУБД. Разумеется, эта конкретика важна и при выборе СУБД. Можно в личку.
Ну и вариант написать собственную СУБД, оптимизированную под задачи, быстродейстующую и с низкоуровневым доступом тоже никто не отменял, он даже все более популярным становится.
Понимаю вашу аргументацию. Но вдруг Илон Маск захочет оплатить съемки чего-то типа этого в космическом масштабе. Чтобы тело двигалось ну ровно-ровно со второй космической. Тоже единственным дублем не обойтись будет.
Я-то имел в виду скорее ту ситуацию, когда поле силы притяжения, действующей на тело, можно считать однородным на протяжении всей траектории движения тела, направление и величина силы одинаковы в любой точке траектории. Эту силы чаще силой тяжести называют в таких случаях :-).
а также графические базы данных и поисковые системы, такие как Elasticsearch и Solr.
Довольно странно их объединять, что автор, по-видимому, делает, не приводя примеров графовых СУБД. Если бы меня попросили привести ровно два примера графовых СУБД, указал бы на Neo4j и AWS Neptune (спросите почему).
Ну и, конечно, «графовые», а не «графические». Google Translate переводит «graph databases» корректно, а вот Яндекс.Переводчик — нет.
Наверное, мы не очень друг друга поняли. Мое маленькое уточнение на тему «удобство разработчика или удобство пользователя» касалось работы с массивами, паддингов в 15 байт и т.д. Оно не касалось колоночной организации хранения.
Или вы и вправду думаете, что колоночная организация хранения — исключительно для удобства разработчика СУБД? Что, например, создатели Amazon Redshift перепиливали PostgreSQL для того, чтобы потом (когда?) было удобнее им самим, а не пользователям AWS? Решили сами заняться рефакторингом Postgres, так сказать? Вот это уж точно будет «психбольница в руках пациентов».
Или тут имелись в виду «колонки» не в том же смысле, в котором ClickHouse является СУБД с колоночным хранением, и это я вас неправильно понял?
И немного масла в огонь
Не сочтите, конечно, за обесценивание ваших трудов. Посмотрев «близкие к реальным» данные и запросы Яндекс.Метрики, я понадеялся, что такие данные и запросы составляют меньшинство, что это не то, для чего создавался и предлагается использовать ClickHouse. Конечно, не то чтобы благородные доны совсем не занимались разбором строк, но все же они предпочитают работать с «things, not strings», как по другому поводу выразился тот, кого тут, наверное, нельзя называть. Но тогда и эффективная обработки строк — достаточно второстепенная задача.
Она летит не по параболической, а по гиперболической орбите. Это говорит о том, что комета не является объектом нашей Солнечной системы, а прилетела издалека.
Мне кажется, объекты Солнечной системы, летающие по чисто параболическим орбитам, летают обычно недалеко и недолго и/или могут быть названы таковыми с большой натяжкой. Понятно, что здесь имеются в виду почти параболические орбиты (эллиптические с большим эксцентриситетом), но зачем школьников смущать.
Great job (и статья, и материал для нее), спасибо!
В ClickHouse тщательно продумана организация хранения данных в памяти — по колонкам.
Мне кажется, корректнее говорить, что организация хранения тщательно оптимизирована для решения тех задач, для которых СУБД предназначена. А то создается впечатление, что раньше просто не умели подумать и поэтому хранили по строкам. Впрочем, и СУБД с колоночным хранением — не невидаль.
С такими массивами очень удобно работать.
Речь ведь идет об удобстве разработчика, а не конечного пользователя, верно? Здесь можно вспомнить название книжки Купера, но раз уж это статья разработчика и для разработчиков, то ОК. К тому же нынче заметен тренд на создание СУБД заказной разработки и с низкоуровневым доступом.
Просто я удивился, что в названии статьи в блоге Яндекса отсутствует слово «Яндекс» и подумал, что зашкаливающий маркетинг будет внутри. Но нет, нашлись только вот такие следовые количества. В остальном см. первый абзац.
Официальные исследователи могут теперь в исследовательских целях автоматически собирать и обрабатывать данные (text and data mining, TDM), если это не создает проблем в функционировании ресурса, даже если в иных случаях это запрещалось бы законодательством об авторских и смежных правах. Можно даже на какое-то время сохранять собранное локально для верификации результатов исследований.
Но скрапить персональные данные GDPR почти прямо запрещает, как выше уже писали в комментариях.
Пользуясь случаем, попиарю свою предыдущую статью. В ней недаром в описании сквозного примера говорится о базе, хотя обычно правильнее говорить о схеме, и название таблицы тоже неспроста такое. Вот таким эзоповым языком скоро будем все политические новости писать.
Надо взять на вооружение: «Господин участковый, здесь курить запрещено, поэтому не мог я здесь курить, отстаньте».
Так-то давняя история об отличии деонтических модальностей от алетических. «Запрещено» ведет себя не так, как «невозможно», «обязательно» — не так, как «необходимо». Из запрещенности чего-либо не следует его недействительность, а из обязательности действительность.
Ну и вообще-то не по адресу обратилась гражданка, да и Роскомнадзор может и вправду не мочь…
Правильно ведь понимаю, что язык назван в честь Гейтинга? Добавьте в статью!
Тогда условный «Яндекс» тоже должен платить налог на прибыль от показов рекламы жителям, допустим, Свердловской области в бюджет оной… Кстати, в Екатеринбурге вроде и офис есть: как вариант, можно платить в местный бюджет долю налога на прибыль, пропорциональную численности сотрудников в этом офисе. Местные даже больше будут рады.
Но это мелочи, места уплаты налогов многих крупнейших налогоплательщиков федерального и московского бюджетов тогда тоже следовало бы перераспределить. Тем более что многие из них уже сейчас называют себя «ИТ-компаниями», другие же стремительно «цифровизуются».
Безотносительно 1С, а так, к словам прицепиться:
Смотря что за бизнес, где и чей… Вот Gartner всем предсказывает операционализацию аналитики и аналитизацию операционной деятельности; сontinuous intelligence взамен business intelligence.
Там, где это счастье уже наступило, хотят не отдельных OLTP и OLAP, а того, что называют HTAP и «translytical».
С этой точки зрения верным путем идут товарищи. Только пару терабайт какой-нибудь NVRAM этому СКД добавить, конечно, бы.
Вы, возможно, предполагали, что первая серия тоже будет посмотрена с вероятностью p, а не безусловно. У вас при p=1/3 получается 0.5 или 1.5?
GodCoder, задачу на суммирование б/у геометрической прогрессии нельзя называть «сложной».
Вступайте сюда: https://lichess.org/team/all-the-leelas
Мне это кажется жизнеспособным, правдоподным и интересным. Возможно, что-нибудь похожее когда-нибудь стихийно сложится, даже хотелось бы надеяться. Может быть, перечисляемые вами трендовые технологии будут сочетаться и какими-то другими способами.
Но, к сожалению, не могу сходу вспомнить случаев из истории ИТ, когда объединение двух больших идей давало бы большую третью. Кажется, что обычно получается пересечение размером в пару стартапов. Впрочем, каждый стартап требует много работы… Раз у вас тут идеи для дюжины стартапов, давайте побуду в роли ментора.
В Semantic Web Layer Cakе есть до сих пор не испеченный коржик под названием «Trust». Блокчейн-то бы туда, быть может. И наверняка что-то написано на этот счет, но больше глядят не в сторону блокчейна.
Что касается использования блокчейна как хранилища для RDF, а не как некоей верифицирующей обертки. Помимо «страниц на бесплатном хостинге» бывают специализированные RDF-хранилища, позволяющие делать к этому RDF нетривиальные запросы. Сделать triplestorе поверх какой-то ledger database наверняка можно, но вызывает вопросы производительность.
Про обратное, семантизацию блокчейна, тоже какие-то статьи есть.
Кстати, вот коллективное письмо 20+ гуглеров примерно о том же (вокруг него потом еще публицистика была). Неплохо бы, дескать, научить ML работать с графами. А то больно много «defining characteristics of human intelligence» пока что «remain out of reach for current approaches».
Насколько знаю, сейчас тут доминирующий подход — это graph embedding, т. е. как word embedding, но для графов. Дескать, давайте похерим всю внутреннюю структуру графа: лучший KR-формализм — линейное пространство достаточно большой размерности… Мне это ваше утверждение кажется большим авансом.
ОК, согласен. Правда, хранение логов тоже можно организовать по-разному: хранить их более сырыми или менее сырыми. Например, в Firefox в базе places.sqlite в таблице moz_places есть предвычисляемый столбец rev_host, позволяющий облегчить типовые тяжелые запросы.
Но я, конечно, слабо представляю себе характер и масштаб задач Яндекс.Метрики. Кажется, возможные подходы к организации хранения данных в ней были рассмотрены в этой статье.
o6CuFl2Q, а можно попросить вас добавить в бенчмарки что-нибудь на тему джойнов? А то правда производит впечатление какой-то строкогрызки.
— Алекс, это ведь будет LPG-граф. Так давайте и будем хранить его в графовой СУБД, а коэффициенты преобразований вычислять запросами. Что у вас там есть развернутого? Neo4, говорите… Ну тогда так:
Да, согласен… Думаю, графовая СУБД с поддержкой правил вывода позволила бы последовательно вычислить наилучшие с точки зрения точности попарные коэффициенты. Конечно, по соображениям производительности лучше не выводить их при каждом запросе, а единожды материализовать.
— Добро пожаловать в Google Knowledge Graph, сынок.
(упс, промахнулся, а тем временем уже написали; еще здесь было про то, что люблю иногда умышленно пощелкать по баннерам с целью нанесения ущерба рекламным бюджетам, к чему, видимо, и относился ответ на этот коментарий)
А что, всемогущий ML пока не может дать ответ на вопрос, почему минусуют?
За собой заметил, что на Stack Overflow плюсую довольно много и минусую совсем мало, здесь же плюсую много и минусую тоже довольно много. Вряд ли причина только в различии «жанров» материалов тут и там. Может быть, дело еще и в том, что там есть и другие способы «воздействия», помимо +1 и -1.
Здесь минусую примерно по тем же причинам, что и все, если судить по комментариям и результатам опроса. Из отличий:
Понимаю, что немного другая целевая аудитория, но для полноты и солидности:
1. Форум «Управление данными 2019»
Организатор: «Открытые системы»
Когда: 24 сентября 2019
Где: Москва, Ренессанс Монарх Центр, Ленинградский проспект 31а, стр. 1
Стоимость: индивидуальные заявки 15900 р., коллективные заявки 12900 р.
Тема очередного форума «Открытых систем» — «Предприятие, основанное на данных: стратегии, архитектуры, платформы, практики».
2. ИКТ в госсекторе
Организатор: CNews Conferences
Когда: 19 сентября 2019
Где: уточняйте у организаторов
Стоимость: бесплатное для представителей заказчиков (при подтверждения регистрации организаторами), 18000 для представителей вендоров и системных интеграторов.
Тема очередной конференции CNews — «„Цифровая экономика“ в действии».
Ну, указать — не то же самое, что рекомендовать…
Neo4j я указал бы по той причине, что самая популярная. Дальше для полноты картины хочется указать что-то с поддержкой Gremlin в противоположность Cypher; что-то с поддержкой модели RDF наряду или в противоположность поддержке LPG; что-то облачное в противоположность on-premise. А позиция всего одна осталась. Но вот Neptune позволяет проиллюстрировать все эти «альтернативы» одним примером.
Если облачность читателю заведомо неинтересна, можно указать AnzoGraph. Он правда, скорее OLAP-решение (кстати, вот еще одна «координата»), создан выходцами из IBM Netezza и Amazon Redshift, но это современный такой OLAP, ближе к HTAP даже.
Короче говоря, выбор обусловлен сугубо дидактическими соображениями. Из этих же соображений не стал бы указывать CosmosDB, OrientDB, ArangoDB, которые следуют сразу за Neo4j на DB-engines. «На самом деле» они документные, как пишу об этом здесь.
Если же пытаться рекомендовать…
Разные enterprise-характеристики (та же горизонтальная масштабируемость) вам тоже, видимо, не очень нужны будут, да? Тогда круг кандидатов расширится. Если требуется с возможностью бесплатного использования в коммерческом продукте или опенсорсное, естественно, сузится.
Мультимодельность и развитые API (language integrated queries и пр.) в перспективе сокращают время разработки. «В перспективе» — это чаще в «следующем проекте», конечно, но как знать, может, успеется и в текущем. Так что ArangoDB и OrientDB я бы вернул в список кандидатов.
Тут интереснее ваша задача. Я-то, конечно, не удивлен, нынче повсюду «connected datа» и пр., но все же интересно узнать больше конкретики о вашем проекте, требующем использования графовой СУБД. Разумеется, эта конкретика важна и при выборе СУБД. Можно в личку.
Ну и вариант написать собственную СУБД, оптимизированную под задачи, быстродейстующую и с низкоуровневым доступом тоже никто не отменял, он даже все более популярным становится.
Понимаю вашу аргументацию. Но вдруг Илон Маск захочет оплатить съемки чего-то типа этого в космическом масштабе. Чтобы тело двигалось ну ровно-ровно со второй космической. Тоже единственным дублем не обойтись будет.
Я-то имел в виду скорее ту ситуацию, когда поле силы притяжения, действующей на тело, можно считать однородным на протяжении всей траектории движения тела, направление и величина силы одинаковы в любой точке траектории. Эту силы чаще силой тяжести называют в таких случаях :-).
Довольно странно их объединять, что автор, по-видимому, делает, не приводя примеров графовых СУБД. Если бы меня попросили привести ровно два примера графовых СУБД, указал бы на Neo4j и AWS Neptune (спросите почему).
Ну и, конечно, «графовые», а не «графические». Google Translate переводит «graph databases» корректно, а вот Яндекс.Переводчик — нет.
Наверное, мы не очень друг друга поняли. Мое маленькое уточнение на тему «удобство разработчика или удобство пользователя» касалось работы с массивами, паддингов в 15 байт и т.д. Оно не касалось колоночной организации хранения.
Или вы и вправду думаете, что колоночная организация хранения — исключительно для удобства разработчика СУБД? Что, например, создатели Amazon Redshift перепиливали PostgreSQL для того, чтобы потом (когда?) было удобнее им самим, а не пользователям AWS? Решили сами заняться рефакторингом Postgres, так сказать? Вот это уж точно будет «психбольница в руках пациентов».
Или тут имелись в виду «колонки» не в том же смысле, в котором ClickHouse является СУБД с колоночным хранением, и это я вас неправильно понял?
Не сочтите, конечно, за обесценивание ваших трудов. Посмотрев «близкие к реальным» данные и запросы Яндекс.Метрики, я понадеялся, что такие данные и запросы составляют меньшинство, что это не то, для чего создавался и предлагается использовать ClickHouse. Конечно, не то чтобы благородные доны совсем не занимались разбором строк, но все же они предпочитают работать с «things, not strings», как по другому поводу выразился тот, кого тут, наверное, нельзя называть. Но тогда и эффективная обработки строк — достаточно второстепенная задача.
Мне кажется, объекты Солнечной системы, летающие по чисто параболическим орбитам, летают обычно недалеко и недолго и/или могут быть названы таковыми с большой натяжкой. Понятно, что здесь имеются в виду почти параболические орбиты (эллиптические с большим эксцентриситетом), но зачем школьников смущать.
Great job (и статья, и материал для нее), спасибо!
Мне кажется, корректнее говорить, что организация хранения тщательно оптимизирована для решения тех задач, для которых СУБД предназначена. А то создается впечатление, что раньше просто не умели подумать и поэтому хранили по строкам. Впрочем, и СУБД с колоночным хранением — не невидаль.
Речь ведь идет об удобстве разработчика, а не конечного пользователя, верно? Здесь можно вспомнить название книжки Купера, но раз уж это статья разработчика и для разработчиков, то ОК. К тому же нынче заметен тренд на создание СУБД заказной разработки и с низкоуровневым доступом.
Просто я удивился, что в названии статьи в блоге Яндекса отсутствует слово «Яндекс» и подумал, что зашкаливающий маркетинг будет внутри. Но нет, нашлись только вот такие следовые количества. В остальном см. первый абзац.
Всем добавившим статью в закладки, возможно, будет интересно. В начале лета в Евросоюзе наконец-то была принята Директива об авторском праве на Едином цифровом рынке.
Официальные исследователи могут теперь в исследовательских целях автоматически собирать и обрабатывать данные (text and data mining, TDM), если это не создает проблем в функционировании ресурса, даже если в иных случаях это запрещалось бы законодательством об авторских и смежных правах. Можно даже на какое-то время сохранять собранное локально для верификации результатов исследований.
Но скрапить персональные данные GDPR почти прямо запрещает, как выше уже писали в комментариях.
И Solid тут порекламирую, конечно.
Пользуясь случаем, попиарю свою предыдущую статью. В ней недаром в описании сквозного примера говорится о базе, хотя обычно правильнее говорить о схеме, и название таблицы тоже неспроста такое. Вот таким эзоповым языком скоро будем все политические новости писать.
Надо взять на вооружение: «Господин участковый, здесь курить запрещено, поэтому не мог я здесь курить, отстаньте».
Так-то давняя история об отличии деонтических модальностей от алетических. «Запрещено» ведет себя не так, как «невозможно», «обязательно» — не так, как «необходимо». Из запрещенности чего-либо не следует его недействительность, а из обязательности действительность.
Ну и вообще-то не по адресу обратилась гражданка, да и Роскомнадзор может и вправду не мочь…