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

[Alex Chistyakov]

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

Ошибка - я, как раз, ее не видел.
Мне очень стыдно, конечно, но так уж вышло.
Впрочем, я вру. Мне не стыдно.

> а то это как-бы анекдот напоминает про дзюдо, тайквандо и много других
> страшных слов

Ну а чего там страшного-то? Бывают LL(n) грамматики, а бывают еще
какие-то там, я бы предположил, что RR.

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

Ну - мы можем об авиационном кластере поговорить тогда. Или об автомобильном.

> вроде пока никто ничего не конкретизировал
>
>
>
>>> 2. размазывание данных (желательно с избыточностью) по кластеру
>>>
>>>
>>> и вот задача "показ лога" - она довольно типовая для бизнесов, а вот
>>> на кластера ложится плохо.
>
>> Ну и в каком именно месте она плохо ложится на кластера?
>> То, что в фидоэхе RU.PERL подписчики до сих пор не знают, как
>> использовать тот же HBase - это проблема кластеров, или, таки,
>> подписчиков RU.PERL?
>
> HBase и хадуп - это ацтой тот еще.

Разумеется.

> вообще все что Java - все ацтой.

Все так и есть.
Куда уж там JVM по своим свойствам до интерпретатора Perl.

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

Да я все понял уже.
Вы решили это не обсуждать, а доказать.
Джава - отстой, MySQL - отстой, HBase и Hadoop - отстой.
Пастернак, кстати, тоже говно то еще.
Это я удачно зашел.

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

А я говорю - прав.
Пока мы метрики не представим измеримые, мы не добьемся ничего.
Очевидно.

>
>> Я к тому, что примеров, конечно, не будет? С планами запросов?
>
> примеров не будет. со времен mysql 5.0.1 я не использую mysql.

MySQL с тех пор в части планировщика не изменился совершенно.

> это уже три по моему года прошло.

3 года? С 5.0.1?
Круто.
С 5.0.1, я думаю, 13 лет уже прошло.
Но, повторюсь, даже 5.0.1 такие косяки не порол, они за гранью разумного.
Не надо считать разработчиков MySQL дебилами, некоторые из них -
долларовые миллионеры.

> и соответственно именно основываясь на планах запросов мы в свое
> время для него писали аналог внешнего with

"У нас есть такие ракеты..."

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

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

>
> я как-то не очень понимаю вашего веселья
> вы там видели обложку Dragon book. и от этого не можете остановиться
> веселиться?

Мое веселье объяснимо очень просто - уже несколько дней мне в почтовый
ящик падают мифы и легенды Древней Греции.
И я чиста зашел поинтересоваться: чем именно вызван этот поток?

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

Мнение этой рассылки относительно того, зло ORM или нет, является для
меня столь же важным, как и мнение кофемашины о причинах глобального
потепления. Тем более, с учетом смысла и значения слова "доказали". У
вас тут Хабрахабр, что ли? Доказанным считается утверждение, за
которое проголосует большая часть электората? На объективную истину
всем плевать?

> когда
> сделали заявку что ORM без возможности писать руками SQL запрос - в
> помойку.

Окей, штатный use case для ORM:
- наколбасить бизнес-логику методом "ххивп" руками джуниоров и стритовых дам,
- методом направленного поиска идентифицировать те 1.5 запроса,
которые требуют ручного вмешательства,
- переписать их в raw SQL, либо модифицировать иным способом,
- PROFIT

В помойку надо отправлять не ORM, а операторов ORM. И некоторых
создателей ORM, которые не ведают, что творят.

> а поскольку фича ORM писать SQL запросы руками становится для ORM
> настолько ключевой, делаем вывод что ни один из ORM с поставленной
> задачей не справляется.

Формально это совершенно верный вывод, но:
а) есть ORM проекты, в которых raw SQL возможен. Например - Hibernate.
б) есть огромная куча продуктов, в которых вообще нет 1.5 запросов,
требующих ручного вмешательства. Просто потому, что они не доросли до
нужного размера.

>
> поэтому о запросах генеренных ORM говорят уже только ламье и школота,
> под влиянием наркоты и Java

В одном письме видеть утверждения "ORM пользуется только ламье" и
"MySQL не умеет применять фильтр к driving table в очевиднейшем
случае" - это должно взрывать мой мозг, но я уже привык ко всему.
Впрочем, некоторые видят пони и говорят с цветами, так что я уважаю вашу веру.

--
SY,
Alex


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