Вторник, 26.09.2017, 13:52
Приветствую Вас Гость | RSS
Главная | Блог | Регистрация | Вход
Форма входа
Логин:
Пароль:
Поиск

Меню сайта

Категории раздела
Техническое [24]
Все о мейнфреймах и не только о них, но все-таки крепко связанное с техникой и инженерными моментами.
Разговорчики [24]
Обо всем остальном, не относящемся к технике.

Календарь
«  Июль 2015  »
ПнВтСрЧтПтСбВс
  12345
6789101112
13141516171819
20212223242526
2728293031

Архив записей

Наш опрос
О регистрации на сайте с помощью соцсетей.
Всего ответов: 12

Метки
EGL ODM бизнес правила программирование SOA arcati блоги журналы Каталог мейнфреймы журнал z/os Freeware VM bigdata nosql MVS OS zOS SLES zLinux мейнфрейм Хабрахабр 50лет документы хранилище Java EE liberty WebSphere history сообщение Форум DFSORT Hercules VSAM отчётность Linux Analytics Accelerator Netezza IMS IBM IDC продажа CHKPT GSam XRST гипервизор KVM Shutdown #hollywar mainframe Вакансии Санкт-Петербург пример Assembler LHI vs XR instruction to clear GPR z Seies CPU performance семинар впечатление доступность ЦБ цены аутсорсинг BMC CMS ZVM санкции Rockwell история z13 мобильность DB2 Java Coupling Facility Parallel Sysplex WebSphere AS MVT ОС ЕС ссср Tape VTL Вакансия БЛОГ Линукс Новое статьи Люксофт Польша Работа

Статистика

Главная » 2015 » Июль » 2 » in-memory, grid, и прочие чудеса технологий

in-memory, grid, и прочие чудеса технологий
12:14
Один российский банк построил удивительную систему. Она умудряется плохо работать на 256 ядрах мощного SMP сервера! Если система не может масштабироваться в рамках одного SMP сервера, то что надо делать? Правильно, попытаться запустить эту систему в кластере, это же очевидно! А заодно применить и кучу новых модных технологий. То есть и in-memory, и grid, и всё, что, по словам вендоров, повышает производительность без изменений архитектуры самой системы.
 
Вот, например, таких технологий.
http://habrahabr.ru/post/160517/
http://habrahabr.ru/post/126580/
 
Так получиться или нет? Делаем ставки?
 
Сразу сделаем оговорку - речь будет идти только о системах, для которых недопустимо потерять каждую транзакцию.
 
Теперь некоторые напоминание.
 
Память в компьютерах бывает энергозависимая, содержимое которой теряется при выключении питания, и энергонезависимая, содержимое которой сохраняется при выключении питания.
 
Энергонезависимая память почему-то имеет сильно худшие показатели по скорости доступа по сравнению с энергозависимой. На текущий момент.
 
Программы обрабатывают данные в энергозависимой памяти. Если данных там нет - они должны быть считаны с энергонезависимой памяти (если они тамхранились, само собой).
 
СУБД - тоже программы.
 
СУБД работают с данными в энергозависимой памяти.
 
Теперь вопрос - в чём принципиальная разница между in-memory СУБД и не in-memory СУБД? Мне кажется в том, что in-memory СУБД перед началом работы считывают с энергонезасивимой памяти 100% данных в эенергозависимую. А не in-memory СУБД считывают данные по мере необходимости. Само собой, в in-memory СУБД отсутсвуют всякие модули, отвечающие за поиск и считывание данных с энергонезависимой памяти, и записывания их обратно - в какой-то мере отсутствуют. Кстати, эффективность работы таких модулей с  энергонезависимой памятью сильно зависит от архитектуры сервера - на мейнфрейме с его канальной  архитектурой эффективность отличается от серверов с шинной архитиектурой, и значительно отличается.
 
