Интересен последний пост, который как раз был пререведен на хабре. В нем сравнительно очень большие цифры — сотни миллионов запросов, 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 может начать двигаться дальше тоже не секрет. Для того чтобы судить об архитектуре этого более чем достаточно.
Здравствуйте, 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-строчек?
Здравствуйте, lazymf, Вы писали:
L>Я правильно понял, что "передовая архитектура" — это "змейка" в 30 JS-строчек?
Как правило, "передовая архитектура" — это как можно больше баззвордов, плохо понимаемых передовыми архитекторами.
То есть — NoSQL, шардинг, "нам не нужен ACID потому что в случае сбоя мы просто поднимаемся из реплики", код сервера на чём-нибудь как можно более динамическом типа Node.js или питона, на клиенте непременно HTML5 потому что "HTML 4 — это iPhone 4, а сейчас надо делать для iPhone 5c и 5s", СSS3, и "ваш броузер — говно, мы тестировали в экспериментальной сборке хрома и там всё работает".
Вот это — передовая архитектура.
Ещё пять лет назад передовой архитектурой было Rich Data Model, ентити-классы, мемкашед чтобы починить проблемы Hibernate, адский SOAP, ручная реализация банальностей типа лоад балансинга и сешшн аффинити при помощи кастомных хедеров и кастомных SOAP Fault.
Боюсь и думать, что будет дальше.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Gurney, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
ANS>>>Для Redis общепринятым термином является NoSql. G>>Еще раз: там где нет хранимых данных это тупо кеш. Хоть redis, хоть memcached. G>Вы какое-то свое определение NoSQL изобрели, которое вам удобно, и теперь его используете чтобы доказать то, что вам нужно. Если в этом кеше включить persistence, это что-нибудь принципиальное изменит?
Я думаю кеш умрет от этого
ANS>>>Если убрать Redis, то цифры из 50:60 превратятся во что-то другое и не факт что, от такой нагрузки система не ляжет. G>>Если убрать redis, но надо прикрутиь кеширование в другом месте. Кеш нужен не потому что кто-то там плохо масштабируется, а чтобы не выполнять работу, которую можно не выполнять. G>Масштабируемость — это способность перестраиваться с целью удерживать увеличивающуюся нагрузку. Совершенно очевидно, что если кеш убрать, то back-end сервера умрут. И увеличивать их размер дальше уже почти некуда.
Один из способов удеживать нагрузку — не делать работу, которую можно не делать. У backend серверов недостаточно информации о том какую работу таки надо делать, а какую — нет.
G>Лично у меня жатых 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, который занимается записью\чтением с диска.
G>Мне кажется вы неправильно трактуете статистику. SQL работая как персистентый сторадж потратил ВСЕГО в 5 раз больше времени чем in-memory redis. Это значит, что у них 95% нагрузки терминируется в redis. Ибо он на порядки более простые и быстрые операции выполняет.
Должно вообще минимум 90% отдаваться из кеша и максимум 10% доходить до манипуляций с данными. Это и есть правильная архитектура. Тем не менее самая важная часть работы заключается именно в этих <10%. Время работы SQL ка раз говорит что sql там небесполезно греет воздух.
Здравствуйте, gandjustas, Вы писали:
ANS>>Что видим в результате — MS SQL используется, как библиотека для более/менее надёжного хранения документиков (как в android — sqlite), а вся реальная работа выполняется Redis-ом, ElasticSearch и спецсервисом тегов. G> G>А ты пост читал по первой ссылке?
G>
G>558,224,585 мс (155 часов) было затрачено на обработку SQL запросов
G>99,346,916 мс (27 часов) потребовалось на ожидание ответа от серверов Redis
G>132,384,059 мс (36 часов) прошло на обработку запросов по тэгам
G>То есть Redis, который отдает данные из ОП по ключу работает в среднем в 5 раз меньше SQL, который занимается записью\чтением с диска.
Запросов обслуживают больше, времени тратят меньше. Вывод один — чем меньше запросов дойдёт до RDBMS, тем успешнее система.
G>Не позорься такими высказываниями.
Ну-ну. Вот приводить SO, как пример традиционной без NoSql архитектурыЮ вот это — позорится.
Здравствуйте, Gurney, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>>И причем тут построение индексов при помощи Map Reduce? G>>http://docs.mongodb.org/manual/core/map-reduce/ G>>неспроста... G>Вы бы все таки почитали что-нибудь системно. А то смотреть больно.
К чему эта фраза?
В Монге явно указано что есть индексы, которые строятся Map Reduce алгоритмом. Во многих NoSQL такое есть, ибо удобно при наличии шардов так считать индексы. Медленно, но реализация получается несложная.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
ANS>>>Что видим в результате — MS SQL используется, как библиотека для более/менее надёжного хранения документиков (как в android — sqlite), а вся реальная работа выполняется Redis-ом, ElasticSearch и спецсервисом тегов. G>> G>>А ты пост читал по первой ссылке?
G>>
G>>558,224,585 мс (155 часов) было затрачено на обработку SQL запросов
G>>99,346,916 мс (27 часов) потребовалось на ожидание ответа от серверов Redis
G>>132,384,059 мс (36 часов) прошло на обработку запросов по тэгам
G>>То есть Redis, который отдает данные из ОП по ключу работает в среднем в 5 раз меньше SQL, который занимается записью\чтением с диска.
ANS>Запросов обслуживают больше, времени тратят меньше. Вывод один — чем меньше запросов дойдёт до RDBMS, тем успешнее система.
По сути так и есть. Но те запросы, которые дойду — являются самыми важными. Объем вложений в обработку этих процентов запросов максимальный. Цифры это и показывают.
G>>Не позорься такими высказываниями.
ANS>Ну-ну. Вот приводить SO, как пример традиционной без NoSql архитектурыЮ вот это — позорится.
Ты о чем? Сами инженеры SO говорят что у них нет NoSQL.
Ты же, как знатный маркетолог, хочешь прилепить бирку NoSQL и приписать достижения к NoSQL.
Чето похожее в свое время было с ООП. Видимо это позиция слабого в архитектурном холиваре.
Здравствуйте, gandjustas, Вы писали:
G>В Монге явно указано что есть индексы, которые строятся Map Reduce алгоритмом. Во многих NoSQL такое есть, ибо удобно при наличии шардов так считать индексы. Медленно, но реализация получается несложная.
Какую роль mr играет в построении индексов. mr вроде нужен для построения запросов типа sql join?
Здравствуйте, Gurney, Вы писали:
G>Совершенно очевидно, что если кеш убрать, то back-end сервера умрут. И увеличивать их размер дальше уже почти некуда.
Откуда такой вывод? Про то, что увеличивать некуда?
Здравствуйте, gandjustas, Вы писали:
G>>>Не позорься такими высказываниями. ANS>>Ну-ну. Вот приводить SO, как пример традиционной без NoSql архитектурыЮ вот это — позорится. G>Ты о чем? Сами инженеры SO говорят что у них нет NoSQL.
На заборе тоже было написано... А оказалось — дрова лежат.
G>Ты же, как знатный маркетолог, хочешь прилепить бирку NoSQL и приписать достижения к NoSQL.
Нет, просто я смотрю в самую суть вещей, а это не доступно многим.
G>Чето похожее в свое время было с ООП.
Чето чё?
G>Видимо это позиция слабого в архитектурном холиваре.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
G>>Ты о чем? Сами инженеры SO говорят что у них нет NoSQL. ANS>На заборе тоже было написано... А оказалось — дрова лежат.
Всё гораздо хуже. На заборе написано "кеш", в сарае redis но связка забор+сарай дают чёткую ассоциацию: там ХХХ... noSQL, в смысле.
G>>Ты же, как знатный маркетолог, хочешь прилепить бирку NoSQL и приписать достижения к NoSQL. ANS>Нет, просто я смотрю в самую суть вещей, а это не доступно многим.
Здравствуйте, Yoriсk, Вы писали:
G>>>Ты же, как знатный маркетолог, хочешь прилепить бирку NoSQL и приписать достижения к NoSQL. ANS>>Нет, просто я смотрю в самую суть вещей, а это не доступно многим. Y>Пронзая мыслью пространство и время, я надеюсь?
