80

Тут говорят!
Авторизация
Список форумов
Войти через акаунт
 

Системы управления базами данных
Подписаться/отписаться на тему (функция доступна только для зарегистрированных пользователей) Любимая тема (вкл/выкл) []

Страницы: 1  2  3  4  5  6   из  12
Добавление сообщений к этой теме для незарегистрированных пользователей невозможно
Тему смотрит 1 незарегистрированный пользователь
Модераторы
Рейтинг темы: ***** (62456 просмотров)
Вы не можете создавать новые темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения
 

R0bur R0bur в оффлайне

писатель
Сообщений: 1 462

R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный

nati_vostrikova (18.02.12 01:28) писал(a):
А теперь выползает молоденькая архитектор, которая этому руководству напрямую не подчиняется, но которая будет за эту систему отвечать, и говорит, что вы, ребята, совсем офонарели такое чудо в продакшн ставить - продакшн повалите как тайгу на лесоповале.
Дяди лучше знают!

Если новая система затрагивает только серверную часть, я бы предложил поднять внедряемую систему на резервном оборудовании, а на входном интерфейсе поставить прокси, который бы направлял входной информационный поток как на основную, так и на внедряемую систему; клиенту выдавать ответ основной системы. Ответ внедряемой системы можно сравнивать с ответом основной (для дополнительного тестирования) или просто игнорировать.

Если затрагивается и клиентская сторона, то дело сложнее, но тоже решаемо. Суть в том, что некоторое время две системы должны работать одновременно и именно под штатной нагрузкой.

--------------------
Приходи тихо, проси мало, уходи быстро.
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 6 158

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

Igoroshka (18.02.12 15:39) писал(a):
Э-эх. Везде одно и то же

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

Удачи!

---------------------
Если можно, пару слов о:

Кластер средствами Windows?
Какое впечатление от работы DB2, если сравнивать Windows и AIX (с поправкой на железо, конечно)?
Кластер средствами Windows, shared disk.
Мое сугубое ИМХО, windows хорош в основном для не сильно нагруженного офисного компа, где печатают отчеты и играют в косынку. Не исключено, что я просто не умею правильно плясать вокруг него с бубном.
UNIX-оподобные системы для серверов, особенно высоконагруженных баз, мне нравятся не в пример больше.
DB2 с AIX мне нравится не в пример больше. На самом деле в деле администрирования DB2 под Windows и DB2 под UNIX почти не отличаются. Даже сертификат на них один DB2 Administrator for linux, Unix, Windows. Но по производительности на AIX работает сильно лучше. Опять же, мое ИМХО и мои наблюдения.

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 6 158

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

R0bur (19.02.12 17:54) писал(a):
Дяди лучше знают!

Если новая система затрагивает только серверную часть, я бы предложил поднять внедряемую систему на резервном оборудовании, а на входном интерфейсе поставить прокси, который бы направлял входной информационный поток как на основную, так и на внедряемую систему; клиенту выдавать ответ основной системы. Ответ внедряемой системы можно сравнивать с ответом основной (для дополнительного тестирования) или просто игнорировать.

Если затрагивается и клиентская сторона, то дело сложнее, но тоже решаемо. Суть в том, что некоторое время две системы должны работать одновременно и именно под штатной нагрузкой.
Затронута и клиентская и серверная части.

Я с Вами согласна, хоть тушкой, хоть чучелом, но следовало бы узнать, будет эта система в принципе работать в продакшене или нет ДО момента накрывания продакшена медным тазиком. А предпосылки к тазику имеются даже очень большие.
Ну ладно, мое дело прокукарекать - а там хоть не рассветай.

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

R0bur R0bur в оффлайне

писатель
Сообщений: 1 462

R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный

nati_vostrikova: Как я понял, у вас довольно большая база данных. Если не секрет, в общих чертах, расскажите, как решаете вопрос архивного хранения информации? Не резервного, а именно архивного.

Например, "Дело N" (содержащее некоторую информацию из БД) "срок хранения 3 года". Информация за все три года хранится в основной БД? Или записи с временем создания, например, больше года (вероятность обращения к которым мала), переносите в архивную БД? Обеспечивается ли интерфейсом пользовательского ПО простой доступ к архивной информации?

--------------------
Приходи тихо, проси мало, уходи быстро.
 

funhouse funhouse в оффлайне

графоман
Сообщений: 4 796

funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный

nati_vostrikova (18.02.12 01:28) писал(a):
Я, собственно, о том же. SLA - 6 секунд на любую операцию

Спасибо за интересный рассказ. С Ораклом я почти незнакома.

Транзакции по логам не распределяются. Ибо тогда появляется возможность нарушения целостности транзакции при восстановлении. Пример: транзакция занимает 2 лог файла. первый есть, второй отсутствует. Целостность транзакции при восстановлении нарушена. Транзакция должна помещаться в 1 лог. Иначе выдается ошибка. По крайней мере так ведет себя DB2 и MS SQL Server.
Размер файлов одинаковый в тесте и продакшене - 4 MB.

Согласна, но и это, ИМХО, желательно сделать ДО момента "зю".


Дело тут даже не в использовании памяти, а в том, что несмотря на заверения вендора, что батчи не буду затронуты изменениями в коде, это очень маловероятно, потому что используется один и тот е код. Плюс мы видим изменение поведения батчей.

Думаю, проблема вот в чем: руководство подписало ТЗ проекта для онлайна с условием, что батчи в этот проект не входят. На проект потрачены бешеные деньги. А теперь выползает молоденькая архитектор, которая этому руководству напрямую не подчиняется, но которая будет за эту систему отвечать, и говорит, что вы, ребята, совсем офонарели такое чудо в продакшн ставить - продакшн повалите как тайгу на лесоповале.И если теперь прогнать тесты, и все накроется - будут очень неудобные вопросы. Правда, если повалить продакшн, будут очень неудобные ответы.

П.С. Вот и получилась дискуссия
Я бы посоветовал профайлинг до и после (на базе и на яве). А также стрес тестирование. Оперировать вероятностями тут не к месту. А "после" не значит "по причине".
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 687

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

nati_vostrikova (20.02.12 00:52) писал(a):
Кластер средствами Windows, shared disk.
Мое сугубое ИМХО, windows хорош в основном для не сильно нагруженного офисного компа, где печатают отчеты и играют в косынку. Не исключено, что я просто не умею правильно плясать вокруг него с бубном.
UNIX-оподобные системы для серверов, особенно высоконагруженных баз, мне нравятся не в пример больше.
DB2 с AIX мне нравится не в пример больше. На самом деле в деле администрирования DB2 под Windows и DB2 под UNIX почти не отличаются. Даже сертификат на них один DB2 Administrator for linux, Unix, Windows. Но по производительности на AIX работает сильно лучше. Опять же, мое ИМХО и мои наблюдения.
Спасибо большое за ответ.

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 687

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

