> что кому-то "теоретически" кажется

Вообще-то это известно, что b-tree  лучше подходит, когда преобладает чтение (и когда обновляется произвольная запись), а lsm - при вставке (и когда обновляется недавно вставленная/обновленная запись). Я ссылками доказывать не буду, но это правда известно.

И ещё не очень понял, зачем Вы обвернули слово "теория" в кавычки. Какой смысл в этом?

> Но я специально не искал, а Вы?

Я искал год/полгода назад, но не видел. Находил только storage с undo log, как в MySQL, и, вроде бы, колоночный storage. Не помню их названия.

> Я ссылками доказывать не буду, но это правда известно.

А я утверждаю, что нет, не "известно". Всё зависит от условий и ограничений при применении, как обычно.

> Какой смысл в этом?

Смысл такой, что упуская (преднамеренно или нет) существенные для конкретной ситуации детали, можно сделать совершенно неправильные выводы (обратные тому, что будет при реализации и тестировании / использовании), например.
Поэтому подобная деятельность — это "теоретизирование", и больше ничего.

хм, надо же... у меня есть база, где под нагрузкой до 300MB/s транзакционного лога пишется. и 95% индексов — btree.


я бы вам рекомендовал поискать и почитать публикации на тему nbtree indexes in rdbms (в частности за авторством Shasha),  разговор был бы более предметным.

> Всё зависит от условий и ограничений

Условия и ограничения назвал, не понимаю Вас. Т.е. паттерн, когда один хуже/лучше явно указан в нашем обсуждении.

> А я утверждаю, что нет, не "известно"

Не верите мне? Не надо. Вся первая страница поиска в Гугл по фразе "lsm vs b-tree" скажет вам тоже самое.

Коллеги, а подскажите, каким запросом лучше мониторить отставание реплики?
Просто есть у нас одна метрика, но по ночам в праймари ничего не происходит, нет передачи на реплику, и, соответственно, мониторинг постоянно алертит, что отстало...
Как вы решаете эту проблему? 🤔

Как хранить doc формат в postgresql. Ввиде html как string или в битах или грузить на s3 и хранить ссылку?

Сейчас вот так смотрим:

SELECT CASE WHEN pg_last_wal_receive_lsn() = pg_last_wal_replay_lsn() THEN 0   ELSE EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp())::INTEGER END AS lag;

Если вопрос в формате голосования, то я за хранение ссылки в бд.

> Условия и ограничения назвал, не понимаю Вас.

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

> Не верите мне? Не надо. Вся первая страница поиска в Гугл по фразе "lsm vs b-tree" скажет вам тоже самое

Послушайте, но это же argumentum ad populum просто не серьёзно. ;)
Т.е. "первая страница поиска в Гугл" по некоторым (многим?) запросам "скажет" мне простую, тривиально доказуемую неправду.

> где под нагрузкой до 300MB/s

Мне эти цифры ни о чем не говорят, особенно в контексте обсуждения b-tree vs lsm.
Покажите пример, где b-tree на запись ведет себя шустрее, чем lsm.

> почитать публикации на тему nbtree indexes in rdbms

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

https://wiki.postgresql.org/wiki/BinaryFilesInDB </thread>

👍

Postgres — open-source. если вы уверены, что lsm лучше, то реализуйте и пользуйтесь, вам только спасибо скажут. тем более, что новые IndexAccess методы можно делать в виде расширений.

А давайте я покажу. ;)
http://www.lmdb.tech/bench/inmem/
LMDB — это "широко известная в узких кругах" высокопроизводительная реализация ACID single-writer b-tree, если что.
А LSM в этом benchmark несколько.

В общем, я тут уже писал (несколько раз, кажется?) по этому поводу — b-tree в реальности (а не в "теоретических" мечтах) "победить" очень трудно, т.е. эта пакость структура данных в "нормальных" условиях зачастую выигрывает у "специализированных" под задачу структур данных (хотя, как кажется "теоретикам", не должна бы), или же не очень существенно проигрывает им.

"Победить" B-Tree достаточно просто
Если интересно - почитайте
https://www.postgresql.org/message-id/flat/315b7ce8-9d62-3817-0a92-4b20519d0c51%40postgrespro.ru

LSM сейчас действительно очень популярна и используется во многих новомодных базах  от тарантула и YDB до cockroach-а.
Правда оно проявляет себя в основном на  вставках и в том случае, когда индекс существенно не влезает   в память. Впрочем при теперешних размерах оперативки этого не так просто добиться:)

Если версия >= 10, то *_lag в pg_stat_replication. Если меньше 10-й, то страдать.

12 версия... С виду есть инфа там. Спасибо. Будем курить тему...

если у вас нету вообще никакой активности на мастере, то это нормальное поведение, т.к. на реплику ничего не приезжает и время последнего replay всё время убегает в прошлое. настройте archive_timeout

Понимаете... если "подтасовать колоду" (т.е., например, сравнивать ACID b-tree и non-ACID LSM; или сравнивать single-threaded LSM игрушку с полноценным многопользовательским b-tree; или в benchmarks использовать исключительно "случайные" данные; или сравнивать "базовую" реализацию b-tree с сильно оптимизированным LSM и т.д. и т.п.), то "победить" очень легко.

И я почитал thread, да (и там люди тоже почему-то сомневаются, что эти результаты показывают / доказывают "победу").

Так что если Вам интересно — посмотрите http://www.lmdb.tech/bench/inmem/  ;)