>>> Ну, если мы говорим о так называемом "хайлоаде", то в HBase. Только >>> ключ надо начинать не с даты, а с ID пользователя, иначе весь биллинг >>> повалится в один и тот же регион. >> >> про ключ - это я думал понятно итак.
> Ну - я на всякий случай. > А то сейчас скажу, не оговорив граничные условия, а кто-нибудь из > читателей воспользуется, не подумав, и будет потом Предъявлять. От > людей, на прошлой неделе открывших для себя Dragon book, всего можно > ожидать. а вы не кичитесь тем что вы Dragon book видели. а то это как-бы анекдот напоминает про дзюдо, тайквандо и много других страшных слов >> >>>> далее если говорить о кластере то в контексте выборок списков шардинг >>>> сюда ложится только с кучей оговорок >> >>> Он здесь нинужен, я бы с этого начал. >> >> мы говорили о кластерах. >> кластера для чего нужны? > О каких именно? Об HA или о LB кластерах? мы говорили о кластерах вообще. вроде пока никто ничего не конкретизировал >> 2. размазывание данных (желательно с избыточностью) по кластеру >> >> >> и вот задача "показ лога" - она довольно типовая для бизнесов, а вот >> на кластера ложится плохо. > Ну и в каком именно месте она плохо ложится на кластера? > То, что в фидоэхе RU.PERL подписчики до сих пор не знают, как > использовать тот же HBase - это проблема кластеров, или, таки, > подписчиков RU.PERL? HBase и хадуп - это ацтой тот еще. вообще все что Java - все ацтой. мне неинтересно это говно обсуждать особенно в таком ключе что дескать подписчики тупые. это вы уж без меня. > А я говорю - не делает! > Я же прав, иначе ведь быть не может? нет не правы > Я к тому, что примеров, конечно, не будет? С планами запросов? примеров не будет. со времен mysql 5.0.1 я не использую mysql. это уже три по моему года прошло. и соответственно именно основываясь на планах запросов мы в свое время для него писали аналог внешнего with >> расставить веса для seq_scan например итп итд > А еще можно засунуть в рот ствол ружья и нажать спусковой крючок > большим пальцем ноги. > Сегодня день отличных рецептов! если база решает что индекс ей использовать не хочется, то единственный способ заставить ее передумать - перераспределить веса критериев, влияющих на ее решение. я как-то не очень понимаю вашего веселья вы там видели обложку Dragon book. и от этого не можете остановиться веселиться? странно, очень страно >> всегда проще переписать запрос > Особенно, если он генереный тем же ORM. > Нет, не всегда проще переписать запрос, далеко не всегда. дык ORM же зло и это в этой рассылке доказали 5-6 писем назад, когда сделали заявку что ORM без возможности писать руками SQL запрос - в помойку. а поскольку фича ORM писать SQL запросы руками становится для ORM настолько ключевой, делаем вывод что ни один из ORM с поставленной задачей не справляется. поэтому о запросах генеренных ORM говорят уже только ламье и школота, под влиянием наркоты и Java -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
