Re[77]: EntityFramework - тормоз
От: alex_public  
Дата: 13.05.15 15:16
Оценка:
Здравствуйте, gandjustas, Вы писали:

_>>Это в какой ценовой категории интересно? )

G>500к-1М рублей

Ууу) На нормальные сервисы (без гигантских sql баз) хватает в 10 раз меньшего)))

_>>Про ресурсы я ничего такого не говорил. Как раз наоборот, nosql БД обычно летают на совсем дохлых серверах. ))) А вот умений программиста с ними действительно надо больше.

G>Ты опять сравниваешь точечные замеры? Не понял еще что отсутствие гарантий замедляет систему?

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

_>>Stackowerflow и т.п. — это старые проекты. Потому и работают на РСУБД.

G>Ты думаешьтам такие лоши работают, что если бы были профит от nosql они бы не отказались от sqlserver?

Я думаю, что там нормальные люди, руководствующиеся принципом "работает — не трогай". ) У них же вряд ли намечается какой-то крупный рост нагрузки в ближайшее время. Так с какой стати им тратиться на переход? ) И в большинстве мест всё тоже самое. А вот в стартапах естественно совершенно другой расклад... )

_>>Речь о текущих стартапах (или уже не совсем стартапах)))).

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

Хыхы, я эту ссылку уже несколько раз тут видел. ))) И соответственно обсуждение тоже уже было. )))

G>Ты удивишься, но все инстансы редиса, которые я видел в продакшене имеют отключенный persistance. Не нужен он там.

G>А memcached — говно, банально нету возможности атомарно увеличить счетчик. Без этого его даже в качестве кеша можно использовать с огромной натяжкой.

Ну вот, ты оказывается постоянно используешь nosql решение, правда не совсем по назначению. )))

_>>ОК, давай, приведи эту https://community.nodebb.org БД в неконсистентное состояние. )))

G>На каждый пост выполняется около 5 обращений к монге, любое падение и база в неконсистентном состоянии. Кроме того это плохо будет работать с multimaster репликацией, так как при репликации вместо инкремента в базу уходит новое значение и легко потерять значения в счетчике при параллельной записи в два разных мастера. Даже ниче специально делать не нужно, оно само рассинхронизируется. Думаешь почему в монгу добавили autoincrement поля?

Нуу так можно увидеть эту "рассинхронизацию" где-то на практике? ) Или у нас по прежнему одни слова будут? )))

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

G>Еще раз: Покажи живой инстанс с посещяемостью rsdn

А ты думаешь там сильно отличается?) Вот я захожу туда и вижу сообщение оставленное "15 minutes ago", захожу на rsdn и вижу у последнего сообщения "11 мин". И? ) Хотя конечно посещаемость теоретически может быть не пропорциональной "скорости написания сообщений"... Но вряд ли отличие на порядки. )))

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

G>Я считаю, что такое возникает гораздо реже, чем об этом ты пишешь.

Это смотря в какой области и на каком языке. )))
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.