читаю
IBM DB2 11 for z/OS, currently in an early support program, provides support for integration with IBM InfoSphere BigInsights (IBM's implementation of Hadoop). IBM Cognos or DB2 for z/OS can invoke predefined HDFS JAQL queries. Even though these might run elsewhere in the enterprise, DB2 for z/OS can retrieve the result sets from the InfoSphere BigInsights environment and load them into DB2 for z/OS tables for integration with the data warehouse and further analysis using the IBM business analytics solutions mentioned previously. There are many similar use cases for IMS.
есть прослойка для интеграции, само решение - отдельный от МФ продукт, который по понятным причинам не имеет смысла иметь на МФ. собственно весь документ лишь об этом.
.....
В этом Вашем источнике много что написано, главным образом о давней уже готовности МФ для "big data". Вы как обычно выбрали цитату подходящую для того чтобы слепить очередную какашку и бросить ее в МФ.
А там есть и вот такое мнение:
Most of the buzz regarding big data has been about Hadoop, but Hadoop is batch
oriented and so is not suitable for immediate analysis of streaming data. Also, as a
program execution environment, it has no built - in data management features; these
are left as exercises to the developers. Therefore, for data collections that require
consistency and order, Hadoop can act as an ingestion point but would be a very
poor manager. When we consider the different kinds of data to be analyzed and the
varied needs for both depth of analysis and speed of delivery of that analysis, it
should be clear that Hadoop is simply not the answer to all big data needs.
P.S. С чего Вы взяли что там была только консолидация файл-серверов? Это я о консолидации в ИБМ на МФ. У Вас есть очередной источник какашек? Вам самому не противно в г..не капатьстя?
flip_flop wrote:Я прочитал об аннонсировании х86 64 бит (тогда блистательной АМД) ещё на исторической родине, в 1999 году. По приезду в страну победившего капитализма, в том же 1999 году, начал работать на 64 битных спарках, вначале на HP, затем на популярной тогда Sun Solaris. Технологии 20-го века.
А что собственно в этой технологии революционного? Первые компьютеры с 64-bit архитектурой появились в 70-е.
Революционного - ничего. А вот доступность для масс - великое дело.
P.S. К тому же залог более революционных технологий сейчас, типа "in memory database, in memory analytics" Переход количественных изменений в качественные
Ответ ожидаемый, но положа руку на сердце Вы ведь тоже согласитесь что это не более чем количественное изменение, кстати, принесшее вместе с новыми горизонтами дополнительный overhead. И например на моем шоркстатион с 2 GB совсем не нужно.
В начале 90-х у IBM была модель MF с реальной памятью 9 GB. А адресация была 31-bit. Но была и Extended memory обмен между которой и main memory осуществлялся 4 KB страницами одной машинной командой. Мы, в начале 2000-x работая на 31-bit системе (т.е. 2 GB прымой адресации) размещали многие GB-ты таблиц DB2 в Extended memory и Data spaces, которые в Extended memory материализовались. С перехом на 64-bit это все просто ушло в небытие, но ничего такого качественно мы не получили строго говоря, просто все эти таблице "в памяти" теперь находятся в одном адресном пространстве DB2 engine s 64-bit адресацией.
Нa MF с целью избежать overhead рекомендуется не увлекаться 64-bit. Думаю тоже справедливо на других платформах.
flip_flop wrote:Я прочитал об аннонсировании х86 64 бит (тогда блистательной АМД) ещё на исторической родине, в 1999 году. По приезду в страну победившего капитализма, в том же 1999 году, начал работать на 64 битных спарках, вначале на HP, затем на популярной тогда Sun Solaris. Технологии 20-го века.
А что собственно в этой технологии революционного? Первые компьютеры с 64-bit архитектурой появились в 70-е.
Революционного - ничего. А вот доступность для масс - великое дело.
P.S. К тому же залог более революционных технологий сейчас, типа "in memory database, in memory analytics" Переход количественных изменений в качественные
Ответ ожидаемый, но положа руку на сердце Вы ведь тоже согласитесь что это не более чем количественное изменение, кстати, принесшее вместе с новыми горизонтами дополнительный overhead. И например на моем шоркстатион с 2 GB совсем не нужно.
В начале 90-х у IBM была модель MF с реальной памятью 9 GB. А адресация была 31-bit. Но была и Extended memory обмен между которой и main memory осуществлялся 4 KB страницами одной машинной командой. Мы, в начале 2000-x работая на 31-bit системе (т.е. 2 GB прымой адресации) размещали многие GB-ты таблиц DB2 в Extended memory и Data spaces, которые в Extended memory материализовались. С перехом на 64-bit это все просто ушло в небытие, но ничего такого качественно мы не получили строго говоря, просто все эти таблице "в памяти" теперь находятся в одном адресном пространстве DB2 engine s 64-bit адресацией.
Нa MF с целью избежать overhead рекомендуется не увлекаться 64-bit. Думаю тоже справедливо на других платформах.
Скорее не соглашусь. Выход за пределы 2 ГБ открывает дверь новым горизонтам, как количественным так и качественным. Например, "in memory database and analytics" ускоряет обработку данных в десятки-сотни раз, особенно для Биг Дата (Биг не в смысле количества, а в смысле качества, Биг разнообразие источников данных и их форматов). Сочетание быстрых Биг Дата и HPC делает возможным и практически целесообразным целый спектр полезных для общества приложений. Предложение оставаться в пределах 2 ГБ (не увлекаться 64 битными приложениями) - даже не знаю что сказать. Может быть для мира МФ имеет смысл. Для других платформ - "это несерьёзно" как минимум. Даже телефоны вышли за эти пределы.
Допущение справедливости рекомендации не увлекаться 64 бит для всех платформ, по моему мнению, как ничто иное характеризует мир МФ. "Я всё сказал, хау"
flip_flop wrote:
Сабина, я помню Ван нравилось на МФ вначале, не то что всем известный ширпотреб типа Оракла, индийцев не было и вообще круто. А теперь чего так? Мне просто интересен "глас народа"
Проэкт был интересен скорее в контексте того как поставленная задача была решена, а поставленная задача была "запустить цивилизованный апп на старом хламе", потому что этого хлама у некоторых компаний много и выкинуть совсем еще не готовы.
Отдельную прелесть проэкту придавал архитектор и команда с которыми было здорово работать.
Все вышесказанное не отменяет факта что хлам надо называть хламом, а не воспевать как альтернативу или superior to big data technologies
flip_flop wrote:Я прочитал об аннонсировании х86 64 бит (тогда блистательной АМД) ещё на исторической родине, в 1999 году. По приезду в страну победившего капитализма, в том же 1999 году, начал работать на 64 битных спарках, вначале на HP, затем на популярной тогда Sun Solaris. Технологии 20-го века.
А что собственно в этой технологии революционного? Первые компьютеры с 64-bit архитектурой появились в 70-е.
Революционного - ничего. А вот доступность для масс - великое дело.
P.S. К тому же залог более революционных технологий сейчас, типа "in memory database, in memory analytics" Переход количественных изменений в качественные
Ответ ожидаемый, но положа руку на сердце Вы ведь тоже согласитесь что это не более чем количественное изменение, кстати, принесшее вместе с новыми горизонтами дополнительный overhead. И например на моем шоркстатион с 2 GB совсем не нужно.
В начале 90-х у IBM была модель MF с реальной памятью 9 GB. А адресация была 31-bit. Но была и Extended memory обмен между которой и main memory осуществлялся 4 KB страницами одной машинной командой. Мы, в начале 2000-x работая на 31-bit системе (т.е. 2 GB прымой адресации) размещали многие GB-ты таблиц DB2 в Extended memory и Data spaces, которые в Extended memory материализовались. С перехом на 64-bit это все просто ушло в небытие, но ничего такого качественно мы не получили строго говоря, просто все эти таблице "в памяти" теперь находятся в одном адресном пространстве DB2 engine s 64-bit адресацией.
Нa MF с целью избежать overhead рекомендуется не увлекаться 64-bit. Думаю тоже справедливо на других платформах.
Скорее не соглашусь. Выход за пределы 2 ГБ открывает дверь новым горизонтам, как количественным так и качественным. Например, "in memory database and analytics" ускоряет обработку данных в десятки-сотни раз, особенно для Биг Дата (Биг не в смысле количества, а в смысле качества, Биг разнообразие источников данных и их форматов). Сочетание быстрых Биг Дата и HPC делает возможным и практически целесообразным целый спектр полезных для общества приложений. Предложение оставаться в пределах 2 ГБ (не увлекаться 64 битными приложениями) - даже не знаю что сказать. Может быть для мира МФ имеет смысл. Для других платформ - "это несерьёзно" как минимум. Даже телефоны вышли за эти пределы.
Допущение справедливости рекомендации не увлекаться 64 бит для всех платформ, по моему мнению, как ничто иное характеризует мир МФ. "Я всё сказал, хау"
Вы меня не до конца поняли. Во времена 31-bit адресации мы, на MF, не были ни в коей мере ограниченны 2-мя GB. Просто механизм доступа к памяти "beyond" 2 GB был не прямой, но данные могли находиться в меморы все равно. Я не знаю точно но вероятно overhead непрямого доступа не превышал overhead-а на 64-bit. А overhead этот не зависим от платформы. Он есть везде кроме систем не использующих виртуальной памяти.
zVlad wrote:
Вы меня не до конца поняли. Во времена 31-bit адресации мы, на MF, не были ни в коей мере ограниченны 2-мя GB. Просто механизм доступа к памяти "beyond" 2 GB был не прямой, но данные могли находиться в меморы все равно. Я не знаю точно но вероятно overhead непрямого доступа не превышал overhead-а на 64-bit. А overhead этот не зависим от платформы. Он есть везде кроме систем не использующих виртуальной памяти.
Конечно соглашусь что везде есть накладные расходы (64 vs 32), но преимущества с лихвой покрывают недостатки для больших задач. В условиях дешёвой доступной памяти - грех этим не воспользоваться и не утилизировать повышенный объём памяти для более высокой производительности.
flip_flop wrote:
Сабина, я помню Ван нравилось на МФ вначале, не то что всем известный ширпотреб типа Оракла, индийцев не было и вообще круто. А теперь чего так? Мне просто интересен "глас народа"
Проэкт был интересен скорее в контексте того как поставленная задача была решена, а поставленная задача была "запустить цивилизованный апп на старом хламе", потому что этого хлама у некоторых компаний много и выкинуть совсем еще не готовы.
Отдельную прелесть проэкту придавал архитектор и команда с которыми было здорово работать.
Все вышесказанное не отменяет факта что хлам надо называть хламом, а не воспевать как альтернативу или superior to big data technologies
Извращение какое-то. Другого не скажешь. Я бы в таком проекте побрезговал участвовать. И Вам, могу с уверенностью сказать, очень ловко заср-ли мозги. Так ловко что Вы другим их теперь засер-eте.
zVlad wrote:
Вы меня не до конца поняли. Во времена 31-bit адресации мы, на MF, не были ни в коей мере ограниченны 2-мя GB. Просто механизм доступа к памяти "beyond" 2 GB был не прямой, но данные могли находиться в меморы все равно. Я не знаю точно но вероятно overhead непрямого доступа не превышал overhead-а на 64-bit. А overhead этот не зависим от платформы. Он есть везде кроме систем не использующих виртуальной памяти.
Конечно соглашусь что везде есть накладные расходы (64 vs 32), но преимущества с лихвой покрывают недостатки для больших задач. В условиях дешёвой доступной памяти - грех этим не воспользоваться и не утилизировать повышенный объём памяти для более высокой производительности.
Прерываюсь на пару дней, работать надо
Речь то вовсе не идет о том чтобы отказываться от "повышенного обьема памяти". Ну да ладно работайте, мне и самому не грeх поработать и избавиться от омерзения вызванного некоторыми патентованными недоумками.
zVlad wrote:
В этом Вашем источнике много что написано, главным образом о давней уже готовности МФ для "big data". Вы как обычно выбрали цитату подходящую для того чтобы слепить очередную какашку и бросить ее в МФ.
в этом источнике попытка натянуть гондон на глобус. нет у МФ биг дата решений, это источник признает и предлагает натягивать разнородные данные на старую добрую реляционную модель db2 . причем кастрированного db2/zOS где даже xml сториджа на тот момент не было. второй вариант юзать МФ как прослойку к нормальному источнику вне МФ.
zVlad wrote: P.S. С чего Вы взяли что там была только консолидация файл-серверов?
поскольку вы не понимаете, что биг дата это вовсе не большая база вы не потянете объяснения...
zVlad wrote: Нa MF с целью избежать overhead рекомендуется не увлекаться 64-bit. Думаю тоже справедливо на других платформах.
не верно. клиенты МФ вынуждены экономить каждый байт памяти из-за ее цены. на современных платформах экономить пару килобайтов нет никакого смысла.
