Здравствуйте, gandjustas, Вы писали:
G>У них есть список железа, пост на MetaOwerflow, глнянь. Относительно не дорого кстати. Как обычно самое дорогое — диски.
У scale up есть одна проблема: предположим что у вас есть сервер за $100k который вас полностью устраивал до тех пор пока нагрузка не выросла. Но теперь он перестал справляться и вам нужен сервер за $150k. В результате вместо того чтобы доплатить всего $50k, вы вынуждены покупать новый сервер за $150k и в довесок вы получаете освободившийся сервер за $100k который вам не нужен.
G>Больше чем стоило бы.
Тебе-то с этого какая боль?
G>Я думаю что им MS стек обходится сильно дешевле.
Я тоже так думаю.
G>Он там на малую часть загружен, почитай пост. Это это совокупный объем памяти, в том числе: passive ноды SQL Server, redis, reverse proxy и IIS с output cache.
Т.е. ты считаешь что они поставили 1Тб памяти чтобы его не использовать, так что ли. Возможно у них и нет кэшей уровня приложения, но Redis и SQL Server наверняка настроены использовать всю память какая только есть под кэши.
G>Кстати многие проблемы когда "упирались в железо" решались оптимизацией кода.
Тогда это называется не "упирались в железо", а "упирались в код".
Здравствуйте, mtnl, Вы писали:
M>этот java код , опять же, очень оптимизируется (у твиттера есть несколько видео про то, как они оптимизировали использование garbage collector)
Вся юзер-френдли оптимизация сводится к выбору, хотите вы чтобы приложение вставали колом каждые полчаса на 10 секунд или притормаживало каждые 10 минут на 100мс. Все остальное уже требует хардкора в стиле: память выделяем заранее, объекты переиспользуем, широко применяем массивы примитивов.
Здравствуйте, gandjustas, Вы писали:
G>Кстати у них МНОГО памяти. Суммарно около 1ТБ RAM. Видимо это позволяет держать в памяти все активные данные и генерировать страницы за 50мс. G>Все это как-то расходится с современными трендами о bigdata и nosql, предлагающими десятки серверов, и всякие map-reduce уже для пары сотен ГБ.
Всё держать в памяти это не расходится с трендами, это оно и есть.
Только сзади не MySql, а MS SQL, но просто не у всех есть деньги на Oracle.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, mtnl, Вы писали:
M>>этот java код , опять же, очень оптимизируется (у твиттера есть несколько видео про то, как они оптимизировали использование garbage collector)
M>Вся юзер-френдли оптимизация сводится к выбору, хотите вы чтобы приложение вставали колом каждые полчаса на 10 секунд или притормаживало каждые 10 минут на 100мс. Все остальное уже требует хардкора в стиле: память выделяем заранее, объекты переиспользуем, широко применяем массивы примитивов.
таки не совсем понял, с чем вы спорите, я вроде прямо пишу про то, что именно код целенаправленно для таких условий пишется
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Они делают scale up, а не scale out и добились офигенных характеристик по нагрузке. S>Угу.
S>Что примечательно (если я ничего не упустил) — со scale out там тоже принципиальных проблем нет.
Принципиальные как раз есть, ибо они джоины делают, а разделить на отдельные шарды при их структуре будет непросто.
Но они scale-out делают за счет кешей и отдельного движка тегов.
S>И по производительности запас вообще неприличный: в комментах Nick Craver ответил, что они пока не используют bufferpool extensions или in-memory oltp (aka hekaton).
Да, при желании они выжмут еще больше из текущего железа.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>У них есть список железа, пост на MetaOwerflow, глнянь. Относительно не дорого кстати. Как обычно самое дорогое — диски.
M>У scale up есть одна проблема: предположим что у вас есть сервер за $100k который вас полностью устраивал до тех пор пока нагрузка не выросла. Но теперь он перестал справляться и вам нужен сервер за $150k. В результате вместо того чтобы доплатить всего $50k, вы вынуждены покупать новый сервер за $150k и в довесок вы получаете освободившийся сервер за $100k который вам не нужен.
И это неверно. Нормальные вендоры выкупят у вас старый сервер за $70к (или сколько там будет с учетом амотризации) и новый продадут за разницу.
Кроме того сервер это не целая коробка. Диски и память обычно переезжают из одного сервака в другой, а они формируют более половины цены.
G>>Больше чем стоило бы. M>Тебе-то с этого какая боль?
Приходится иногда исправлять.
G>>Он там на малую часть загружен, почитай пост. Это это совокупный объем памяти, в том числе: passive ноды SQL Server, redis, reverse proxy и IIS с output cache. M>Т.е. ты считаешь что они поставили 1Тб памяти чтобы его не использовать, так что ли. Возможно у них и нет кэшей уровня приложения, но Redis и SQL Server наверняка настроены использовать всю память какая только есть под кэши.
Они поставили 1 ТБ, чтобы быть уверенными, что память не кончится.
G>>Кстати многие проблемы когда "упирались в железо" решались оптимизацией кода. M>Тогда это называется не "упирались в железо", а "упирались в код".
Это две стороны одной медали.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Don Reba, Вы писали:
G>>>У них read-mostly workload. Они могут оч долго не упираться в железо. А потом добавить еще один MS SQL. DR>>
Stack Overflow actually has a 40:60 read-write ratio. Yeah, you read that right, 60% of our database disk access is writes
ANS>Это то, что доходит до БД, потому как спереди выстроен огород из кешей, который и обслуживает запросы на чтение. Типичный NoSql.
Я выше писал что NoSQL — маркетинговый термин. Давайте понимать под ним всетаки конкретные продукты и подходы построения архитектуры вокруг них. Кроме того имеет смысл рассматривать только те месте, где есть read\write.
Кеши NoSQL не являются никак.
Иначе получится что любоая работа с данным в памяти — NoSQL. Так сами РСУБД пытаются кешировать все, они же от этого не станут NoSQL.
Здравствуйте, gandjustas, Вы писали: G>Принципиальные как раз есть, ибо они джоины делают, а разделить на отдельные шарды при их структуре будет непросто.
Я их схему смотрел очень поверхностно, но по-моему там ничего не мешает разделению на партишны по постам + ro-репликации остальных частей.
Но по сути они и так делают то же самое, только через кэширование. Так что да, выигрыша наверно не будет.
Здравствуйте, gandjustas, Вы писали:
G>>>>У них read-mostly workload. Они могут оч долго не упираться в железо. А потом добавить еще один MS SQL. DR>>>
Stack Overflow actually has a 40:60 read-write ratio. Yeah, you read that right, 60% of our database disk access is writes
ANS>>Это то, что доходит до БД, потому как спереди выстроен огород из кешей, который и обслуживает запросы на чтение. Типичный NoSql. G>Я выше писал что NoSQL — маркетинговый термин. Давайте понимать под ним всетаки конкретные продукты и подходы построения архитектуры вокруг них. Кроме того имеет смысл рассматривать только те месте, где есть read\write. G>Кеши NoSQL не являются никак.
Для Redis общепринятым термином является NoSql. Если убрать Redis, то цифры из 50:60 превратятся во что-то другое и не факт что, от такой нагрузки система не ляжет. Причина понятна — RDBMS плохо масштабируется А если убрать их специализированный сервис тегов, то тут ваще капец. Что видим в результате — MS SQL используется, как библиотека для более/менее надёжного хранения документиков (как в android — sqlite), а вся реальная работа выполняется Redis-ом, ElasticSearch и спецсервисом тегов.
G>Иначе получится что любоая работа с данным в памяти — NoSQL. Так сами РСУБД пытаются кешировать все, они же от этого не станут NoSQL.
Не станут. А если в приложении используется Redis?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>>>>У них read-mostly workload. Они могут оч долго не упираться в железо. А потом добавить еще один MS SQL. DR>>>>
Stack Overflow actually has a 40:60 read-write ratio. Yeah, you read that right, 60% of our database disk access is writes
ANS>>>Это то, что доходит до БД, потому как спереди выстроен огород из кешей, который и обслуживает запросы на чтение. Типичный NoSql. G>>Я выше писал что NoSQL — маркетинговый термин. Давайте понимать под ним всетаки конкретные продукты и подходы построения архитектуры вокруг них. Кроме того имеет смысл рассматривать только те месте, где есть read\write. G>>Кеши NoSQL не являются никак.
ANS>Для Redis общепринятым термином является NoSql.
Еще раз: там где нет хранимых данных это тупо кеш. Хоть redis, хоть memcached.
ANS>Если убрать Redis, то цифры из 50:60 превратятся во что-то другое и не факт что, от такой нагрузки система не ляжет.
Если убрать redis, но надо прикрутиь кеширование в другом месте. Кеш нужен не потому что кто-то там плохо масштабируется, а чтобы не выполнять работу, которую можно не выполнять.
ANS>Причина понятна — RDBMS плохо масштабируется
Ага, у чуваков 2тб данных, а ты говоришь плохо масштабируется. Любой NoSQL уже бы согнулся.
ANS>А если убрать их специализированный сервис тегов, то тут ваще капец.
Сервис тегов делает консистентные операции с тегами. Full text ssearch в SQL не смог обеспечить достаточный уровень консистентности.
Вообще почитай что пишут разработчики SO, их блоги можно найти в интернетах. Там как раз есть посты о том как и почему они пришли к отдельному сервису обработки тегов.
ANS>Что видим в результате — MS SQL используется, как библиотека для более/менее надёжного хранения документиков (как в android — sqlite), а вся реальная работа выполняется Redis-ом, ElasticSearch и спецсервисом тегов.
А ты пост читал по первой ссылке?
558,224,585 мс (155 часов) было затрачено на обработку SQL запросов
99,346,916 мс (27 часов) потребовалось на ожидание ответа от серверов Redis
132,384,059 мс (36 часов) прошло на обработку запросов по тэгам
То есть Redis, который отдает данные из ОП по ключу работает в среднем в 5 раз меньше SQL, который занимается записью\чтением с диска.
Здравствуйте, Miroff, Вы писали:
M>Адекватная инфраструктурная команда тоже стоит довольно дорого. Даже если вы предпочитаете разворачивать инфраструктуры внутри компании, непонятно как в рамках компании утилизовать неиспользуемые ресурсы, если в понедельник утром у вас 100к запросов в секунду, а ночью на уик-енд всего 5к. Держать запас топовых серверов чтобы справляться с пиками? Перепродавать неиспользуемые ресурсы вашего облака?
Ну про 5К QPS и 100K QPS вы это загнули. Это очень похоже на digg эффект, к-ый тривиально утраняется CDN-ом или reserver-проксями. Скорее бывает 50K-100K, или 5K/10K. А если 5K сегодня, 100K завтра на Амазоне, то
1) У вас нет стабильной аудитории, и у вас все плохо.
2) Если у вас есть стабильная аудитория, послезавтра приходит ваш CFO и начинает вас херачить палкой по голове, пока вы оттуда не уберетесь в нормальный DC. Ибо: ОЧЕНЬ ДОРОГО
Не очень понятно о каких топовых серверах идет речь. 12cores/64GB/4SSDs 1U сервер стоит ~6-7 KUSD. При этом покупка этого железа с ценами clouds _отобьется полностью_ за 4 месяца!!! А сервер-то будет еще и в 1.5 раза большую нагрузку держать, и вы сможете на серверах делать что хотите.
Про запас это тоже маркетинговый булшит, не далее как месяц назад для performance environment-а нам потребовалось 6 HI IO instances в us-east-1. На что Amazon показал всем известный орган, и сказал что это требует лично обсуждения с account manager-ом. Всего после 2 недель базара по телефону, нам милостливо разрешили использовать 6. При этом когда нам понадобилось еще 3, их ТУПО НЕ ОКАЗАЛОСЬ В НАЛИЧИИ. Как вы думаете, за сколько нам выделили эти сервера в дата-центре Dell? (ответ в часах)
G>>А сколько бы они отдали консультантам, если бы делали scale out... M>У них же довольно квалифицированная команда, могли и сами справиться.
У них стабильная команда выходцев из Микрософт. Я думаю вы понимаете, что это означает.
G>>У них read-mostly workload. Они могут оч долго не упираться в железо. А потом добавить еще один MS SQL. M>И мгновенно упереться в сеть между репликами SQL сервера.
А конечно новые NoSQL базы при исполнении той же самой нагрузки в сеть не упрутся.
G>>Одними из основных факторов архитектуры являются: G>>1) доступность людей с нужной квалификацией в технологическом стеке M>Для небольшой компании это не проблема, на рынке всегда найдется несколько человек любой необходимой квалификации, даже если технологический стек основан на лиспе с фортом.
Вы это про какую страну говорите? Про Индию или Белорусию? Что-то в ИТ мире компаний, у которых не было бы проблемы с поиском кадров.
G>>2) технологическая стратегия компании M>Технологическая стратегия обусловленная первой производной от требований (изменением требований).
Нет, она конечно же не обусловлена многомилионными контрактами и партнерскими соглашениями с IBM, Oracle и Microsoft. Она обусловлена требованиями одного проекта.
G>>То, что люди позволяют себе судить о ПГАВИЛЬНОЙ АРХИТЕКТУРКЕ без знания этих факторов, ставит большой вопрос относительно их способностей. M>Требования к SO известны, как они менялись со временем известно, куда SO может начать двигаться дальше тоже не секрет. Для того чтобы судить об архитектуре этого более чем достаточно.
Вы достаточно хорошо проиллюстрировали мой тезис.
Здравствуйте, gandjustas, Вы писали:
G>>И причем тут построение индексов при помощи Map Reduce? G>http://docs.mongodb.org/manual/core/map-reduce/ G>неспроста...
Вы бы все таки почитали что-нибудь системно. А то смотреть больно.
Здравствуйте, gandjustas, Вы писали:
ANS>>Для Redis общепринятым термином является NoSql. G>Еще раз: там где нет хранимых данных это тупо кеш. Хоть redis, хоть memcached.
Вы какое-то свое определение NoSQL изобрели, которое вам удобно, и теперь его используете чтобы доказать то, что вам нужно. Если в этом кеше включить persistence, это что-нибудь принципиальное изменит?
ANS>>Если убрать Redis, то цифры из 50:60 превратятся во что-то другое и не факт что, от такой нагрузки система не ляжет. G>Если убрать redis, но надо прикрутиь кеширование в другом месте. Кеш нужен не потому что кто-то там плохо масштабируется, а чтобы не выполнять работу, которую можно не выполнять.
Масштабируемость — это способность перестраиваться с целью удерживать увеличивающуюся нагрузку. Совершенно очевидно, что если кеш убрать, то back-end сервера умрут. И увеличивать их размер дальше уже почти некуда.
ANS>>Причина понятна — RDBMS плохо масштабируется G>Ага, у чуваков 2тб данных, а ты говоришь плохо масштабируется. Любой NoSQL уже бы согнулся.
Не нужно обобщать свойства конкретных баз, к-ые вы попробовали на всю экосистему. Вся концепция NoSQL создавалась с целью достигнуть масштабируемости за счет феерического геммороя для разработчиков. Потом конечно набежали всякие шарлатаны и наплодили свои MongoDB, RavenDB и <добавьте свою NoSQL базу написанную 1 человеком на полставки> и дополнили концептуальный гемморой еще своими кривыми руками.
Лично у меня жатых 300TB в HBase лежит. А вот у этих https://www.facebook.com/Engineering — петабайты.
ANS>>Что видим в результате — MS SQL используется, как библиотека для более/менее надёжного хранения документиков (как в android — sqlite), а вся реальная работа выполняется Redis-ом, ElasticSearch и спецсервисом тегов.
G>
G>558,224,585 мс (155 часов) было затрачено на обработку SQL запросов
G>99,346,916 мс (27 часов) потребовалось на ожидание ответа от серверов Redis
G>132,384,059 мс (36 часов) прошло на обработку запросов по тэгам
G>То есть Redis, который отдает данные из ОП по ключу работает в среднем в 5 раз меньше SQL, который занимается записью\чтением с диска.
Мне кажется вы неправильно трактуете статистику. SQL работая как персистентый сторадж потратил ВСЕГО в 5 раз больше времени чем in-memory redis. Это значит, что у них 95% нагрузки терминируется в redis. Ибо он на порядки более простые и быстрые операции выполняет.
Здравствуйте, lazymf, Вы писали:
L>Ой, а расскажите пожалуйста, что такое "передовая архитектура"?
Это, в основном, то, о чём сейчас модно писать на хабре.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Miroff, Вы писали:
L>>Ой, а расскажите пожалуйста, что такое "передовая архитектура"? M>Почему бы вам не пойти за этим на highscalability.com?
Ок, не вопрос, иду на highscalability.com, вижу статью про Salesforce, читаю ее — ява и оракл. Омг, кто бы мог подумать, это же ровно то, что все использовали и пять и десять лет назад. Или это недостаточно "передовая архитектура"?
Здравствуйте, Sinclair, Вы писали:
L>>Ой, а расскажите пожалуйста, что такое "передовая архитектура"? S>Это, в основном, то, о чём сейчас модно писать на хабре.
Я правильно понял, что "передовая архитектура" — это "змейка" в 30 JS-строчек?
А если убрать их специализированный сервис тегов, то тут ваще капец. Что видим в результате — MS SQL используется, как библиотека для более/менее надёжного хранения документиков (как в android — sqlite), а вся реальная работа выполняется Redis-ом, ElasticSearch и спецсервисом тегов.
