Lemmy
20 листопада 2022, 17:09
CMS-like бекенд з GraphQL API генеруємий з схеми
Привіт, все займаюся бекендом для UJournal. Читаю різноманітні статі для того щоб зробити більш усвідомлений вибір. Головні якості які я хочу знайти у рішенні: чесний SQL або дуже близький до SQL язик. Авторизація та User-Access-Control. В ідеалі, хочется щоб був інтерфейс для управління даними.
Передивився рішення:
- Superbase — чудове рішення, використовував їх клауд для того щоб робити пет-проєкти. Дивлюся на їх Self-Hosted рішення. Трохи бентежить те що документації мало;
- Pocketbase — рішення яке я зараз тестую. Чудова адмінка та виглядає простим настройка. Бачу перепони в тому що відношення між таблицями зроблені поверхнево. Прочитав про SQLite у продакшинє і кажуть що на великих об’ємах маленьких операцій воно працює так собі.
Зараз вирішив: або брати чистий MySQL/Postgress та робити бек на Laravel/AdonisJS або далі підбирати більш-меньш підходящі CMS-like рішення. Ось Keystone виглядає дуже підходящим рішенням. Може використовувати БД Postgress та має розвинуту систему хуків. Зараз тестую. Згодом може виклам більш детальний розбір цього рішення.
Нужно не забывать, что SQLite это библиотека, а не стэндалон СУБД. И там используются обычные b‑tree индексы, как в pg/mysql и работает ну никак не хуже, да и производительность в целом более предсказуемая и памяти нужно меньше.
Вообще у самого SQL концептуально всегда были проблемы с производительностью, из-за чего его не любят на хоть каких-то нагрузках. На нагрузках сложные запросы с разными там джоинами и модными фичами создают проблемы, могут создаваться временные таблицы, таблицы сканироваться не по тем индексам или вообще целиком, такие запросы нужно потом анализировать, после анализа переписывать на простые запросы, где легко понятно по какому индексу выбираются данные, нужно выкидывать обертки вокруг SQL, чтобы писать запросы напрямую и т.д. Скажем так, если производительность важна, то SQL все равно придется использовать как просто навороченное KV хранилище. Речь об OLTP конечно, для аналитики по другому все.
Еще тут важно разобраться с инкрементальными бэкапами и восстановлением, чтобы иметь возможность откатиться в случае чего и не делать бэкап целой базы, когда она неизбежно распухнет. Ну как важный, можно потерпеть если на сервере ссд диски и каналы толстые, и просто делать бэкапы всей базы целиком каждую ночь, такое может и не один год проработать.
Думаю брать что-то что является стандартом. MySQL/Postgress очень распространены и гарантировано масштабируются. Читал что SQLite масштабировать можно, но то что это заложено в дизайн базы — такого нет.
Хочется использовать обертку поверх БД, просто чтобы меньше писать кода, меньше кода — меньше ошибок и меньше костов на поддержку. Логика примерно такая.
На маленьком масштабе проблем с производительностью скорей всего видно не будет.
Подскажи (если знаешь), на какие инсрументы можно посмотреть для нагрузочного тестирования?
Нагрузочное тестирование разное бывает, готовые нужны разве что погонять веб сервер и проверить его конфигурацию, лимиты на количество дескрипторов, соединений, такое всякое — подойдет «ab» из пакета apache2-utils (ubuntu) , ей конечно можно и просто побенчмаркить запросы на бекенд, но это не покажет, как запросы в реальности будут отвечать, а только общий оверхед языка, платформы, фреймворка, коммуникаций по сути.
Для реальной нагрузки придется самому делать инструмент, если хочется, но это не так нужно. Если уже заниматься чем-то таким, то лучше метрики собрать из своего кода и веб сервера, т.е. записывать в логи сколько милисекунд ушло на ответ от веб сервера (nginx умеет), измерять хотя бы сэмплами запросы к БД, диску, измерять какие-то ключевые функции и тоже все это записывать в логи.
Спасибо за референс на утилиту ab. А есть мейнстримный маст-хев набор тулзов для мониторинга nginx или все индивидуально под каждый проект?
Ничего не маст хев, можно обойтись вообще без ничего просто посматривать логи. Дело скорее не в проекте, а в конкретной инфраструктуре, и как в ней заведено, под то и делается. Если ничего нет, то и задумываться пока не о чем. А потом будет понятнее куда двигаться, если понадобится.
Я в цьому нічого не тямлю, але в мобільному додатку я юзав SQLite + Firebase
Думаю для мобільного додатку юзати SQLite + Firebase це прям ок, тому що у бази даних один юзер — це аплікуха. Один користувач — це володар мобільного пристрою.