> Ну, если мы говорим о так называемом "хайлоаде", то в HBase. Только > ключ надо начинать не с даты, а с ID пользователя, иначе весь биллинг > повалится в один и тот же регион.
про ключ - это я думал понятно итак. >> далее если говорить о кластере то в контексте выборок списков шардинг >> сюда ложится только с кучей оговорок > Он здесь нинужен, я бы с этого начал. мы говорили о кластерах. кластера для чего нужны? 1. распределение нагрузки по кластеру 2. размазывание данных (желательно с избыточностью) по кластеру и вот задача "показ лога" - она довольно типовая для бизнесов, а вот на кластера ложится плохо. > В MySQL - не сюрприз, а клевета. > MySQL так не делает, точка. делает делает. >> иногда очень много усилий надо приложить чтобы ЗАСТАВИТЬ Pg делать >> выборку ДО JOIN. > "Много усилий" - например, отключить hash join в данной сессии? расставить веса для seq_scan например итп итд всегда проще переписать запрос > Допускаю такую возможность - но на практике удавалось избежать > подобного дропнув индекс большего размера вообще и лишив планировщик > выбора. ну вот. дропнуть индекс... все так просто у вас. а вот есть одна база. одна таблица. пользователь в эту одну таблицу пялится иногда по этому индексу, а иногда по другому. то есть два индекса они не просто так построены, а для двух возможных вариантов. > Либо подобрав условие в WHERE так, чтобы большой индекс > задействовать было нельзя. либо переписав запрос >> и единственный способ убедить его как надо правильно действовать - >> WITH. > Не самый плохой способ, работает же. дык я об этом и говорю. только этот способ сразу ставит крест на переносимости кода с базы на базу -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
