2015-01-16 21:07 GMT+03:00 Ivan Petrov <[email protected]>: >>>> Ну, если мы говорим о так называемом "хайлоаде", то в 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 > [email protected] | http://moscow.pm.org -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
