Блин, это я тему перепутал, убрал куда хотел изначально http://javascript.ru/forum/showthread.php?p=326433

Короче перед тем как создавать тему нужно было до конца разобраться чем реляционные бд отличаються от noSql

Главное что нужно понять в NoSQL - что это термин за которым срываются большое количество абсолютно разных СУБД, например,

ключ-значение: reddis
семейства столбцов: casandra
документо-ориентированные: mongoDB
графовые: Neo4J
и т.д.

Рекомендую к прочтению М. Фаулер NoSQL - это небольшая книженция в которой коротко и без воды рассмастриваются все основные виды NoSQL СУБД.

На лицо суждение о NoSQL по СУБД типа ключ-значение, но NoSQL этим не ограничивается (читай пост выше).

Для сложных отношений нет ничего лучше графовых СУБД типа Neo4J (а это NoSQL). Например запрос типа: построй карту "6-ти рукопожатий" от юзера А до юзера Б в графовых СУБД делается очень просто и очень быстро, а во всех остальных решениях это как правило ад.

Очень сомнительная иллюстрация.

Зачем монге ещё редис вешать? Как и любая нормальная СУБД монга старается держать всё в оперативе и при нормальном индексе кеш редиса не даст никакого профита. Также Redis (или тот же memcacheDB) можно спокойно юзать как самостоятельную СУБД

В проектировании БД главное предусмотреть сегментирование (в некоторых СУБД есть решения из коробки), а всё остальное ерунда, а если ваша БД не сегментируется, то рано или поздно настанет момент, когда все данные не влезут в оперативу и вам придётся переписывать всю вашу серверную логику, т.е. сегментирование должно быть автоматическим.

Более того, в современном мире в рамках проекта используется как правило 2-3 СУБД одновременно, даже есть термин - многовариантная персистентность.

Или не настанет никогда. Я однажды сделал предварительную оптимизацию, которая позволяла много чего, взамен небольшое неудобство при написании кода. Я проклял эту оптимизацию, т.к. она никогда не пригодилась, а вот с неудобством при написании кода я натрахался по самые уши.

ПС: думаю что кибер тебя не поймет, а если и поймет, то построить что-то толковое вряд ли сможет сходу. Для твоего предложения нужен опыт работы хотябы с одной базой данных и случай "невлезания" данных, а судя по его мыслям у него опыта никакого нет.

Если только приложение и не планируется под такой объём. Проблема сегментирования в том, что его нельзя потом просто включить, т.к. придётся переписывать вообще всё.

Использование решений "из-коробки" вроде MongoDB (на самом деле много кто предоставляет автосегментацию, но как правило это дорогие решения вроде Oracle) может переложить эту заботу на другие плечи.

PS: что касается Postgre, то у него есть своя отдельная СУБД для проектирования таких вещей.

Вот тут главное правильно оценить ситуацию:
1. Приложение может и не вырасти.
2. Написанный код (выбранный способ) может и не справиться с объемом, т.к. ситуация по сути абстрактная
3. Затраты на написание сегм. кода больше.

Иногда проще написать с нуля, чем сразу писать то, что не понимаешь.

Все зависит от скорости роста (проекта, посещаемости). Иногда проще взять машину помощнее или памяти побольше и проблема будет решена, нежели сразу писать код|выбирать способ рассчитанный на высокую нагрузку. Конечно в идеале лучше сразу писать код, выбирать базу рассчитывая на нагрузку. Особенно если это не затратно как по времени написания, так и по деньгам аренды оборудования.

Но как показывает практика, если что-то делаешь впервые, то лучше делать это проще.

Проект может не взлететь. Писать дольше на том, что изучаешь. Основная ошибка будет не там где думаешь. Это от того, что кибер понятия не имеет с чем столкнулся и выводы, уверен на 80% сделает в большинстве своем ошибочные, даже если ты ему все правильно скажешь. Прежде чем он сделает правильные выводы у него должен появиться опыт.

Поэтому чё париться предлагать писать сразу мега нагруженное приложение, когда ты даже тз его не знаешь, темы, идеи и посещаемости, а также динамики роста?

Gozar имхо в таком случае лучше взять готовое решение в облаке и немного переплатить, а потом когда встанет вопрос просто провести миграцию на такой же сервис, но уже свой. И волки сыты и овцы целы :)