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