>Это очень даже неплохо. Можно даже сказать, что и прекрасно.
придерживаюсь аналогичного мнения ;-)
>Если появятся граждане с рассуждениями типа "а если вдруг самолёт
>в здание врежется", гоните их в шею.
смешно говорить, но такие находятся и, что удивительно, мгновенно. видимо, это самое приминивное, в смысле самое простое, что может прийти в голову.
>Не могу утверждать, что вообще нельзя - я не особенно большой знаток
>RAC - но на поверхности таких средств не наблюдается.
ясно. спасибо и на этом. ;-)
>
>Можно, конечно, взять пионера-самоучку, способного обучаться с
>приемлемой скоростью, и даже заплатить те самые килобаксы за его
>обучение и экзамен. Поначалу будет некая экономия, затем пионер
>перестанет быть пионером, и всё вернётся к исходному варианту.
вещи (и, тем более, люди) стоят столько, сколько они стоят. экономить на этом -- лишать себя возможности контролировать ситуацию... ;-)
>
>>задача является аналогом банковской процессинговой системы по обслуживанию магнитных и микропроцесорных пластиковых
>>карт.
>>
>>транзакции следующего типа:
>>1. положить/снять кредиты на счет
>
>Само по себе мелочь. Зависит от того, насколько сложная структура
>учёта используется, а также от того, не пытается ли кто-либо
>в онлайне считать какую-нибудь аналитику.
согласен: все зависит от структуры учета. но она пока до конца не ясна, т.к. процесс находится в состоянии идентификации требований к ПО.
все это в полной мере относится и к аналитической обработке. она будет, предположительно сложная, но большинство деталей еще не выявлены.
придерживаюсь мнения, что аппаратура нужна для того, чтобы обеспечивать потребности прикладной программы. следовательно, архитектура аппаратной базы вторична по отношению к архитектуре ПО (в первую очередь прикладного). следовательно и исходить необходимо из потребностей софта.
но порой приходится разворачивать ситуацию на 180 градусов: с целью минимизации времени, необходимого для принятия проектных решений по всей вычислительной системе, приходится проектировние структуры аппаратной части вести параллельно с проектированием структуры ПО. При этом, к началу этапа тестирования должна уже быть некая аппаратная база. кроме этого, задача усложняется проблемой защиты инвестиций: нецелесообразно для тестирования и опытной эксплуатации покупать один комплект аппаратуры, а для промышленной эксплуатации -- другой.
>>4. сохранение информации для аудита
>
>Вероятно, наиболее "тяжёлый" тип нагрузки. Может сопровождаться
>труднолокализуемыми блокировками по данным и порождать
>"узкие места" в параллельной обработке.
полностью согласен, так оно и есть: сбор данных за длительные периоды -- слишком дорогостоищ.
>
>Известный обходной путь - отдельно хранить журнал операций,
>периодически реплицировать его в другую БД и на другую машину,
>и всю аналитику с аудитом крутить там. Тогда, по крайней мере,
>удастся аккуратно разнести нагрузку.
а такой вопрос: каким образом настраивается балансировка нагрузки в RAC? по каким принципам? по экземплярам БД, по серверным узлам, по сессиям?
>
>Мелкософт хвастается, что сервера под W2K, выпускаемые её OEM-артнёрами,
>оную надёжность обеспечивают. Что-то не верится...
мелкософт, да, если честно, и не только он, выдают желаемое за действительное. люди, по незнанию, в это верят и, как говорится, хавают. ;-)
говоря по-русски -- правдоподобно врут. очень нехорошее явление в последнее время, от которого просто спасу нет.
>
>>ну, наверное, это закон для тех, кто не понимает истинного
>>значения фразы "пипл хавает" ;-)
>
>Вот Титомир пусть и хавает. А мы погодим!
ну мы же задумываемся по крайней мере, где мухи, а где котлеты, чтобы отложить первых в сторону.
>Вы ценами на сервера HP (не писюками, а PA-RISC) поинтересуйтесь.
>Sun покажется конторой для бедных. А Ultra-3 SCSI винчестер с
>функциями горячей замены, 16-ти мегабайтным буфером, скоростью
>обращения 15000 и длиннющей гарантией может и дороже стоить.
интересовался. вот от них и улетаю. ;-)
>
>Я, собственно, о другом. ERGO: "Естественный" параллелизм отличается
>от "неестественного" количеством усилий, затраченных на достижение
>достаточного его уровня для решения прикладной задачи с приемлемой
>для предметной области производительностью. :)
я понял, вы хотели сказать, что: есть задачи хорошо векторизуемые (раскладываемые на одновременно выполняющиеся операции), а есть исключительно последовательные, т.к. результаты начальных операций используются в последующих. хорошо векторизуемые вы назвали "естественным" параллелизмом. что ж, видимо так оно и есть ;-)
Вариант для распечатки
OpenNET: Виртуальная конференция (Public)
on
11-Сен-03, 11:21 (MSK)
