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

потом смотришь сколько же там записей... 1млн+ и просто молишься на то что будь хотя бы счетное количество этих схем, или хотя бы каждая из этих схем была совместима между собой, или хотя бы используются те поля которые всегда одинаковые во всех этих схемах... но как обычно ХУЙ там

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

давно придумано, что если у тебя слой интеграции с внешним сервисом и ты не можешь гарантировать строгий детерменированный интерфейс - у тебя должно быть хотя бы два уровня готовности данных - RAW данные, и строгие данные, на которые уже опирается бизнес-логика. (про уровни бронза/серебро/золото уже речи не завожу)

А в какой то момент источник начинает слать дичь к которой ты не готов, все ложится и обработать уже это целая проблема, а потом еще и восстановить, а потом еще и извиниться перед всеми клиентами. Если было бы два уровня гарантии то в первом уровне появилась бы уже новая схема - и ничего СИЛЬНОстрашного. сервис конечно же упадет все равно, но второй уровень спасет - ты когда починишь проблему - восстановишь от и до.

для того что бы такого не случалось надо писать сразу правильно в реляционную структуру ставить ХОТЯБЫ схему жсона строгую (и монги это касается в первую очередь). и она быть должна всегда строгой. а консистентность схем не может клиент обеспечить никогда - поэтому в идеале это должно быть на уровне гарантий базы данных.

и да. ты за свою "нефиксированную" схему данных платишь в итоге перформансом и на чтение (нет таких эффективных БД которые умеют варить запросы к произвольным ключам лучше чем это сделает к структурированным строгим данным) и на запись (проверить схему перед вставкой). и если вставка не асинхронная то это может существенно притормозить весь сервис.

А если ты не платишь за это перформансом - то платишь потом месяцами и собственными ночами и нервами, когда все лежит, ты пытаешься запустить и на тебя еще все давят, и НИКТО не доволен. везет тому кто потом уволился...

никто не вспомнит что ты сделал это быстро. зато всегда запоминают что сделано это плохо

== pg_jsonschema
https://supabase.com/blog/pg-jsonschema-a-postgres-extension-for-json-validation

весьма интересный и полезный совет о котором я даже не думал

== 13 Tips to Improve PostgreSQL Insert Performance
https://www.timescale.com/blog/13-tips-to-improve-postgresql-insert-performance/
1. Use indexes in moderation
2. Reconsider foreign key constraints
3. Avoid unnecessary UNIQUE keys
4. Use separate disks for WAL and data
5. Use performant disks
6. Use parallel writes
7. Insert rows in batches
8. Properly configure shared_buffers
9. Run our Docker images on Linux hosts
10. Write data in loose time order
11. Avoid “too large” chunks
12. Avoid too many or too small chunks
13. Watch row width

ребят подскажите нормальный софт для просмотра больших (10...1000мб) ЛОГ файлов, так что бы можно было разбивать по колонкам, искать взаимосвязи и случаи, подсветка, структурирование

немного греп поднадоел)

хочу

а если по сабжу. то это крутющая идея
https://www.plaud.ai/?sca_ref=5794545.HpYCFsZdQh&utm_source=uppromote&utm_medium=plaud-giftgenius_2024&utm_campaign=kol_p-k

нашел таки неплохую програмулину для поиска и фильтрации текста в больших файлах

KLOGG

кросплатформенная прилага (написанная на QT)

из того что понравилось - это табы для поиска и разных фильтров
- после того как отфильтровал можно еще и искать !!!!
- можно по регуляркам и по прямому совпадению
- работает быстро очень

не понравилось
- сильно минималистичный интерфейс
- возможности подсветки интересующих ключевиков или секций прям таки сильно минималистичны

Тот момент когда на линкед-ине за месяц навалило столько, что придется делать так как делают все - не отвечать. и просто пропустить все. Я нарушил свой ритм. и впервые за 10 лет кому то не отвечу

нашел хорошую картинку=обьяснение разницы
- Load Balancer
- Reverse Proxy
- Api Gateway

подкинули годноты https://www.youtube.com/shorts/0Dga-arq2oc

а ну как так то ? почему я об этом сразу не знал ?! столько неудобств изза того что это окно постоянно занимает место только ради информации текущей композиции ?! а тут есть микроплейер. удобно


https://community.spotify.com/t5/Community-Blog/Introducing-the-Spotify-Miniplayer-to-Spotify-Desktop/ba-p/5956132

на злобу дня
https://youtu.be/SETnK2ny1R0?si=je9NbpIj5sVblVOP

не забыть посмотреть что за оно

== курс по смарт контрактам телеграма (TON)
https://youtube.com/playlist?list=PLOIvUFGfwP93tZI_WnaLyJsZlskU4ao92&si=FcZsIpZPSNngjMnY

== ODMantic
https://art049.github.io/odmantic/ и вроде даже выглядит нормально. кто использовал ?

как подкастик норм

== Postgres Internal Architecture Explained
https://youtu.be/Q56kljmIN14?si=NM1_GVOtqEihaFRV

- Postgres MVCC
- Processes vs Threads
- Postmaster Process
- Backend Processes
- Shared Buffers
- Background Workers
- Auxiliary Processes
- Background Writer
- Checkpointer
- Logger
- Autovacuum Launcher and Workers
- WAL Processes
- Startup Process

Rust - telegram bot

https://pudding-entertainment.medium.com/rust-how-to-create-telegram-bot-f7d569bf8bc

- teloxide https://docs.rs/teloxide/latest/teloxide/

- telebot https://crates.io/crates/telebot

== 5 Secrets for making PostgreSQL run BLAZING FAST. How to improve database performance https://youtu.be/YON9PliOYFk?si=2g7HhtMx6A7gqyLj

- prepared statements
- benchmark
- indexing
- partitioning

подпишусь под эти слова

== Микросервисы как худший архитектурный выбор для стартапа
https://youtu.be/6QU-8kcdhDM?si=3lzrvrJiU8WKjT41

тема с ИИ помочником в БД это просто пушка. вот где где = тут просто шикарно

https://www.jetbrains.com/datagrip/whatsnew/

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

надо пробовать по ходу

вим на нормальных дрожжах https://docs.astronvim.com/
PS: и можно из него выйти постарому)