Добро пожаловать в 17-й эпизод сериала Steampipe+Mastodon, в котором мы представляем новый сюжет: историю временной шкалы. До сих пор примеры, которые я показывал и обсуждал, работали с текущими временными шкалами. Мы видели SQL-запросы, которые извлекают результаты вызовов в режиме реального времени к API Mastodon, и информационные панели Steampipe, которые отображают эти результаты. Но Steampipe — это не просто перекачка API, это еще и база данных Postgres. Таким образом, он поддерживает переходные таблицы, созданные оболочкой сторонних данных и плагинами Steampipe, но также позволяет создавать собственные собственные таблицы. И вы можете использовать эти собственные таблицы для накопления данных из временных внешних таблиц.
Поскольку сохранение и поиск данных о мастодонтах — спорная тема в федиверсе — никто из нас не хочет повторять Big Social — до сих пор я сосредоточился на запросах, которые исследуют недавний поток мастодонтов, о которых можно написать еще много. Но никто не должен возражать, если я помню свою домашнюю временную шкалу, поэтому несколько недель назад я сделал инструмент для ежечасного чтения и добавления новых инструментов в таблицу Postgres.
Прежде чем вы сможете добавить какие-либо инструменты в таблицу, конечно, вы должны создать эту таблицу. Вот как я сделал это.
create table mastodon_home_timeline as select * from mastodon_toot_home limit 200
После создания таблица может быть обновлена такими новыми инструментами.
with data as ( select account, -- more -- columns username from mastodon_toot_home limit 200 ) insert into mastodon_home_timeline ( account, -- more -- columns username ) select * from data where id not in ( select t.id from mastodon_home_timeline t )
Чтобы запустить этот запрос из crontab, на машине, где установлен Steampipe, сохраните его как mastodon_home_timeline.sql
затем запланируйте его.
15 * * * * cd /home/jon/mastodon; steampipe query mastodon_home_timeline.sql
Вот и все! Теперь число, сообщенное select count(*) from mastodon_home_timeline
растет ежечасно.
Я собираю инструменты всего пару недель и еще не начал изучать эти данные; посмотрим, что будет, когда доберемся туда. А пока я хочу показать, как такое исследование может быть командным упражнением.
Мой друг, которого я назову Элвисом, разделяет мой интерес к выявлению связей между людьми, серверами и хэштегами. Он мог зафиксировать свою собственную временную шкалу, используя метод, показанный здесь. Но так как мы будем рассматривать эти данные вместе, мы договорились, что я соберу обе наши временные шкалы. Чтобы включить это, он поделился (отзываемым) токеном API Mastodon, который я использовал для настройки Steampipe с учетными данными для обеих наших учетных записей.
connection "mastodon_social_jon" { plugin = "mastodon" server = "https://mastodon.social" access_token = "..." } connection "mastodon_social_elvis" { plugin = "mastodon" server = "https://mastodon.social" access_token = "..." }
Оболочка внешних данных Steampipe превращает каждое из этих именованных соединений в собственную схему Postgres. Кстати, хотя у нас один и тот же домашний сервер, в этом нет необходимости. Команда, сотрудничающая таким образом, могла бы объединить временные рамки из мастодонт.социальный и hachyderm.io и fosstodon.org и любой другой сервер, совместимый с Mastodon-API.
(Вы можете сделать то же самое с AWS, Slack, GitHub или другой учетной записью, определив несколько подключений. Steampipe выполняет вызовы API одновременно через параллельные подключения.)
С этой конфигурацией я могу читать свою временную шкалу вот так.
select * from mastodon_social_jon.mastodon_toot_home limit 200
И Элвис такой.
select * from mastodon_social_elvis.mastodon_toot_home limit 200
Если я хочу запросить оба в реальном времени, например, чтобы подсчитать общую сумму, я могу использовать SQL UNION. Или я могу определить зонтичное соединение, объединяющее эти два.
connection "all_mastodon" { plugin = "mastodon" type = "aggregator" connections = [ "mastodon_social_jon", "mastodon_social_elvis" ] } connection "mastodon_social_jon" { plugin = "mastodon" server = "https://mastodon.social" access_token = "..." } connection "mastodon_social_elvis" { plugin = "mastodon" server = "https://mastodon.social" access_token = "..." }
Теперь запрос select * from all_mastodon.mastodon_toot_home limit 200
выполняет вызовы API от имени обеих учетных записей — параллельно — и объединяет результаты. Когда мы переходим по полученным URL-адресам, чтобы ответить или повысить, мы будем делать это как отдельные личности. И мы сможем использовать запросы и информационные панели Steampipe в том же однопользовательском режиме. Но мы также сможем объединить наши временные шкалы и направить наши запросы и информационные панели на объединенную историю.
Будет ли это интересно? Полезный? Это еще предстоит выяснить. Я думаю, что это один из многих экспериментов, которые стоит попробовать, пока Fediverse разбирается сама. И я рассматриваю Steampipe как одну из лабораторий, в которой можно проводить такие эксперименты. С SQL как абстракцией над API, агрегированием соединений и информационными панелями как кодом у вас есть все ингредиенты, необходимые для быстрого и недорогого перехода к общим пространствам Mastodon, адаптированным для команд или групп.
Эта серия:
- Автономность, размер пакета, трение, разветвление и скорость
- Mastodon, Steampipe и RSS
- Просмотр федиверса
- Терминал Bloomberg для Mastodon
- Создайте свой собственный Mastodon UX
- Списки и люди на Mastodon
- Сколько людей в моей ленте Mastodon также написали сегодня в Твиттере?
- URL-адреса Mastodon с указанием экземпляра
- Графики взаимоотношений мастодонтов
- Работа со списками мастодонтов
- Изображения считаются вредными (иногда)
- Картирование более широкой федеральной сети
- Протоколы, API и соглашения
- Новости в федерации
- Сопоставление людей и тегов в Mastodon
- Визуализация модерации сервера Mastodon
- Сроки Mastodon для команд
- Плагин Mastodon теперь доступен на Steampipe Hub.