funhouse (20.02.12 23:31) писал(a):
Я бы посоветовал профайлинг до и после (на базе и на яве). А также стрес тестирование. Оперировать вероятностями тут не к месту. А "после" не значит "по причине".
Что есть "стресс тестирование"? И что как не вероятности "стресс" и "профайлинг"?
Снятие и интерпретация метрик времени выполнения БД -- задача далеко не тривиальная. Особенно в высококонкурирующей за ресурсы среде. Плюс наличие оптимизатора в СУБД.

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 6 158

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

R0bur (20.02.12 20:43) писал(a):
nati_vostrikova: Как я понял, у вас довольно большая база данных. Если не секрет, в общих чертах, расскажите, как решаете вопрос архивного хранения информации? Не резервного, а именно архивного.

Например, "Дело N" (содержащее некоторую информацию из БД) "срок хранения 3 года". Информация за все три года хранится в основной БД? Или записи с временем создания, например, больше года (вероятность обращения к которым мала), переносите в архивную БД? Обеспечивается ли интерфейсом пользовательского ПО простой доступ к архивной информации?
Ок. в общих чертах это выглядит так: есть клиент, есть его действия (транзакции например). Между таблицами, содержащими информацию о клиенте, между основной базой и архивной сделана репликация. То есть информация о клиенте содержится в обеих базах (не вся полностью, только та, которая необходима для поддержания целостности данных архивной базы). Аналогично реплицируются таблицы, содержащие статические данные. Далее информация о действиях клиента за 3 месяца содержится в активной базе. Информация о действиях клиента, которая старше 3 месяцев, выгружается из активной базы, загружается в архивную базу, после чего удаляется из активной базы. То есть в активной базе лежат действия клиента только за прошедшие 3 месяца. В архивной базе действия клиента лежат, предположим, 5 лет. Все, что старше этого "возраста", удаляется из архивной базы.
В архивной базе созданы дополнительные индексы и партишены, ибо доступ к ней осуществляется не в режиме OLTP. По условиям информация о действиях клиента, которые старше 3 месяцев, клиенту из онлайна недоступны и доступны только при запросе непосредственно сотруднику компании.
В данном случае страничка, на которой сотрудник готовит отчет для клиента, обращается к архивной базе. На нее SLA=6 секунд не распространяются.
Немного похоже на data warehouse, но в полном смысле этого слова им не является.

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

R0bur R0bur в оффлайне

писатель
Сообщений: 1 462

R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный

nati_vostrikova (21.02.12 02:54) писал(a):
Ок. в общих чертах это выглядит так...
...Немного похоже на data warehouse, но в полном смысле этого слова им не является.
Спасибо за пояснения!

--------------------
Приходи тихо, проси мало, уходи быстро.
 

funhouse funhouse в оффлайне

графоман
Сообщений: 4 796

funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный

Igoroshka (21.02.12 01:30) писал(a):
Что есть "стресс тестирование"? И что как не вероятности "стресс" и "профайлинг"?
Снятие и интерпретация метрик времени выполнения БД -- задача далеко не тривиальная. Особенно в высококонкурирующей за ресурсы среде. Плюс наличие оптимизатора в СУБД.
Стресс тестирование - это процесс тестирования системы под пиковой(нормальной) нагрузкой. Цель тестирования выявление дедлоков мемориликов, узких мест. При обычном тестировании подобные ошибки обычно не выявляются.
Если вы о "вероятностном" характере результатов то они безусловно вероятностные но в строгом понимании этого термина а не в бытовом в котором было употреблено ране, а теория вероятностей дисциплина, как известно, точная.
Снятие и интерпретация метрик в высоконкурирующей за ресурсы среде в общем случае наверное действительно задача не тривиальная, а в конкретном не только тривиальная но и абсолбтно необходимая. Без стресс тестирования ни одна более менее сложная система в продакш не пойдет. Оптимизатор тут совершенно ни при чем.
Если вы намекаете что нужно как можно более точно имитировать реальные условия работы системы так тут нельзя не согласится, но кто говорил что будет легко.
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 687

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

1. Всегда считал, что стресс тестирование -- это определение поведения системы при возникновении внештатных ситуаций: от отказа сетевого коммутатора, выхода из строя дисковой стойки до падения процесса(ов) ОС, СУБД.
2. Блокировки (в хорошей системе они, как правило, практически отсутствуют) -- всего лишь факты в биографии работы СУБД. Если они есть, при нагрузке они будут всего лишь учащаться, но не более того.
3. Утечку памяти в крупных СУБД типа Oracle (другие знаю мало) обнаружить достаточно проблематично. Явные проблемы закрываются регулярными патчами, а мелкие "успешно маскируются" множеством процессов.
4. Теорвер, как дисциплина, может быть и точная. Но ее результаты вероятностны по определению . Результат (например, время завершения выполнения запроса) как суперпозиция множества событий в СУБД с учетом вероятности их наступления, да еще в определенные моменты времени, является всего лишь оценкой с большей или меньшей погрешностью.
5. Снятие метрик, даже когда их количество переваливает за сотню, действительно, относительно несложный процесс. Сложности возникают в их интерпретации с учетом настроек системы, работы оптимизатора, выполняемых запросов, исполняемых заданий и т.д.
А запускать в промышленную эксплуатацию более-менее серьезную систему без всестороннего тестирования, в т.ч. и стрессового, таки да, неразумно.
6. Я не намекаю . Я прямо говорю, что чем тщательней определены условия работы системы, оценены перспективы, аккуратней выполнено тестирование (и документирование), тем меньше проблем будет при промышленной эксплуатации.

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 6 158

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

Господа, по-моему, неправы Вы оба
Цитирую Википедию: "Стресс-тестирование (англ. Stress Testing) — один из видов тестирования ПО, которое оценивает надежность и устойчивость системы в условиях превышения пределов нормального функционирования. Стресс-тестирование особенно необходимо для "критически важного" ПО, однако также используется и для остального ПО. Обычно стресс-тестирование лучше обнаруживает устойчивость, доступность и обработку исключений системой под большой нагрузкой, чем то, что считается корректным поведением в нормальных условиях.
Термин "стресс-тестирование" часто используется как синоним "нагрузочного тестирования", а также "тестирования производительности" ошибочно, так как эти виды тестирования отвечают на разные бизнес-вопросы и используют различную методологию"
"Нагрузочное тестирование (англ. Load Testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Если создаваемая нагрузка на систему превышает нормальные сценарии её использования, с целью протестировать время отклика системы на высоких или пиковых нагрузках, такое тестирование называется стресс-тестированием. В этом случае нагрузка обычно столь высока, что предсказуема ошибочная работа системы, однако не существует четкой границы между тем, когда тестирование является нагрузочным и тем, когда оно становится стресс-тестированием.".
Так что funhouse, говоря о нормальной нагрузке (или все-таки пиковой??), говорит о нагрузочном тестировании, а то, о чем говори Igoroshka - это recovery testing (сорри, не знаю, как это по-русски)
"In software testing, recovery testing is the activity of testing how well an application is able to recover from crashes, hardware failures and other similar problems."
А по теме дискуссии: все согласны, что хотя бы какое-то тестирование должно иметь место? Причем не для части системы (онлайн), а для всей системы целиком (онлайн + батчи + database maintenance)?

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 687

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

