DPH3skyANAпропущено...
Уточните свой вопрос.

Ну, вы решили вместо MS SQL (или другой РСУБД) использовать MongoDB с самодельной реализацией транзакций, при этом исходили из требований масштабирования и надежности.Не вместо. Мы решили кардинально переделать CMS модуль нашей системы. Только данные, относящиеся к этому модулю, перенесли в MongoDB. MS Sql Server остался основным хранилищем.

DPH3Интересно:
на какую нагрузку (пишущих/читающих транзакций в секунду, время отклика) вы рассчитывалиПиковая нагрузка у нас - 300+ запросов в секунду (если я правильно помню цифры). Рабочая - это десятки запросов в секунду.
Из них большая часть - это читающие транзакции. Порядка 90%.

DPH3какую надежность (в часах простоя в год, например или во времени восстановления) планировалиНе хуже чем только с MS Sql Server. Мы снимаем показатели за каждый месяц. Наши основные сервисы доступны 99.8-100% времени.
99.5% - это уже не очень хорошо :)

Случаются конечно единичные простои, но не из-за СУБД.

DPH3что в результате получилосьКак раз сейчас готовимся к gradual upgrade наших клиентов. Ещё только посмотрим, что получилось
Но по нашим тестам с MongoDB в плане надёжности проблем нет.

DPH3ну и как реализовывали HA для MongoDB между датацентрами :)Не понял о чём Вы. О каких датацентрах речь?

DPH3И почему именно Mongo, а не та же Cassandra?

Заранее спасибо )Мы рассмотрели разные варианты, взвесили за и против и решили, что MongoDB нам больше подходит.

Основные данные CMS - это структура веб страниц и шаблонов страниц, а также история их изменений (версии). А это что? Правильно, документы :)

Плюс возможность писать запросы к данным и наличие официального драйвера для C#.
Вообще у на в корпоративной wiki (confluence) есть более полный перечень pros and cons, всего не помню.

DPH3skyANAПиковая нагрузка у нас - 300+ запросов в секунду (если я правильно помню цифры). Рабочая - это десятки запросов в секунду.
Из них большая часть - это читающие транзакции. Порядка 90%.

Т.е. нагрузка не существенна, производительность не являлась сколь-нибудь существенным фактором?Является.
DPH3Как я понимаю специфику CMS, там довольно мало сложноструктурированных данных (документов, да), так что все равно все в кэшах.Почти всё в кэше, используем Couchbase, выше писал. History и Trash не кэшируются.
DPH3До этого как вы хранили эти данные в MS SQL? Блобы, текстовые поля, полная нормализация? В чем были проблемы с использованием решения на MS SQL?Нормализация (структура и функционал был намного проще). Решение на MS SQL оказалось трудозатратнее и дороже по нашим оценкам.

DPH3skyANAНе хуже чем только с MS Sql Server. Мы снимаем показатели за каждый месяц. Наши основные сервисы доступны 99.8-100% времени.

Сколько отказов железа было за это время? На каком уровне? Сколько физических серверов использует MongoDB?

skyANAНе понял о чём Вы. О каких датацентрах речь?

Ну, вообще-то, когда я слышу о HA, то я сразу вспоминаю, что один датацентр - это в лучшем случае три девятки на долгих сроках, реально меньше. И если все-таки нужна высокая доступность, то это всегда разнесение системы по физически изолированным датацентрам. Если у вас нет требований защищаться от рисков уровня ДЦ - то ладно, хотя тогда зачем говорить о высокой доступности :)

Но, впрочем, данные у вас в монго не слишком важные, потеряете - не страшно :)Это как посмотреть. Для нас важные :)

За инфраструктуру у нас отвечают отдельные люди. Раньше было 12 физических серверов. Вроде как их заменили на 6 более мощных, старые вывели из эксплуатации.
Также вся инфраструктура переводится на Hyper-V. Вроде как 4 гипервизора на тестовой. Сколько будет в продакшн, пока не скажу.

DPH3skyANAпропущено...
Является.

Тогда я, честно говоря, не понимаю. 300 запросов на чтение в секунду в пиках, без хитрых join, да еще и с внешним кэшированием - это вообще не нагрузка.1. Если бы делали на MS SQL, то появились бы хитрые join;
2. Ну не ждать же нам, когда посещаемость наших сервисов не миллионами, а десятками миллинов в сутки будет измеряться?

Мы же представляем динамику роста нагрузки и готовимся заранее.

DPH3skyANAпропущено...
Нормализация (структура и функционал был намного проще). Решение на MS SQL оказалось трудозатратнее и дороже по нашим оценкам.

Хм, если вас устроила модель Mongo, то уж банальные блобы в MS SQL уж всяко работали бы не хуже.Опа на, вот тут я сильно засомневался в Вашей компетентности. Как бы Вы на блобах построили систему и обеспечили приемлимую скорость сериализации/десериализации, не говоря уже о шардинге, репликации и поддержке обновлений?

DPH3Ни одной из "фишек" монго вы, похоже, не используете.О каких "фишках" речь? И с чего Вы решили, что мы их не используем?

DPH3skyANAЗа инфраструктуру у нас отвечают отдельные люди. Раньше было 12 физических серверов. Вроде как их заменили на 6 более мощных, старые вывели из эксплуатации.
Также вся инфраструктура переводится на Hyper-V. Вроде как 4 гипервизора на тестовой. Сколько будет в продакшн, пока не скажу.
Это только на монго или это всего на проект? И что сказали люди, отвечающие за инфраструктуру на выбор Монго?На данный момент к MongoDB у них претензий нет. Со всеми критическими и важными проблемами разобрались. А вот к MS SQL...

А на гипервизорах тестовой среды не только монго вертится, но и всё остальное под CentOS и Windows.

DPH3, про "фишки" забыли рассказать.