Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 72
В даннй момент у нас примерно 2 ТБ данныхи 1ТБ оперативки. Решение очень даже понятное.
Молодцы. Качественный код само собой экономит железо.
Кстати интересно, а какая часть из этого логи? Может так оказаться, что как раз половина. Тогда фактически все живые данные в оперативе.
Да, их архитектура — хороший пример того, как делать не надо, и что получается с архитектурой при узости кругозора и отсутствии актуальных знаний.
На самом деле, особой проблемы в 1Tb оперативной памяти нет — 30 сверхдешёвых 1-юнитовых серверов с 32Gb памяти (или 60 — с 16Gb) не стоят почти ничего. Большая проблема в том, что даже при условии работы с таким количеством оперативной памяти, их приложение никак не масштабируется, что вынуждает их покупать сверхдорогие сервера с сотнями Gb памяти и сильно ограничивать функционал.
Хотя, мне кажется, самое интересное будет в статье про их приложение и написание кода — там при таком подходе должно быть много проблем.
На самом деле, особой проблемы в 1Tb оперативной памяти нет — 30 сверхдешёвых 1-юнитовых серверов с 32Gb памяти (или 60 — с 16Gb) не стоят почти ничего. Большая проблема в том, что даже при условии работы с таким количеством оперативной памяти, их приложение никак не масштабируется, что вынуждает их покупать сверхдорогие сервера с сотнями Gb памяти и сильно ограничивать функционал.
Хотя, мне кажется, самое интересное будет в статье про их приложение и написание кода — там при таком подходе должно быть много проблем.
Да, их архитектура — хороший пример того, как делать не надо, и что получается с архитектурой при узости кругозора и отсутствии актуальных знаний.
Да что вы? Просвятите нас как надо.
Малое количество дорогих серверов выгоднее с точки зрения лицензирования и оверхеда. Кроме того мне кажется что их 10 дороги серверов не сильно дороже 30 дешевых. А с учетом лицензирования дешевле на порядок.
Можно начать с того, что не использовать лицензирование, которое, если верить вашим словам, может стоить значительно дороже железа. Я, конечно, не специалист по решениям от Microsoft, но google услужливо подсказывает, что Windows Server 2012 Foundation (вполне годный на небольшие сервера) стоит меньше $100, а Windows Server 2012 Standard стоит раз в 10-15 дороже; аналогично, MS SQL лицензируется пропорционально количеству ядер.
Если серьёзно, при умении пользоваться, внезапно, Linux оказывается ничем не хуже Windows (кроме проприетарных технологий типа C#), PostgreSQL ничем не хуже MS SQL, да и программировать можно не только для .NET.
Что касается «как надо» — надо так, чтобы решение оптимально решало бизнес-задачи. Если решение требует несравнимо больших капиталовложений, весьма ограниченно и очень дорого масштабируется и делает добавление ресурсоёмких фич аналогично ограниченным и крайне дорогим — это, очевидно, плохое решение.
Конкретно в данном случае, возможности шардинга при грамотной архитектуре особо не ограничены, поскольку вопросы, ответы, комментарии, голоса и авторы могут храниться даже в нормальном key-value хранилище, а решений для их индексации по всем интересующим выборкам более чем достаточно.
PS Спасибо за минус, это лучший способ поддержки дискуссии!
Если серьёзно, при умении пользоваться, внезапно, Linux оказывается ничем не хуже Windows (кроме проприетарных технологий типа C#), PostgreSQL ничем не хуже MS SQL, да и программировать можно не только для .NET.
Что касается «как надо» — надо так, чтобы решение оптимально решало бизнес-задачи. Если решение требует несравнимо больших капиталовложений, весьма ограниченно и очень дорого масштабируется и делает добавление ресурсоёмких фич аналогично ограниченным и крайне дорогим — это, очевидно, плохое решение.
Конкретно в данном случае, возможности шардинга при грамотной архитектуре особо не ограничены, поскольку вопросы, ответы, комментарии, голоса и авторы могут храниться даже в нормальном key-value хранилище, а решений для их индексации по всем интересующим выборкам более чем достаточно.
PS Спасибо за минус, это лучший способ поддержки дискуссии!
Ключевое слово тут — Failover. Это требует Enterprise лицензий как на Windows, так и на SQL Server.
Кстати хороший 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».
ЗЫ. Я минусы не ставлю.
Кстати хороший 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».
ЗЫ. Я минусы не ставлю.
Failover можно без особых проблем реализовать на уровне приложения. Хороший failover для mysql/postgres называется master-slave репликация (для особо важных случаев — синхронная), для особо ленивых — на уровне приложения или middleware. Настраивается просто, работает эффективно.
Шардинг можно делать на уровне приложения или middleware — это избавляет бд от неумения эффективно горизонтально масштабироваться.
Джойны, конечно, штука нужная и удобная, но на практике неэффективная для Big Data. Данные можно денормализовывать под запросы, можно «джойнить», «доставать данные по индексам» итд на уровне приложения или middleware.
Что касается ACID, практически всегда consistency не нужно (достаточно eventual consistency), как и, с оговорками, не нужна атомарность, и в этом случае оно реализуется даже простейшими распределёнными блокировками, без транзакций. Подводные камни, конечно, есть, но они многими решены, и в этом нет ничего супер-сложного и уникального — обычная инженерная работа.
Что касается вашей ссылки, помимо весьма ограниченного подхода, она написана больше 4 лет назад, когда NoSQL решений было заметно меньше, и многие не были достаточно хорошо сделаны для production-использования.
PS Значит, по хабру ходит маньяк — фанат ограниченных проприетарных решений.
Шардинг можно делать на уровне приложения или middleware — это избавляет бд от неумения эффективно горизонтально масштабироваться.
Джойны, конечно, штука нужная и удобная, но на практике неэффективная для Big Data. Данные можно денормализовывать под запросы, можно «джойнить», «доставать данные по индексам» итд на уровне приложения или middleware.
Что касается ACID, практически всегда consistency не нужно (достаточно eventual consistency), как и, с оговорками, не нужна атомарность, и в этом случае оно реализуется даже простейшими распределёнными блокировками, без транзакций. Подводные камни, конечно, есть, но они многими решены, и в этом нет ничего супер-сложного и уникального — обычная инженерная работа.
Что касается вашей ссылки, помимо весьма ограниченного подхода, она написана больше 4 лет назад, когда NoSQL решений было заметно меньше, и многие не были достаточно хорошо сделаны для production-использования.
PS Значит, по хабру ходит маньяк — фанат ограниченных проприетарных решений.
Судя по тестам синхронная репликация на 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 доживет один стартап из миллиона.
Работа программистов, которые вынуждены этот 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 доживет один стартап из миллиона.
Судя по выводам, вы не разбираетесь в технологии, тесты которой смотрите. Pgpool-II — надёжное и эффективное решение для синхронной репликации.
Железо, конечно, дешевле программистов, но вы упускаете тот факт, что SO сами пишут, что для того чтобы их приложение нормально работало даже на их серверах-монстрах, им приходится серьёзно оптимизировать производительность, в том числе поскольку стоимость сервера при scale up растёт совсем не линейно, и старые сервера надо куда-то девать. При работе с шардингом такой проблемы нет; более того, в ряде случаев можно выкладывать совсем неэффективный код и оптимизировать позже по факту наличия потребностей и ресурсов на это.
Что касается стоимости поддержки шардинга — вы правы, она есть. Но это единоразовые затраты на разработку обёртки для этого или внедрения существующего решения, издержки на что значительно снижаются, если в команде было понимание и опыт работы с такими решениями.
Что касается джойнов, на мой взгляд, вы за них слишком сильно цепляетесь. Слишком редко действительно нужны сложные запросы (поскольку без них код получается слишком раздутым, или нужен неадекватно большой трансфер промежуточных данных) — большей частью для сложной аналитики, а для этого есть специализированные решения, в которые можно, например, экспортировать данные. Слишком редко действительно нужна нормализация, и обеспечение в коде денормализации, несмотря на мифы, весьма простое.
Если же действительно нужны транзакции, очень хочется джойнов, или просто хочется работать с привычными инструментами, всегда можно шардить MySQL или PostgreSQL, и там уже иметь всё что нужно. Это не сложно, это не создаёт значительных сложностей в поддержке, для этого есть готовые решения, и оно эффективно. Конечно, решение не полностью заменяет единую базу, но на действительно больших объёмах данных выборки не по основному ключу можно делать снаружи (например, в единой базе данных, для выборок по тегам/разделам/рейтингу), и это тоже несложно.
Про нерешённость проблем, посмотрите доклады на VLDB, некоторые доклады на Highload++ и прочие специализированные мероприятия — люди успешно решают «нерешённые проблемы», и рассказывают об этом тем, кто готов слушать.
Например, если верить вашим словам, у SO есть «нерешённая проблема» — приходится часто делать длительный даунтайм сервиса для обслуживания.
PS У стартапов другие проблемы — при такой архитектуре они при скачкообразном росте нагрузки внезапно упираются в сервер, и вынуждены вкладывать значительные деньги в покупку нового, потому как сервера-монстры с большим количеством процессоров и памяти мало у кого можно арендовать, а стоимость облаков минимум в разы выше.
Железо, конечно, дешевле программистов, но вы упускаете тот факт, что SO сами пишут, что для того чтобы их приложение нормально работало даже на их серверах-монстрах, им приходится серьёзно оптимизировать производительность, в том числе поскольку стоимость сервера при scale up растёт совсем не линейно, и старые сервера надо куда-то девать. При работе с шардингом такой проблемы нет; более того, в ряде случаев можно выкладывать совсем неэффективный код и оптимизировать позже по факту наличия потребностей и ресурсов на это.
Что касается стоимости поддержки шардинга — вы правы, она есть. Но это единоразовые затраты на разработку обёртки для этого или внедрения существующего решения, издержки на что значительно снижаются, если в команде было понимание и опыт работы с такими решениями.
Что касается джойнов, на мой взгляд, вы за них слишком сильно цепляетесь. Слишком редко действительно нужны сложные запросы (поскольку без них код получается слишком раздутым, или нужен неадекватно большой трансфер промежуточных данных) — большей частью для сложной аналитики, а для этого есть специализированные решения, в которые можно, например, экспортировать данные. Слишком редко действительно нужна нормализация, и обеспечение в коде денормализации, несмотря на мифы, весьма простое.
Если же действительно нужны транзакции, очень хочется джойнов, или просто хочется работать с привычными инструментами, всегда можно шардить MySQL или PostgreSQL, и там уже иметь всё что нужно. Это не сложно, это не создаёт значительных сложностей в поддержке, для этого есть готовые решения, и оно эффективно. Конечно, решение не полностью заменяет единую базу, но на действительно больших объёмах данных выборки не по основному ключу можно делать снаружи (например, в единой базе данных, для выборок по тегам/разделам/рейтингу), и это тоже несложно.
Про нерешённость проблем, посмотрите доклады на VLDB, некоторые доклады на Highload++ и прочие специализированные мероприятия — люди успешно решают «нерешённые проблемы», и рассказывают об этом тем, кто готов слушать.
Например, если верить вашим словам, у SO есть «нерешённая проблема» — приходится часто делать длительный даунтайм сервиса для обслуживания.
PS У стартапов другие проблемы — при такой архитектуре они при скачкообразном росте нагрузки внезапно упираются в сервер, и вынуждены вкладывать значительные деньги в покупку нового, потому как сервера-монстры с большим количеством процессоров и памяти мало у кого можно арендовать, а стоимость облаков минимум в разы выше.
Синхронная репликация — не failover. Это часть решения, но не все. Полное failover решение изкаропки имеет MS SQL и Oracle. Остальные СУБД требуют дополнительных компонент и\или поддержку на уровне приложения.
Все нормальные вендоры имею пограммы по апгрейду железа на гарантии, так что scaleup получается даже дешевле чем докупка серваков.
Любые затраты на разработку не явлюятся единоразовыми. Любой код требует поддержки. Особенно инфраструктурный, так как он зависит от внешних систем, которые постоянно развиваются.
Джоины нужны. Вся теория применения NoSQL говорит о том, что надо правильно построить структуру документа (читай заранее придумать все джоины). В SQL такой проблемы нет, так как джоином можно вытащить любое поддерево данных. Вот только такое вытаскивание требует ссылочной целостности, которое в свою очередь требует согласованности изменений. Поэтому NoSQL рулит в очень ограниченных сценариях, а SQL практически во всех. Там где не хватает SQL можно прикрутить кеш, полнотекстовый индекс или свой middleware, обычно этого хватает для очень масштабных проектов.
Шардинг SQL баз мешает джоинам. Вот в SO несколько сущностей: посты, комменты, пользователи. По какому ключу шардить? По пользователям? Тогда как собрать ленту новых постов? По постам? тогда как показать все посты пользователя? Денормализация и middleware скажете, так это усложнение на порядок на ровном месте, а выигрыш какой?
Денормальзация увеличивает количество код примерно в 3 раза. Начинать с этого нельзя в принципе. Для оптимизации надо не о денормализации думать, а о грамотном кешировании.
Я смотрел доклады на HiLoad — там решают проблемы, которых почти не возникает со взрослыми БД и нормальными платформами.
SO делает даунтайм раз в месяц примерно, но обслуживание серверов случается гораздо чаще. Потому что у них failover таки нормальный.
Все нормальные вендоры имею пограммы по апгрейду железа на гарантии, так что scaleup получается даже дешевле чем докупка серваков.
Любые затраты на разработку не явлюятся единоразовыми. Любой код требует поддержки. Особенно инфраструктурный, так как он зависит от внешних систем, которые постоянно развиваются.
Джоины нужны. Вся теория применения NoSQL говорит о том, что надо правильно построить структуру документа (читай заранее придумать все джоины). В SQL такой проблемы нет, так как джоином можно вытащить любое поддерево данных. Вот только такое вытаскивание требует ссылочной целостности, которое в свою очередь требует согласованности изменений. Поэтому NoSQL рулит в очень ограниченных сценариях, а SQL практически во всех. Там где не хватает SQL можно прикрутить кеш, полнотекстовый индекс или свой middleware, обычно этого хватает для очень масштабных проектов.
Шардинг SQL баз мешает джоинам. Вот в SO несколько сущностей: посты, комменты, пользователи. По какому ключу шардить? По пользователям? Тогда как собрать ленту новых постов? По постам? тогда как показать все посты пользователя? Денормализация и middleware скажете, так это усложнение на порядок на ровном месте, а выигрыш какой?
Денормальзация увеличивает количество код примерно в 3 раза. Начинать с этого нельзя в принципе. Для оптимизации надо не о денормализации думать, а о грамотном кешировании.
Я смотрел доклады на HiLoad — там решают проблемы, которых почти не возникает со взрослыми БД и нормальными платформами.
SO делает даунтайм раз в месяц примерно, но обслуживание серверов случается гораздо чаще. Потому что у них failover таки нормальный.
> Кстати хороший failover на *nix+mysql\postgres стоит тоже немало, но работает обычно хуже и\или сложнее в настройке.
> Полное failover решение изкаропки имеет MS SQL и Oracle. Остальные СУБД требуют дополнительных компонент и\или поддержку на уровне приложения.
Есть mysql xtradb cluster с поддержкой percona.com (если вдруг мануал не осилится -оплачивается только рабочее время, заранее пакет покупать не надо).
Так что про то что чего-то там нет в linux — это неправда.
> Полное failover решение изкаропки имеет MS SQL и Oracle. Остальные СУБД требуют дополнительных компонент и\или поддержку на уровне приложения.
Есть mysql xtradb cluster с поддержкой percona.com (если вдруг мануал не осилится -оплачивается только рабочее время, заранее пакет покупать не надо).
Так что про то что чего-то там нет в linux — это неправда.
facepalm
Извините, но у меня возникает такое ощущение что вы из области теоретических архитекторов.
Все что вы говорите — то да, все правильно. НО стоит это обычно дороже и архитектуры scale up. А про надежность и говорить нечего. В том смысле что если руки правильные то все работает как положено и падений 0.0001%, но для этого нужно прямые руки, большая/светлая голова и куча знаний которые ни за каких докладов не получишь, только собственный опыт. К тому же какая разница сколько будет стоить сервер с кучей GB памяти если он все равно отобьется. Как вы предлагаете кучу дешевых серверов — то как бы не дороже вышло. Маршрутизаторы на FC не копейки стоят. Плюс куча серверов — это куча места в DC за которое платить тоже надо. А по лицензиям вообще бред. Откуда вы знаете сколько они там платят, может Cпольски у МС скидку попросил как бывший сотрудник :)
Извините, но у меня возникает такое ощущение что вы из области теоретических архитекторов.
Все что вы говорите — то да, все правильно. НО стоит это обычно дороже и архитектуры scale up. А про надежность и говорить нечего. В том смысле что если руки правильные то все работает как положено и падений 0.0001%, но для этого нужно прямые руки, большая/светлая голова и куча знаний которые ни за каких докладов не получишь, только собственный опыт. К тому же какая разница сколько будет стоить сервер с кучей GB памяти если он все равно отобьется. Как вы предлагаете кучу дешевых серверов — то как бы не дороже вышло. Маршрутизаторы на FC не копейки стоят. Плюс куча серверов — это куча места в DC за которое платить тоже надо. А по лицензиям вообще бред. Откуда вы знаете сколько они там платят, может Cпольски у МС скидку попросил как бывший сотрудник :)
Только обычно master-slave делается не для failover, а для скорости. А для failover-а master-master в разных вариациях. Вообще странные вы вещи говорите и про ACID и про атомарность.
На Windows уже не требуется Enterprise лицензия, с WIndows Server 2012 ее вообще нет, остались только Standard и Datacenter, которые равны по функциям и отличаются только количеством виртуалок, на которые распространяется лицензия.
Стэковые сайты работают на удивление хорошо, зачем придумывать проблемы там, где их нет. Если им подходит и устраивает такая архитектура, то может банально они умеют её готовить? Это же не проект майкрософта, они посчитали во сколько им всё это обходится и их это устраивает. Экономия может оказаться на спичках, если вообще выйдет. Вы ведь никаких цифр не привели чтобы сравнить, просто написали названия продуктов и предположили, что они будут работать не хуже и ещё и бесплатно. Цифры есть? Такой же по нагрузке проект как стековый, сколько всё стоит, сколько поддержка, как оно резервируется и т.д.
>зачем придумывать проблемы там, где их нет
Например, потому что вы можете не видеть этих проблем, или они могут считать их неразрешимыми. Даунтаймы для обслуживания, высокие требования к эффективности работы кода и sql-запросов, трудность в добавлении ресурсоёмких фич — это всё те вещи, которых вы не увидите (кроме даунтайма). У них действительно большая команда для сервиса с объективно не очень большим количеством фич, и не быстро изменяющимся — это тоже может быть проблемой.
Цифры можно приводить только под конкретные требования и ресурсы. Те продукты, с которыми я работаю, заведомо не помещаются в scale up архитектуру, кратко моё мнение относительно сложности работы со scale out архитектурой в комментариях выше.
Например, потому что вы можете не видеть этих проблем, или они могут считать их неразрешимыми. Даунтаймы для обслуживания, высокие требования к эффективности работы кода и sql-запросов, трудность в добавлении ресурсоёмких фич — это всё те вещи, которых вы не увидите (кроме даунтайма). У них действительно большая команда для сервиса с объективно не очень большим количеством фич, и не быстро изменяющимся — это тоже может быть проблемой.
Цифры можно приводить только под конкретные требования и ресурсы. Те продукты, с которыми я работаю, заведомо не помещаются в scale up архитектуру, кратко моё мнение относительно сложности работы со scale out архитектурой в комментариях выше.
Посмотри оригинальный пост и комменты.
Команда инженеров не просто маленькая, очень маленькая.
Даунтаймы у них не проблема вообще, плановые даунтаймы у них случаются раз в месяц, три девятки они держат, при этом умудряются использовать edge технологии, вроде CTP версий MS SQL.
Количество фич на SO просто зашкаливает, сравнимо с соцсетями, на порядок больше чем у твиттера.
ЗЫ. С какими же продуктами ты работаешь, что scale up для них недоступен? Приведи цифры по количеству запросов и объемам данных.
Команда инженеров не просто маленькая, очень маленькая.
Даунтаймы у них не проблема вообще, плановые даунтаймы у них случаются раз в месяц, три девятки они держат, при этом умудряются использовать edge технологии, вроде CTP версий MS SQL.
Количество фич на SO просто зашкаливает, сравнимо с соцсетями, на порядок больше чем у твиттера.
ЗЫ. С какими же продуктами ты работаешь, что scale up для них недоступен? Приведи цифры по количеству запросов и объемам данных.
PostgreSQL ничем не хуже MS SQL, да и программировать можно не только для .NET.
Есть же Mono и у него сейчас уже очень неплохая производительность.
> кроме проприетарных технологий типа C#
en.wikipedia.org/wiki/Mono_(software) — читаем, прежде чем городить чушь.
en.wikipedia.org/wiki/Mono_(software) — читаем, прежде чем городить чушь.
Считать что серверы с 350Gb памяти это дорого — заблуждение. Такое количество памяти сейчас поддерживается любым коммодити сервером. Пример: www.supermicro.com/products/system/2u/2027/ssg-2027r-e1r24n.cfm
Спасибо за замечание, вы абсолютно правы. Проблема в том, что для того, чтобы сервер смог эффективно пользоваться таким количеством памяти, ему может понадобится 8 процессоров по 4-6 ядер, серверу потребуется высокопроизводительный raid с multipath io, 10Gbps сетка и прочие страшные вещи.
Для любой РСУБД чем больше памяти, тем лучше. Все операции чтения с диска кэшируются в памяти и повторные чтения страниц не производятся. Фактически для максимально быстрой работы объем ОП должен быть не меньше объема активных данных (к которым происходят регулярные обращения).
Это кстати совершенно не зависит от процессоров и сети.
Про скорость диска полностью аналогично, ведь кроме запросов на чтение есть еще и запросы на запись. Чем быстрее диски, тем выше скорость работы СУБД (для нормальных субд), независимо от памяти и процессора.
Поэтому в зависимости от workload имеет смысл вкладывать ровно в то, что принесет максимальный прирост.
Только вот когда scale up не поддерживается, а доступен только scale out, приходится покупать все вместе: если нужно 360гб памяти, то придется купить 12 серваков по 32гб, а они будут иметь по 4 ядра, итого 48, которые в итоге будут бесполезно греть воздух (ибо 48 ядер нагружить на порядок сложнее, чем 360 гб). И каждому еще понадобится по диску прикупить, а то и несколько. Это уже не говоря про сеть, питание и охоаждение.
Еще раз повторю — scale out менее экономичный подход, чем scale up. Это только в облаках scale out — подход по умолчанию, а scale up очень ограничен. Облачные провайдеры используют недорогое commodity железо, поднимая деньги на том что перепродают тебе его. Они не считают совокупные затраты на приложение, а в SO считают.
Это кстати совершенно не зависит от процессоров и сети.
Про скорость диска полностью аналогично, ведь кроме запросов на чтение есть еще и запросы на запись. Чем быстрее диски, тем выше скорость работы СУБД (для нормальных субд), независимо от памяти и процессора.
Поэтому в зависимости от workload имеет смысл вкладывать ровно в то, что принесет максимальный прирост.
Только вот когда scale up не поддерживается, а доступен только scale out, приходится покупать все вместе: если нужно 360гб памяти, то придется купить 12 серваков по 32гб, а они будут иметь по 4 ядра, итого 48, которые в итоге будут бесполезно греть воздух (ибо 48 ядер нагружить на порядок сложнее, чем 360 гб). И каждому еще понадобится по диску прикупить, а то и несколько. Это уже не говоря про сеть, питание и охоаждение.
Еще раз повторю — scale out менее экономичный подход, чем scale up. Это только в облаках scale out — подход по умолчанию, а scale up очень ограничен. Облачные провайдеры используют недорогое commodity железо, поднимая деньги на том что перепродают тебе его. Они не считают совокупные затраты на приложение, а в SO считают.
Для того, чтобы сервер эффективно смог поддерживать такое количество памяти, необходимо в него установить эту память и 2 CPU (любых серверных, стоимостью от 8000 рублей каждый), чтобы вся память была видна. Все остальное (raid, 10G и прочее) к делу не имеет никакого отношения, это зависит от конкретных задач.
>ему может понадобится 8 процессоров по 4-6 ядер
Я говорю о commodity серверах с LGA 2011 сокетом под серверные Intel Xeon'ы (которые чуть менее чем полностью владеют commodity рынком) и которых можно установить лишь 2 (два) на материнскую плату, вон выше даже модель конкретную привел. 2 процессора на плату для них — это технологическое ограничение. О каких магических 8 процессорах по 4-6 ядер говорите вы мне представить сложно.
Еще раз повторюсь: сотни гигабайт памяти сейчас — это будничная реальность commodity железа.
>ему может понадобится 8 процессоров по 4-6 ядер
Я говорю о commodity серверах с LGA 2011 сокетом под серверные Intel Xeon'ы (которые чуть менее чем полностью владеют commodity рынком) и которых можно установить лишь 2 (два) на материнскую плату, вон выше даже модель конкретную привел. 2 процессора на плату для них — это технологическое ограничение. О каких магических 8 процессорах по 4-6 ядер говорите вы мне представить сложно.
Еще раз повторюсь: сотни гигабайт памяти сейчас — это будничная реальность commodity железа.
Как можно обвинять создателей stackoverflow в узости кругозора и отсутствии знаний? Спольски и Этвуд. Не считая остальных очень умных ребят из их команды. Они построили знаковый сайт входящий в топ60 самых посещаемых, никогда не имели особых проблем с надежностью(по-моему стэк лежит реже чем разные облака), без проблем росли и масштабировались. Работает это все без огромных железных затрат, а могут всё это запустить вообще с пары-тройки серверов и при этом всё работает очень быстро. Какие вообще претензии?
Интересно, как часто (и сколько в час / день / неделю) выходят из строя SSD.
Такой информации от них нет, но по своему опыту скажу, что SSD — не страшно. На своих проектах сейчас используется 34 SSD диска — за пол года не было проблем. Грузятся они не столько на скорость записи/чтения, сколько на IOPS. При этом, диски — бюджетные интеловские (320-е в основном).
Ресурс MLC SSD по порядку величины это сотни терабайт записанной даты, а от чтений они не портятся. Так что если не хранить на SSD волатильные данные (логи/своп) — они будут жить почти вечно.
Очень интересно. Спасибо за наводку!
36,095,312 из них — настоящие загрузки страниц
Но 23 млн 12 ноября на www.quantcast.com/p-c1rF4kxgLUzNc
Это нормально. quantcast, как и многие другие JS счётчики, дают только примерную оценку, которая обычно немного занижена за счёт того, что не все обрабатывают JS. Например, большинство спайдеров и скрейперов не учитываются этими счётчиками, а сервер такой запрос обрабатывает.
Поэтому и получается, что логи сервера будут показывать больше.
Поэтому и получается, что логи сервера будут показывать больше.
12-го ноября страница загружалась в среднем 28 миллисекунд. Мы стараемся поддерживать скорость загрузки не дольше 50 миллисекунд.
Все таки здесь речь, видимо, о рендере страницы на сервере, а не времени загрузки у пользователя — 50 миллисекунд в абсолютном большинстве случаев не хватит даже для того, чтобы соединиться с сервером и загрузить голый html, а там еще, примерно, 3 десятка запросов.
разноцветные кабели питания, какая прелесть!
Отличный проект и отлично заменяет метод научного тыка.
А когда StackOverflow падает, как они узнают, как его поднять? (с)
Если БД цела, делают select-ы в консоли. Если нет — надежда только на кэш Гугла.
Я бы копирайт все же поставил сюда: twitter.com/GonzoHacker/status/395559651980234752
Идут на ответы.мэйл.ру :))))))
148,084,883 HTTP запросов до нашего балансировщика нагрузки
Вы хотели сказать «к нашему баланировщику»?
Хмм, а что у них такого случилось с августа по октябрь? На последнем графике там рост в разы.
Было бы намного интереснее и полезнее посмотреть на схему архитектуры.
Что-нибудь вроде такого blog.serverfault.com/2011/09/30/the-stack-exchange-architecture-2011-edition-episode-1/ или такого blog.stackoverflow.com/2010/01/stack-overflow-network-configuration/
Есть такая информация?
Что-нибудь вроде такого blog.serverfault.com/2011/09/30/the-stack-exchange-architecture-2011-edition-episode-1/ или такого blog.stackoverflow.com/2010/01/stack-overflow-network-configuration/
Есть такая информация?
4 MS SQL сервера
11 IIS Веб-серверов
Интересно, почему выбор пал на Windows решение?
У них основатель в Микрософте работал, насколько помню. Мне больше интересно зачем им ASA и как физически идет пакет из внешней сетки до веб-сервера.
Идейный лидер — Joel Spolsky, действительно работал в MS, будучи Program Manager в команде Excel. С тех пор люто ненавидел MS, managed платформы и взрослые РСУБД.
Где-то читал что как раз Джоэл хотел сделать проект на RoR, его переубедили использовать .NET. Как раз в тот момент появились ASP.NET MVC и Linq2SQL, которые обладали функционалом не хуже RoR.
Где-то читал что как раз Джоэл хотел сделать проект на RoR, его переубедили использовать .NET. Как раз в тот момент появились ASP.NET MVC и Linq2SQL, которые обладали функционалом не хуже RoR.
Есть версия что из-за Linq2SQL. Это позволило быстро и качественно сделать Data Access и стартануть буквально на одном серваке.
Возможно сначала так и было. Но где-то видел что Data Access Layer у них сейчас полностью самописный.
Примерно 2 года назад они перешли на code.google.com/p/dapper-dot-net/, до этого были на Linq2SQL с самого начала (более трех лет).
Надо не забывать что большую часть страниц SO отдает честно бегая в базу, поэтому именно Data Access они оптимизируют до невозможности. Linq2SQL медленно строит запросы и небыстро мапит на объекты. Dapper использует текстовые запросы и делает очень быстрый мапинг.
Кстати начать с dapper было бы практически нереально. Так как текстовые запросы убили бы продуктивность программистов.
Надо не забывать что большую часть страниц SO отдает честно бегая в базу, поэтому именно Data Access они оптимизируют до невозможности. Linq2SQL медленно строит запросы и небыстро мапит на объекты. Dapper использует текстовые запросы и делает очень быстрый мапинг.
Кстати начать с dapper было бы практически нереально. Так как текстовые запросы убили бы продуктивность программистов.
Как же, наверное, линуксоидам не по себе от этой информации.
А, собственно, почему бы и нет? Особенно если отбросить политику.
Собсно ASP.NET MVC + Linq2DB очень неплохи для стартапа. Ну и как показывает нам статья — вполне себе и для более чем «взрослого» приложения.
Собсно ASP.NET MVC + Linq2DB очень неплохи для стартапа. Ну и как показывает нам статья — вполне себе и для более чем «взрослого» приложения.
А что за система мониторинга?
Чем строите графики?
Чем строите графики?
Растолкуйте пожалуйста — как правильно понять первые две цифры:
Правильно ли я понимаю что в IIS лог за день попало 36 млн. записей?
Но что тогда означает первая цифра и почему она настолько больше?
148,084,883 HTTP запросов к нашему балансировщику нагрузки
36,095,312 из них — настоящие загрузки страниц
Правильно ли я понимаю что в IIS лог за день попало 36 млн. записей?
Но что тогда означает первая цифра и почему она настолько больше?
>В даннй момент у нас примерно 2 ТБ данных в SQL (1.06/1.16 ТБ на первом кластере из 18 SSD и 0.889/1.45 ТБ на втором, состоящем из 4 SSD). Возможно, стоило бы задуматься об облаках, но сейчас мы используем SSD и время записи в базу равно буквально 0 миллисекундам
Возможно уже давно пора было задуматься о переносе базы с локальных винтов на внешнюю SAN хранилку, не?
Возможно уже давно пора было задуматься о переносе базы с локальных винтов на внешнюю SAN хранилку, не?
Почему на обработку тегов требуются такие большие ресурсы?
Очень интересная статья на стеке MS + чучуть *nix.
Какие именно версии .NET Framework, Windows, MS SQL вы используете?
Почему не SphinxSearch и не MongoDB?
Планируете ли переходить на Mono в будущем?
Посмотреть бы на программную архитектуру с мапом на железо…
Какие именно версии .NET Framework, Windows, MS SQL вы используете?
Почему не SphinxSearch и не MongoDB?
Планируете ли переходить на Mono в будущем?
Посмотреть бы на программную архитектуру с мапом на железо…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как работает Stack Overflow — железо