nati_vostrikova (22.02.12 03:40) писал(a):
Господа, по-моему, неправы Вы оба
Цитирую Википедию: "Стресс-тестирование (англ. Stress Testing) — один из видов тестирования ПО, которое оценивает надежность и устойчивость системы в условиях превышения пределов нормального функционирования. Стресс-тестирование особенно необходимо для "критически важного" ПО, однако также используется и для остального ПО. Обычно стресс-тестирование лучше обнаруживает устойчивость, доступность и обработку исключений системой под большой нагрузкой, чем то, что считается корректным поведением в нормальных условиях.
Термин "стресс-тестирование" часто используется как синоним "нагрузочного тестирования", а также "тестирования производительности" ошибочно, так как эти виды тестирования отвечают на разные бизнес-вопросы и используют различную методологию"
"Нагрузочное тестирование (англ. Load Testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Если создаваемая нагрузка на систему превышает нормальные сценарии её использования, с целью протестировать время отклика системы на высоких или пиковых нагрузках, такое тестирование называется стресс-тестированием. В этом случае нагрузка обычно столь высока, что предсказуема ошибочная работа системы, однако не существует четкой границы между тем, когда тестирование является нагрузочным и тем, когда оно становится стресс-тестированием.".
Так что funhouse, говоря о нормальной нагрузке (или все-таки пиковой??), говорит о нагрузочном тестировании, а то, о чем говори Igoroshka - это recovery testing (сорри, не знаю, как это по-русски)
"In software testing, recovery testing is the activity of testing how well an application is able to recover from crashes, hardware failures and other similar problems."
А по теме дискуссии: все согласны, что хотя бы какое-то тестирование должно иметь место? Причем не для части системы (онлайн), а для всей системы целиком (онлайн + батчи + database maintenance)?
Прежде, чем дискутировать, необходимо договориться о понятиях .
Действительно, вышла путаница. Говоря о стресс-тестировании системы предполагал проверку работы всего комплекса при различных отказах: СУБД, ОС, сервер, сеть, СХД. При этом контролируется и фиксируется поведение целевых систем -- СУБД, клиентское ПО, резервных серверов.
Мы различаем стресс-тестирование (в определении выше) и нагрузочное тестирование в определении Вики для ПО.

