PostgreSQL API, в особенности для публичных данных и в перспективе миграции

[mkgrgis]

На основе https://github.com/EnterpriseDB/mongo_fdw создать типизированные шаблоны коллекций для

• Создания над публичными коллекциями(публичными частями коллекций) простого публичного API и его исполнтелей под пользователям только для чтения в PostgreSQL
• Оценки производительности выборок из PostgreSQL в перспективе миграции
• Простого редактирования некоторых служебных коллекций через пользователя, имеющего права записи

Перспективы PostgreSQL

• Типизация и управление структурой данных в БД из одного места подходят для регулярного стиля использования MongoDB, который сейчас преобладает для большиснтва коллекций
• Некоторые проверки (взаимная увязка, обязательность, значения по списку и дипазонам) данных могут быть вынесены на уровень БД
• PostGIS немного более развит для геоаналитики чем MongoDB, хорошо бы понять достаточно ли он производителен при пригодности для хранения geoJSON.
• Механизм материализованных представлений и вычислимых хранимых полей в PostgreSQL может создавать низкоуровневые заделы ускорения выборки с автоматической гарантией актуальности данных.
• Механизм хранения JSON и встроенного преобразования табличных данных в JSON могут приблизить выдаваемые данные к текущему формату выдачи из MongoDB
• Механизм индексации в PostGIS позволяет быстро выбирать ближайшие точки
• Большое число выборок на чтение и менее интенсивная запись с преобладанием комментариев при незначительном числе удалений - хороший сценарий для PostgreSQL
• Явное наличие структур данных с гарантиями заполнения или значений полей облегчит простую прокладку связей таблиц при создании систем каталога тегов, взаимных упоминаний и т.д.
• Дешевизна создания явных связей FOREIGN KEY позволяет легко проверять качество данных и отсутствие упущенных концов при восстановлении после аварий.
• Применение значенний-массивов позволяет упростить редкие сложные процедуры, вроде повторного переименования пользователя.

[paul-k-pastvu]

Я очень-очень жду возможности SQL-запросов к базе.

[aeifn]

А чем json-запросы не устраивают?

[paul-k-pastvu]

Тем, что а) я их пока не умею, и б) мне так никто и не дал интерфейс, чтобы с ними играться

[mkgrgis]

С моей стороны основная претензия в том, что запрос в документном стиле почти всегда будет касаться регулярной структуры и потребность в данных тогда покрывается опять же результатом в виде регулярной и типизированной структуры. Сначала думал, что ув. @klimashkin придумал существующую архитектуру по соображениям скорости ответа, но после #307 (comment) стало понятно, что в момент создания PastVu просто не было гибких реляционных БД с достаточно быстрым чтением произвольных JSON структур.

[aeifn]

Мне представляется, что работа по миграции на postgres будет "дороже", чем возможные выгоды от этого.

[mkgrgis]

Что конкретно Вы вкладываете в "дороже"? Мне понравилась структура Монги, которую я поднял из образца, но оказалось, что более чем в 90% случаев она используется не как документное, а как регулярно-структурное хранилище, только без типизации, простых переименований и простого добавления полей. 90% регулярности + редкие чистые JSON случаи + ГИС + преобладание чтения над записью (S+I-U-D-) это типичная сфера postgres. Стандарт JSON запросов создан не без влияния реализации в Pg.

[aeifn]

Что конкретно Вы вкладываете в "дороже"?

Слишком много и сложно придется перекраивать код, чтобы мигрировать на postgres.

Что касается типизации, то она есть на уровне моделей.

[mkgrgis]

Слишком много и сложно придется перекраивать код

При том, что Postgres легко научить идентичному формату выдачи данных через json_agg, json_row и др. на первом этапе я не вижу других участков кода для переработки кроме mongoose и слоя запросов JSON. Не могли бы Вы примерно оценить сколько это строчек?

Что касается типизации, то она есть на уровне моделей.

Видел модели. От них как раз пошла идея о регулярных структурах в Postgres. Вроде бы типизация достаточная, но немого смущает, что она непосредственно не существует в БД и всякий запрос на вывод для валидации или красивого результата должен декорироваться моделью.

[klimashkin]

Модель используется при чтении только при использовании orm. В большинстве случаем мы используем прямой запрос на чтение. Зачем что-то валидировать при чтении, в этом случае просто создается нужные объекты, например date

[aeifn]

Но сама идея открыть публичную часть базы для ридонли запросов - интересная. Это может полностью заменить pastvu.com/api2 и дать более широкий простор для творчества разработчикам

[mkgrgis]

Да, я задумался об этом когда писал PastVu-архивариус, собирающий по всем изображениям координаты. В период недоступности сайта через QGIS или leaflet было инетресно просматривать наличие точек в нужной области. Изображения нередко можно найти в кэшах Яндекса и других, а вот координаты нет.

[klimashkin]

дать более широкий простор для творчества разработчикам

И позволит им повесить базу. Прямого доступа к базе никогда нельзя давать наружу

[aeifn]

И позволит им повесить базу. Прямого доступа к базе никогда нельзя давать наружу

А если через тонкий (в десятки строк) прокси?

[klimashkin]

Нельзя позволить кому-то снаружи завязаться на структуру базы, всегда должен быть слой поверх который можно менять и версионировать. Если хочется можно сделать graphql чтобы у внешних была свобода выборки, но слой абстракции должен быть всегда

