Кстати вопрос знатокам.
Если я правильно понимаю, то работать async\await будет ровно как в C# — переписывать функции в КА, а замыкания в классы. Как при этом будет сделан контроль времени жизни\владения? Где будет храниться объект-замыкание?
То есть вы таки утверждаете что переход от кусочной виртуализации (как оно обычно бывает) к private cloud позволит что-то сэкономить на железе? За счет чего?
Проблема то не в самих серверах, а в том что не все приложения смогут захоститься на одном сервере. Хостить несколько приложений на одном сервере выгоднее чем хостить несколько виртуалок, не находите? Тут надо смотреть на конкретные приложения и считать. Но это НЕУДОБНО. А вот закупить железа с запасом раза в 3, а потом виртуализацией нарезать отдельные машины УДОБНО, но не очень эффективно по деньгам. Об этом я писал, а не о том, о чем вы думаете ;)
1) Я об этом и писал. Но вот в статье п1 — экономия на железе. А по факту не на железе, а на удобстве.
3) Без конкретной прикладной задачи слова ни о чем. А с конкретной задачей уже надо считать имеет смысл виртуализировать или нет.
1) Если ресурсов нет, то надо закупать. Если ресурсы есть, то можно и без виртуализации поднимать приложения на серверах. Где экономия?
3) Покупайте одинаковые серваки и будет вам однородность. Тем более, из пункта 1 мы понимаем что серваки уже закуплены. Какую проблему тут решает виртуализация?
1) Частное облако для экономии ресурсов — фейк. Даже наоборот, все эти потуги с виртуализацией увеличивают требования к железу, по сравнению с обычным размещением. Другое дело, что управление всем зоопарком при виртуализации гораздо удобнее, но об этом как раз и не написано.
2) Лицензирование почти у всех вендоров сейчас учитывает виртуализацию. А вообще может оказаться даже дороже из-за overcommit ядер, как например для MS SQL Server.
3) «масштабирование без боли» требует большого резерва мощностей, которые стоят денег и греют воздух. Это особенно касается тестовых сред.
Реальная польза виртуализации получается когда приложения знают об этой самой виртуализацией и могут автоматически подстривать потребление ресурссов под профиль использования.
На примере с порталом — в рабочее время поднимать больше виртуалок с веб-серверами для облуживания запросов, а в нерабочее время поднимать backend серверы для обхода и построения поискового индекса.
Увы готовых таких решений для private cloud я пока еще не видел.
Для любой РСУБД чем больше памяти, тем лучше. Все операции чтения с диска кэшируются в памяти и повторные чтения страниц не производятся. Фактически для максимально быстрой работы объем ОП должен быть не меньше объема активных данных (к которым происходят регулярные обращения).
Это кстати совершенно не зависит от процессоров и сети.
Про скорость диска полностью аналогично, ведь кроме запросов на чтение есть еще и запросы на запись. Чем быстрее диски, тем выше скорость работы СУБД (для нормальных субд), независимо от памяти и процессора.
Поэтому в зависимости от workload имеет смысл вкладывать ровно в то, что принесет максимальный прирост.
Только вот когда scale up не поддерживается, а доступен только scale out, приходится покупать все вместе: если нужно 360гб памяти, то придется купить 12 серваков по 32гб, а они будут иметь по 4 ядра, итого 48, которые в итоге будут бесполезно греть воздух (ибо 48 ядер нагружить на порядок сложнее, чем 360 гб). И каждому еще понадобится по диску прикупить, а то и несколько. Это уже не говоря про сеть, питание и охоаждение.
Еще раз повторю — scale out менее экономичный подход, чем scale up. Это только в облаках scale out — подход по умолчанию, а scale up очень ограничен. Облачные провайдеры используют недорогое commodity железо, поднимая деньги на том что перепродают тебе его. Они не считают совокупные затраты на приложение, а в SO считают.
Команда инженеров не просто маленькая, очень маленькая.
Даунтаймы у них не проблема вообще, плановые даунтаймы у них случаются раз в месяц, три девятки они держат, при этом умудряются использовать edge технологии, вроде CTP версий MS SQL.
Количество фич на SO просто зашкаливает, сравнимо с соцсетями, на порядок больше чем у твиттера.
ЗЫ. С какими же продуктами ты работаешь, что scale up для них недоступен? Приведи цифры по количеству запросов и объемам данных.
Надо не забывать что большую часть страниц SO отдает честно бегая в базу, поэтому именно Data Access они оптимизируют до невозможности. Linq2SQL медленно строит запросы и небыстро мапит на объекты. Dapper использует текстовые запросы и делает очень быстрый мапинг.
Кстати начать с dapper было бы практически нереально. Так как текстовые запросы убили бы продуктивность программистов.
Синхронная репликация — не failover. Это часть решения, но не все. Полное failover решение изкаропки имеет MS SQL и Oracle. Остальные СУБД требуют дополнительных компонент и\или поддержку на уровне приложения.
Все нормальные вендоры имею пограммы по апгрейду железа на гарантии, так что scaleup получается даже дешевле чем докупка серваков.
Любые затраты на разработку не явлюятся единоразовыми. Любой код требует поддержки. Особенно инфраструктурный, так как он зависит от внешних систем, которые постоянно развиваются.
Джоины нужны. Вся теория применения NoSQL говорит о том, что надо правильно построить структуру документа (читай заранее придумать все джоины). В SQL такой проблемы нет, так как джоином можно вытащить любое поддерево данных. Вот только такое вытаскивание требует ссылочной целостности, которое в свою очередь требует согласованности изменений. Поэтому NoSQL рулит в очень ограниченных сценариях, а SQL практически во всех. Там где не хватает SQL можно прикрутить кеш, полнотекстовый индекс или свой middleware, обычно этого хватает для очень масштабных проектов.
Шардинг SQL баз мешает джоинам. Вот в SO несколько сущностей: посты, комменты, пользователи. По какому ключу шардить? По пользователям? Тогда как собрать ленту новых постов? По постам? тогда как показать все посты пользователя? Денормализация и middleware скажете, так это усложнение на порядок на ровном месте, а выигрыш какой?
Денормальзация увеличивает количество код примерно в 3 раза. Начинать с этого нельзя в принципе. Для оптимизации надо не о денормализации думать, а о грамотном кешировании.
Я смотрел доклады на HiLoad — там решают проблемы, которых почти не возникает со взрослыми БД и нормальными платформами.
SO делает даунтайм раз в месяц примерно, но обслуживание серверов случается гораздо чаще. Потому что у них failover таки нормальный.
Судя по тестам синхронная репликация на postgres тормозит, вернее ТОРМОЗИТ. На уровне приложения failover делать неудобно, сильно усложняет приложение. Middleware — усложнение ещё сильнее.
Работа программистов, которые вынуждены этот middleware поддерживать, оказывается дороже, чем лицензиии, и сильно дороже, чем железо.
Читай тут: www.codinghorror.com/blog/2008/12/hardware-is-cheap-programmers-are-expensive.html
Как я уже говорил — шардинг дороже scale up. Поэтому скорее наоборот — шардинг это решение, когда scaleup невозможен. Но шардинг автоматически добавляет проблемы с джоинами, и снова нужно писать (а потом поддерживать) код, который будет имитировать функции MSSQL.
Несмотря на то, что ссылка 4-летней давности, проблемы актуальны и сейчас. Инженерные проблемы в общем случае не решены и некоторые нерешаемы вообще. Они решены в частных случаях конкретных систем. Адаптировать их — тоже работа, которую надо делать и код потом поддерживать.
NoSQL is hard сейчас не менее чем 4 года назад, и люди в stackoverflow это прекрасно знают и не связываются с этим.
ЗЫ. SO это не big data, даже не близко. Тем не менее до масштаба SO доживет один стартап из миллиона.
Ключевое слово тут — Failover. Это требует Enterprise лицензий как на Windows, так и на SQL Server.
Кстати хороший failover на *nix+mysql\postgres стоит тоже немало, но работает обычно хуже и\или сложнее в настройке.
Шардинг обычно более дорогой, чем scale up, вот только не все СУБД умеют хорошо делать scale up.
Конкретно в этом случае в SO делаются JOINы. Это позволяет оптимизировать время работы SQL и Web серверов. Там где джоины работают плохо (читай операции с тегами) уже работает отдельный middleware, тяжелые джоины кешируются в redis.
Если хранить это все в key-value, то надо как-то делать эти джоины. Готовые решения по индексации почти всегда не дают acid транзакционности, что усложняет код. Дополнительное железо понадобилось бы обеспечения транзакционности. И много подводных камней.
Идейный лидер — Joel Spolsky, действительно работал в MS, будучи Program Manager в команде Excel. С тех пор люто ненавидел MS, managed платформы и взрослые РСУБД.
Где-то читал что как раз Джоэл хотел сделать проект на RoR, его переубедили использовать .NET. Как раз в тот момент появились ASP.NET MVC и Linq2SQL, которые обладали функционалом не хуже RoR.
Если я правильно понимаю, то работать async\await будет ровно как в C# — переписывать функции в КА, а замыкания в классы. Как при этом будет сделан контроль времени жизни\владения? Где будет храниться объект-замыкание?
В C++ обязательно надо добавить async\await и yield из C#. А в C# надо реализовать шаблоны, как в C++ или хотябы подмножество, как в F#.
А еще в обоих надо TypeClasses как в Цацкелле.
Стандарт-стандартом, а практика немного другая:
stackoverflow.com/questions/174348/will-web-browsers-cache-content-over-https
Или тут: blog.httpwatch.com/2011/01/28/top-7-myths-about-https/
3) Без конкретной прикладной задачи слова ни о чем. А с конкретной задачей уже надо считать имеет смысл виртуализировать или нет.
3) Покупайте одинаковые серваки и будет вам однородность. Тем более, из пункта 1 мы понимаем что серваки уже закуплены. Какую проблему тут решает виртуализация?
Если бы получше искал, то нашел бы closedxml.codeplex.com/
2) Лицензирование почти у всех вендоров сейчас учитывает виртуализацию. А вообще может оказаться даже дороже из-за overcommit ядер, как например для MS SQL Server.
3) «масштабирование без боли» требует большого резерва мощностей, которые стоят денег и греют воздух. Это особенно касается тестовых сред.
Реальная польза виртуализации получается когда приложения знают об этой самой виртуализацией и могут автоматически подстривать потребление ресурссов под профиль использования.
На примере с порталом — в рабочее время поднимать больше виртуалок с веб-серверами для облуживания запросов, а в нерабочее время поднимать backend серверы для обхода и построения поискового индекса.
Увы готовых таких решений для private cloud я пока еще не видел.
Это кстати совершенно не зависит от процессоров и сети.
Про скорость диска полностью аналогично, ведь кроме запросов на чтение есть еще и запросы на запись. Чем быстрее диски, тем выше скорость работы СУБД (для нормальных субд), независимо от памяти и процессора.
Поэтому в зависимости от workload имеет смысл вкладывать ровно в то, что принесет максимальный прирост.
Только вот когда scale up не поддерживается, а доступен только scale out, приходится покупать все вместе: если нужно 360гб памяти, то придется купить 12 серваков по 32гб, а они будут иметь по 4 ядра, итого 48, которые в итоге будут бесполезно греть воздух (ибо 48 ядер нагружить на порядок сложнее, чем 360 гб). И каждому еще понадобится по диску прикупить, а то и несколько. Это уже не говоря про сеть, питание и охоаждение.
Еще раз повторю — scale out менее экономичный подход, чем scale up. Это только в облаках scale out — подход по умолчанию, а scale up очень ограничен. Облачные провайдеры используют недорогое commodity железо, поднимая деньги на том что перепродают тебе его. Они не считают совокупные затраты на приложение, а в SO считают.
Команда инженеров не просто маленькая, очень маленькая.
Даунтаймы у них не проблема вообще, плановые даунтаймы у них случаются раз в месяц, три девятки они держат, при этом умудряются использовать edge технологии, вроде CTP версий MS SQL.
Количество фич на SO просто зашкаливает, сравнимо с соцсетями, на порядок больше чем у твиттера.
ЗЫ. С какими же продуктами ты работаешь, что scale up для них недоступен? Приведи цифры по количеству запросов и объемам данных.
Надо не забывать что большую часть страниц SO отдает честно бегая в базу, поэтому именно Data Access они оптимизируют до невозможности. Linq2SQL медленно строит запросы и небыстро мапит на объекты. Dapper использует текстовые запросы и делает очень быстрый мапинг.
Кстати начать с dapper было бы практически нереально. Так как текстовые запросы убили бы продуктивность программистов.
Все нормальные вендоры имею пограммы по апгрейду железа на гарантии, так что scaleup получается даже дешевле чем докупка серваков.
Любые затраты на разработку не явлюятся единоразовыми. Любой код требует поддержки. Особенно инфраструктурный, так как он зависит от внешних систем, которые постоянно развиваются.
Джоины нужны. Вся теория применения NoSQL говорит о том, что надо правильно построить структуру документа (читай заранее придумать все джоины). В SQL такой проблемы нет, так как джоином можно вытащить любое поддерево данных. Вот только такое вытаскивание требует ссылочной целостности, которое в свою очередь требует согласованности изменений. Поэтому NoSQL рулит в очень ограниченных сценариях, а SQL практически во всех. Там где не хватает SQL можно прикрутить кеш, полнотекстовый индекс или свой middleware, обычно этого хватает для очень масштабных проектов.
Шардинг SQL баз мешает джоинам. Вот в SO несколько сущностей: посты, комменты, пользователи. По какому ключу шардить? По пользователям? Тогда как собрать ленту новых постов? По постам? тогда как показать все посты пользователя? Денормализация и middleware скажете, так это усложнение на порядок на ровном месте, а выигрыш какой?
Денормальзация увеличивает количество код примерно в 3 раза. Начинать с этого нельзя в принципе. Для оптимизации надо не о денормализации думать, а о грамотном кешировании.
Я смотрел доклады на HiLoad — там решают проблемы, которых почти не возникает со взрослыми БД и нормальными платформами.
SO делает даунтайм раз в месяц примерно, но обслуживание серверов случается гораздо чаще. Потому что у них failover таки нормальный.
Работа программистов, которые вынуждены этот middleware поддерживать, оказывается дороже, чем лицензиии, и сильно дороже, чем железо.
Читай тут: www.codinghorror.com/blog/2008/12/hardware-is-cheap-programmers-are-expensive.html
Как я уже говорил — шардинг дороже scale up. Поэтому скорее наоборот — шардинг это решение, когда scaleup невозможен. Но шардинг автоматически добавляет проблемы с джоинами, и снова нужно писать (а потом поддерживать) код, который будет имитировать функции MSSQL.
Несмотря на то, что ссылка 4-летней давности, проблемы актуальны и сейчас. Инженерные проблемы в общем случае не решены и некоторые нерешаемы вообще. Они решены в частных случаях конкретных систем. Адаптировать их — тоже работа, которую надо делать и код потом поддерживать.
NoSQL is hard сейчас не менее чем 4 года назад, и люди в stackoverflow это прекрасно знают и не связываются с этим.
ЗЫ. SO это не big data, даже не близко. Тем не менее до масштаба SO доживет один стартап из миллиона.
Кстати хороший failover на *nix+mysql\postgres стоит тоже немало, но работает обычно хуже и\или сложнее в настройке.
Шардинг обычно более дорогой, чем scale up, вот только не все СУБД умеют хорошо делать scale up.
Конкретно в этом случае в SO делаются JOINы. Это позволяет оптимизировать время работы SQL и Web серверов. Там где джоины работают плохо (читай операции с тегами) уже работает отдельный middleware, тяжелые джоины кешируются в redis.
Если хранить это все в key-value, то надо как-то делать эти джоины. Готовые решения по индексации почти всегда не дают acid транзакционности, что усложняет код. Дополнительное железо понадобилось бы обеспечения транзакционности. И много подводных камней.
Читай тут — highscalability.com/blog/2009/8/5/stack-overflow-architecture.html, раздел «NoSQL is Hard».
ЗЫ. Я минусы не ставлю.
Где-то читал что как раз Джоэл хотел сделать проект на RoR, его переубедили использовать .NET. Как раз в тот момент появились ASP.NET MVC и Linq2SQL, которые обладали функционалом не хуже RoR.