Поддержка этого железа, если приложение кривое и не умеет масштабироваться тоже требует времени, и не факт, что это дешевле времени девелоперов. Плюс накопление технического долга может привести к очень неприятным последствиям. Так ли этот вывод очевиден?
Так Вы используете штатную схему master-slave или всё же полноценную репликацию с арбитрами и отложенной репликой? Если первое — почему именно был сделан выбор в этом направлении? Если мне память не изменяет, master-slave и replica set — взаимоисключающие понятия.
Я так понял, у Вас арбитры располагаются на тех же серверах, где и сами реплика сеты для шардов? Это достаточно плохая практика, так как при обвале одного сервера отвалятся secondary и arbiter для одного из шардов, что приведёт к неработоспообности replica set (primary не увидит большинства членов replica set и уйдёт в secondary). Лучше положить арбитров на третий сервер, раз у Вас их три.
«Это какой-то неправильный DevOps» =) СI, CD, канарейки, выкатка в рабочее время — наше всё. Хотя и проблем хватает, конечно. Например, для веба, изменение схемы жирнющей БД без остановки сервиса.
Хороших специалистов ни в одной сфере нет избытка.
Хотя бы с адекватными скиллам запросами и желанием учиться — вот кого реально не хватает, ИМХО.
Но тут и ситуация с рынком влияет — часто потенциальные работодатели хотят, чтобы был и швец, и жнец, и на дуде игрец за 30 тысяч где-нибудь в Москве или Питере. Столько этих «работать в нашем банке — большая честь» видел, аж жуть.
Если мне память не изменяет, года 1.5 назад как раз разработчики Openstack решили перейти на полугодовой цикл релизов, привязанный к циклу релизов Ubuntu. Как раз когда Canonical серьёзно начала переходить от Eucalyptus к Openstack.
Правда, в результате я второй год не понимаю, какой репозиторий использовать для связки Ubuntu + Openstack. Только недавно же для Ubuntu 12.04 появился репозиторий с Havana.
А вообще — в релиз-цикле icehouse как раз была указана дата 17.04.
Да, мой пробел, по всей видимости. Продумал ещё раз — никак что-то не получается. Даже если делать апдейт на каждое использование с гарантированным move — всё равно не получится, так как для самой монги данные окажутся там же, а не перемешёнными.
Удивлён, что Redis здесь (топик и комментарии) упоминается всего 1 раз. Логичное решение. Для LRU в MongoDB имеет смысл использовать небольшую capped-коллекцию, но и там есть свои подводные камни. Троллейбус в заголовке идеально описывает данный подход.
Это нормальная ситуация для RC. Даже для наземных моделей типа Axial SCX10 (внедорожники) нормальное время работы от одной батареи — около 20 минут. А тут вес с собой в воздух брать надо.
Хотя бы с адекватными скиллам запросами и желанием учиться — вот кого реально не хватает, ИМХО.
Но тут и ситуация с рынком влияет — часто потенциальные работодатели хотят, чтобы был и швец, и жнец, и на дуде игрец за 30 тысяч где-нибудь в Москве или Питере. Столько этих «работать в нашем банке — большая честь» видел, аж жуть.
Правда, в результате я второй год не понимаю, какой репозиторий использовать для связки Ubuntu + Openstack. Только недавно же для Ubuntu 12.04 появился репозиторий с Havana.
А вообще — в релиз-цикле icehouse как раз была указана дата 17.04.
Поосторожнее, от передозировки баззвордов может сколлапсировать мозг.