[mkgrgis]

И позволит им повесить базу. Прямого доступа к базе никогда нельзя давать наружу

Знаю проекты, где доступ к отстающим подписчикам Pg почти прямой. Да, их иногда вешают, но чем это страшно для API без критических обязательств по обслуживанию и обязательств по многолетнему формату вызовов? В нашем случае чем может подвести подписчик-реплика MongoDB если открыть публичные данные реплики по mongo_fdw?

[mkgrgis]

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

[klimashkin]

Весь meteor был построен на oplog в монге много лет, куда уж более интерактивно.
Но это, вместе с упомянутым триггерами постгре не самый лучший вариант, он будет сдерживать масштабирование в будущем, и нарушает принцип сервисной архитектуры, потому что сервисы начинают глубоко знать про внутренности базы и от нее зависеть.

Для подписок и распространения данных надо использовать нормальный MQ или кафку как центральную шину в кластере

[aeifn]

Для подписок и распространения данных надо использовать нормальный MQ или кафку как центральную шину в кластере

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

[klimashkin]

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

[mkgrgis]

В качестве отдельного решения RabbitMQ или Кафка как микросерсис кажутся более зрелым. С Pg в преспективе запросто можно выйти за пределы комфортного масштаба уведомлений в перегрузку. Хочется надеятся, что до таких нагрузок можно вырасти.

[mkgrgis]

Вспоминая апаратный крах нашей MongoDB и героические усилия ИТ-команды по спасению веток в разных коллекциях, не могу пройти мимо факта, что в Pg существует репликация на уровне БД и есть бесплатные программы переключения основной БД с отправителя на одного из подписчиков при крахе бывшего отправителя.
Сама концепция подпиисчика с сильными или слабыми гарантиями целостности данных весьма интересна для резервирования или баланса нагрузок в смысле публичного API.

[klimashkin]

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

[mkgrgis]

Поддержу. По опыту крахи больше зависят от интенсивности записи, чем от СУБД. Если я знаю меньше крахов Монги, чем Слона, то только потому, что Монга реже. Разрушительность краха слабее зависит от типа БД, чем от физического источнкиа нарушения.

[paul-k-pastvu]

Коллеги, пока что из этой темы я вижу, что @klimashkin и @aeifn скорее против идеи миграции на PostgreSQL, считая, что все мыслимые "хотелки" можно реализовать и в Монге, так?

[paul-k-pastvu]

Однако мне очень важной кажется вопрос про уведомления пользователей - я вынес его в отдельную тему: #338

[mkgrgis]

Выложил проект для архивации гегографических координат изображений из БД PastVu.

[mkgrgis]

Удалось подцепить mongo_fdw, вскоре предложу SQL интерфейс для отдельных административно-инспецкционных задач.

[paul-k-pastvu]

Сказать, что я весь в ожидании - это сильно преуменьшить. Это будет прорыв! ПК пт, 18 мар. 2022 г., 16:37 Михаил ***@***.***>:

…

Удалось подцепить mongo_fdw, вскоре предложу SQL интерфейс для отдельных административно-инспецкционных задач. — Reply to this email directly, view it on GitHub <#336 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOLAIHE2DQR7MVTKPS4IYYDVASBIXANCNFSM4UWZ44KA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[mkgrgis]

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

Многие коллекции хорошо ложатся в PostgreSQL, так как имеют слабо стабильный состав. Некоторые имеют сильно стабильный состав, например, news. Коллекция photo_history использует оригинальные возможности MongoDB/JavaScript, что сильно затрудняет нормализацию и типизацию.

По образцам представлений из #469 можно создавать представления и внешние таблицы для других коллекций.

Для полноценной интеграции интерфейса нужно включение PostgreSQL в docker в качестве необязательного компонента и, самое сложное, запаковка работающего mongo_fdw в среду разворачивания. Воспросы к @aeifn и не только.

[kabalin]

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

Отдельно от этого, есть же стандартный BI коннектор https://www.mongodb.com/docs/bi-connector/current/what-is-the-bi-connector/, в качестве инструмента там может выступать любой sql клиент поддерживающий JDBC or ODBC. Чем это решение отличается от того, что вы пытаетесь достичь и как вы представляете дальнейшее его использование?

[mkgrgis]

Описание каждой коллекции можно смотреть в коде.

Спасибо за наводку, Руслан! Так удобнее. Надесь что код покрывает разннобразие реальных ветвлений в записях коллекций.

стандартный BI коннектор

Задача не в анализе данных. Для себя я вижу такие направления развития:

1. Отладочный инструмент осмотра БД для тех кто плохо дружит с запросами к MongoDB.
2. Группа представлений для административных нужд.
3. Основа PostGIS интерфейса для эксперементальных геометрических вычислений
4. Основа PostGIS интерфейса для экспорта координат всех публичных точек с описаниями изображений (архивация уникальных для проекта данных)
5. Основа для PostGIS инструмента внесения OSM geoJSON в MongoDB коллекцию regions.
6. Основа для реляционного API по изображениям и их публичным свойствам. PostgreSQL реплика с ежечасными MATERIALIZED VIEWS может минимизировать риски перегрузки для основной БД.

На первом этапе просто делаю представления в близкой к MongoDB форме для себя, потом нормализую их названия для Павла.