Комментарии 55
Спасибо за статью. Извиняюсь за возможно ламерские вопросы, но:
1) технология открыта или нужно покупать лицензию у GigaSpaces?
2) это только Java, что если у нас платформа на Ruby?
1) технология открыта или нужно покупать лицензию у GigaSpaces?
2) это только Java, что если у нас платформа на Ruby?
Насколько я знаю Gigaspaces продает XAP — то есть он не бесплатный, хотя вроде и не очень дорогой. Если хочешь я могу навести справки узнать сколько именно он стоит.
XAP работает не только с java, там как миниму есть еще и поддержка дот нета. Ruby — не уверен, скорее всего нет, но они постоянно расширяют горизонты, опять таки, если интересно могу узнать, когда они будут поддерживать и Ruby
XAP работает не только с java, там как миниму есть еще и поддержка дот нета. Ruby — не уверен, скорее всего нет, но они постоянно расширяют горизонты, опять таки, если интересно могу узнать, когда они будут поддерживать и Ruby
Соображения по Руби (если не вспоминать о JRuby) описал в комментарии ниже на странице. В целом, вполне можно собрать аналог на текущих инструментах и практиках для кластеризации. Писать нужно будет только скрипт как данные будут перетекать по нодам, но в любом случае это достаточно зависимая от проекта вещь. Понятно, что такой подход в теории технически может быть несколько менее оптимален, чем XAP (потребуется для такого же кол-ва запросов больше нод, но не учитывается стоимость лицензий и поддержки XAP), но пиковую нагрузку все равно сможет выдержать.
Вооооот. Вот это другое дело!
с 11 до 3 ночи сидели)))
Не минусуйте jbaruch он дело говорит
ХАБР – хреновая архитектура быстро разоряет )
Во первых — спасибо автору за одну из первых толковых статей про XAP на русском. Сам я с полгода занимаюсь конкретно с Gigaspaces и параллельно с другими гридами(GridGain, Gemfire). Вопрос к автору — будет ли запись вашего выступления где то доступна? Тк я нахожусь очень далеко, а послушать очень хочется. И планируется ли продолжение статей про XAP?
Поддерживаю! Очень хочется послушать, но нет возможности приехать.
Запись будет, JUG в этом году очень качественный, и запись будет на высоком уровне, по крайней мере так мне обещали :)
Как только ее зальют, я скину линк.
На счет продолжение статей про XAP, если будет время с удовольствием напишу еще, скажите только в каком направлении писать.
Как только ее зальют, я скину линк.
На счет продолжение статей про XAP, если будет время с удовольствием напишу еще, скажите только в каком направлении писать.
на jug.ru будет и вконтакте
Иной хабровчанин даже может решить, что такое решение способствует нездоровому смешиванию данных с логикой. Однако опыт показывает, что настоящих умельцев никакие слои не остановят и при наличии должных навыков, винегрет можно сделать, имея какую угодно «архитектуру»!
Грамотный подход…
Интересно, конечно, еще посмотреть на декларативную часть.
То есть " живя в мире, где объём данных растёт экспоненциально" — нам стоит эти данные перенести в оперативку и наступит счастье? А стоимость оперативки точно будет падать экспоненциально для осуществления этого благого начинания?
Данные, хранимые в оперативке, можно сориентировать таким образом, чтобы применялось сжатие. При этом, со случайным доступом. Существуют такие данные, которые эффективно сжимаются, например, какая-нибудь бизнес аналитика.
И, кстати, когда я смотрел некоторые вещи по SAP HANA, например, там объяснили, что стоимость памяти идёт из расчёта стоимости передачи 1 гигабайта данных в единицу времени. То есть с пропускной способностью плашки памяти вы передадите данные быстрее, чем SSD в пересчёте, допустим, на один доллар.
И, кстати, когда я смотрел некоторые вещи по SAP HANA, например, там объяснили, что стоимость памяти идёт из расчёта стоимости передачи 1 гигабайта данных в единицу времени. То есть с пропускной способностью плашки памяти вы передадите данные быстрее, чем SSD в пересчёте, допустим, на один доллар.
А какая альтернатива?
Оперативка может и не экспоненциально дешевеет, но она в любом случае дешевле чем БД.
Понятно что можно взять бесплатную БД и тогда выйдет дешевле, причем существенно, так как жесткий диск дешевле оперативки.
Но мы же говорим про огромнные массивы данных. А тут каким нибудь дерби не отделаешься, а покупать у оракла лизенцию и саппорт выйдет намного дороже оперативки.
Оперативка может и не экспоненциально дешевеет, но она в любом случае дешевле чем БД.
Понятно что можно взять бесплатную БД и тогда выйдет дешевле, причем существенно, так как жесткий диск дешевле оперативки.
Но мы же говорим про огромнные массивы данных. А тут каким нибудь дерби не отделаешься, а покупать у оракла лизенцию и саппорт выйдет намного дороже оперативки.
производительность процов (раньше частоты, теперь количетство ядер) и пропускная способность шины тоже растут экспоненциально. Это компенсирует.
И я не совсем понял товарищей из Kohl’s… Я к сожалению ни разу не спец по системам на java, но почему было не добавить LoadBalancing какого-либо вида между веб-сервером и процессами + между процессами и данными? И спокойно остаться в рамках трёхзвенки, не создавая себе счастья от перехода на новую архитектуру?
Судя по статье у них балансеры были. Было много серверов. Но не было мониторинга (какие сервисы начинают перегреваться и их нужно расширять). И не были готовы расширяться быстро (не было готовых современных образов для облачных систем и т.п.). Особенно не смогли бы масштабироваться, если у них покупные продукты есть на серверах.
В итоге большую часть покупателей обслужить не смогли.
Т.к. потеря 20% от года — невероятно много, начались внутренние разборки кто виноват и что делать, чтобы это НИКОГДА!!!!!111 не повторилось. XAP удачно подвернулась и была внедрена. Возможно, даже, айтишники сохранили свои рабочие места после этого.
У XAP, опять же по статье, достаточно простая идея: берем трехзвенку (БД+сервер приложений+сервер статики+кеш какой-нить), размещаем на 1ой машине, базе даем достаточно ОЗУ, чтобы все хранилось в ней, делаем образы такой машины, деплоим их по необходимости. Понятно, что именно в XAP это, скорее всего, не только на 1 машине, но еще и как-то дополнительно оптимизировано, чтобы было за что деньги брать.
У подхода (без деталей реализации) 3 проблемы на вскидку:
1) Т.к. XAP платен, то, возможно, будут задержки во времени на получение лицензий и их оплату (тысяч 10 долларов, например, быстро перевести) при необходимости увеличить в 10 раз количество серверов.
2) По самой же архитектуре мы предполагаем, что систему можем разбить на одинаковые маленькие блоки. Оставив только один какой-то суперблок для авторизации и перераспределения блоков. Такое можно сделать для всяких Бейскемпов — там один аккаунт не зависит совершенно от другого, только информация о аккаунте централизована. В интернет-магазине добавляются единая информация о складе. Ее как отдельную систему можно так же по XAP масштабировать, но тогда получаем 2 отдельных системы: уже нужно принимать решение какую из них масштабировать. Впрочем, при наличии мониторинга и готовой инфраструктуры это особой проблемой не будет. В зависимости от особенностей проекта может быть достаточно много таких отдельных XAP-систем.
3) С практической точки зрения будет важным удобство инструмента перераспределения количества нодов. Т.е. мы добавляем к 10 нодам еще 2. Нужно, чтобы данные, в транзакционном режиме (без потери изменений в последний момент на старом сервере или выдачи ошибки клиенту), перетекли на 2 новых сервера и они включились в работу. Аналогично мы отключаем 3 ноды и данные обратно должны перетекать. Возможно и не при включении перетекать, а при логине пользователя. Пользователь залогинился — данные с его учетки перетекли на этот сервер (их относительно немного).
По поводу других платформ (той же Ruby on rails). Версию для своей системы сделать довольно просто:
1) придумываете на сколько систем разбивать проект и как внутри каждой системы разбивать данные.
2) собственно разбиваете проект на подпроекты, настраиваете обычную свою БД и пишите скрипт миграции данных (тут можно было со временем выделить общие для разных проектов библиотеки, но и без этого достаточно недорого самим написать).
3) готовите отдельные образы операционных систем под каждую систему и каждый предполагаемый облачный хостинг
4) тестируете, что добавление и удаление нод работает как предполагалось; не забываете подключить мониторинг на каждый нод и нотификации в смс о перегрузках; возможно, автоматическое увеличение нод в каких-то пределах
5) далее не забываете обновлять образы (в принципе, что-то вроде capistrano вполне поможет)
Тут главное, чтобы был мониторинг и 100%-ая готовность запустить новые ноды с дроблением данных по нодам. Дальше уже можно бесконечно оптимизировать и фичерить каждый отдельный элемент схемы, чем, видимо, разработчки XAP и занимаются.
В итоге большую часть покупателей обслужить не смогли.
Т.к. потеря 20% от года — невероятно много, начались внутренние разборки кто виноват и что делать, чтобы это НИКОГДА!!!!!111 не повторилось. XAP удачно подвернулась и была внедрена. Возможно, даже, айтишники сохранили свои рабочие места после этого.
У XAP, опять же по статье, достаточно простая идея: берем трехзвенку (БД+сервер приложений+сервер статики+кеш какой-нить), размещаем на 1ой машине, базе даем достаточно ОЗУ, чтобы все хранилось в ней, делаем образы такой машины, деплоим их по необходимости. Понятно, что именно в XAP это, скорее всего, не только на 1 машине, но еще и как-то дополнительно оптимизировано, чтобы было за что деньги брать.
У подхода (без деталей реализации) 3 проблемы на вскидку:
1) Т.к. XAP платен, то, возможно, будут задержки во времени на получение лицензий и их оплату (тысяч 10 долларов, например, быстро перевести) при необходимости увеличить в 10 раз количество серверов.
2) По самой же архитектуре мы предполагаем, что систему можем разбить на одинаковые маленькие блоки. Оставив только один какой-то суперблок для авторизации и перераспределения блоков. Такое можно сделать для всяких Бейскемпов — там один аккаунт не зависит совершенно от другого, только информация о аккаунте централизована. В интернет-магазине добавляются единая информация о складе. Ее как отдельную систему можно так же по XAP масштабировать, но тогда получаем 2 отдельных системы: уже нужно принимать решение какую из них масштабировать. Впрочем, при наличии мониторинга и готовой инфраструктуры это особой проблемой не будет. В зависимости от особенностей проекта может быть достаточно много таких отдельных XAP-систем.
3) С практической точки зрения будет важным удобство инструмента перераспределения количества нодов. Т.е. мы добавляем к 10 нодам еще 2. Нужно, чтобы данные, в транзакционном режиме (без потери изменений в последний момент на старом сервере или выдачи ошибки клиенту), перетекли на 2 новых сервера и они включились в работу. Аналогично мы отключаем 3 ноды и данные обратно должны перетекать. Возможно и не при включении перетекать, а при логине пользователя. Пользователь залогинился — данные с его учетки перетекли на этот сервер (их относительно немного).
По поводу других платформ (той же Ruby on rails). Версию для своей системы сделать довольно просто:
1) придумываете на сколько систем разбивать проект и как внутри каждой системы разбивать данные.
2) собственно разбиваете проект на подпроекты, настраиваете обычную свою БД и пишите скрипт миграции данных (тут можно было со временем выделить общие для разных проектов библиотеки, но и без этого достаточно недорого самим написать).
3) готовите отдельные образы операционных систем под каждую систему и каждый предполагаемый облачный хостинг
4) тестируете, что добавление и удаление нод работает как предполагалось; не забываете подключить мониторинг на каждый нод и нотификации в смс о перегрузках; возможно, автоматическое увеличение нод в каких-то пределах
5) далее не забываете обновлять образы (в принципе, что-то вроде capistrano вполне поможет)
Тут главное, чтобы был мониторинг и 100%-ая готовность запустить новые ноды с дроблением данных по нодам. Дальше уже можно бесконечно оптимизировать и фичерить каждый отдельный элемент схемы, чем, видимо, разработчки XAP и занимаются.
Непонятно тогда, зачем картинка со схемой архитектуры постулирует наличие «бутылочных горлышек» именно на передаче данных между слоями…
Про реальную проблему в мониторинге наверное соглашусь, на это серьёзно намекают слова «Более того, зачастую добавка дополнительных ресурсов в один из уровней (например, серверов БД) не только не поможет, но, наоборот, повысит время ожидания». То есть ребята не только не знали, куда вставлять новые ноды, но и не представляли, что это вообще вычисляемо :-)
Про реальную проблему в мониторинге наверное соглашусь, на это серьёзно намекают слова «Более того, зачастую добавка дополнительных ресурсов в один из уровней (например, серверов БД) не только не поможет, но, наоборот, повысит время ожидания». То есть ребята не только не знали, куда вставлять новые ноды, но и не представляли, что это вообще вычисляемо :-)
Так «бутылочные горлышки» можно решить 2-мя способами:
1) Выделить между блоками специализацию (ренжи), в том числе и отдельные физические каналы.
2) Если первого не хватит, то посадить блоки по возможности на 1 машину, чтобы выдавался только результат небольшой из такой системы.
Собственно, это сделано у них и описано у меня.
1) Выделить между блоками специализацию (ренжи), в том числе и отдельные физические каналы.
2) Если первого не хватит, то посадить блоки по возможности на 1 машину, чтобы выдавался только результат небольшой из такой системы.
Собственно, это сделано у них и описано у меня.
>>В результате, по данным гугла сегодня их сайт занимает одно из первых мест в мире по скорости выдачи страниц
Что не мудрене, т.к. их сайт выдаёт следующее:
www.kohls.com/
— Access Denied
You don't have permission to access «www.kohls.com/» on this server.
Reference #18.6160434d.1377846957.541b4b5
— Я просто их сайт посмотреть хотел, что же там такого страшного, а там — тролфейс.жпг однако.
Что не мудрене, т.к. их сайт выдаёт следующее:
www.kohls.com/
— Access Denied
You don't have permission to access «www.kohls.com/» on this server.
Reference #18.6160434d.1377846957.541b4b5
— Я просто их сайт посмотреть хотел, что же там такого страшного, а там — тролфейс.жпг однако.
Хабрэффект нагнул сайт — теперь и XAP стал бутылочным горлышком и надо что-то новое придумыать. Наверное, размещать по маленькому серверу сразу у каждого клиента :)
промахнулся.
На самом деле вы спокойно можете пойти на сайт Kohls через американский ip. Т.к. заказ товаров с их сайта доступен только для некоторых стран, то, как и многие крупные интернет магазины — они просто ограничили доступ к ресурсу тем, кому недоступен заказ. Правильность данного решения оставим за рамками обсуждения данной статьи.
То есть (is) теперь (now) рейтинг статьи (article) намного лучше (better)?
Но если статья перевод вчерашней на смишную (то есть смысл тот же), то у меня вопрос: а как происходит синхронизация данных между модулями (partitions)? То есть если всё в памяти и периодически синхронизируется в бэкенд (backend) то как обеспечивается что у всех модулей одни и те же данные?
В случае с магазином, это не критично, но допустим, сиистема обслуживает некую ММОРПГ и нужно, чтоб любые два игрока, оказавшись в одном контексте, видели одно и то же и всё время а не иногда.
Но если статья перевод вчерашней на смишную (то есть смысл тот же), то у меня вопрос: а как происходит синхронизация данных между модулями (partitions)? То есть если всё в памяти и периодически синхронизируется в бэкенд (backend) то как обеспечивается что у всех модулей одни и те же данные?
В случае с магазином, это не критично, но допустим, сиистема обслуживает некую ММОРПГ и нужно, чтоб любые два игрока, оказавшись в одном контексте, видели одно и то же и всё время а не иногда.
У объектов, которые загружаются в space(хранилище всех объектов) — есть поле RoutingId, по которому как раз определяется — в какой интсанс спейса будет задеплоен этот объект. Но, нужно учитывать — что у Gigaspaces есть 3 топологии — sync-replicated, async-replicated и partitioned-sync2backup. И только последняя из них поддерживает партиции.
Извиняюсь — почему то отправился предыдущий комментарий недописанный. Дальше — полная версия моего ответа.
Нужно учитывать — что у Gigaspaces есть 3 топологии — sync-replicated, async-replicated и partitioned-sync2backup. И только последняя из них поддерживает партиции и друг между другом они не синхронизируюся. У объектов, которые загружаются в space(хранилище всех объектов) с использованием последней топологии — есть поле RoutingId, по которому как раз определяется — в какой space будет загружен этот объект. В каждом space содержатся данные без overlap(перекрытия). У каждого space в этой топологии есть backup space, куда синхронно заливаются изменения из primary space.
А вот в первых двух как раз в каждом space содежатся одни и те же данные, которые реплицируются на все spaces. Вывод — синхронизация только без партиций.
Нужно учитывать — что у Gigaspaces есть 3 топологии — sync-replicated, async-replicated и partitioned-sync2backup. И только последняя из них поддерживает партиции и друг между другом они не синхронизируюся. У объектов, которые загружаются в space(хранилище всех объектов) с использованием последней топологии — есть поле RoutingId, по которому как раз определяется — в какой space будет загружен этот объект. В каждом space содержатся данные без overlap(перекрытия). У каждого space в этой топологии есть backup space, куда синхронно заливаются изменения из primary space.
А вот в первых двух как раз в каждом space содежатся одни и те же данные, которые реплицируются на все spaces. Вывод — синхронизация только без партиций.
Давайте разберемся. Теорему CAP еще никто не отменял. В бизнес приложениях, связанных с продажей и деньгами, consistency является одним из ключевых параметров. В для веба требуется хороший availability. Поэтому как ни крути архитектурой, узкое горлышко останется именно в persistence store partitioning. Так и поступили, заменив Oracle RAC на in-memory distributed store, и погнали бочку на трехуровневую архитектуру. Вместо этого можно было бы все оптимизировать в рамках прежней системы.
1. На картинке обозначены 2 горлышка: Business Tier и Data Tier. Надо поправить, что с точки зрения архитектуры Business Tier не является узким местом в плане масштабирования, потому как не хранит общего состояния (shared state). J2EE архитектура изначально была задумана как распределенная. Добавить новый нод в Weblogic — пара щелчков мышкой в консоли. Остается только Data Tier.
2. Из картинки непонятна специфика работы интернет-магазина. Веб не только осуществляет транзакции, но также читает данные о продуктах из базы данных. И соотношение read/write запросов может достигать 10:1 (а реально намного больше). Поэтому грузит базу данных именно веб своими запросами на чтение. В этом случае поможет упомянутая прослойка в виде распределенного кеша, например Oracle Coherence. Чтобы архитектура была идентична представленному XAP, нужно добавить асинхронный сброс изменений в bb.dd, который увеличит производительность в десятки раз, однако в случае сбоя дает вероятность потерять целостность.
3. Бизнес логика. Обозначена одним блоком с кучей процессов внутри. А именно она определяет всю кухню. Если хреново написано — тут никакая архитектура не поможет. Задача магазина простая — операции со счетами и логистикой. Пара select-ов и update-ов. Здесь целое поле для оптимизации.
4. JMS. А нахрена он вообще здесь нужeн? MoM и JMS хороши для связи со сторонними системами, чтобы иметь наименьшую зависимость от них. Тут есть свои паттерны проектирования типа ESB. Внутри-то апликации зачем нужна асинхронность на каждом уровне, если все операции должны делаться внутри одной транзакции? Обычный remote EJB call или на крайняк WS! Пересылка каждого persistent-сообщения JMS делает как минимум 2 жестких апдейта в JMS persistence store. Поэтому скорость пересылки JMS невелика: benchmark Apache ActiveMQ давал около 1000 сообщений в секунду, что мало для системы, где все основано на JMS. Плюс геморрой с мониторингом всего этого. Если так нужна асинхронность, есть asynchronous beans.
5. Еще Over 9000 причин, связанных с реализацией и не связанных с архитектурой, которые могут быть выявлены профайлингом или стрессовым тестированием.
Вывод: низкая производительность зависит в большей мере от деталей реализации, нежели от выбранной архитектуры, о которых сложно судить, не обладая всем объемом информации.
1. На картинке обозначены 2 горлышка: Business Tier и Data Tier. Надо поправить, что с точки зрения архитектуры Business Tier не является узким местом в плане масштабирования, потому как не хранит общего состояния (shared state). J2EE архитектура изначально была задумана как распределенная. Добавить новый нод в Weblogic — пара щелчков мышкой в консоли. Остается только Data Tier.
2. Из картинки непонятна специфика работы интернет-магазина. Веб не только осуществляет транзакции, но также читает данные о продуктах из базы данных. И соотношение read/write запросов может достигать 10:1 (а реально намного больше). Поэтому грузит базу данных именно веб своими запросами на чтение. В этом случае поможет упомянутая прослойка в виде распределенного кеша, например Oracle Coherence. Чтобы архитектура была идентична представленному XAP, нужно добавить асинхронный сброс изменений в bb.dd, который увеличит производительность в десятки раз, однако в случае сбоя дает вероятность потерять целостность.
3. Бизнес логика. Обозначена одним блоком с кучей процессов внутри. А именно она определяет всю кухню. Если хреново написано — тут никакая архитектура не поможет. Задача магазина простая — операции со счетами и логистикой. Пара select-ов и update-ов. Здесь целое поле для оптимизации.
4. JMS. А нахрена он вообще здесь нужeн? MoM и JMS хороши для связи со сторонними системами, чтобы иметь наименьшую зависимость от них. Тут есть свои паттерны проектирования типа ESB. Внутри-то апликации зачем нужна асинхронность на каждом уровне, если все операции должны делаться внутри одной транзакции? Обычный remote EJB call или на крайняк WS! Пересылка каждого persistent-сообщения JMS делает как минимум 2 жестких апдейта в JMS persistence store. Поэтому скорость пересылки JMS невелика: benchmark Apache ActiveMQ давал около 1000 сообщений в секунду, что мало для системы, где все основано на JMS. Плюс геморрой с мониторингом всего этого. Если так нужна асинхронность, есть asynchronous beans.
5. Еще Over 9000 причин, связанных с реализацией и не связанных с архитектурой, которые могут быть выявлены профайлингом или стрессовым тестированием.
Вывод: низкая производительность зависит в большей мере от деталей реализации, нежели от выбранной архитектуры, о которых сложно судить, не обладая всем объемом информации.
Браво, отличный комментарий к статье!
От себя добавлю:
И если он действительно нужен, можно избежать бутылочного горлышка и здесь. Месседжинг месседжингу рознь! Опять же можно делать партиционирование/балансировку персистентных очередей(например при получении коннекта по JNDI). Можно использовать неперсистентный мессенджинг с репликой сообщения на N узлов для отказоустойчивости. Можно наконец забить на JMS и использовать связку zookeeper+curator для похожей функциональности(и даже партиционирование из нескольких кластеров zoo, т.к. при записи нужен кворум и подтверждения со всех узлов, что они записали сообщение в персистентный лог).
От себя добавлю:
4. JMS. А нахрена он вообще здесь нужeн?
И если он действительно нужен, можно избежать бутылочного горлышка и здесь. Месседжинг месседжингу рознь! Опять же можно делать партиционирование/балансировку персистентных очередей(например при получении коннекта по JNDI). Можно использовать неперсистентный мессенджинг с репликой сообщения на N узлов для отказоустойчивости. Можно наконец забить на JMS и использовать связку zookeeper+curator для похожей функциональности(и даже партиционирование из нескольких кластеров zoo, т.к. при записи нужен кворум и подтверждения со всех узлов, что они записали сообщение в персистентный лог).
Зависит опять же от специфики работы. Основная черта месседжинг-систем — это асинхронность, то есть работа по принципу отправил-и-забыл. Хорошо там, где это применимо: подписчики на события, слабо связанные компоненты системы, интерфейс со сторонними системами. Спорным решением проектирования здесь является паттерн request-reply, реализованный через асинхронную очередь. И явной ошибкой является его реализация в одной транзакции, несмотря на то, что JMS позволяет такое. Если нужна только распределенность и отказоустойчивость в рамках синхронного запроса, годится и обычный JNDI+EJB — большинство серверов умеют это делать прозрачно для клиента. Поэтому использовать JMS везде как универсальный транспорт для всей системы, на мой взгляд, плохая идея.
JMS везде как универсальный транспортбезусловно плохая идея. Еще один use case — задачи которые выполняются длительный промежуток времени, лучше оставить заявку на операцию через JMS.
Или же как вы писали про интеграционную часть со сторонними ситемами. А с помощью AMQP другие системы могут быть реализованы не только на java. Может быть выбрано такое решение по политическим требованиям. Например, комманда которая саппортит и масштабирует message-oriented middleware получает за это деньги из бюджета проекта, но при этом снимает с вашей комманды часть рисков)
JNDI+EJB могут быть тоже не очень уместны, если приложение написано как java standalone, что не редко бывает… В этом случае могут быть более удобная для системы связка сериализации данных и транспорта.
А где в итоге узкое место то было? Или его и не стали искать?
Если в оракловые сервера поставить памяти больше, чем данных на дисках, трёхзвенка всё равно будет работать сильно хуже, чем XAP? Если да, то почему?
Если в оракловые сервера поставить памяти больше, чем данных на дисках, трёхзвенка всё равно будет работать сильно хуже, чем XAP? Если да, то почему?
Горлышко бутылки в первую очередь была БД.
И добавлять еще инстансов проблему не решает. Оракл не рекомендует больше чем 16 инстансов — там дальше на их синхронизацию и локи будет больше тратиться времени чем то что можно будет выиграть. И решать проблему приходится аппликативно. То есть делать много разных схем и разбрасывать данные по машинам, что в принципе XAP дает out of the box. С той только разницой что оперативка еще и намного быстрее работает чем БД. И нет никакого ограничение сколько инстансов может быть.
И добавлять еще инстансов проблему не решает. Оракл не рекомендует больше чем 16 инстансов — там дальше на их синхронизацию и локи будет больше тратиться времени чем то что можно будет выиграть. И решать проблему приходится аппликативно. То есть делать много разных схем и разбрасывать данные по машинам, что в принципе XAP дает out of the box. С той только разницой что оперативка еще и намного быстрее работает чем БД. И нет никакого ограничение сколько инстансов может быть.
Дьявол, как обычно в деталях. На видео по вашей ссылке www.gigaspaces.com/xap-in-memory-computing-event-processing/Meet-XAP дьявол на 40-й секунде: achieving share nothing architecture. Если данные позволяют так сделать — то методов множество, начиная от агрессивного кеширования данных, которое вообще бесплатное, знай себе память доставляй. Можно шардировать в приложении, количество инстансов не будет лимитировано ничем. Если же данные не позволяют share nothing, то никакой XAP не поможет.
Ну и конечно же вывод ваш крайне странный. Живя в мире, где объём данных растёт экспоненциально, мы должны понимать, что данные никогда не будут помещаться в память. Если они помещаются — то это не BigData.
Ну и конечно же вывод ваш крайне странный. Живя в мире, где объём данных растёт экспоненциально, мы должны понимать, что данные никогда не будут помещаться в память. Если они помещаются — то это не BigData.
Несколько странно слышать про то, что оперативка работает принципиально быстрее БД. Если БД на той же машине и настроена, то она так же практически не обращается к жесткому диску (в идеале только на запись). Если же чисто в оперативке хранить, то теряем в надежности данных (бд сбрасывает на жесткий диск и понятным образом делаются бекапы).
16 инстансов не проблема, если делаем шарды. Что собственно и предполагает как основное архитектурное изменение XAP. Отдельно, недавно была статья про монстров с сотнями процессоров для БД (видимо, и для подобных случаев, только их за день не купишь).
Как бы это смешно не звучало, но шарды и MySQL (или PostgreSQL) спасли бы ситуацию с большой вероятностью (если бы были до инцидента). OpenSource DB, т.к. новые ноды бесплатно и не нужно оперативно за 1 час закупать в 2 раза больше лицензий (за бешенные деньги), чем есть сейчас. Они бы и шардинг потребовали бы раньше, т.к. в некоторых случаях все же хуже работают.
Ребята из Kohl были просто не готовы отмасштабировать систему до нужного уровня. Будь, условно, у них 1 месяц на подготовку, они бы и без всякого XAP придумали бы и отработали как при необходимости поднять производительность. Либо халатность, либо не дали денег на масштабирования до инцидента.
16 инстансов не проблема, если делаем шарды. Что собственно и предполагает как основное архитектурное изменение XAP. Отдельно, недавно была статья про монстров с сотнями процессоров для БД (видимо, и для подобных случаев, только их за день не купишь).
Как бы это смешно не звучало, но шарды и MySQL (или PostgreSQL) спасли бы ситуацию с большой вероятностью (если бы были до инцидента). OpenSource DB, т.к. новые ноды бесплатно и не нужно оперативно за 1 час закупать в 2 раза больше лицензий (за бешенные деньги), чем есть сейчас. Они бы и шардинг потребовали бы раньше, т.к. в некоторых случаях все же хуже работают.
Ребята из Kohl были просто не готовы отмасштабировать систему до нужного уровня. Будь, условно, у них 1 месяц на подготовку, они бы и без всякого XAP придумали бы и отработали как при необходимости поднять производительность. Либо халатность, либо не дали денег на масштабирования до инцидента.
Уф. Правильно ли я понял что каждый контейнер содержит свою БД (в ОЗУ и по сути является локальным отдельным законченным (не знаю как правильно назвать) сервисом. Далее данные БД со всех них бекапятися кудато в разные места. Вопрос. а на этих то отдельных сервисах в ОЗУ хранится одна БД котороая просто распределенная, или же у них у каждого своя. Как они синхронизируют все это между собой.
Ибо, к примеру склад у нас один на 10 товаров. И есть 10 таких отдельных веб сервисов. И как нам не продать лишнего, и как нам продать все что есть в случае отказов клиентов с приемлимым времение задержки.
Ибо, к примеру склад у нас один на 10 товаров. И есть 10 таких отдельных веб сервисов. И как нам не продать лишнего, и как нам продать все что есть в случае отказов клиентов с приемлимым времение задержки.
Очередной «silver bullet».
Теперь у универмагов Kohl самый быстрый отклик, но всех пофигу, потому что есть Amazon, Target, WallMart etc, а о универмагах Kohl я услышал в первый раз.
По архитектуре, хорошо разобрал Throwable.
От себя добавлю, такие картинки хорошо показывать на презентации менеджменту, потому как они люди внушаемые, им можно впарить всё что угодно, а здесь люди техничные и ясно что эта картинка не показывает ничего. Потому как у вас messageing server получает сообщения из космоса вестимо, потом гонит на бизнес слой, а слой презентации валит напрямую, нафига нам messenging слой?
Теперь у универмагов Kohl самый быстрый отклик, но всех пофигу, потому что есть Amazon, Target, WallMart etc, а о универмагах Kohl я услышал в первый раз.
По архитектуре, хорошо разобрал Throwable.
От себя добавлю, такие картинки хорошо показывать на презентации менеджменту, потому как они люди внушаемые, им можно впарить всё что угодно, а здесь люди техничные и ясно что эта картинка не показывает ничего. Потому как у вас messageing server получает сообщения из космоса вестимо, потом гонит на бизнес слой, а слой презентации валит напрямую, нафига нам messenging слой?
парни, мне тут к докладу готовиться, так что на остальные вопросы отвечу в воскресенье.
Вы лучше на JUG приходите — вживую поговорим. Остальным будет линк.
Вы лучше на JUG приходите — вживую поговорим. Остальным будет линк.
Сдается мне, если они элементарно не рассчитали нагрузку в праздник и не провели соответствующее нагрузочное тестирование, то облажались бы с абсолютно любой архитектурой, тут просто вопрос везения. А так идея, конечно, выглядит интересно, мне и самому нравятся самодостаточные юниты, но я далеко не уверен, что это подойдет прямо-таки любому проекту.
Спасибо вам за статью! Похоже на очередной маркетинговы bullshit.
Такое было с хадупом, когда менеджмент хавал агитацию и заставлял его втыкать во все дыры, потому что так работают yahoo и google. В не зависимости подходит оптимально или не подходит он для решения конкретной задачи.
Собственно обычный балансировщик + приложение учитывающее data affinity + датагрид. Gigaspaces конечно молодцы, респект за отличный маркетинг! И возможно можно продать свою экспертизу в «уникальной» технологии, читать курсы.
Я бы не стал привязываться в проекте к какой либо технологии/серверу/фреймворку. Лишь подходящая абстракция и архитектура которая оптимально решит задачу с учетом всех нефункциональных требований и их изменений в обозримом будущем!
А за абстракцией реализация на любом подходящем datagrid или шардированной базе с кешом, любой подходящий для задачи транспорт между узлами.
В итоге приложение будет легко переносить на другие сервера или вообще запускать в других типах контейнеров или даже просто как standalone приложение и даже часть компонентов может быть реализовано на более подходящем для подзадачи языке/технологии.
Такое было с хадупом, когда менеджмент хавал агитацию и заставлял его втыкать во все дыры, потому что так работают yahoo и google. В не зависимости подходит оптимально или не подходит он для решения конкретной задачи.
Собственно обычный балансировщик + приложение учитывающее data affinity + датагрид. Gigaspaces конечно молодцы, респект за отличный маркетинг! И возможно можно продать свою экспертизу в «уникальной» технологии, читать курсы.
Я бы не стал привязываться в проекте к какой либо технологии/серверу/фреймворку. Лишь подходящая абстракция и архитектура которая оптимально решит задачу с учетом всех нефункциональных требований и их изменений в обозримом будущем!
А за абстракцией реализация на любом подходящем datagrid или шардированной базе с кешом, любой подходящий для задачи транспорт между узлами.
В итоге приложение будет легко переносить на другие сервера или вообще запускать в других типах контейнеров или даже просто как standalone приложение и даже часть компонентов может быть реализовано на более подходящем для подзадачи языке/технологии.
Статья в целом хорошая, тема интересная, но деталей возможной реализации нет и сомнений конечно хватает. Буду ждать продолжения и развернутой дискуссии после конференции.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
XAP (Хреновая Архитектура Разоряет)