nati_vostrikova, а нет ли у IBM чего-то, подобного Real Application Testing у Оракл (https://blogs.oracle.com/AlejandroVa...ING-ON-10G.pdf, стр. 36-74, http://compit.by/upload/Mark_RAT.pdf)? Это был бы один из наиболее адекватных инструментов в вашем случае.

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

R0bur R0bur в оффлайне

писатель
Сообщений: 1 462

R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный

nati_vostrikova (22.02.12 03:40) писал(a):
А по теме дискуссии: все согласны, что хотя бы какое-то тестирование должно иметь место? Причем не для части системы (онлайн), а для всей системы целиком (онлайн + батчи + database maintenance)?
Система, состоящая из набора компонентов, отличается от простого набора этих компонентов наличием новых качеств и свойств, возникающих из-за наличия связей между компонентами (по-моему, одно из первых определений системного анализа). Поэтому говорить о свойствах и поведении системы, опираясь лишь на знания о дискретных компонентах, несколько легкомысленно. Переведите на английский и передайте своему начальству. И вообще, самое время заявить, что "стае нужен новый вожак!"

P.S. Кстати, Вы уверены, что коллеги/начальство Вас не разыгрывает и Вы владеете полной информацией о предполагаемом поведении системы? Возможно, у них "козыри в рукаве"...

Последний раз редактировалось R0bur; 22.02.12 в 19:48.
--------------------
Приходи тихо, проси мало, уходи быстро.
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 687

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

R0bur (22.02.12 19:43) писал(a):
...P.S. Кстати, Вы уверены, что коллеги/начальство Вас не разыгрывает и Вы владеете полной информацией о предполагаемом поведении системы? Возможно, у них "козыри в рукаве"...
Это было бы череcчур ... экстравагантно . Простой системы, обслуживающей 17 тыс. пользователей, смею предположить, весьма недешево стоит.

Последний раз редактировалось Igoroshka; 23.02.12 в 07:52.
--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

funhouse funhouse в оффлайне

графоман
Сообщений: 4 796

funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный

nati_vostrikova (22.02.12 03:40) писал(a):
Господа, по-моему, неправы Вы оба
Цитирую Википедию: "Стресс-тестирование (англ. Stress Testing) — один из видов тестирования ПО, которое оценивает надежность и устойчивость системы в условиях превышения пределов нормального функционирования. Стресс-тестирование особенно необходимо для "критически важного" ПО, однако также используется и для остального ПО. Обычно стресс-тестирование лучше обнаруживает устойчивость, доступность и обработку исключений системой под большой нагрузкой, чем то, что считается корректным поведением в нормальных условиях.
Термин "стресс-тестирование" часто используется как синоним "нагрузочного тестирования", а также "тестирования производительности" ошибочно, так как эти виды тестирования отвечают на разные бизнес-вопросы и используют различную методологию"
"Нагрузочное тестирование (англ. Load Testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Если создаваемая нагрузка на систему превышает нормальные сценарии её использования, с целью протестировать время отклика системы на высоких или пиковых нагрузках, такое тестирование называется стресс-тестированием. В этом случае нагрузка обычно столь высока, что предсказуема ошибочная работа системы, однако не существует четкой границы между тем, когда тестирование является нагрузочным и тем, когда оно становится стресс-тестированием.".
Так что funhouse, говоря о нормальной нагрузке (или все-таки пиковой??), говорит о нагрузочном тестировании, а то, о чем говори Igoroshka - это recovery testing (сорри, не знаю, как это по-русски)
"In software testing, recovery testing is the activity of testing how well an application is able to recover from crashes, hardware failures and other similar problems."
А по теме дискуссии: все согласны, что хотя бы какое-то тестирование должно иметь место? Причем не для части системы (онлайн), а для всей системы целиком (онлайн + батчи + database maintenance)?
Значит так, это все термины. Я мог бы быть и более строгим в терминах. Но как говорится гуд энаф. На практике не проводится обычно и нагрузочное и стресс тестирование. Потому как оно переходит одно в другое. Не читал вики кстати но даже интерестно где они точно проведут границу. Типа 1000 запросов в минуту от 50 конкуретных пользователей это "нагрузочное" а 1001 - это уже стресовое очевидно. На практике часто бывает так проводили "нагрузочное" а оказалось "стрессовое" и когда пофиксали все узкие места, тогда да - снова нагрузочное. Детский сад, вообщем. Ну да ладно, тестеры и их теоретики - это особая каста. На практике, да, стесс тестирование может помочь тестирование например обработки ошибок в экстремальных ситациях типа "оут оф мемори". Но это на самом деле редко кого интересует, хотя и может быть важно.
Что касается - "нет мемори ликов в СУБД", вообщем скорее всего, да, не найдешь, но не факт - зависит от приложения. Но сама постановка вопроса выдает - администратора БД - который дальше БД не смотрит. А основные проблемы как раз таки создают пользователи БД которые могут "озадачить" любую БД. Ну или выявить слабые места. Например банальное отсутсвие индекса там где он необходим (но, например, "потерялся").
Вообщем стресс тестирование, мой рецепт.

Последний раз редактировалось funhouse; 23.02.12 в 00:26.
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 687

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

В крупных системах, с которыми приходится работать, "озадачить" СУБД запросами удавалось только разработчику прикладного ПО (в большинстве своем) или ДБА, так как пользователь работает только через приложение.
А "банальное отсутствие индекса" или же, наоборот, его неоправданное присутствие как раз лежит на совести разработчика и ДБА, но никак не пользователя. К слову, проверяется это весьма просто.

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 6 158

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

Igoroshka (23.02.12 09:13) писал(a):
В крупных системах, с которыми приходится работать, "озадачить" СУБД запросами удавалось только разработчику прикладного ПО (в большинстве своем) или ДБА, так как пользователь работает только через приложение.
А "банальное отсутствие индекса" или же, наоборот, его неоправданное присутствие как раз лежит на совести разработчика и ДБА, но никак не пользователя. К слову, проверяется это весьма просто.
Соглашусь на 100%. В больших системах пользователь запросов не вводит. (Можно я полюбуюсь на банковскую систему, в которой пользователь вводит запрос на базу? Или в которой вдруг может сгенерироваться запрос, который базу подвесит) Запросы выполняются из приложения, и автор их - разработчик или сам ДБА, а ответственность за их работу - на ДБА. Это обязанность ДБА проверить топ 10 - 20 самых тяжелых запросов приложения и выяснить, почему они таковыми являются. И проверить план выполнения хранимок, прежде чем ставить их в продакшн. У меня ни одна хранимка без моего ревью на прод не уходит.
Потерянный индекс ловится на раз-два-три. Как и лишний индекс. И делает это ДБА исходя из плана исполнения запроса. Только не индексами едиными жива база. Например, если разработчики не знали, что такое параметризованный запрос и в динамический запрос загоняли значения параметров явно, то с индексами может все быть в порядке. Вот только сервер в основном будет заниматься компиляцией и построением плана исполнения запроса.
Кстати, мое сугубое ИМХО, ДБА отвечает за работоспособность базы. куда-то дальше ему смотреть не обязательно. ИМХО. Я рисую архитектуру данных - и архитектура остального приложения меня интересует постольку поскольку. Мне полезно знать, что батч сервер у нас на самом деле кластер, но как именно он реализован - уже не моя забота.

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 6 158

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

Igoroshka (22.02.12 20:08) писал(a):
Это было бы череcчур ... экстравагантно . Простой системы, обслуживающей 17 тыс. пользователей, смею предположить, весьма недешево стоит.
Вопрос тут скорее в другом: на проект кэширования потрачено пару-тройку миллионов долларов. Если остановить вывод системы в продакшн, оттестировать и увидеть, что система неработоспособна вся целиком, то вопросы будут к вендору, делавшему проект кэширования (для простоты - вендору 1). Если вывести систему в продакшн, и она там повалится, отвечать будем мы. Для заказчика мы такой же вендор как и авторы проекта кэширования, хотя при этом заказчик является нашей же дочерней структурой. Забавно, правда? Заказчик долгое время хороводился вендором 1, потом пришло руководство с вопросом "и что это было?" - так на горизонте появились мы. Естественно по старой памяти заказчик скорее спихнет вину на нас, чем на любимого вендора 1. А я как-то не хочу получать по ушам за проект, влияния на который я оказать не могу.
Политика, йошкин кот.

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 687

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

nati_vostrikova (23.02.12 15:53) писал(a):
...Например, если разработчики не знали, что такое параметризованный запрос и в динамический запрос загоняли значения параметров явно, то с индексами может все быть в порядке. Вот только сервер в основном будет заниматься компиляцией и построением плана исполнения запроса...
Или пишут некое "универсальное" приложение для "всех СУБД", которое на реальной системе приводит к созданию очередей ввиду особенностей конкретной СУБД. Или расставляют везде хэши, потому что запросы выполняются с полным сканированием таблиц так как механически перенесли статистику с тестовой системы на производственную, и оптимизатор делает неправильное заключение. Или разрабатывают приложение, функционирующее на кластере, но пишут его так, будто работает на одиночном сервере, а потом удивляются, почему такие большие задержки при банальном получении очередного значения для sequence?

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 687

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

nati_vostrikova (23.02.12 16:10) писал(a):
...Если вывести систему в продакшн...
А как планируется вводить новую систему в промышленную эксплуатацию? Система ведь 24х7. Определены ли контрольные точки?

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

funhouse funhouse в оффлайне

графоман
Сообщений: 4 796

funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный

nati_vostrikova (23.02.12 15:53) писал(a):
Соглашусь на 100%. В больших системах пользователь запросов не вводит. (Можно я полюбуюсь на банковскую систему, в которой пользователь вводит запрос на базу? Или в которой вдруг может сгенерироваться запрос, который базу подвесит) Запросы выполняются из приложения, и автор их - разработчик или сам ДБА, а ответственность за их работу - на ДБА. Это обязанность ДБА проверить топ 10 - 20 самых тяжелых запросов приложения и выяснить, почему они таковыми являются.
Капец. Конечно пользователь своих запросов не вводит и все тысячи запросов которые написаны разработчиком или (прости господи) DBA они являют собой совершенство - при взгде на плна запроса просто хочется плакать. И причем хорошая большая система написана так что все 15 запросов которые могут быть написаны заранее оттестированы и отточены. Если понадобится 16 то систему придется дописывать несколько месяцев. И причем они совершенны настолько, что не зависят ни от количества записей ни от нагрузки на систему. Ни от того что статистика не собрана уже давно. Посмотрит прищурив правый глаз DBA на 10-20 самых тяжелых запросов и вынесет свй приговор. Да что я знаю о больших системах. Причем конечно любой заказчик решает заранее, что все будет работать к примеру на DB2 и если вдруг окажется что появилось предложение повыгоднее или, например, железо купили не от IBM а от какой-другой конторы то заказчик предложит переписать приложение чтобы все эти сторед процедуры написанные с любовью к DB2 были переписаны под sqlserver например. Или может быть заказчик сразу оговорит что СУБД может быть любой (или несколько). Впрочем о чем это же все фантазии. В реальности есть топ 20-30 запросов которые работают идеально при любом количестве данных. Динамического sql не бывает, Запросы "пишут" только те кто знает как писать. И вообще "нагрузочное" (вы настаиваите) тестирование вещь избыточное.

Прошу прощение, а у вас сколько лет опыта работы с различными "большими" системами?

Последний раз редактировалось funhouse; 24.02.12 в 01:46.
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 6 158

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

Igoroshka (23.02.12 23:29) писал(a):
Или пишут некое "универсальное" приложение для "всех СУБД", которое на реальной системе приводит к созданию очередей ввиду особенностей конкретной СУБД....
Что собственно с нами и произошло

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 6 158

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

funhouse (24.02.12 01:44) писал(a):
Капец. Конечно пользователь своих запросов не вводит и все тысячи запросов которые написаны разработчиком или (прости господи) DBA они являют собой совершенство - при взгде на плна запроса просто хочется плакать. И причем хорошая большая система написана так что все 15 запросов которые могут быть написаны заранее оттестированы и отточены. Если понадобится 16 то систему придется дописывать несколько месяцев.
"О чем это ты, дядя Сидор?" (с) "Неуловимые мстители". Почему это систему придется дописывать несколько месяцев, если потребуется 16 вместо 15-ти? Поясните, пожалуйста, сей поток сознания.
И причем они совершенны настолько, что не зависят ни от количества записей ни от нагрузки на систему. Ни от того что статистика не собрана уже давно.
Вообще-то в нормальных системах статистика собирается регулярно. У нас сбор статистики висит раз в неделю и на проде и на тестовых средах. Никто вроде не говорил, что план исполнения запроса не зависит от количества записей в таблицах и распределения, которое имеют данные в таблице. Зависят. Только вот тестируют обычно на production-like данных - то есть тех, которые реально имеют близкое к продакшену распределение и количество записей в табличке. Я про UAT.
Посмотрит прищурив правый глаз DBA на 10-20 самых тяжелых запросов и вынесет свй приговор. Да что я знаю о больших системах. Причем конечно любой заказчик решает заранее, что все будет работать к примеру на DB2 и если вдруг окажется что появилось предложение повыгоднее или, например, железо купили не от IBM а от какой-другой конторы то заказчик предложит переписать приложение чтобы все эти сторед процедуры написанные с любовью к DB2 были переписаны под sqlserver например. Или может быть заказчик сразу оговорит что СУБД может быть любой (или несколько). Впрочем о чем это же все фантазии.
В реальности крупный банк или другая контора, занимающаяся, к примеру, онлайн транзакциями, заранее знает, на чем именно будет работать сия система. Вплоть до версии СУБД и конфигурации железа. Обычно такие конторы являются "primary partner" IBM или Microsoft и не бегают от одного вендора к другому. Поэтому системы, с которыми приходилось сталкиваться мне, изначально писались под конкретную СУБД, конкретную ось и т.д.
Но я имела дело в основном с западными заказчиками (или адекватными местными) и базами размером от 2 терабайт онлайн часть.
А по поводу универсальности - как говорит мой папа, лучший пример универсальной системы - это утка. Она умеет и плавать и летать и ходить. И то, и другое, и третье делает плохо.
Если после подписания требований к системе, заказчик вдруг решает поменять DB2 на Oracle, менфрейм на Linux сервер и систему с 1 базой на распределенную - адекватный заказчик должен понимать, что это фактически означает переписывание продукта. Как если бы заказчику вдруг стрельнуло в мозг сделать систему не на джаве а на дотнете. Вы тоже будете писать код так, чтобы он заработал и там и там? ИМХО, писать систему, которая станет и на мейнфрейм и на linux, и на Oracle и на DB2, одинаково хорошо будет работать и на кластере и на одиночном сервере - непродуктивно. Универсальная система в каждом случае будет работать хуже, чем заточенная под конкретную СУБД, ось и т.д. Впрочем, в системах, с которыми доводилось сталкиваться мне, требование производительности и безопасности стояло в списке приоритетов сильно выше, чем возможность быстро поменять СУБД. Видимо потому, что никто из моих заказчиков в обозримом будущем делать этого не собирался.
В реальности есть топ 20-30 запросов которые работают идеально при любом количестве данных.
а кто-то спорит?
Динамического sql не бывает, Запросы "пишут" только те кто знает как писать.
"О чем это ты, дядя Сидор?" (с) дубль два.
Динамические и статические запросы отлавливаются на DB2 следующим образом: снапшот кэша запросов или монитор (db2 get snapshot for dynamic sql или create event monitor for dynamic sql - если не подглючило с синтаксисом). И тот и другой метод позволяет увидеть реальное время выполнения каждого запроса, независимо от того, изначально он динамический или статический. Плюс позволяет увидеть текст запроса, который впоследствии подсовывается анализотору плана исполнения. Из этого множества (а если используются параметр маркеры, то множество сильно уменьшается), выбираются наиболее "тяжелые" и анализируется план их исполнения (db2expln). Далее по обстоятельствам.
динамические запросы существуют, но, как Вы могли выше заметить, я в основном работаю с DB2, а она реализует концепцию хранения плана статического запроса хранимой процедуры в базе как объект базы данных. То есть если план исполнения запроса не найден в кэше запросов, он не строится заново, а подчитывается из базы. в данном случае, если обращение происходит к таблицам в которых статистика по данным меняется не сильно (то есть например вчера было 1 миллион 100 тыс записей, сегодня стало 1 миллион 110 тыс записей с примерно одинаковым распределением - для статистики это не так уж существенно по сравнению с "вчера в таблице лежало 10 тыс записей, сегодня миллион с абсолютно другим распределением")эта стратегия позволяет экономить время, которое иначе было бы затрачено на компиляцию и построение плана исполнения запроса. В большинстве случаев подчитать запрос из базы обходится "дешевле", чем скомпилировать и построить план исполнения. Кроме того хранимые процедуры в DB2 позволяют вызывающему их иметь только грант на выполнение хранимки (если хранимка не содержит динамического запроса сама по себе). Явных прав на объекты базы вызывающему не требуется. Таким образом, id, с которым приложение ходит на базу, получает только права на хранимки, а явных прав на объекты не получает. Тогда id приложения на базе может совершать только действия, заранее определенные и известные. А поскольку я работаю с банковскими системами, проблема безопасности данных у нас стоит на первом месте.
Поэтому в нашем случае гораздо более адекватно будет использовать хранимые процедуры и затачивать систему под конкретную СУБД - DB2.
И вообще "нагрузочное" (вы настаиваите) тестирование вещь избыточное.
Повторяю еще раз и очень медленно: я считаю необходимым нагрузочное тестирование нашей системы. Причем всех компонент системы сразу, а не кусочками, как хочет сделать наш заказчик. Полтопика как раз составляет обсуждение, что заказчик наш зело неправ и рискует с такими настроениями положить продакшн.
.
Прошу прощение, а у вас сколько лет опыта работы с различными "большими" системами?
никогда не страдала желанием мерятся у кого длиннее.... опыт работы... Фаллометрию оставьте, пожалуйста, для другого собеседника.

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

funhouse funhouse в оффлайне

графоман
Сообщений: 4 796

funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный

nati_vostrikova (24.02.12 04:57) писал(a):
"О чем это ты, дядя Сидор?" (с) "Неуловимые мстители". Почему это систему придется дописывать несколько месяцев, если потребуется 16 вместо 15-ти? Поясните, пожалуйста, сей поток сознания.

Вообще-то в нормальных системах статистика собирается регулярно. У нас сбор статистики висит раз в неделю и на проде и на тестовых средах. Никто вроде не говорил, что план исполнения запроса не зависит от количества записей в таблицах и распределения, которое имеют данные в таблице. Зависят. Только вот тестируют обычно на production-like данных - то есть тех, которые реально имеют близкое к продакшену распределение и количество записей в табличке. Я про UAT.

В реальности крупный банк или другая контора, занимающаяся, к примеру, онлайн транзакциями, заранее знает, на чем именно будет работать сия система. Вплоть до версии СУБД и конфигурации железа. Обычно такие конторы являются "primary partner" IBM или Microsoft и не бегают от одного вендора к другому. Поэтому системы, с которыми приходилось сталкиваться мне, изначально писались под конкретную СУБД, конкретную ось и т.д.
Но я имела дело в основном с западными заказчиками (или адекватными местными) и базами размером от 2 терабайт онлайн часть.
А по поводу универсальности - как говорит мой папа, лучший пример универсальной системы - это утка. Она умеет и плавать и летать и ходить. И то, и другое, и третье делает плохо.
Если после подписания требований к системе, заказчик вдруг решает поменять DB2 на Oracle, менфрейм на Linux сервер и систему с 1 базой на распределенную - адекватный заказчик должен понимать, что это фактически означает переписывание продукта. Как если бы заказчику вдруг стрельнуло в мозг сделать систему не на джаве а на дотнете. Вы тоже будете писать код так, чтобы он заработал и там и там? ИМХО, писать систему, которая станет и на мейнфрейм и на linux, и на Oracle и на DB2, одинаково хорошо будет работать и на кластере и на одиночном сервере - непродуктивно. Универсальная система в каждом случае будет работать хуже, чем заточенная под конкретную СУБД, ось и т.д. Впрочем, в системах, с которыми доводилось сталкиваться мне, требование производительности и безопасности стояло в списке приоритетов сильно выше, чем возможность быстро поменять СУБД. Видимо потому, что никто из моих заказчиков в обозримом будущем делать этого не собирался.

а кто-то спорит?

"О чем это ты, дядя Сидор?" (с) дубль два.
Динамические и статические запросы отлавливаются на DB2 следующим образом: снапшот кэша запросов или монитор (db2 get snapshot for dynamic sql или create event monitor for dynamic sql - если не подглючило с синтаксисом). И тот и другой метод позволяет увидеть реальное время выполнения каждого запроса, независимо от того, изначально он динамический или статический. Плюс позволяет увидеть текст запроса, который впоследствии подсовывается анализотору плана исполнения. Из этого множества (а если используются параметр маркеры, то множество сильно уменьшается), выбираются наиболее "тяжелые" и анализируется план их исполнения (db2expln). Далее по обстоятельствам.
динамические запросы существуют, но, как Вы могли выше заметить, я в основном работаю с DB2, а она реализует концепцию хранения плана статического запроса хранимой процедуры в базе как объект базы данных. То есть если план исполнения запроса не найден в кэше запросов, он не строится заново, а подчитывается из базы. в данном случае, если обращение происходит к таблицам в которых статистика по данным меняется не сильно (то есть например вчера было 1 миллион 100 тыс записей, сегодня стало 1 миллион 110 тыс записей с примерно одинаковым распределением - для статистики это не так уж существенно по сравнению с "вчера в таблице лежало 10 тыс записей, сегодня миллион с абсолютно другим распределением")эта стратегия позволяет экономить время, которое иначе было бы затрачено на компиляцию и построение плана исполнения запроса. В большинстве случаев подчитать запрос из базы обходится "дешевле", чем скомпилировать и построить план исполнения. Кроме того хранимые процедуры в DB2 позволяют вызывающему их иметь только грант на выполнение хранимки (если хранимка не содержит динамического запроса сама по себе). Явных прав на объекты базы вызывающему не требуется. Таким образом, id, с которым приложение ходит на базу, получает только права на хранимки, а явных прав на объекты не получает. Тогда id приложения на базе может совершать только действия, заранее определенные и известные. А поскольку я работаю с банковскими системами, проблема безопасности данных у нас стоит на первом месте.
Поэтому в нашем случае гораздо более адекватно будет использовать хранимые процедуры и затачивать систему под конкретную СУБД - DB2.

Повторяю еще раз и очень медленно: я считаю необходимым нагрузочное тестирование нашей системы. Причем всех компонент системы сразу, а не кусочками, как хочет сделать наш заказчик. Полтопика как раз составляет обсуждение, что заказчик наш зело неправ и рискует с такими настроениями положить продакшн.

никогда не страдала желанием мерятся у кого длиннее.... опыт работы... Фаллометрию оставьте, пожалуйста, для другого собеседника.
Ни с кем не хотел ничем меряться. Вопрос про опыт был потому, что есть подозрение, что он не большой и поэтому много иллюзий. Вообще смысл того поста был - "добро пожаловать в реальность". Крупные системы для крупных "западных заказчиков" все чаще пишутся DB анэвере и предпочтительно и ОС анэвере тоже, как это не, может быть прискорбно для DBA. Это достигается либо с помощью всяких фрэймворков которые имеют SQL диалект либо с переносом логики в сторед процедуры причем на входе они принимаю что-нибудь типа xml, для того чтобы при добавлении параметра не надо было интерфейс менять. DB превращается хранилище xml. Все чаще от DB вообще отказываются. Короче, добро пожаловать в реальность... впрочем, как угодно.
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 687

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

funhouse (24.02.12 09:54) писал(a):
Ни с кем не хотел ничем меряться. Вопрос про опыт был потому, что есть подозрение, что он не большой и поэтому много иллюзий. Вообще смысл того поста был - "добро пожаловать в реальность". Крупные системы для крупных "западных заказчиков" все чаще пишутся DB анэвере и предпочтительно и ОС анэвере тоже, как это не, может быть прискорбно для DBA. Это достигается либо с помощью всяких фрэймворков которые имеют SQL диалект либо с переносом логики в сторед процедуры причем на входе они принимаю что-нибудь типа xml, для того чтобы при добавлении параметра не надо было интерфейс менять. DB превращается хранилище xml. Все чаще от DB вообще отказываются. Короче, добро пожаловать в реальность... впрочем, как угодно.
Угу. Только потом система начинает захлебываться от невероятного количества commit, или созданных очередей из-за различий в реализации изолирования транзакций в различных СУБД.
Подход разработчиков (работа с СУБД как с черным ящиком) понятен: один и тот же продукт может быть предложен в качестве решения заказчикам с различными СУБД.
Но заказчика то интересует работа его системы, ее устойчивость, безопасность, производительность, масштабируемость.
Редко приходится видеть, чтобы система падала от ошибок в СУБД (хотя такое, конечно, тоже бывает). В большинстве своем причины падения кроются в приложении, сбоях в железе или же неучете особенностей взаимодействия с другими системами (например, размещение LUNов в одной дисковой группе СХД с другими системами).

А по поводу "Все чаще от DB вообще отказываются" хотелось бы поподробней. Кто, в каких случаях и от чего отказывается? И чем заменяет?

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 6 158

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

funhouse (24.02.12 09:54) писал(a):
Ни с кем не хотел ничем меряться. Вопрос про опыт был потому, что есть подозрение, что он не большой и поэтому много иллюзий. Вообще смысл того поста был - "добро пожаловать в реальность". Крупные системы для крупных "западных заказчиков" все чаще пишутся DB анэвере и предпочтительно и ОС анэвере тоже, как это не, может быть прискорбно для DBA. Это достигается либо с помощью всяких фрэймворков которые имеют SQL диалект либо с переносом логики в сторед процедуры причем на входе они принимаю что-нибудь типа xml, для того чтобы при добавлении параметра не надо было интерфейс менять. DB превращается хранилище xml. Все чаще от DB вообще отказываются. Короче, добро пожаловать в реальность... впрочем, как угодно.
Понимаете ли, уважаемый собеседник, я практически не работала в аутсорсинг конторах по принципу "написал, спихнул, забыл". Я работаю онсайт. То есть: работаю в банке, сами приложение пишем, сами поддерживаем. И видим систему в работе, а не только со стороны простоты написания и спихивания нескольким разным клиентам с разными СУБД. Крупные банки могут позволить себе держать свой IT отдел и иметь заранее определенного вендора (IBM, Microsoft). И им не нужно таскать систему с одной платформы на другую, аки диван-транслятор в известной книжке. Точно знаю про три из пяти крупнейших банков страны, где живу, - у них всей IT отдел и заранее определенная платформа (остальные, подозреваю, что так же, но точно не знаю - не работала с ними). Аналогично в стране предыдущего проживания.
С другой стороны из личного опыта: в нашем банке 2 системы онлайн-банкинга (мы поддерживаем свою систему и систему дочернего банка). Одна система писалась под конкретную платформу. Другая - DB unaware.
Заточенная под конкретную платформу держит 1.5 миллиона клиентов и использует 16 CPU на каждой ноде (кластер, 2 ноды). Компиляция запросов занимает порядка 6% общего времени работы системы.
DB unavare держит 400 тысяч клиентов, кушает 32 CPU на каждой ноде (опять же, 2 ноды). Компиляция запросов занимает чуть больше 80% времени работы системы. А все потому, что используется динамика без параметр маркеров там, где могла бы (по примеру первой системы) использоваться статика. Но статика - это затачивание под конкретную СУБД. DB unaware система при ожидаемой в скором будущем нагрузке в 1.2 миллиона клиентов будет кушать 96 CPU (по крайней мере индусы клянутся, что этого хватит, я результатов тестов пока не видела) на каждой ноде (сравниваем с 16, тихо материмся).
Кроме того добрые дяди, писавшие DB unavare систему (угораздило же наш дочерний банк в кризис прикупить систему from the box типа из экономии, на доработку которой выкинуто уже столько, что проще было пару раз переписать самим) тоже считали, что база данных - это хранилище xml. Результат прост и красив: есть у нас табличка аудита, в которую, согласно требованиям, аудитится каждый чих клиента. Туда добрые дяди-индусы загоняют xml. Табличка за год работы системы имеет размер 580 гигов и каждый месяц прирастает 50 гигами. Данные необходимо хранить 18 месяцев. То есть к моменту первого удаления данных мы будем иметь табличку размера порядка 900 гигов. А поскольку система у нас DB unavare, то делать partitioning никто не стал. Табличка single partition. Время поиска по этой табличке несмотря на наличие правильного индексирования все себе представляют? Тантрический смысл хранения там xml непонятен никому.
Самописная система работает стабильно и тамошний админ пьет кофе. У нас сплошные пляски с бубном - как заставить это чудо индусской мысли работать и укладываться в SLA.
Так что мое сугубое ИМХО из собственного опыта: DB unaware системы хороши для небольших и средних заказчиков и аутсорсинг-контор. Конторам хорошо - code reuse и систему можно спихнуть нескольким заказчикам. Поэтому даже если конкретная платформа заранее известна, стараются писать так, чтобы потом этот же код подсунуть другому заказчику с другой платформой. Заказчикам хорошо - при небольших объемах данных такие системы вполне конкурентноспособны, особенно по цене. ТОлько вот очень крупным банкам такая система не подходит - потери на производительности сильно превышают выгоду от покупки DB unavare системы.

Кстати, какую альтернативу DB Вы можете предложить для банков?
P.S. прошу прощения за опечатки.. 7 утра на часах было.

Последний раз редактировалось nati_vostrikova; 24.02.12 в 16:29.
--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

R0bur R0bur в оффлайне

писатель
Сообщений: 1 462

R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный

nati_vostrikova (24.02.12 15:07) писал(a):
Кстати, какую альтернативу DB Вы можете предложить для банков?
Предполагаю, что речь идёт о так называемых "NoSQL" (или "key-value") базах данных (в противоположность традиционным SQL DB). Они действительно хорошо зарекомендовали себя в высоконагруженных системах, где не требуется сложная схема данных (сервисы социальных сетей и т. п.). Конечно, при этом бизнес-логика целиком возвращается в приложения со всеми вытекающими последствиями.

--------------------
Приходи тихо, проси мало, уходи быстро.
 

funhouse funhouse в оффлайне

графоман
Сообщений: 4 796

funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный

nati_vostrikova (24.02.12 15:07) писал(a):
Понимаете ли, уважаемый собеседник, я практически не работала в аутсорсинг конторах по принципу "написал, спихнул, забыл". Я работаю онсайт. То есть: работаю в банке, сами приложение пишем, сами поддерживаем. И видим систему в работе, а не только со стороны простоты написания и спихивания нескольким разным клиентам с разными СУБД. Крупные банки могут позволить себе держать свой IT отдел и иметь заранее определенного вендора (IBM, Microsoft). И им не нужно таскать систему с одной платформы на другую, аки диван-транслятор в известной книжке. Точно знаю про три из пяти крупнейших банков страны, где живу, - у них всей IT отдел и заранее определенная платформа (остальные, подозреваю, что так же, но точно не знаю - не работала с ними). Аналогично в стране предыдущего проживания.
С другой стороны из личного опыта: в нашем банке 2 системы онлайн-банкинга (мы поддерживаем свою систему и систему дочернего банка). Одна система писалась под конкретную платформу. Другая - DB unaware.
Заточенная под конкретную платформу держит 1.5 миллиона клиентов и использует 16 CPU на каждой ноде (кластер, 2 ноды). Компиляция запросов занимает порядка 6% общего времени работы системы.
DB unavare держит 400 тысяч клиентов, кушает 32 CPU на каждой ноде (опять же, 2 ноды). Компиляция запросов занимает чуть больше 80% времени работы системы. А все потому, что используется динамика без параметр маркеров там, где могла бы (по примеру первой системы) использоваться статика. Но статика - это затачивание под конкретную СУБД. DB unaware система при ожидаемой в скором будущем нагрузке в 1.2 миллиона клиентов будет кушать 96 CPU (по крайней мере индусы клянутся, что этого хватит, я результатов тестов пока не видела) на каждой ноде (сравниваем с 16, тихо материмся).
Кроме того добрые дяди, писавшие DB unavare систему (угораздило же наш дочерний банк в кризис прикупить систему from the box типа из экономии, на доработку которой выкинуто уже столько, что проще было пару раз переписать самим) тоже считали, что база данных - это хранилище xml. Результат прост и красив: есть у нас табличка аудита, в которую, согласно требованиям, аудитится каждый чих клиента. Туда добрые дяди-индусы загоняют xml. Табличка за год работы системы имеет размер 580 гигов и каждый месяц прирастает 50 гигами. Данные необходимо хранить 18 месяцев. То есть к моменту первого удаления данных мы будем иметь табличку размера порядка 900 гигов. А поскольку система у нас DB unavare, то делать partitioning никто не стал. Табличка single partition. Время поиска по этой табличке несмотря на наличие правильного индексирования все себе представляют? Тантрический смысл хранения там xml непонятен никому.
Самописная система работает стабильно и тамошний админ пьет кофе. У нас сплошные пляски с бубном - как заставить это чудо индусской мысли работать и укладываться в SLA.
Так что мое сугубое ИМХО из собственного опыта: DB unaware системы хороши для небольших и средних заказчиков и аутсорсинг-контор. Конторам хорошо - code reuse и систему можно спихнуть нескольким заказчикам. Поэтому даже если конкретная платформа заранее известна, стараются писать так, чтобы потом этот же код подсунуть другому заказчику с другой платформой. Заказчикам хорошо - при небольших объемах данных такие системы вполне конкурентноспособны, особенно по цене. ТОлько вот очень крупным банкам такая система не подходит - потери на производительности сильно превышают выгоду от покупки DB unavare системы.

Кстати, какую альтернативу DB Вы можете предложить для банков?
P.S. прошу прощения за опечатки.. 7 утра на часах было.
Вот именно потому что DB превращаются в хранилище xml и соотвественно поиск и отчеты в таких db становятся не эффективными от DB и отказываются вовсе. Наберите в гугле hadoop gfs solr. И этого не изменить. Структуры данных меняется постоянно и системы пишутся с учетом этого. У вас странное представление о оутсортинге это не сделал забыл это обычн оработа в смешанной команде, но это к делу не относится. Бесплатный совет - работа айти специалиста в банке - это плохая работа, пототму что айти специалист в банке это чернорабочий. Работы много а благодарности или удовлетворения от работы никакой. Никто не будет спорить с тем что специализированная система (хорошо написанная) будет эффективней чем общая но модернизация и адаптация будет стоить дороже чем добавить десяток-другой процессоров или виртуалок в кластер.

Последний раз редактировалось funhouse; 25.02.12 в 00:15.
 

funhouse funhouse в оффлайне

графоман
Сообщений: 4 796

funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный

Igoroshka (24.02.12 10:15) писал(a):
Угу. Только потом система начинает захлебываться от невероятного количества commit, или созданных очередей из-за различий в реализации изолирования транзакций в различных СУБД.
Подход разработчиков (работа с СУБД как с черным ящиком) понятен: один и тот же продукт может быть предложен в качестве решения заказчикам с различными СУБД.
Но заказчика то интересует работа его системы, ее устойчивость, безопасность, производительность, масштабируемость.
Редко приходится видеть, чтобы система падала от ошибок в СУБД (хотя такое, конечно, тоже бывает). В большинстве своем причины падения кроются в приложении, сбоях в железе или же неучете особенностей взаимодействия с другими системами (например, размещение LUNов в одной дисковой группе СХД с другими системами).

А по поводу "Все чаще от DB вообще отказываются" хотелось бы поподробней. Кто, в каких случаях и от чего отказывается? И чем заменяет?
Google например. Реляционные DB умирают.
Страницы: 1  2  3  4  5  6   из  12
 
Быстрый переход
[]
Вверх
HOSTER.BY: профессиональный хостинг и регистрация доменов .BY
Более 35000 сайтов выбрали нас. Присоединяйтесь!
 
РЕСУРСЫ ПОРТАЛА
   Все ресурсы