Не знаю как для удаленного доступа, это все таки редкий кейс, а вот я для себя увидел неплохую альтернативу для включения логирования работы с инстансом через LoggingProxy. Не замеряли насколько такая штука «просаживает» производительность?
Не замерял. В CPU-intensive алгоритма, такое опосредованное использование свойств будет видно. Вопрос в том, что, кроме собственно вызова свойства или метода, исполняется в данном коде. Если "полезный эффект" (например работа с глобалами) составляет существенную часть времени, но и 2ой уровень вызова будет не очень заметен. Собственно, проброс переменного количества аргументов Logs… достаточно оптимизирован. Также как и $property и $method и $classmethod.
Хорошее замечание -да, для того, чтобы геттер отличить от сеттера в логе, имеет смысл протоколировать их по разному. Например так:
Method %DispatchGetProperty(Property As %String)
{
#dim Value as %String = $property(..OpenedObject, Property)
do ..LogArgs("Get "_Property, Value)
return Value
}
Method %DispatchSetProperty(Property, Value As %String)
{
do ..LogArgs("Set "_Property, Value)
set $property(..OpenedObject, Property) = Value
}
Давайте вернемся к основам: парадигма MapReduce работает в пакетном (batch) режиме. Пока текущая стадия не закончит обработку, следующая стадия конвейера не запустится. Для очень больших объемов чанка вы такого не хотите. Вы хотите много, разумного размера чанков, или, если нет возможности нарезать данные на чанки, то вы хотите поточный режим. Это уже не MapReduce, т.е. как минимум не его оригинальная реализация.
Если нужна поточная реализация (и вы пишете на Java) то вам в Spark Streaming или Apache Storm. Если вы про Си++, то увы, и MapReduce реализации у вас нет, не говоря про streaming реализацию (ждем публичного релиза Yandex YT как-нибудь в будущем, тогда появится всё). Если же вы про InterSystems Caché ObjectScript, то продолжайте читать данную серию. (Вторая часть, третья часть) Там будет и поточный режим.
БигДата в данном случе не бесконечной длины поток сознания, а большое количество файлов конечного размера (пусть и достаточно большого). При создании системы надо попытаться сбалансировать количество параллельных обработчиков, размер чанка (чем больше тем лучше, но не больше чем), и накладные расходы на планировщик (при маленьких чанках у нас не останется времени на полезную работу — одни функции планировщика и мастера).
Здравый смысл подсказывает, что если входные данные расположены в файлах, то проще всего отдавать отдельному обработчику на стадии отображения файл полностью.
(Главное, не пытаться запихнуть весь файл в память, ни к чему это.)
(Очень странно мы от MapReduce вырулили на [неизвестные мне] eCQM и QRDA), ну раз уж зашел разговор, и раз никто из московских специалистов по InterSystems HealthShare или TrakCaare в общем, и по HL7 в частности не ответил, то попытаюсь вывести дискусиию на более освещенное место.
Я прошелся по страницам с описанием eCQM и QRDA и насколько понял это для обмена информации метрокой о качестве (чего? услуг?). Вроде как звучит релевантно тому, что делал бы модуль HealthShare Information Exchange, но легкий гуглинг ничего похожего не принес. С другой стороны, это может быть более релевантно другому продукту InterSystems — TrakCare но и там ничего похожего вроде бы не видно ( logist ?).
Потому вопрос, Wayfarer15, объясните мне несведущему что это такое и почему это должно быть релевантно MapReduce?
Я не являюсь большим специалистом по InterSystems HealthShare, но с большой долей вероятности могу предположить, что там еще не используется ни MapReduce в описываемой мной конфигурации (который является моим собственным pet project), ни будущий sharding. Т.к. они не могут полагаться на невыпущенный еще продукт. И средства масштабирования должны быть из текущего арсенала (зеркалирование, ECP, и все такое)
В статье Марка Болинского про развертывание на Azure https://community.intersystems.com/post/intersystems-example-reference-architecture-microsoft-azure-resource-manager-arm можно увидеть пример архитектуры как TrakCare так и HealthShare в облаке. Очень показательно.
Самые нетерпеливые могут посмотреть код в репозитории GitHub/cache-map-reduce и собственно примеры будут из пакетов MR.Sample.WordCount и MR.Sample.AgeAverage.
Почему всё? Слухи и смерти MapReduce слегка преувеличены. И пока за ним такие большие игроки, как Яндекс, пусть и с изменениями и улучшениями, парадигма будет жить.
Здесь же («хороша ложка к обеду») речь шла про то, как плотно пошли статьи, моя — вчера, и из Яндекса сегодня. Что, опять же, свидетельствует о том, что технология еще актуальна и о ней говорят и её применяют.
Как известно, «хороша ложка к обеду», и, по счастливому стечению обстоятельств, maxim_babenko из Яндекса сегодня опубликовал описание их системы MapReduce https://habrahabr.ru/company/yandex/blog/311104/
Потому что это не библиотека, это сервис. Чтобы он хорошо работал и был удобным, нужен огромный кусок инфраструктуры: планировщик задач, система управления ресурсами, система развёртывания приложений, распределённая файловая система, системы мониторинга и половина стандартной библиотеки впридачу.
Вот, кстати, нет. Это именно библиотека, которая может основываться на инфраструктуре (определенная распределенная файловая система, или развертывание приложений), а может быть и абстрагиована от всего этого. Как я покажу в остальных статьях серии, MapReduce остаётся MapReduce дже если у него вынуть GFS или HDFS и пользовться другими средствами доставки данных в кластере.
(В-общем и целом, если бы Google выложил MapReduce только как библиотеку, то сообщество нашло бы чем заменить инфраструктуру. Но чего уж тут. Нет так нет)
Конечно же речь о самой парадигме, и путях прихода её в индустрию. Но так уж получилось, что в 2004 году речь шла о Си++ реализации в Google, а в 2006 Hadoop был выпущен с Java реализацией. Вполне, даже, допускаю, что Яндекс свою Си++ реализацию написл примерно в тот же временной период.
Но, к сожалению, ни Google, ни Яндекс, не опубликовали Си++ реализации, и народу оставалось играться на Java. (Вы только представьте себе, какой другой, «более лучшей» была бы индустрия HPC/BigData если бы изначально у народа были бы доступны C++ библиотеки для масштабирования bigdata решений. Но, история не терпит сослагательного наклонения, и мы рабоиаем на чем работаем)
Да libicu — правильный подход получить Unicode независимо от операционной системы. Но уж больно толстый! Одним неверным движением, просто за счет 3х dll-ек, ты добавляешь 15МБ добра.
Ребята, это все ужасно. Overdesign, over complicated.
Если надо параметризовать через аргументы или с интерактивом установку чего-то, то используем %Installer.Manifest и генерируемую функцию вызываем из командной строки с аргументами или спрашивая о них.
Если есть возможность инсталлироваться никого не спрашивая, то используем проекции. Если надо что-то спросить, см. пункт 1
P.S.
%Installer.Manifest хорошо интегрируется в пользовательские установщики (которые могут быть с GUI и похожими пирогами).
Не замерял. В CPU-intensive алгоритма, такое опосредованное использование свойств будет видно. Вопрос в том, что, кроме собственно вызова свойства или метода, исполняется в данном коде. Если "полезный эффект" (например работа с глобалами) составляет существенную часть времени, но и 2ой уровень вызова будет не очень заметен. Собственно, проброс переменного количества аргументов Logs… достаточно оптимизирован. Также как и $property и $method и $classmethod.
Хорошее замечание -да, для того, чтобы геттер отличить от сеттера в логе, имеет смысл протоколировать их по разному. Например так:
Если нужна поточная реализация (и вы пишете на Java) то вам в Spark Streaming или Apache Storm. Если вы про Си++, то увы, и MapReduce реализации у вас нет, не говоря про streaming реализацию (ждем публичного релиза Yandex YT как-нибудь в будущем, тогда появится всё). Если же вы про InterSystems Caché ObjectScript, то продолжайте читать данную серию. (Вторая часть, третья часть) Там будет и поточный режим.
Здравый смысл подсказывает, что если входные данные расположены в файлах, то проще всего отдавать отдельному обработчику на стадии отображения файл полностью.
(Главное, не пытаться запихнуть весь файл в память, ни к чему это.)
Редкий случай, когда я согласен с большинством комментаторов на Youtube. Почти 16 минут «ни о чем».
Я прошелся по страницам с описанием eCQM и QRDA и насколько понял это для обмена информации метрокой о качестве (чего? услуг?). Вроде как звучит релевантно тому, что делал бы модуль HealthShare Information Exchange, но легкий гуглинг ничего похожего не принес. С другой стороны, это может быть более релевантно другому продукту InterSystems — TrakCare но и там ничего похожего вроде бы не видно ( logist ?).
Потому вопрос, Wayfarer15, объясните мне несведущему что это такое и почему это должно быть релевантно MapReduce?
В статье Марка Болинского про развертывание на Azure https://community.intersystems.com/post/intersystems-example-reference-architecture-microsoft-azure-resource-manager-arm можно увидеть пример архитектуры как TrakCare так и HealthShare в облаке. Очень показательно.
Примеры — пожалуйста!
Самые нетерпеливые могут посмотреть код в репозитории GitHub/cache-map-reduce и собственно примеры будут из пакетов
MR.Sample.WordCountиMR.Sample.AgeAverage.Здесь же («хороша ложка к обеду») речь шла про то, как плотно пошли статьи, моя — вчера, и из Яндекса сегодня. Что, опять же, свидетельствует о том, что технология еще актуальна и о ней говорят и её применяют.
Вот, кстати, нет. Это именно библиотека, которая может основываться на инфраструктуре (определенная распределенная файловая система, или развертывание приложений), а может быть и абстрагиована от всего этого. Как я покажу в остальных статьях серии, MapReduce остаётся MapReduce дже если у него вынуть GFS или HDFS и пользовться другими средствами доставки данных в кластере.
(В-общем и целом, если бы Google выложил MapReduce только как библиотеку, то сообщество нашло бы чем заменить инфраструктуру. Но чего уж тут. Нет так нет)
Но, к сожалению, ни Google, ни Яндекс, не опубликовали Си++ реализации, и народу оставалось играться на Java. (Вы только представьте себе, какой другой, «более лучшей» была бы индустрия HPC/BigData если бы изначально у народа были бы доступны C++ библиотеки для масштабирования bigdata решений. Но, история не терпит сослагательного наклонения, и мы рабоиаем на чем работаем)
P.S.
%Installer.Manifest хорошо интегрируется в пользовательские установщики (которые могут быть с GUI и похожими пирогами).