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

[Alex Chistyakov]

2015-01-16 18:36 GMT+03:00 Ivan Petrov <i.petro.77.00 на gmail.com>:
>
>> Ну, если мы говорим о так называемом "хайлоаде", то в HBase. Только
>> ключ надо начинать не с даты, а с ID пользователя, иначе весь биллинг
>> повалится в один и тот же регион.
>
> про ключ - это я думал понятно итак.

Ну - я на всякий случай.
А то сейчас скажу, не оговорив граничные условия, а кто-нибудь из
читателей воспользуется, не подумав, и будет потом Предъявлять. От
людей, на прошлой неделе открывших для себя Dragon book, всего можно
ожидать.

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

О каких именно? Об HA или о LB кластерах?
Какие в кластере трейдоффы? Это CP или AP система?

>
> 1. распределение нагрузки по кластеру

Я хочу посмотреть на распределение нагрузки по HA кластеру!

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

Ну и в каком именно месте она плохо ложится на кластера?
То, что в фидоэхе RU.PERL подписчики до сих пор не знают, как
использовать тот же HBase - это проблема кластеров, или, таки,
подписчиков RU.PERL?

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

А я говорю - не делает!
Я же прав, иначе ведь быть не может?
Я к тому, что примеров, конечно, не будет? С планами запросов?

>
>>> иногда очень много усилий надо приложить чтобы ЗАСТАВИТЬ Pg делать
>>> выборку ДО JOIN.
>
>> "Много усилий" - например, отключить hash join в данной сессии?
>
> расставить веса для seq_scan например итп итд

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

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

Особенно, если он генереный тем же ORM.
Нет, не всегда проще переписать запрос, далеко не всегда.

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

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

> то есть два индекса они не просто так построены, а для двух возможных
> вариантов.
>
>> Либо подобрав условие в WHERE так, чтобы большой индекс
>> задействовать было нельзя.
>
> либо переписав запрос
>
>>> и единственный способ убедить его как надо правильно действовать -
>>> WITH.
>
>> Не самый плохой способ, работает же.
>
> дык я об этом и говорю.
> только этот способ сразу ставит крест на переносимости кода с базы на
> базу
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org