2015-01-16 12:02 GMT+03:00 Ivan Petrov <[email protected]>: >>> мне кажется голый SQL это единственный способ строить нормальные >>> хайлоады. >>> как показывает практика ВСЕ кластерные решения (шардинг и проч) - вещи >>> ОЧЕНЬ интимные. >>> >>> то есть например если у вас пользователи, то вам пойдет практически >>> любой вид шардинга, а если у вас таблицы с логами действий тех же >>> пользователей и вам надо выводить списки, то уже далеко не любой >>> подойдет. > >> Хранить time-series data в RDBMS, да еще и с шардами - какая свежая >> идея, однако! > > Вот допустим билинг у вас. > пользователь что-то сделал, а Вы с него денюжку считали. > все транзакции пишем в лог + баланс пользователя расчитываем. > > Нужно уметь показывать выборки из этого лога > ибо пользователь захочет видеть отчет вида "списания с времени X до > времени Y" > соответственно такой лог где Вы предлагаете хранить?
Ну, если мы говорим о так называемом "хайлоаде", то в HBase. Только ключ надо начинать не с даты, а с ID пользователя, иначе весь биллинг повалится в один и тот же регион. Как вариант - в OpenTSDB (то есть, в том же HBase). Предупреждая вопросы - я так делал, брат жив. Только у меня был не лог операций, а другие первичные пользовательские данные. > > далее если говорить о кластере то в контексте выборок списков шардинг > сюда ложится только с кучей оговорок Он здесь нинужен, я бы с этого начал. > >>> SELECT >>> * >>> FROM >>> table1 >>> JOIN >>> table2 >>> JOIN >>> table3 >>> WHERE >>> table1.col = 10 >>> >>> до сих пор многие базы не научились нормально во всех случаях >>> оптимизировать. >>> то есть до того что нужно СПЕРВА сделать выборку table1 а потом ее >>> JOIN на все остальное додумается далеко не каждый планировщик. причем >>> те планировщики которые умеют до такого додуматься, додумаются не >>> всегда. > >> Силюсь понять, что имеется в виду. >> Что значит "сперва сделать выборку table1, а потом ее JOIN"? Есть >> какие-то планировщики, которые сначала сделают декартово произведение, >> а потом только наложат условие? ДА ЛАДНО? Где это такая радость? > > в MySQL и Pg. сюрприз? В MySQL - не сюрприз, а клевета. MySQL так не делает, точка. > иногда очень много усилий надо приложить чтобы ЗАСТАВИТЬ Pg делать > выборку ДО JOIN. "Много усилий" - например, отключить hash join в данной сессии? Или покажите план - возможно, мы просто не вполне понимаем друг друга. Если не покажите, то хотя бы опишите словами, что за чем будет следовать. > > вторая проблема, толкающая в свой синтаксис - заставить использовать > именно нужный индекс. > > это пожалуй единственная хорошая черта MySQL - то что можно сказать в > явной форме какой индекс использовать для запроса. Ну - это не офигеть какая хорошая черта (и, да, не единственная, не нужно этого элитизма). > в Pg если у Вас частичный индекс размером 100Кб построенный специально > для данного запроса, то он все равно может решить использовать > 8Гиговый индекс по каким-то своим внутренним соображениям. Допускаю такую возможность - но на практике удавалось избежать подобного дропнув индекс большего размера вообще и лишив планировщик выбора. Либо подобрав условие в WHERE так, чтобы большой индекс задействовать было нельзя. > и единственный способ убедить его как надо правильно действовать - > WITH. Не самый плохой способ, работает же. -- SY, Alex > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
