Комментарии 55
Насколько я знаю Gigaspaces продает XAP — то есть он не бесплатный, хотя вроде и не очень дорогой. Если хочешь я могу навести справки узнать сколько именно он стоит.
XAP работает не только с java, там как миниму есть еще и поддержка дот нета. Ruby — не уверен, скорее всего нет, но они постоянно расширяют горизонты, опять таки, если интересно могу узнать, когда они будут поддерживать и Ruby
XAP работает не только с java, там как миниму есть еще и поддержка дот нета. Ruby — не уверен, скорее всего нет, но они постоянно расширяют горизонты, опять таки, если интересно могу узнать, когда они будут поддерживать и Ruby
0
Соображения по Руби (если не вспоминать о JRuby) описал в комментарии ниже на странице. В целом, вполне можно собрать аналог на текущих инструментах и практиках для кластеризации. Писать нужно будет только скрипт как данные будут перетекать по нодам, но в любом случае это достаточно зависимая от проекта вещь. Понятно, что такой подход в теории технически может быть несколько менее оптимален, чем XAP (потребуется для такого же кол-ва запросов больше нод, но не учитывается стоимость лицензий и поддержки XAP), но пиковую нагрузку все равно сможет выдержать.
0
Вооооот. Вот это другое дело!
0
ХАБР – хреновая архитектура быстро разоряет )
+18
Во первых — спасибо автору за одну из первых толковых статей про XAP на русском. Сам я с полгода занимаюсь конкретно с Gigaspaces и параллельно с другими гридами(GridGain, Gemfire). Вопрос к автору — будет ли запись вашего выступления где то доступна? Тк я нахожусь очень далеко, а послушать очень хочется. И планируется ли продолжение статей про XAP?
+4
Поддерживаю! Очень хочется послушать, но нет возможности приехать.
0
Запись будет, JUG в этом году очень качественный, и запись будет на высоком уровне, по крайней мере так мне обещали :)
Как только ее зальют, я скину линк.
На счет продолжение статей про XAP, если будет время с удовольствием напишу еще, скажите только в каком направлении писать.
Как только ее зальют, я скину линк.
На счет продолжение статей про XAP, если будет время с удовольствием напишу еще, скажите только в каком направлении писать.
+1
0
Иной хабровчанин даже может решить, что такое решение способствует нездоровому смешиванию данных с логикой. Однако опыт показывает, что настоящих умельцев никакие слои не остановят и при наличии должных навыков, винегрет можно сделать, имея какую угодно «архитектуру»!
Грамотный подход…
+2
Интересно, конечно, еще посмотреть на декларативную часть.
0
То есть " живя в мире, где объём данных растёт экспоненциально" — нам стоит эти данные перенести в оперативку и наступит счастье? А стоимость оперативки точно будет падать экспоненциально для осуществления этого благого начинания?
+4
Данные, хранимые в оперативке, можно сориентировать таким образом, чтобы применялось сжатие. При этом, со случайным доступом. Существуют такие данные, которые эффективно сжимаются, например, какая-нибудь бизнес аналитика.
И, кстати, когда я смотрел некоторые вещи по SAP HANA, например, там объяснили, что стоимость памяти идёт из расчёта стоимости передачи 1 гигабайта данных в единицу времени. То есть с пропускной способностью плашки памяти вы передадите данные быстрее, чем SSD в пересчёте, допустим, на один доллар.
И, кстати, когда я смотрел некоторые вещи по SAP HANA, например, там объяснили, что стоимость памяти идёт из расчёта стоимости передачи 1 гигабайта данных в единицу времени. То есть с пропускной способностью плашки памяти вы передадите данные быстрее, чем SSD в пересчёте, допустим, на один доллар.
+1
А какая альтернатива?
Оперативка может и не экспоненциально дешевеет, но она в любом случае дешевле чем БД.
Понятно что можно взять бесплатную БД и тогда выйдет дешевле, причем существенно, так как жесткий диск дешевле оперативки.
Но мы же говорим про огромнные массивы данных. А тут каким нибудь дерби не отделаешься, а покупать у оракла лизенцию и саппорт выйдет намного дороже оперативки.
Оперативка может и не экспоненциально дешевеет, но она в любом случае дешевле чем БД.
Понятно что можно взять бесплатную БД и тогда выйдет дешевле, причем существенно, так как жесткий диск дешевле оперативки.
Но мы же говорим про огромнные массивы данных. А тут каким нибудь дерби не отделаешься, а покупать у оракла лизенцию и саппорт выйдет намного дороже оперативки.
0
производительность процов (раньше частоты, теперь количетство ядер) и пропускная способность шины тоже растут экспоненциально. Это компенсирует.
0
И я не совсем понял товарищей из Kohl’s… Я к сожалению ни разу не спец по системам на java, но почему было не добавить LoadBalancing какого-либо вида между веб-сервером и процессами + между процессами и данными? И спокойно остаться в рамках трёхзвенки, не создавая себе счастья от перехода на новую архитектуру?
-1
Судя по статье у них балансеры были. Было много серверов. Но не было мониторинга (какие сервисы начинают перегреваться и их нужно расширять). И не были готовы расширяться быстро (не было готовых современных образов для облачных систем и т.п.). Особенно не смогли бы масштабироваться, если у них покупные продукты есть на серверах.
В итоге большую часть покупателей обслужить не смогли.
Т.к. потеря 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 и занимаются.
+1
Непонятно тогда, зачем картинка со схемой архитектуры постулирует наличие «бутылочных горлышек» именно на передаче данных между слоями…
Про реальную проблему в мониторинге наверное соглашусь, на это серьёзно намекают слова «Более того, зачастую добавка дополнительных ресурсов в один из уровней (например, серверов БД) не только не поможет, но, наоборот, повысит время ожидания». То есть ребята не только не знали, куда вставлять новые ноды, но и не представляли, что это вообще вычисляемо :-)
Про реальную проблему в мониторинге наверное соглашусь, на это серьёзно намекают слова «Более того, зачастую добавка дополнительных ресурсов в один из уровней (например, серверов БД) не только не поможет, но, наоборот, повысит время ожидания». То есть ребята не только не знали, куда вставлять новые ноды, но и не представляли, что это вообще вычисляемо :-)
0
Так «бутылочные горлышки» можно решить 2-мя способами:
1) Выделить между блоками специализацию (ренжи), в том числе и отдельные физические каналы.
2) Если первого не хватит, то посадить блоки по возможности на 1 машину, чтобы выдавался только результат небольшой из такой системы.
Собственно, это сделано у них и описано у меня.
1) Выделить между блоками специализацию (ренжи), в том числе и отдельные физические каналы.
2) Если первого не хватит, то посадить блоки по возможности на 1 машину, чтобы выдавался только результат небольшой из такой системы.
Собственно, это сделано у них и описано у меня.
0
>>В результате, по данным гугла сегодня их сайт занимает одно из первых мест в мире по скорости выдачи страниц
Что не мудрене, т.к. их сайт выдаёт следующее:
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
— Я просто их сайт посмотреть хотел, что же там такого страшного, а там — тролфейс.жпг однако.
+6
Хабрэффект нагнул сайт — теперь и XAP стал бутылочным горлышком и надо что-то новое придумыать. Наверное, размещать по маленькому серверу сразу у каждого клиента :)
+5
промахнулся.
0
На самом деле вы спокойно можете пойти на сайт Kohls через американский ip. Т.к. заказ товаров с их сайта доступен только для некоторых стран, то, как и многие крупные интернет магазины — они просто ограничили доступ к ресурсу тем, кому недоступен заказ. Правильность данного решения оставим за рамками обсуждения данной статьи.
+3
То есть (is) теперь (now) рейтинг статьи (article) намного лучше (better)?
Но если статья перевод вчерашней на смишную (то есть смысл тот же), то у меня вопрос: а как происходит синхронизация данных между модулями (partitions)? То есть если всё в памяти и периодически синхронизируется в бэкенд (backend) то как обеспечивается что у всех модулей одни и те же данные?
В случае с магазином, это не критично, но допустим, сиистема обслуживает некую ММОРПГ и нужно, чтоб любые два игрока, оказавшись в одном контексте, видели одно и то же и всё время а не иногда.
Но если статья перевод вчерашней на смишную (то есть смысл тот же), то у меня вопрос: а как происходит синхронизация данных между модулями (partitions)? То есть если всё в памяти и периодически синхронизируется в бэкенд (backend) то как обеспечивается что у всех модулей одни и те же данные?
В случае с магазином, это не критично, но допустим, сиистема обслуживает некую ММОРПГ и нужно, чтоб любые два игрока, оказавшись в одном контексте, видели одно и то же и всё время а не иногда.
0
У объектов, которые загружаются в space(хранилище всех объектов) — есть поле RoutingId, по которому как раз определяется — в какой интсанс спейса будет задеплоен этот объект. Но, нужно учитывать — что у Gigaspaces есть 3 топологии — sync-replicated, async-replicated и partitioned-sync2backup. И только последняя из них поддерживает партиции.
+2
Извиняюсь — почему то отправился предыдущий комментарий недописанный. Дальше — полная версия моего ответа.
Нужно учитывать — что у 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. Вывод — синхронизация только без партиций.
+1
Давайте разберемся. Теорему 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 причин, связанных с реализацией и не связанных с архитектурой, которые могут быть выявлены профайлингом или стрессовым тестированием.
Вывод: низкая производительность зависит в большей мере от деталей реализации, нежели от выбранной архитектуры, о которых сложно судить, не обладая всем объемом информации.
+17
Браво, отличный комментарий к статье!
От себя добавлю:
И если он действительно нужен, можно избежать бутылочного горлышка и здесь. Месседжинг месседжингу рознь! Опять же можно делать партиционирование/балансировку персистентных очередей(например при получении коннекта по JNDI). Можно использовать неперсистентный мессенджинг с репликой сообщения на N узлов для отказоустойчивости. Можно наконец забить на JMS и использовать связку zookeeper+curator для похожей функциональности(и даже партиционирование из нескольких кластеров zoo, т.к. при записи нужен кворум и подтверждения со всех узлов, что они записали сообщение в персистентный лог).
От себя добавлю:
4. JMS. А нахрена он вообще здесь нужeн?
И если он действительно нужен, можно избежать бутылочного горлышка и здесь. Месседжинг месседжингу рознь! Опять же можно делать партиционирование/балансировку персистентных очередей(например при получении коннекта по JNDI). Можно использовать неперсистентный мессенджинг с репликой сообщения на N узлов для отказоустойчивости. Можно наконец забить на JMS и использовать связку zookeeper+curator для похожей функциональности(и даже партиционирование из нескольких кластеров zoo, т.к. при записи нужен кворум и подтверждения со всех узлов, что они записали сообщение в персистентный лог).
0
Зависит опять же от специфики работы. Основная черта месседжинг-систем — это асинхронность, то есть работа по принципу отправил-и-забыл. Хорошо там, где это применимо: подписчики на события, слабо связанные компоненты системы, интерфейс со сторонними системами. Спорным решением проектирования здесь является паттерн request-reply, реализованный через асинхронную очередь. И явной ошибкой является его реализация в одной транзакции, несмотря на то, что JMS позволяет такое. Если нужна только распределенность и отказоустойчивость в рамках синхронного запроса, годится и обычный JNDI+EJB — большинство серверов умеют это делать прозрачно для клиента. Поэтому использовать JMS везде как универсальный транспорт для всей системы, на мой взгляд, плохая идея.
0
JMS везде как универсальный транспортбезусловно плохая идея. Еще один use case — задачи которые выполняются длительный промежуток времени, лучше оставить заявку на операцию через JMS.
Или же как вы писали про интеграционную часть со сторонними ситемами. А с помощью AMQP другие системы могут быть реализованы не только на java. Может быть выбрано такое решение по политическим требованиям. Например, комманда которая саппортит и масштабирует message-oriented middleware получает за это деньги из бюджета проекта, но при этом снимает с вашей комманды часть рисков)
JNDI+EJB могут быть тоже не очень уместны, если приложение написано как java standalone, что не редко бывает… В этом случае могут быть более удобная для системы связка сериализации данных и транспорта.
0
А где в итоге узкое место то было? Или его и не стали искать?
Если в оракловые сервера поставить памяти больше, чем данных на дисках, трёхзвенка всё равно будет работать сильно хуже, чем XAP? Если да, то почему?
Если в оракловые сервера поставить памяти больше, чем данных на дисках, трёхзвенка всё равно будет работать сильно хуже, чем XAP? Если да, то почему?
0
Горлышко бутылки в первую очередь была БД.
И добавлять еще инстансов проблему не решает. Оракл не рекомендует больше чем 16 инстансов — там дальше на их синхронизацию и локи будет больше тратиться времени чем то что можно будет выиграть. И решать проблему приходится аппликативно. То есть делать много разных схем и разбрасывать данные по машинам, что в принципе XAP дает out of the box. С той только разницой что оперативка еще и намного быстрее работает чем БД. И нет никакого ограничение сколько инстансов может быть.
И добавлять еще инстансов проблему не решает. Оракл не рекомендует больше чем 16 инстансов — там дальше на их синхронизацию и локи будет больше тратиться времени чем то что можно будет выиграть. И решать проблему приходится аппликативно. То есть делать много разных схем и разбрасывать данные по машинам, что в принципе XAP дает out of the box. С той только разницой что оперативка еще и намного быстрее работает чем БД. И нет никакого ограничение сколько инстансов может быть.
+1
Дьявол, как обычно в деталях. На видео по вашей ссылке www.gigaspaces.com/xap-in-memory-computing-event-processing/Meet-XAP дьявол на 40-й секунде: achieving share nothing architecture. Если данные позволяют так сделать — то методов множество, начиная от агрессивного кеширования данных, которое вообще бесплатное, знай себе память доставляй. Можно шардировать в приложении, количество инстансов не будет лимитировано ничем. Если же данные не позволяют share nothing, то никакой XAP не поможет.
Ну и конечно же вывод ваш крайне странный. Живя в мире, где объём данных растёт экспоненциально, мы должны понимать, что данные никогда не будут помещаться в память. Если они помещаются — то это не BigData.
Ну и конечно же вывод ваш крайне странный. Живя в мире, где объём данных растёт экспоненциально, мы должны понимать, что данные никогда не будут помещаться в память. Если они помещаются — то это не BigData.
+3
Несколько странно слышать про то, что оперативка работает принципиально быстрее БД. Если БД на той же машине и настроена, то она так же практически не обращается к жесткому диску (в идеале только на запись). Если же чисто в оперативке хранить, то теряем в надежности данных (бд сбрасывает на жесткий диск и понятным образом делаются бекапы).
16 инстансов не проблема, если делаем шарды. Что собственно и предполагает как основное архитектурное изменение XAP. Отдельно, недавно была статья про монстров с сотнями процессоров для БД (видимо, и для подобных случаев, только их за день не купишь).
Как бы это смешно не звучало, но шарды и MySQL (или PostgreSQL) спасли бы ситуацию с большой вероятностью (если бы были до инцидента). OpenSource DB, т.к. новые ноды бесплатно и не нужно оперативно за 1 час закупать в 2 раза больше лицензий (за бешенные деньги), чем есть сейчас. Они бы и шардинг потребовали бы раньше, т.к. в некоторых случаях все же хуже работают.
Ребята из Kohl были просто не готовы отмасштабировать систему до нужного уровня. Будь, условно, у них 1 месяц на подготовку, они бы и без всякого XAP придумали бы и отработали как при необходимости поднять производительность. Либо халатность, либо не дали денег на масштабирования до инцидента.
16 инстансов не проблема, если делаем шарды. Что собственно и предполагает как основное архитектурное изменение XAP. Отдельно, недавно была статья про монстров с сотнями процессоров для БД (видимо, и для подобных случаев, только их за день не купишь).
Как бы это смешно не звучало, но шарды и MySQL (или PostgreSQL) спасли бы ситуацию с большой вероятностью (если бы были до инцидента). OpenSource DB, т.к. новые ноды бесплатно и не нужно оперативно за 1 час закупать в 2 раза больше лицензий (за бешенные деньги), чем есть сейчас. Они бы и шардинг потребовали бы раньше, т.к. в некоторых случаях все же хуже работают.
Ребята из Kohl были просто не готовы отмасштабировать систему до нужного уровня. Будь, условно, у них 1 месяц на подготовку, они бы и без всякого XAP придумали бы и отработали как при необходимости поднять производительность. Либо халатность, либо не дали денег на масштабирования до инцидента.
+4
Уф. Правильно ли я понял что каждый контейнер содержит свою БД (в ОЗУ и по сути является локальным отдельным законченным (не знаю как правильно назвать) сервисом. Далее данные БД со всех них бекапятися кудато в разные места. Вопрос. а на этих то отдельных сервисах в ОЗУ хранится одна БД котороая просто распределенная, или же у них у каждого своя. Как они синхронизируют все это между собой.
Ибо, к примеру склад у нас один на 10 товаров. И есть 10 таких отдельных веб сервисов. И как нам не продать лишнего, и как нам продать все что есть в случае отказов клиентов с приемлимым времение задержки.
Ибо, к примеру склад у нас один на 10 товаров. И есть 10 таких отдельных веб сервисов. И как нам не продать лишнего, и как нам продать все что есть в случае отказов клиентов с приемлимым времение задержки.
0
Очередной «silver bullet».
Теперь у универмагов Kohl самый быстрый отклик, но всех пофигу, потому что есть Amazon, Target, WallMart etc, а о универмагах Kohl я услышал в первый раз.
По архитектуре, хорошо разобрал Throwable.
От себя добавлю, такие картинки хорошо показывать на презентации менеджменту, потому как они люди внушаемые, им можно впарить всё что угодно, а здесь люди техничные и ясно что эта картинка не показывает ничего. Потому как у вас messageing server получает сообщения из космоса вестимо, потом гонит на бизнес слой, а слой презентации валит напрямую, нафига нам messenging слой?
Теперь у универмагов Kohl самый быстрый отклик, но всех пофигу, потому что есть Amazon, Target, WallMart etc, а о универмагах Kohl я услышал в первый раз.
По архитектуре, хорошо разобрал Throwable.
От себя добавлю, такие картинки хорошо показывать на презентации менеджменту, потому как они люди внушаемые, им можно впарить всё что угодно, а здесь люди техничные и ясно что эта картинка не показывает ничего. Потому как у вас messageing server получает сообщения из космоса вестимо, потом гонит на бизнес слой, а слой презентации валит напрямую, нафига нам messenging слой?
+4
парни, мне тут к докладу готовиться, так что на остальные вопросы отвечу в воскресенье.
Вы лучше на JUG приходите — вживую поговорим. Остальным будет линк.
Вы лучше на JUG приходите — вживую поговорим. Остальным будет линк.
+1
Сдается мне, если они элементарно не рассчитали нагрузку в праздник и не провели соответствующее нагрузочное тестирование, то облажались бы с абсолютно любой архитектурой, тут просто вопрос везения. А так идея, конечно, выглядит интересно, мне и самому нравятся самодостаточные юниты, но я далеко не уверен, что это подойдет прямо-таки любому проекту.
+1
Спасибо вам за статью! Похоже на очередной маркетинговы bullshit.
Такое было с хадупом, когда менеджмент хавал агитацию и заставлял его втыкать во все дыры, потому что так работают yahoo и google. В не зависимости подходит оптимально или не подходит он для решения конкретной задачи.
Собственно обычный балансировщик + приложение учитывающее data affinity + датагрид. Gigaspaces конечно молодцы, респект за отличный маркетинг! И возможно можно продать свою экспертизу в «уникальной» технологии, читать курсы.
Я бы не стал привязываться в проекте к какой либо технологии/серверу/фреймворку. Лишь подходящая абстракция и архитектура которая оптимально решит задачу с учетом всех нефункциональных требований и их изменений в обозримом будущем!
А за абстракцией реализация на любом подходящем datagrid или шардированной базе с кешом, любой подходящий для задачи транспорт между узлами.
В итоге приложение будет легко переносить на другие сервера или вообще запускать в других типах контейнеров или даже просто как standalone приложение и даже часть компонентов может быть реализовано на более подходящем для подзадачи языке/технологии.
Такое было с хадупом, когда менеджмент хавал агитацию и заставлял его втыкать во все дыры, потому что так работают yahoo и google. В не зависимости подходит оптимально или не подходит он для решения конкретной задачи.
Собственно обычный балансировщик + приложение учитывающее data affinity + датагрид. Gigaspaces конечно молодцы, респект за отличный маркетинг! И возможно можно продать свою экспертизу в «уникальной» технологии, читать курсы.
Я бы не стал привязываться в проекте к какой либо технологии/серверу/фреймворку. Лишь подходящая абстракция и архитектура которая оптимально решит задачу с учетом всех нефункциональных требований и их изменений в обозримом будущем!
А за абстракцией реализация на любом подходящем datagrid или шардированной базе с кешом, любой подходящий для задачи транспорт между узлами.
В итоге приложение будет легко переносить на другие сервера или вообще запускать в других типах контейнеров или даже просто как standalone приложение и даже часть компонентов может быть реализовано на более подходящем для подзадачи языке/технологии.
+2
Статья в целом хорошая, тема интересная, но деталей возможной реализации нет и сомнений конечно хватает. Буду ждать продолжения и развернутой дискуссии после конференции.
0
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
XAP (Хреновая Архитектура Разоряет)