Hacker News Digest

GNU Artanis — первый production-ready веб-фреймворк на Scheme. Лёгкий, быстрый, с поддержкой JSON/XML/SXML, WebSocket, i18n, MySQL/SQLite/PostgreSQL, кэширования, шаблонов и статики.

(use-modules (artanis artanis))
(init-server)
(get "/hello" (λ () "hello world"))
(run #:port 8080)

Скачать

• GNU FTP
• GitLab

Документация
Официальное руководство

Исходники

• Savannah: https://savannah.gnu.org/projects/artanis
• GitLab: https://gitlab.com/hardenedlinux/artanis

История
2013 — рождение на hack-potluck Guile; 2014 — награда «Lisp In Summer Projects»; 2015 — первая стабильная версия и вступление в GNU; 2021 — переход под крыло HardenedLinux.

Контакты
Почта: artanis@gnu.org
GitLab: https://gitlab.com/hardenedlinux/artanis

• Участники обсуждают фреймворк Artanis для Guile Scheme: кто-то хвалит простоту синтаксиса и встроенный веб-сервер, кто-то жалуется на отсутствие CSRF, 404-ссылок и слабое tooling.
• Почему Guile не стал популярен? Недостаток LSP, отладки, туториалов и узкая аудитория.
• Название «Artanis» — отсылка к Sinatra (Ruby) и палиндрому «Sinatra» задом-наперёд.
• Сайт без JS и шрифтов выглядит чисто, но кто-то считает текст слишком крупным и структуру странной.
• По безопасности: при грамотных разработчиках Scheme-системы могут быть безопаснее «обычных».

ChartDB — инструмент для интерактивной визуализации схем БД.
Поддерживает PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, CockroachDB, MongoDB.

Ключевые возможности

• Импорт схемы одним кликом из любой поддерживаемой СУБД.
• Авто-раскладка таблиц и связей; ручное перемещение.
• Экспорт в форматы PNG, SVG, PDF.
• Режим «одной страницы» для быстрого просмотра.
• Поиск и фильтрация по названию таблицы или столбца.
• Тёмная и светлая темы.

Быстрый старт

1. Открыть chartdb.io.
2. Нажать «Import from DB», вставить строку подключения или SQL-дамп.
3. Получить готовую схему за секунды.

• Некоторые команды продолжают рисовать ERD и документировать именно схему БД, особенно при проектировании новых фич и онбординге.
• Другие полагаются на абстракции вроде ORM/DDD и считают диаграммы избыточными, особенно для типовых SaaS с generic auth и payment.
• Инструменты вроде dbdiagram.io, Lucidchart и ChartDB спросом пользуются, но часто ломаются при >15 таблиц или требуют изучения нового UI.
• Сторонники диаграмм аргументируют: «базы живут дольше абстракций», а отсутствие документации — потеря для индустрии.

Проблема
При промахе кэша Readyset выполняет запрос с нуля. Для «расколотых» соединений (предикаты есть и в WHERE, и в ON) старый hash-join читал обе таблицы полностью:

• фильтр по email возвращал 1 строку users;
• фильтр по status='SHIPPED' — 99 % таблицы orders.
  Материализовав миллионы лишних строк, система строила хэш-таблицу и лишь потом отбрасывала ненужное. Профилирование показало: 30 % времени уходило на распаковку RocksDB, затем на 10 K IOPS и 81 % загрузки NVMe.

Решение: Index Condition Pushdown
Новый план использует индексы и «проталкивает» условия вниз:

1. Сначала выбираем 1 строку users по индексу email.
2. Для каждой найденной u.id делаем индексный lookup в orders с условием user_id = u.id AND status='SHIPPED'.
   Так читаются только нужные строки orders, объём I/O падает на порядки, а хэш-таблица больше не строится.

Результат
ICP устраняет лишнее чтение и распаковку, превращая холодный straddled-join из многомиллисекундной операции в субмиллисекундную.

• Пользователи жалуются, что планировщик запросов не продавливает фильтры к индексам, и считают это багом производительности.
• Многие разработчики вынуждены сами заниматься индексами, партиционированием и анализом EXPLAIN, потому что DBA лишь «держат свет».
• В RonDB и ReadySet показали примеры «pushdown-joins» и Index Condition Pushdown, дав ускорение до 450×.
• ReadySet описывают как «кеш-прокси» поверх MySQL/Postgres, который по логу репликации инкрементально обновляет материализованные представления.
• Часть участников считает, что современные оптимизаторы должны делать такие оптимизации автоматически, и не понимает, зачем изобретать велосипед.