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

[Alex Chistyakov]

2015-01-16 12:02 GMT+03:00 Ivan Petrov <i.petro.77.00 на gmail.com>:
>>> мне кажется голый SQL это единственный способ строить нормальные
>>> хайлоады.
>>> как показывает практика ВСЕ кластерные решения (шардинг и проч) - вещи
>>> ОЧЕНЬ интимные.
>>>
>>> то есть например если у вас пользователи, то вам пойдет практически
>>> любой вид шардинга, а если у вас таблицы с логами действий тех же
>>> пользователей и вам надо выводить списки, то уже далеко не любой
>>> подойдет.
>
>> Хранить time-series data в RDBMS, да еще и с шардами - какая свежая
>> идея, однако!
>
> Вот допустим билинг у вас.
> пользователь что-то сделал, а Вы с него денюжку считали.
> все транзакции пишем в лог + баланс пользователя расчитываем.
>
> Нужно уметь показывать выборки из этого лога
> ибо пользователь захочет видеть отчет вида "списания с времени X до
> времени Y"
> соответственно такой лог где Вы предлагаете хранить?

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

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

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

>
>>> SELECT
>>>     *
>>> FROM
>>>     table1
>>> JOIN
>>>     table2
>>> JOIN
>>>     table3
>>> WHERE
>>>     table1.col = 10
>>>
>>> до сих пор многие базы не научились нормально во всех случаях
>>> оптимизировать.
>>> то есть до того что нужно СПЕРВА сделать выборку table1 а потом ее
>>> JOIN на все остальное додумается далеко не каждый планировщик. причем
>>> те планировщики которые умеют до такого додуматься, додумаются не
>>> всегда.
>
>> Силюсь понять, что имеется в виду.
>> Что значит "сперва сделать выборку table1, а потом ее JOIN"? Есть
>> какие-то планировщики, которые сначала сделают декартово произведение,
>> а потом только наложат условие? ДА ЛАДНО? Где это такая радость?
>
> в MySQL и Pg. сюрприз?

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

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

"Много усилий" - например, отключить hash join в данной сессии?
Или покажите план - возможно, мы просто не вполне понимаем друг друга.
Если не покажите, то хотя бы опишите словами, что за чем будет следовать.

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

Ну - это не офигеть какая хорошая черта (и, да, не единственная, не
нужно этого элитизма).

> в Pg если у Вас частичный индекс размером 100Кб построенный специально
> для данного запроса, то он все равно может решить использовать
> 8Гиговый индекс по каким-то своим внутренним соображениям.

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

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

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

--
SY,
Alex


>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org