2015-11-09 18:17 GMT+03:00 Ivan Petrov <[email protected]>: > > >>> Минимизировал участие MySQL в пользу REDIS там, где нет длинных > портянок > >> в > >>> таблицах и NoSQL лучше подходит. Зашуршало. > > >> кстати ВЕЗДЕ (кроме случаев server-side шардинга, а сейчас пожалуй и в > >> них тоже) noSQL базы данных проигрывают "монстрам". > >> ибо noSQL пишут как правило полнейшие ламеры и всякий noSQL как > >> правило представляет из себя один-два BTREE индекса и все. > > > Как правило - не BTREE. > > как правило BTREE > > > Вот уж делать BTREE - и правда смысла ноль. > > LSM-tree, как правило. > > LSM это уже способ хранения а не способ TREE >
Если под "TREE" понимать любую упорядоченную структуру с возможностью range scan, то оно, конечно, TREE. Тонкая грань между физическим представлением и абстракцией. > > а мы говорили об индексах а не о способе хранения на диске. > Тем не менее, способ хранения на диске очень важен. > > >> смысла использования noSQL ровно ноль. > > >> у noSQL только одно преимущество и оно не относится к быстродействию, > >> функциональности и так далее. > >> оно относится только к социальному фактору: > > >> когда человек пишет на SQL он не всегда понимает что там происходит в > >> хранилище и поэтому очень легко загоняет хранилище в ступор. > >> когда человек пишет на noSQL то он ВЫНУЖДЕН понимать как хранилище > >> устроено и поэтому загнать его в ступор ему трудно. > > >> а так, вон Pg давно по бенчмаркам уделывает все эти модные > >> монги/редисы, мало того - еще и масштабируется неплохо по CPU. > > >> а server-side шардинг, ну толкового пока никто его не написал ни на > >> редисе, ни на монге, ни на SQL. > > > Это потому что и редис, и монга - это маркетинговые решения, а не > > технологические. > > а технологические - это кто? > Да какая разница. Все равно вокруг одни монга и редис. Впрочем, это временно, помню времена, когда вокруг был один Perl. > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org >
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
