Здравствуйте, 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>Пронзая мыслью пространство и время, я надеюсь?
