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