Слишком много предъяв, в основном не по делу.
По делу же, для 99% задач (сайты, обычный или мобильный web, вот это все) подходят уже готовые решения, даже обсираемый MySQL, ибо: 1. “Папа железа докупит” (кто помнит описалова того, как были устроены написанные на JAVA “Одноклассники" - тот поймет). 2. Пока розробочеги умничают, у инвесторов успевает кончиться бабло до скачка реальной посещаемости. В особых случаях (например real-time аналитика или рекламные сервисы) приходится изъебываться так, что коробочные истории просто не подходят, для чего приходится строить собственные решения, которые потом нигде не задействуешь. — Yours Dmitry Eremeev On 9 November 2015 at 17:23:32, Alex Chistyakov ([email protected]) wrote: 2015-11-09 17:19 GMT+03:00 Ivan Petrov <[email protected]>: > Минимизировал участие MySQL в пользу REDIS там, где нет длинных портянок в > таблицах и NoSQL лучше подходит. Зашуршало. кстати ВЕЗДЕ (кроме случаев server-side шардинга, а сейчас пожалуй и в них тоже) noSQL базы данных проигрывают "монстрам". ибо noSQL пишут как правило полнейшие ламеры и всякий noSQL как правило представляет из себя один-два BTREE индекса и все. Как правило - не BTREE. Вот уж делать BTREE - и правда смысла ноль. LSM-tree, как правило. смысла использования noSQL ровно ноль. у noSQL только одно преимущество и оно не относится к быстродействию, функциональности и так далее. оно относится только к социальному фактору: когда человек пишет на SQL он не всегда понимает что там происходит в хранилище и поэтому очень легко загоняет хранилище в ступор. когда человек пишет на noSQL то он ВЫНУЖДЕН понимать как хранилище устроено и поэтому загнать его в ступор ему трудно. а так, вон Pg давно по бенчмаркам уделывает все эти модные монги/редисы, мало того - еще и масштабируется неплохо по CPU. а server-side шардинг, ну толкового пока никто его не написал ни на редисе, ни на монге, ни на SQL. Это потому что и редис, и монга - это маркетинговые решения, а не технологические. -- Moscow.pm mailing list [email protected] | http://moscow.pm.org -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
