Я учился в гуманитарной школе (с углубленным изучением немецкого языка), ни на какие олимпиады по языкам нас ни разу не посылали.
За все десять лет обучения мне довелось с приятелем побывать лишь на олимпиаде по химии :)
Тут мы привязаны к софту и его разработчикам. И я думаю, IBM не станет менять архитектуру софта в пользу RAC, потому что текущая архитектура уже проверена временем и хорошо работает.
Смена архитектуры откинет их назад на пару лет девелопмента и тестирований.
Во-первых, а данном софте оракл — единственный вариант базы, который может использоваться, поэтому писать прослойку пришлось лишь один раз, запросы там тоже далеко не простые, так как все оптимизировалось именно под оракл изначально.
Во-вторых, в данном классе софта (системы performance management) наоборот есть тенденция как можно сильнее абстрагировать уровень вычисления от уровня хранения результатов вычисления. Есть несколько причин, почему так делают, основаные из них — это производительность и масштабируемость решения (тех компонентов, которые вычисления делают).
Софт имеет уровень сбора данных, уровень обработки (вычисления), уровень хранения и уровень представления. Первые два и последний уровни часто необходимо масштабировать и разносить как логически, так и физически/географически. С базой этот трюк не проходит. Она должна быть одна.
Прямой конкурент Proviso — компания InfoVista — имеет схожее софтовое решение, по эволюции их софта очень хорошо прослеживается, как они медленно, но верно понимали, что вычисления нужно выносить за пределы базы данных.
Таким образом, с одной стороны иметь все внутри базы — хорошо, но с другой — сложно масштабировать это решение. По крайней мере в случае упомянутого мной выше класса софта.
В иделе, да, база + стандбай, но сейчас из-за необходимости обе базы работают в обычном режиме. Просто с одной одни данные, в другой — другие.
К сожаление методы использования базы диктуются софтом, который стоит. Там как раз архитектура приложения сделана таким образом, что функционал максимально вынесен из базы и выполняется отдельно. База исключетельно как хранилище для исторических и текущих данных.
Софт — IBM Tivoli Netcool Proviso (теперь они его правда называют Performance Manager).
Пока что я вынужден покупать и дорогое спарковское железо, и платить за лицензии на оракл :)
Причем самое неприятное в том, что оракл лицензирует по количеству ядер, а у меня два проца по 8 ядер каждый в сервере.
Да, согласен, единственный вариант — это ждать и смотреть, что будет дальше.
Просто не переживать за судьбу SPARC не могу, у меня добрых два десятка таких серверов на работе, и софт на них крутится, который мониторит всю сеть компании. Один раз уже Sun сделал недоброе дело, свернув линейку 215/245 серверов, чем лишил нас entry-level железок по сути.
Тенденция перехода на Linux и в случае нашего софта на AIX (потому что IBM теперь разработчик) конечно есть, но какая-то она вялая и невнятная пока получается.
SPARC может, конечно, и провальное решение в экономическом плане, но именно под SPARC Solaris написано очень большое количество софта, используемого, например, в телекоме в системах управления и мониторинга (fault and performance management).
Небольшой пример. IBM, купив Micromuse, которая писала изначально исключительно под SPARC Solaris, уже длительное время никак не может заставить хотя бы часть софта работать корректно под своим AIX. Речь идет о софте, который используется в той или иной степени в 80% операторов связи в мире.
Поэтому, мне кажется, что спрос на SPARC, хоть и не сверхбольшой, останется и быстро эту линейку свернуть не получится.
Вряд ли будущее Solaris окажется под вопросом. Уж слишком велоко количество серверных инсталляций этой ОС, а также написанного под нее. Пытаться убить ОС было бы большой ошибкой со стороны IBM.
У них уже есть подобное решение — это их in-ear phones с теми же кнопками на шнуре. Цена как раз 79$.
Звучат на порядок лучше стандартных, хотя, имхо, все равно не дотягивают до более или менее адекватного звука.
Все это логично, но мы ж были не единственной такой школой с немецким языком, в мск их десяток другой точно есть.
За все десять лет обучения мне довелось с приятелем побывать лишь на олимпиаде по химии :)
Смена архитектуры откинет их назад на пару лет девелопмента и тестирований.
Во-вторых, в данном классе софта (системы performance management) наоборот есть тенденция как можно сильнее абстрагировать уровень вычисления от уровня хранения результатов вычисления. Есть несколько причин, почему так делают, основаные из них — это производительность и масштабируемость решения (тех компонентов, которые вычисления делают).
Софт имеет уровень сбора данных, уровень обработки (вычисления), уровень хранения и уровень представления. Первые два и последний уровни часто необходимо масштабировать и разносить как логически, так и физически/географически. С базой этот трюк не проходит. Она должна быть одна.
Прямой конкурент Proviso — компания InfoVista — имеет схожее софтовое решение, по эволюции их софта очень хорошо прослеживается, как они медленно, но верно понимали, что вычисления нужно выносить за пределы базы данных.
Таким образом, с одной стороны иметь все внутри базы — хорошо, но с другой — сложно масштабировать это решение. По крайней мере в случае упомянутого мной выше класса софта.
К сожаление методы использования базы диктуются софтом, который стоит. Там как раз архитектура приложения сделана таким образом, что функционал максимально вынесен из базы и выполняется отдельно. База исключетельно как хранилище для исторических и текущих данных.
Софт — IBM Tivoli Netcool Proviso (теперь они его правда называют Performance Manager).
Пока что я вынужден покупать и дорогое спарковское железо, и платить за лицензии на оракл :)
Причем самое неприятное в том, что оракл лицензирует по количеству ядер, а у меня два проца по 8 ядер каждый в сервере.
Просто не переживать за судьбу SPARC не могу, у меня добрых два десятка таких серверов на работе, и софт на них крутится, который мониторит всю сеть компании. Один раз уже Sun сделал недоброе дело, свернув линейку 215/245 серверов, чем лишил нас entry-level железок по сути.
Тенденция перехода на Linux и в случае нашего софта на AIX (потому что IBM теперь разработчик) конечно есть, но какая-то она вялая и невнятная пока получается.
Небольшой пример. IBM, купив Micromuse, которая писала изначально исключительно под SPARC Solaris, уже длительное время никак не может заставить хотя бы часть софта работать корректно под своим AIX. Речь идет о софте, который используется в той или иной степени в 80% операторов связи в мире.
Поэтому, мне кажется, что спрос на SPARC, хоть и не сверхбольшой, останется и быстро эту линейку свернуть не получится.
У дойче телекома 20000 по всему миру, а не в одном городе.
в случае md5 это теоретически возможно кстати.
Звучат на порядок лучше стандартных, хотя, имхо, все равно не дотягивают до более или менее адекватного звука.