Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, gandjustas, Вы писали:

_>>>Гораздо дешевле? ))) Это с каких это пор жирные кластеры стали дешёвыми? ) Как раз наоборот, намного дешевле взять несколько простенький серверов (можно вообще на Атоме), объединённых в сеть.
G>>Это тоже миф, который поддерживают апологеты nosql и подобной муйни. Я перед новым годом считал hp-шные серверы. Сервер в два раз толще оказался на 30% дешевле, чем два сервера.

_>Это в какой ценовой категории интересно? )
500к-1М рублей

_>Да, кстати, и два сервера к тому же дают дополнительную надёжность... )
Это только при покупке дополнительных мощностей, сверх необходимого. В противном случае наоборот снижает надежность, так как отказ любого сервера ведет к остановке системы или к деградации производительности.
Если ты шардишь базу в монге, а потом у тебя одна из шард падает, то без реплики ты в большинстве случаев не сможешь продолжать работу.

G>>Ок, шардить таки можно, но чуть сложнее, чем в nosql, ок?
G>>При этом помним, что у РСУБД потребность в шардинге на порядок ниже. Грубо говоря noSQL нужно шардить когда объем данных больше объема ОП, а у РСУБД такой необходимости нет.
_>Угу. ) Это из серии на ассемблере писать таки можно, но чуть сложнее, чем на C#. )
Я делал шардинг и писал программы на ассемблере, шардинг попроще будет. Да и потребность в нем на порядки (в 10-100 раз) ниже в РСУБД.

_>>>Ну да, согласен, это инструмент требующий умений и продумывания заранее. Но это ещё не повод его не использовать.
G>>То есть ты признаешь, что использование noSQL требует больше затрат, чем классические РСУБД, тогда зачем их использовать? Сложнее, ресурсов больше надо, в чем профит?
_>Про ресурсы я ничего такого не говорил. Как раз наоборот, nosql БД обычно летают на совсем дохлых серверах. ))) А вот умений программиста с ними действительно надо больше.
Ты опять сравниваешь точечные замеры? Не понял еще что отсутствие гарантий замедляет систему?

G>>Что ты имеешь ввиду под "современный веб движется именно в эту сторону"? Все используют фейсбук, твиттер и прочите соцсети как сервис. Но практически никто не пишет свои лайки на 100500 миллионов пользователей. А в масштабах того же stackowerflow все прекрасно работает на РСУБД. И это офигенно большие масштабы для типичного веб-проекта. 99% веб-проектов до таких масштабов не дорастут никогда.

_>Stackowerflow и т.п. — это старые проекты. Потому и работают на РСУБД.
Ты думаешьтам такие лоши работают, что если бы были профит от nosql они бы не отказались от sqlserver?

_>Речь о текущих стартапах (или уже не совсем стартапах)))).
Вот тебе о стартапах — http://habrahabr.ru/post/231213/ как раз соцсеть с лайками. Прочитай внимательно прежде чем продолжать писать.

_>>>Хыхы, redis — это вообще то тоже игрушка из мира nosql. )))
G>>Редис это кэш, никакого отношения к persistent storage не имеет. По сути почти весь nosql это попытка на простой key-value кэш натянуть persistance. Попытка скорее неудачная.

_>https://ru.wikipedia.org/wiki/Redis — "Нереляционная высокопроизводительная СУБД." А пример именно кэша, это Memcached (неожиданное название, да? ), который в отличие от Redis не умеет сохранят данные на диск. Ну и кстати для просто кэша у Redis'a многовато типов данных. )))
Ты удивишься, но все инстансы редиса, которые я видел в продакшене имеют отключенный persistance. Не нужен он там.
А memcached — говно, банально нету возможности атомарно увеличить счетчик. Без этого его даже в качестве кеша можно использовать с огромной натяжкой.

G>>Когда жмешь отправить — видишь "ваше сообщение добавлено", это и его гарантия, что следующий запрос достанет новое сообщение.
G>>А в nosql было бы "ваше сообщение скоро будет добавлено, поэфпячьте страницу, чтобы его увидеть. А тут начинаются конкуретные апдейты, например для выделения подветки в отделенную тему и база приходит в неконсистентное состояние.

_>ОК, давай, приведи эту https://community.nodebb.org БД в неконсистентное состояние. )))
На каждый пост выполняется около 5 обращений к монге, любое падение и база в неконсистентном состоянии. Кроме того это плохо будет работать с multimaster репликацией, так как при репликации вместо инкремента в базу уходит новое значение и легко потерять значения в счетчике при параллельной записи в два разных мастера. Даже ниче специально делать не нужно, оно само рассинхронизируется. Думаешь почему в монгу добавили autoincrement поля?

_>>>Кстати, а вот один из самых современных (и при этом крайне быстрый) движков форумов https://nodebb.org работает с тремя (кстати, как раз через обсуждаемый выше слой абстракции БД) nosql СУБД и никаких проблем не испытывает. Причём одна из них как раз совсем не соответствующая ACID Redis.
G>>Покажи живой инстанс с посещяемостью rsdn.

_>Вообще то прямой по моей ссылке в меню можно было найти живое демо. Но я на всякий случай уже дал прямую ссылку в предыдущем абзаце. )))
Еще раз: Покажи живой инстанс с посещяемостью rsdn


_>>>Я что-то не понял, ты считаешь что это не реальные цифры или что? )
G>>Нет, я считаю что ты говоришь, о том, чего у тебя и большинства тут присутствующих никогда не будет. А если рассмотреть то, с чем сталкивается большинство ежедневно, то будет ровно обратная картина тому, что ты говоришь.
_>Т.е. переводя на русский язык твои кривые намёки, можно сказать, что ты считаешь описанную ситуацию (с преимуществом оптимизации программистами, над заменой железа) редким случаем? )
Я считаю, что такое возникает гораздо реже, чем об этом ты пишешь.