Re[79]: EntityFramework - тормоз
От: alex_public  
Дата: 14.05.15 22:26
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


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

S>Покажите ссылку на железку, о который вы говорите. 10-20 килобаксов — это совершенно мейнстримный сервер, что-то вроде Dell R920. Наши партнёры покупают такие сотнями

Я конечно не эксперт в серверах, но вот например здесь http://www.zdnet.com/article/dell-launches-r920-high-end-server/ он почему-то называется хайэндом. )))

Ну а что касается озвученных мною цифр, то даже если брать недешёвый HP, то какой-нибудь DL380e G8/DL180 G9 спокойно потянет приличную нагрузку.

S>А на машинке за $1000 вы ничего интересного захостить не сможете — она умрёт быстрее, чем вы задеплоите первую версию.


Ну да, если на винде и с sql server, то может быть)))

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

S>Как раз наоборот — он его использует строго по назначению. key-value хороши в качестве кэша — когда есть внешний источник консистентности. Потому что при потере консистентности вернуть её обратно в них невозможно просто никак. Грубо говоря, мы никак не можем отличить ситуацию "форумный пост успел закоммититься в историю пользователя, но не успел в топик" от ситуации "форумный пост успели замодерировать из топика, но не успели из истории пользователя", если у нас нет гарантированно консистентной базы под нашим кэшем. Если есть — мы просто сбрасываем кэш и перечитываем консистентное состояние.

Уже же вроде обсуждалось здесь. Redis — это не кэш, т.к. хранит данные на диске (хотя это и можно отключать). Пример кэша — это memcached, который действительно живёт только в оперативной памяти.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.