pro.jvm

20 Jun 2025 20:36

И тут мы задумываемся чем поиск отличается от выборки (и бд от поискового движка)

pro.jvm

20 Jun 2025 20:34

Мы так сейчас дойдем до того, что не надо все это искать в БД, а нужен отдельный индекс внешний

pro.jvm

20 Jun 2025 20:28

Так сделайте автор-тайтл и тайтл-автор

pro.jvm

20 Jun 2025 20:25

А чаще ищут по автору или названию?

pro.jvm

20 Jun 2025 20:15

Как не получится? Получится конечно же.

pro.jvm

20 Jun 2025 20:11

Но тогда такой поиск будет неэффективным же

pro.jvm

20 Jun 2025 20:09

В плане, если у тебя индекс будет (title, author) то просто по автору не получится искать

pro.jvm

20 Jun 2025 20:08

В плане? Ну да индекс может быть из двух колонок.
Вы индекс и праймери кей не путаете?

pro.jvm

02 May 2025 10:06

Сделали ФП ЯП поверх Голанг vm, как Scala или Clojure поверх java jvm

pro.jvm

02 May 2025 09:29

?
Можно поподробнее с пояснениями, пожалуйста

pro.jvm

02 May 2025 07:01

Я как-то делал похожее на то, что тебе нужно с помощью неблокирующих очередей в комбинации с BooleanLatch. У меня было много потоков обновляющих очереди, один поток читающий в цикле эти очереди и передающий в экзекутор на исполнение. Те кто пополнял очереди, выставлял latch в позитивное значение, читающий сбрасывал его и блокировался на нем. Но забыл я почему именно этот латч выбирал, но помню, что до этого изменения очереди в цикле читались нон-стоп и подскочила утилизация цпу у одного из клиентов.

pro.jvm

01 May 2025 23:25

тут видится вопрос что хочется разгрузить, консумеров или продьюсеров. Изза этого лок можно сместить или упрятать за чек раз в N на локе как в обычном синхроне

pro.jvm

01 May 2025 23:10

перед T1 wait check c локом

pro.jvm

01 May 2025 23:08

посередеине лок на чемто

pro.jvm

01 May 2025 23:07

так он еще не замьючен

pro.jvm

20 Jun 2025 20:35

Ты всегда можешь их нагенерировать

pro.jvm

20 Jun 2025 20:31

а теперь вопрос знатокам, сколько нужно таких композтных индексов, если фильтрация возможна не по двум, а по пяти атрибутам?

pro.jvm

20 Jun 2025 20:27

В pgsql все так. Второе поле по индексу будет искать только если первое поле так же есть в условии. Это если мы говорим про дефолтный b-tree.

pro.jvm

20 Jun 2025 20:17

Можно конечно сдвоенный индекс для запросов где оба условия

pro.jvm

20 Jun 2025 20:14

Зависит от ьипа индекса. Но все же это эффективней чем фулскан таблицы. Ну и оьычно там норм дерево собираеться

pro.jvm

20 Jun 2025 20:09

Можно конечно но это уже изменения существеное

pro.jvm

20 Jun 2025 20:08

праймери кей тоже можно композит

pro.jvm

02 May 2025 10:29

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

pro.jvm

02 May 2025 09:57

Синтаксис очень похож на хачкель, я не спец но по мне почти один в один

pro.jvm

02 May 2025 07:35

Какой то очередной хачкель

pro.jvm

02 May 2025 06:08

Я делал так: обычная ConcurrentQueue, основной тред укладывает туда задания, другие треды (у меня было фиксированное кол-во) забирают их и исполняют. Всё просто и незатейливо. Не то?

pro.jvm

01 May 2025 23:23

Сейчас башка особо не варит, и там надо ещё посмотреть, что будут делать консюмеры, не доходящие до синхронизированной части, но с атомарными публикациями выглядит что может сработать, если паблишер всегда под тем же монитором. Про последнее я как-то не думал.

pro.jvm

01 May 2025 23:09

- T1 outstanding -> 0
- T1 tear point
- T2 publish()
- T2 outstanding <- 1
- T2 signal()
- T1 tear point recovery
- T1 wait()

pro.jvm

01 May 2025 23:08

ну смотри, у тебя ли двух этапный мьют либо двухътапный размьют

pro.jvm

01 May 2025 23:07

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