Одно из назначений СУБД - обеспечение непротиворечивости данных. СУБД переводит данные из одного непротиворечивого состояния в другое. В том числе и в случае всяких сбоев, к которым может относится и пропадания электропитания. СУБД обязаны иметь возможность восстановить данные в непротиворечивое состояние при старте после сбоя. Для реализации этой возможности СУБД используют разные по названию механизмы, но все они используют запись в энергонезависимую память - и это очевидно. Если записи о транзакции нет в энергонезависимой памяти - нет возможности восстановить состояние после сбоя. Это в равной мере относится к in-memory и к не-in-memory СУБД. Здесь они в равных условиях.
 
Теперь grid, cloud, и всё, что угодно, укладывающиеся в страстное желание купить кучу дешёвых серверов вместо одного дорогого. Вообще-то, на транзакционных задачах кластер привносит дополнительные расходы и скорее будет снижать производительность, отнимая ресурсы на обеспечения работы кластера, чем повышать её. В одной из статей по ссылке предлагается использование двухфазной транзакции между узлами кластера. Двухфазная транзакция и в пределах одной машины изрядно снижает производительность, а уж по сети... В любом случае, на обслуживание кластера будут тратится ресурсы. Остаются и вопросы выхода узлов кластера из строя. Обеспечение отказоустойчивости потребует дополнительных расходов. В зависимости от технологии это могут быть разные расходы, но они неизбежно будут.
 
Использование сети снижает производительность и повышает затраты на обеспечения согласования всех узлов между собой.
 
Если коротко, то ситуация описывается очень старыми терминами:
- кошмар межнодового обмена
- split brain. 
 
Полагать, что транзакционная система, плохо работающая на одном SMP сервере, будет прекрасно работать в каком-либо типе кластера - это верх наивности.
 
Как-то так, если на-коротке.
 
А то одновременно нескольким человекам пришлось отвечать про одно и то же. А теперь вот можно просто дать ссылку на мои мысли, и на критику оппонентов, которые, я надеюсь, не заставят себя ждать.
 
Надел каску и залез под стол, в ожидании швыряемых табуреток.
Категория: Техническое | Просмотров: 846 | Добавил: ggv | Рейтинг: 0.0/0 |


Всего комментариев: 9
3  
А если говорить не о СУБД, а о стейтлесс задачах: кластер серверов приложений с бизнес-логикой например? Сплитбрейн и прочие нечисти могут проявиться только при обновлении кода приложений, да собственно кроме кода на таком кластере может больше ничего и не быть.

4  
Чтобы небыло "а если", я специально в самом начале, сделал оговорку - речь будет идти только о системах, для которых недопустимо потерять каждую транзакцию.
А все прочие системы, решающие в том числе и задачи расчёта параметров ядерного взрыва, схлопывания вселенной, и так далее, в данный контекст обсуждения не входят.
Их можно обсудить в другом контексте.

7  
В рассматриваемой системе хотят вообще СУБД заменить на in-memory БД или все же задействовать in-memory только для read-only данных (как пример, но не ограничиваясь, НСИ)? А то вот мне не понятно, например, зачем серверу приложений постоянно обращаться к БД, за теми же справочниками клиентов, а не сохранить его в кэше. Ну а если ребут, то да - прочитаем с диска и наполним кеш.

Хотя, я думаю, посыл поста был не в том, что in-memory плох, а в том зачем кластер, если все можно в одном ящике, тем более довольно мощном (мне кажется к 256 ядер должно и соответственно памяти прилагаться). Если я правильно понял, то полностью согласен, да и вообще очевидные во многом вещи-то.

З.Ы. Помню, когда еще плотно занимался WebLogic, Oracle предалагала идею очередей сообщений без персистентности на диск, а с сохранением в распределенный кэш. Т.е. идея в том, что у нас несколько десятков серверов и, если вероятность отказа всех одновременно очень мала (ну там резервирование по питанию и т.д.), то зачем использовать энергонезависимую память, если можно просто резервировать сообщения в энергозависимойпамяти на других машинах (хотя и по сети, что наверное даже медленнее, чем диск). Но вот не взлетело, такой реализации JMS (АПИ Java для работы с очередями сообщений) мы так и не дождались.

