Интересен последний пост, который как раз был пререведен на хабре. В нем сравнительно очень большие цифры — сотни миллионов запросов, 2тб данных, но при этом все работает 2 MS SQL, 2 кеш-сервера redis и 3 сервера обработки тегов и 11 WFE. При этом серваки работают менее чем на 30% своего capacity в среднем.
Кстати у них МНОГО памяти. Суммарно около 1ТБ RAM. Видимо это позволяет держать в памяти все активные данные и генерировать страницы за 50мс.
Все это как-то расходится с современными трендами о bigdata и nosql, предлагающими десятки серверов, и всякие map-reduce уже для пары сотен ГБ.
Здравствуйте, gandjustas, Вы писали:
G>Все это как-то расходится с современными трендами о bigdata и nosql, предлагающими десятки серверов, и всякие map-reduce уже для пары сотен ГБ.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, gandjustas, Вы писали:
G>>Все это как-то расходится с современными трендами о bigdata и nosql, предлагающими десятки серверов, и всякие map-reduce уже для пары сотен ГБ.
vsb>У них не очень много данных в базе.
2ТБ это много, но и не мало. Большая част интернет-сервисов не дорастает и до таких объемов.
Здравствуйте, gandjustas, Вы писали:
G>Интересен последний пост, который как раз был пререведен на хабре. В нем сравнительно очень большие цифры — сотни миллионов запросов, 2тб данных, но при этом все работает 2 MS SQL, 2 кеш-сервера redis и 3 сервера обработки тегов и 11 WFE. При этом серваки работают менее чем на 30% своего capacity в среднем. G>Кстати у них МНОГО памяти. Суммарно около 1ТБ RAM. Видимо это позволяет держать в памяти все активные данные и генерировать страницы за 50мс. G>Все это как-то расходится с современными трендами о bigdata и nosql, предлагающими десятки серверов, и всякие map-reduce уже для пары сотен ГБ.
BigData это маркетинговый термин, смысл которого сводится к "столько данных, что их тяжело обрабатывать". Ни больше, ни меньше. Если вы на этих данных отчеты считаете, то вообще один сервер справится. У нас 20TB одна база пережевывает. Вот только задумываемся переехать на Vertica или что-нибудь подобное. И честно говоря, резервы еще есть.
NoSQL — это группа продуктов, к-ые имеют свой необычный интерфейс доступа к данным. Строго говоря, некоторые из таких продуктов позволяют делать десятки серверов, а некоторые нет. Это вообще ортогональные вещи.
Кстати, Redis — это один из ярких и наиболее успешных NoSQL хранилищ данных. Так что не расходится.
150M запросов в день, это не такая из ряда вон нагрузка. В среднем 1500 запросов в секунду. Даже если у них пиковая возрастает в 3 раза (4500K), это все равно далеко не верхний предел.
Что касается MapReduce — это способ offline обработки данных в пакетном режиме. То есть аналитика, отчеты, машинное обучение (да, если вы особый мазохист то на MapReduce можно делать машинное обучение). Но и только. Обслуживать web-site эта система не предназначена.
Кстати для MapReduce 200GB это может быть и мало и много. Смотря что вы там считаете. Априори, если у вас такие объемы, то про Hadoop думать рано.
Здравствуйте, Gurney, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>Интересен последний пост, который как раз был пререведен на хабре. В нем сравнительно очень большие цифры — сотни миллионов запросов, 2тб данных, но при этом все работает 2 MS SQL, 2 кеш-сервера redis и 3 сервера обработки тегов и 11 WFE. При этом серваки работают менее чем на 30% своего capacity в среднем. G>>Кстати у них МНОГО памяти. Суммарно около 1ТБ RAM. Видимо это позволяет держать в памяти все активные данные и генерировать страницы за 50мс. G>>Все это как-то расходится с современными трендами о bigdata и nosql, предлагающими десятки серверов, и всякие map-reduce уже для пары сотен ГБ.
G>BigData это маркетинговый термин, смысл которого сводится к "столько данных, что их тяжело обрабатывать". Ни больше, ни меньше. Если вы на этих данных отчеты считаете, то вообще один сервер справится. У нас 20TB одна база пережевывает. Вот только задумываемся переехать на Vertica или что-нибудь подобное. И честно говоря, резервы еще есть.
Все термины в последнем предложении — маркетинговые.
G>NoSQL — это группа продуктов, к-ые имеют свой необычный интерфейс доступа к данным. Строго говоря, некоторые из таких продуктов позволяют делать десятки серверов, а некоторые нет. Это вообще ортогональные вещи.
NoSQL тоже маркетинговый термин есличто. Но не интересует NoSQL вообще, интересует NoSQL применимо к конкретной архитектуре типа SO.
G>Кстати, Redis — это один из ярких и наиболее успешных NoSQL хранилищ данных. Так что не расходится.
Он там только для кеша. Причем кеш довольно тупой судя по комментам команды.
G>150M запросов в день, это не такая из ряда вон нагрузка. В среднем 1500 запросов в секунду. Даже если у них пиковая возрастает в 3 раза (4500K), это все равно далеко не верхний предел.
Верхний предел чего?
G>Что касается MapReduce — это способ offline обработки данных в пакетном режиме. То есть аналитика, отчеты, машинное обучение (да, если вы особый мазохист то на MapReduce можно делать машинное обучение). Но и только. Обслуживать web-site эта система не предназначена.
Тем не менее многие NoSQL базы данных предлагают map-reduce для построения индексов.
Здравствуйте, gandjustas, Вы писали:
G>Все это как-то расходится с современными трендами о bigdata и nosql, предлагающими десятки серверов, и всякие map-reduce уже для пары сотен ГБ.
Ну они же давно начали, майкрософт тогде ещё не использовал терминов map-reduce и nosql в агитационных материалах ))
А архитектура вполне типовая, игры (серверную часть) с сотней тысяч одновременных пользователей аналогично делают — тот же redis в роли тупого кеша и postgres для данных, до этого в хайлоад вебе был в моде memcached.
Здравствуйте, mtnl, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Все это как-то расходится с современными трендами о bigdata и nosql, предлагающими десятки серверов, и всякие map-reduce уже для пары сотен ГБ.
M>Ну они же давно начали, майкрософт тогде ещё не использовал терминов map-reduce и nosql в агитационных материалах ))
И сейчас не использует.
M>А архитектура вполне типовая, игры (серверную часть) с сотней тысяч одновременных пользователей аналогично делают — тот же redis в роли тупого кеша и postgres для данных, до этого в хайлоад вебе был в моде memcached.
Важно не то что типовая, а то что контртрендовая.
Они не используют облака.
Они делают scale up, а не scale out и добились офигенных характеристик по нагрузке.
Они не используют NoSQL как storage, только как кеш.
Они используют windows, sql server и .net, а не ruby, linux и mysql\postgres.
Они оптимизируют Data Access, а не ставят кеши, вдвое превышающие объем данных.
Они оптимизируют .NET код, добиваясь больших успехов.
У них 2ТБ данных и они не называют это BigData
Посмотрите комменты, там повылезали теоритекторы (теоретические архитекторы), которые "гораздо лучше" знают как сделать SO.
Здравствуйте, gandjustas, Вы писали:
G>Посмотрите комменты, там повылезали теоритекторы (теоретические архитекторы), которые "гораздо лучше" знают как сделать SO.
Так то ж хабр. Там в каментах вообще тихий ужас, за редким исключением. Собственно как и в статьях.
Здравствуйте, gandjustas, Вы писали:
G>Важно не то что типовая, а то что контртрендовая.
Это обусловленно выбором стека .net на котором передовую архитектуру построить невозможно.
G>Они не используют облака.
Логично. Чтобы облака были выгодны необходимо: а) чтобы приложение горизонтально масштабировалось б) чтоб нагрузка значительно изменялась во временем
G>Они делают scale up, а не scale out и добились офигенных характеристик по нагрузке.
Вопрос только в том сколько это стоило.
G>Они не используют NoSQL как storage, только как кеш.
Мало кто использует NoSQL как основной сторедж.
G>Они используют windows, sql server и .net, а не ruby, linux и mysql\postgres.
Опять же вопрос во сколько им это обходится.
G>Они оптимизируют Data Access, а не ставят кеши, вдвое превышающие объем данных.
Как это не ставят кэши, а 1ТБ RAM им тогда для чего?
G>Они оптимизируют .NET код, добиваясь больших успехов.
Это пока они не уперлись в железо. Когда их сервера перестанут тянуть, посмотрим как они слезут с этой йолки.
G>У них 2ТБ данных и они не называют это BigData
Потому что это всего лишь текст. 2 ТБ текста это не так уж много.
G>Посмотрите комменты, там повылезали теоритекторы (теоретические архитекторы), которые "гораздо лучше" знают как сделать SO.
Вполне возможно они действительно знают как сделать лучше. В конце концов стоимость содержания SO в статье не раскрыта.
Здравствуйте, gandjustas, Вы писали:
G>>>Все это как-то расходится с современными трендами о bigdata и nosql, предлагающими десятки серверов, и всякие map-reduce уже для пары сотен ГБ.
M>>Ну они же давно начали, майкрософт тогде ещё не использовал терминов map-reduce и nosql в агитационных материалах ))
G>И сейчас не использует.
http://www.microsoftvirtualacademy.com/training-courses/big-data-analytics например
M>>А архитектура вполне типовая, игры (серверную часть) с сотней тысяч одновременных пользователей аналогично делают — тот же redis в роли тупого кеша и postgres для данных, до этого в хайлоад вебе был в моде memcached.
G>Важно не то что типовая, а то что контртрендовая.
Видимо, медиа-хайп и реальный тренд — немножко разные вещи.
В случае упомянутых уже мной игр, опять же, обычно
никаких облаков
никаких руби, очень часто — внезапно java (про руби, кстати, показательно, что твиттер с него громко съехал в пользу JVM),
этот java код , опять же, очень оптимизируется (у твиттера есть несколько видео про то, как они оптимизировали использование garbage collector)
Здравствуйте, Miroff, Вы писали:
G>>Важно не то что типовая, а то что контртрендовая.
M>Это обусловленно выбором стека .net на котором передовую архитектуру построить невозможно.
G>>Они используют windows, sql server и .net, а не ruby, linux и mysql\postgres.
M>Опять же вопрос во сколько им это обходится.
Ну, у них основной пойнт рассказов про свою архитектуру в том,
что они используют 25 серверов, на которых имеют ещё очень хороший запас (по их оценке — могли бы жить и на 5 серверах),
в то время как у других для обслуживания такой нагрузки используется 100-500 серверов.
(цифры из http://www.youtube.com/watch?v=t6kM2EM6so4)
Т.е. стоимость лицензий на виндовс и скуль должна с лихвой отбиваться экономией на железе.
G>>NoSQL — это группа продуктов, к-ые имеют свой необычный интерфейс доступа к данным. Строго говоря, некоторые из таких продуктов позволяют делать десятки серверов, а некоторые нет. Это вообще ортогональные вещи. G>NoSQL тоже маркетинговый термин есличто. Но не интересует NoSQL вообще, интересует NoSQL применимо к конкретной архитектуре типа SO.
G>>Кстати, Redis — это один из ярких и наиболее успешных NoSQL хранилищ данных. Так что не расходится. G>Он там только для кеша. Причем кеш довольно тупой судя по комментам команды.
Большинство нагрузок для NoSQL баз, к-ые приходилось видеть, могут быть интерпретированы именно как кеширование.
G>>150M запросов в день, это не такая из ряда вон нагрузка. В среднем 1500 запросов в секунду. Даже если у них пиковая возрастает в 3 раза (4500K), это все равно далеко не верхний предел. G>Верхний предел чего?
Нагрузки на large website.
G>>Что касается MapReduce — это способ offline обработки данных в пакетном режиме. То есть аналитика, отчеты, машинное обучение (да, если вы особый мазохист то на MapReduce можно делать машинное обучение). Но и только. Обслуживать web-site эта система не предназначена. G>Тем не менее многие NoSQL базы данных предлагают map-reduce для построения индексов.
Примеры в студию
Здравствуйте, Miroff, Вы писали:
G>>Они не используют облака. M>Логично. Чтобы облака были выгодны необходимо: а) чтобы приложение горизонтально масштабировалось б) чтоб нагрузка значительно изменялась во временем
в) чтобы не было команды, которая не способна это сделать в рамках компании
Облака они, сцуко, дорогие. Если у вас CTO, считающий деньги, и адекватная infrastructure команда, то пробивать это сложно.
G>>Они делают scale up, а не scale out и добились офигенных характеристик по нагрузке. M>Вопрос только в том сколько это стоило.
А сколько бы они отдали консультантам, если бы делали scale out...
G>>Они оптимизируют .NET код, добиваясь больших успехов. M>Это пока они не уперлись в железо. Когда их сервера перестанут тянуть, посмотрим как они слезут с этой йолки.
У них read-mostly workload. Они могут оч долго не упираться в железо. А потом добавить еще один MS SQL.
G>>Посмотрите комменты, там повылезали теоритекторы (теоретические архитекторы), которые "гораздо лучше" знают как сделать SO. M>Вполне возможно они действительно знают как сделать лучше. В конце концов стоимость содержания SO в статье не раскрыта.
Одними из основных факторов архитектуры являются:
1) доступность людей с нужной квалификацией в технологическом стеке
2) технологическая стратегия компании
То, что люди позволяют себе судить о ПГАВИЛЬНОЙ АРХИТЕКТУРКЕ без знания этих факторов, ставит большой вопрос относительно их способностей.
Здравствуйте, mtnl, Вы писали:
M>этот java код , опять же, очень оптимизируется (у твиттера есть несколько видео про то, как они оптимизировали использование garbage collector)
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Важно не то что типовая, а то что контртрендовая.
M>Это обусловленно выбором стека .net на котором передовую архитектуру построить невозможно.
Передовая != эффективная
G>>Они не используют облака. M>Логично. Чтобы облака были выгодны необходимо: а) чтобы приложение горизонтально масштабировалось б) чтоб нагрузка значительно изменялась во временем
G>>Они делают scale up, а не scale out и добились офигенных характеристик по нагрузке. M>Вопрос только в том сколько это стоило.
У них есть список железа, пост на MetaOwerflow, глнянь. Относительно не дорого кстати. Как обычно самое дорогое — диски.
G>>Они не используют NoSQL как storage, только как кеш. M>Мало кто использует NoSQL как основной сторедж.
Больше чем стоило бы.
G>>Они используют windows, sql server и .net, а не ruby, linux и mysql\postgres. M>Опять же вопрос во сколько им это обходится.
Я думаю что им MS стек обходится сильно дешевле.
G>>Они оптимизируют Data Access, а не ставят кеши, вдвое превышающие объем данных. M>Как это не ставят кэши, а 1ТБ RAM им тогда для чего?
Он там на малую часть загружен, почитай пост. Это это совокупный объем памяти, в том числе: passive ноды SQL Server, redis, reverse proxy и IIS с output cache.
G>>Они оптимизируют .NET код, добиваясь больших успехов. M>Это пока они не уперлись в железо. Когда их сервера перестанут тянуть, посмотрим как они слезут с этой йолки.
За время существования SO они много раз упирались в железо. Стартовали вообще на одном сервере. Проблем со scaleup не было. Сегодня 360 гб памяти в сервере не проблема вообще.
Кстати многие проблемы когда "упирались в железо" решались оптимизацией кода.
Здравствуйте, Gurney, Вы писали:
G>>>Что касается MapReduce — это способ offline обработки данных в пакетном режиме. То есть аналитика, отчеты, машинное обучение (да, если вы особый мазохист то на MapReduce можно делать машинное обучение). Но и только. Обслуживать web-site эта система не предназначена. G>>Тем не менее многие NoSQL базы данных предлагают map-reduce для построения индексов. G>Примеры в студию
Здравствуйте, gandjustas, Вы писали:
G>Они делают scale up, а не scale out и добились офигенных характеристик по нагрузке.
Угу.
Что примечательно (если я ничего не упустил) — со scale out там тоже принципиальных проблем нет. И по производительности запас вообще неприличный: в комментах Nick Craver ответил, что они пока не используют bufferpool extensions или in-memory oltp (aka hekaton).
Здравствуйте, Gurney, Вы писали:
G>в) чтобы не было команды, которая не способна это сделать в рамках компании
G>Облака они, сцуко, дорогие. Если у вас CTO, считающий деньги, и адекватная infrastructure команда, то пробивать это сложно.
Адекватная инфраструктурная команда тоже стоит довольно дорого. Даже если вы предпочитаете разворачивать инфраструктуры внутри компании, непонятно как в рамках компании утилизовать неиспользуемые ресурсы, если в понедельник утром у вас 100к запросов в секунду, а ночью на уик-енд всего 5к. Держать запас топовых серверов чтобы справляться с пиками? Перепродавать неиспользуемые ресурсы вашего облака?
G>А сколько бы они отдали консультантам, если бы делали scale out...
У них же довольно квалифицированная команда, могли и сами справиться.
G>У них read-mostly workload. Они могут оч долго не упираться в железо. А потом добавить еще один MS SQL.
И мгновенно упереться в сеть между репликами SQL сервера.
G>Одними из основных факторов архитектуры являются: G>1) доступность людей с нужной квалификацией в технологическом стеке
Для небольшой компании это не проблема, на рынке всегда найдется несколько человек любой необходимой квалификации, даже если технологический стек основан на лиспе с фортом.
G>2) технологическая стратегия компании
Технологическая стратегия обусловленная первой производной от требований (изменением требований).
G>То, что люди позволяют себе судить о ПГАВИЛЬНОЙ АРХИТЕКТУРКЕ без знания этих факторов, ставит большой вопрос относительно их способностей.
Требования к SO известны, как они менялись со временем известно, куда SO может начать двигаться дальше тоже не секрет. Для того чтобы судить об архитектуре этого более чем достаточно.
