[Moscow.pm] v2 просьба о ревью модуля DBIx::Struct

[Ivan Petrov]

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

про ключ - это я думал понятно итак.

>> далее если говорить о кластере то в контексте выборок списков шардинг
>> сюда ложится только с кучей оговорок

> Он здесь нинужен, я бы с этого начал.

мы говорили о кластерах.
кластера для чего нужны?

1. распределение нагрузки по кластеру
2. размазывание данных (желательно с избыточностью) по кластеру


и вот задача "показ лога" - она довольно типовая для бизнесов, а вот
на кластера ложится плохо.

> В MySQL - не сюрприз, а клевета.
> MySQL так не делает, точка.

делает делает.

>> иногда очень много усилий надо приложить чтобы ЗАСТАВИТЬ Pg делать
>> выборку ДО JOIN.

> "Много усилий" - например, отключить hash join в данной сессии?

расставить веса для seq_scan например итп итд

всегда проще переписать запрос


> Допускаю такую возможность - но на практике удавалось избежать
> подобного дропнув индекс большего размера вообще и лишив планировщик
> выбора.

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

> Либо подобрав условие в WHERE так, чтобы большой индекс
> задействовать было нельзя.

либо переписав запрос

>> и единственный способ убедить его как надо правильно действовать -
>> WITH.

> Не самый плохой способ, работает же.

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