9  
любое изделие  in-memory СУБД имеет смысл в том случае, когда запросы на чтение значительно, очень значительно преобладают перед запросами на внесение/изменение данных, иначе журнал транзакций уровняет условия. Как верно подмечено - случай НСИ. Но не транзакционные системы.

Посыл был в том, что лучшая в смысле производительности и эффективности транзакционная система на планете на текущий момент одна, это IBM  IMS в одном экземпляре, не в кластере, её результат пока никем не превзойдён, имхо. Там интересное соотношение по типу запросов.
Но как утверждают специалисты лаборатории IMS - значительное превосходство платформы можно продемонстрировать в самых тяжёлых условиях - выполняя update данных.

2  
я там накосячил - поправил вот эту фразу
СУБД работают с данными в энергозависимой памяти.
конечно же в энергозависимой, в оперативной памяти должны быть данные.
на скорую руку писал, вот и накосячил.
Если не умничать - мало суметь поднять все данные в оперативную память, это никоим образом не снимает задач по обеспечению восстановления после сбоя, а значит писать на диск придётся, и предельная скорость системы будет зависеть от предельной скорости записи на диск структуры, обеспечивающей восстановление после сбоя, типа журнала транзакций.

0
1  
А вы говорите, что "нет приличных специалистов в стране". Есть! Есть приличные специалисты! Смогли же построить систему, которая плохо работает на 256-ядерной установке! А это задача не каждому по плечу! Слава Всевышнему, есть чем нам ответить всяким злопыхателям. И пусть они заранее трепещут!...

По существу. Я что-то давно не встречал тех, кто надеются, что кластер будет работать быстрее, чем ящик. Кластер работает лучше только в случае, когда (по разным причинам) начинает иметь значение скорость переключения контекста адресного пространства, и в тестируемой системе это делается слишком расходно. Кластер в таком случае просто позволяет уменьшить количество таких переключений. Но это реликтовая на сегодняшний день ситуция, рассматривать ее, я думаю, не имеет смысла.

И конечно, кластера лучше продаются, а это, батенька, аргумент такой, что всем аргументам аргумент!

5  
а другие специалисты сейчас будут объяснять, что надо заменить шило на мыло, ПО одного вендора на типичное ПО другого вендора...
Кстати, аппаратуру так уже меняли, убедили, что дело в сервере, вендор не тот...
Не помогло, как ни странно.
Заказчик, кажется, стал что-то подозревать, и уже не хочет менять шило на мыло.
Но пока надеется на серебряные пули.

6  
вот сравнение скорости переключения контекста супротив скорости сетевого взаимодействия в кластере я бы с удовольствием послушал.
Кластер выигрывает только тогда, когда задача замечательно параллелится и отдельные подзадачи не пересекаются по данным. Тогда да, бинго и кластер. Взаимодействие между нодами сведено к минимуму, данные на каждом узле кластера свои... Если задача не параллелится, или есть необходимость работы с одними и теми же данными на разных узлах в одно и то же время, то кластерная инфраструктура начинает усложнятся, накладные расходы возрастать, что неизбежно ведёт к проигрышу одному серверу
ИМХО.

8  
Про что я и писал в первом ответе, но подумал, что если есть распределенные транзакции, то сервер приложений начинает ими управлять, т.е. появляется все то же самое: лог транзакций вместе с сопутствующими накладными расходами и обращениями к диску (собственно на практике именно это и наблюдали постоянно - самое узкое место при работе сервера приложений в бою на дистрибьютед платформах даже не память или там процессор, а диск).

Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]


Яндекс.Метрика