80

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

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

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

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 в оффлайне

графоман
Сообщений: 5 807

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 в оффлайне

графоман
Сообщений: 5 807

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 в оффлайне

графоман
Сообщений: 5 807

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 262

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 умирают.
 

Igoroshka Igoroshka в оффлайне

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

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

R0bur (24.02.12 19:01) писал(a):
Предполагаю, что речь идёт о так называемых "NoSQL" (или "key-value") базах данных (в противоположность традиционным SQL DB). Они действительно хорошо зарекомендовали себя в высоконагруженных системах, где не требуется сложная схема данных (сервисы социальных сетей и т. п.). Конечно, при этом бизнес-логика целиком возвращается в приложения со всеми вытекающими последствиями.
Конечно имелись ввиду либо NoSQL СУБД типа MongoDB, CouchDB, Cassandra, HBase, Google и т.д., либо объектно ориентированные типа Cache .
Хорошие, конечно, системы. Для своей ниши.
Кроме того все ведущие игроки на рынке СУБД так или иначе имеют в своих линейках подобные системы, используют их отдельные элементы в своих флагманских продуктах.

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

Igoroshka Igoroshka в оффлайне

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

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

funhouse (25.02.12 00:23) писал(a):
Google например. Реляционные DB умирают.
Эти сказки я слышу последние лет этак 10-15, начиная еще с постреляционных СУБД, пожалуй, с пиком, совпадающим с пиком популярности объектно-ориентированных СУБД. И..?

Спору нет, реляционны СУБД не всесильны. И не все может (и должно) быть впихнуто в жестко табулированную схему. И во многих приложениях реляционным СУБД прийдется подвинуться. Вернее, каждая из систем получит свою область применения. Но и только .
За примерами, хоть и несколько из другой области, не нужно далеко ходить: эвклидовая геометрия, квантовая механика, теория относительности, ...

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

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 807

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

Господа, дабы дать обсуждению новый толчок и дать ответ на вопрос, поляжет ли продакшен: как и предсказывалось, первый же запуск дневного батча после релиза - и онлайн ушел в астрал. 39 часов овертайма за выходные (суббота и воскресенье) были потрачены та то, чтобы подкрутить батч и заставить его не класть онлайн. Тихо молюсь о судьбе runstats в следующие выходные.
Зато теперь начальство бегает и заискивающе в глазки смотрит

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

Igoroshka Igoroshka в оффлайне

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

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

nati_vostrikova (08.03.12 02:36) писал(a):
Господа, дабы дать обсуждению новый толчок и дать ответ на вопрос, поляжет ли продакшен: как и предсказывалось, первый же запуск дневного батча после релиза - и онлайн ушел в астрал. 39 часов овертайма за выходные (суббота и воскресенье) были потрачены та то, чтобы подкрутить батч и заставить его не класть онлайн. Тихо молюсь о судьбе runstats в следующие выходные.
Зато теперь начальство бегает и заискивающе в глазки смотрит
Для начала с праздником .

Что касается системы. Тоже результат. Лучше, конечно, учиться на чужих ошибках. Но все предпочитают свои .
А как поставщих кэширования пояснял ситуацию и как оправдывался за свои прогнозы?

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

U-Cesar U-Cesar в оффлайне

писатель
Сообщений: 2 787

U-Cesar отключил(а) отображение уровня репутации

funhouse (25.02.12 00:23) писал(a):
Реляционные DB умирают.
Вы имеете в виду их вытеснение объектными БД?

Последний раз редактировалось U-Cesar; 15.03.12 в 17:46.
--------------------
momento mori
Момент - и в море (ц)
 

U-Cesar U-Cesar в оффлайне

писатель
Сообщений: 2 787

U-Cesar отключил(а) отображение уровня репутации

nati_vostrikova (08.03.12 02:36) писал(a):
Зато теперь начальство бегает и заискивающе в глазки смотрит
Угу, есть такой грешок. Когда всё работает, никто не замечает, обходят премиальными etc, но вот стоит лечь чему-нить, вот тут и наступает прозрение.

--------------------
momento mori
Момент - и в море (ц)
 

U-Cesar U-Cesar в оффлайне

писатель
Сообщений: 2 787

U-Cesar отключил(а) отображение уровня репутации

Igoroshka (25.02.12 10:06) писал(a):
Эти сказки я слышу последние лет этак 10-15, начиная еще с постреляционных СУБД, пожалуй, с пиком, совпадающим с пиком популярности объектно-ориентированных СУБД. И..?

Спору нет, реляционны СУБД не всесильны. И не все может (и должно) быть впихнуто в жестко табулированную схему. И во многих приложениях реляционным СУБД прийдется подвинуться. Вернее, каждая из систем получит свою область применения. Но и только .
За примерами, хоть и несколько из другой области, не нужно далеко ходить: эвклидовая геометрия, квантовая механика, теория относительности, ...
Хотя сама идея объектной СУБД весьма привлекательна, согласитесь.
Я покамест не шибко какой специалист по СУБД. Решаю тут прикладную задачку, поставленную начальством. Для конкретно моей задачи объектная СУБД была бы впору. Наверное

--------------------
momento mori
Момент - и в море (ц)
 

funhouse funhouse в оффлайне

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

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

U-Cesar (15.03.12 17:43) писал(a):
Вы имеете в виду их вытеснение объектными БД?
Нет. Я имею в виду, что реляционные СУБД используются на все более примитивном уровне - для хранения блобов (структурированных, чаще всего xml). То есть структуры данных больше не в схемах базы, а в xsd/xml. Раньше так не было. От баз требуется транзакционность и кокурентный доступ с хорошей скоростью. Происходит это потому что структуры данных должны быть гибкими и меняться быстро. кроме того реляционные базы даже изначально и даже по утверждению их "отца" плохо справлялись с отчетами.
 

U-Cesar U-Cesar в оффлайне

писатель
Сообщений: 2 787

U-Cesar отключил(а) отображение уровня репутации

funhouse (15.03.12 22:36) писал(a):
Нет. Я имею в виду, что реляционные СУБД используются на все более примитивном уровне - для хранения блобов (структурированных, чаще всего xml). То есть структуры данных больше не в схемах базы, а в xsd/xml. Раньше так не было. От баз требуется транзакционность и кокурентный доступ с хорошей скоростью. Происходит это потому что структуры данных должны быть гибкими и меняться быстро. кроме того реляционные базы даже изначально и даже по утверждению их "отца" плохо справлялись с отчетами.
Спасибо за комментарий.

--------------------
momento mori
Момент - и в море (ц)
 

Igoroshka Igoroshka в оффлайне

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

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

funhouse (15.03.12 22:36) писал(a):
Нет. Я имею в виду, что реляционные СУБД используются на все более примитивном уровне - для хранения блобов (структурированных, чаще всего xml). То есть структуры данных больше не в схемах базы, а в xsd/xml. Раньше так не было. От баз требуется транзакционность и кокурентный доступ с хорошей скоростью. Происходит это потому что структуры данных должны быть гибкими и меняться быстро. кроме того реляционные базы даже изначально и даже по утверждению их "отца" плохо справлялись с отчетами.
Подтверждающие ссылки, пожалуйста. О все большем использовании РСУБД для хранения xml blob. О необходимости быстро менять структуру данных. Об утверждении "отца" (кто имелся ввиду?)

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

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 807

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

funhouse (15.03.12 22:36) писал(a):
Нет. Я имею в виду, что реляционные СУБД используются на все более примитивном уровне - для хранения блобов (структурированных, чаще всего xml). То есть структуры данных больше не в схемах базы, а в xsd/xml. Раньше так не было. От баз требуется транзакционность и кокурентный доступ с хорошей скоростью. Происходит это потому что структуры данных должны быть гибкими и меняться быстро. кроме того реляционные базы даже изначально и даже по утверждению их "отца" плохо справлялись с отчетами.
Первый вопрос, который я бы задавала, если бы я рисовала архитектуру данных этой базы был бы: а нужен ли там xml на самом деле. Я, конечно понимаю, что xml это модно, но, как показывает практика, 90% систем прекрасно живут при условии грамотно спроектированной реляционной структуры. Не так много систем, где частота изменения структуры данных такова, что нет возможности предусмотреть/спроектировать реляционную структуру и есть необходимость хранить ее в xml схеме. По крайней мере далеко не все данные настолько волатильны по структуре. Для волатильных по стурктуре данных используем xml, для остальных (которых будет большинство) реляционную структуру. Но с точки зрения "гибкости системы" в плане минимальной переделки от одной задачи (заказчика) к другой (другому) xml показывает себя неплохо. Но мы про возможность впарить один и тот же продукт многим заказчикам или о стабильной системе с высокой производительностью говорим?

Дело в том, что в архитектуре данных есть постулат (и лично я считаю его правильным и стараюсь придерживаться), который гласит: не храните в базе данных больше, чем Вам это необходимо для решения поставленной задачи. Для примера: не храните таймстемп там, где нужна только дата, не храните дату там, где нужны год и месяц, не храните весь номер кредитки если для ваших нужд нужны только последние 4 цифры и т.д (надеюсь, нет необходимости объяснять, почему). То же самое действительно и в отношении xml. Если можно безболезненно для приложения вытащить значения из xml и положить их в реляционную структуру без ухудшения производительности - я использую реляционную структуру.

Если будет необходимость хранить именно xml - первое решение, которое я буду рассматривать, будет xml - столбец, дабы облегчить манипуляции с данным столбцом и его полями при условии, что данные из этого xml активно используются. Если судить по Вашему посту, значения из xml и его структуру вы использовать все-таки собираетесь, поэтому запихивать xml в BLOB в таком случае - это нечто из измерения Извр (см Р. Асприн "Еще один великолепный МИФ")

Блоб (может хотя-бы в клоб положим? или вам xml только в бинарном виде хранить надо, в текстовом не позволяют убеждения? ) для хранения xml я буду использовать ТОЛЬКО при условии, что xml при любых условиях должен остаться в первозданном виде (т.е. вид xml должен остаться одним и тем же даже если xml-схема поменялась) и при условии, что его поля по отдельности будут использоваться КРАЙНЕ редко. Пример - настройки для использования системы присылаются пользователю в виде xml. В данном случае даже если схема поменялась, необходимо хранить тот вид xml, который мы послали клиенту для того, чтобы трекать возникающие проблемы.

Поэтому позволю себе не согласиться с утверждением, что базы превращаются в хранилище xml. Чаще всего это происходит от нежелания/неумения нормально эти системы проектировать. ИМХО.

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

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 807

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

Igoroshka (08.03.12 14:46) писал(a):
Для начала с праздником .

Что касается системы. Тоже результат. Лучше, конечно, учиться на чужих ошибках. Но все предпочитают свои.
А как поставщих кэширования пояснял ситуацию и как оправдывался за свои прогнозы?
Спасибо за поздравления, коллега!
Поставщик кэширования сказал "OOPS" и на этом от дальнейших комментариев отказался. Когда нашей команде начальство из дочернего банка сказало буквально следующее: "Да, Вы нас предупреждали, что вендор поставил нам плохой код, но Вы все равно утратили наше доверие, потому что мы вам не поверили. Поэтому мы требуем передать всю разработку и поддержку вендору" (не пробуйте понять логику, она там даже рядом не пробегала ), ваша покорная слуга хлопнула на стол заявление об уходе и ушла поддерживать систему сравнимую с процессингом Визы по размеру и нагрузке на зарплату на 30% выше. И пусть сами каждую ночь перестартовывают сервер баз данных по нескольку раз.

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

Igoroshka Igoroshka в оффлайне

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

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

nati_vostrikova (30.03.12 03:47) писал(a):
...не храните весь номер кредитки если для ваших нужд нужны только последние 4 цифры и т.д (надеюсь, нет необходимости объяснять, почему)...
Здесь еще о PCI DSS вспомним .

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

Igoroshka Igoroshka в оффлайне

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

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

nati_vostrikova (30.03.12 04:02) писал(a):
Спасибо за поздравления, коллега!
Поставщик кэширования сказал "OOPS" и на этом от дальнейших комментариев отказался. Когда нашей команде начальство из дочернего банка сказало буквально следующее: "Да, Вы нас предупреждали, что вендор поставил нам плохой код, но Вы все равно утратили наше доверие, потому что мы вам не поверили. Поэтому мы требуем передать всю разработку и поддержку вендору" (не пробуйте понять логику, она там даже рядом не пробегала ), ваша покорная слуга хлопнула на стол заявление об уходе и ушла поддерживать систему сравнимую с процессингом Визы по размеру и нагрузке на зарплату на 30% выше. И пусть сами каждую ночь перестартовывают сервер баз данных по нескольку раз.
Ай, маладца.
"Ах, я чем виноват?" - "Молчи! устал я слушать,
Досуг мне разбирать вины твои, щенок!
Ты виноват уж тем, что хочется мне кушать".
Логи им в руки, каску на голову и тазик прикрыть зад .

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

R0bur R0bur в оффлайне

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

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

nati_vostrikova (30.03.12 04:02) писал(a):
"... но Вы все равно утратили наше доверие, потому что мы вам не поверили. Поэтому мы требуем передать всю разработку и поддержку вендору"
Смахивает на запланированную операцию по реструктуризации с сокращением штата.

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

U-Caesar U-Caesar в оффлайне

графоман
Сообщений: 5 780

U-Caesar отключил(а) отображение уровня репутации

U-Cesar (01.02.12 08:59) писал(a):
Масштабируемость, разработка приложений, опыт эксплуатации, жизненный цикл, защита данных.
Дискуссия
В тырнетах надыбал информацию про СУБД РВ "Линтер". Якобы самая устойчивая в плане защиты информации. Действительно, что-ли?
 

Igoroshka Igoroshka в оффлайне

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

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

U-Caesar (08.05.12 17:05) писал(a):
В тырнетах надыбал информацию про СУБД РВ "Линтер". Якобы самая устойчивая в плане защиты информации. Действительно, что-ли?
Еще бы знать, что значит "самая устойчивая" и в защите какой информации.
Да, в вики указано, что "СУБД ЛИНТЕР — единственная в своем классе, имеющая сертификаты[5] на соответствие 2 классу защиты информации от несанкционированного доступа[6] и 2 уровню контроля отсутствия недекларированных возможностей[7] для СВТ". В действительности, как и следует понимать, речь идет о "комплексе средств защиты СУБД "Линтер" версии 5.9 под управлением ОС ..." (http://linter.ru/ru/company/licenses/)

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

toggle.by toggle.by в оффлайне

новичок
Сообщений: 1

toggle.by на старте

День добрый,можно узнать, кто-нибудь еще в Минске занимается подобной деятельностью ? см. www.toggle.by
 

Igoroshka Igoroshka в оффлайне

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

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

toggle.by (22.04.13 17:19) писал(a):
День добрый,можно узнать, кто-нибудь еще в Минске занимается подобной деятельностью ?
Рекламой ресурса ?
Что касается Оракл, в Минске (и не только) больше десятка контор со специалистами с подтвержденной (в отличие от рекламируемого ресурса) квалификацией ДБА.

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

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 807

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

toggle.by (22.04.13 17:19) писал(a):
День добрый,можно узнать, кто-нибудь еще в Минске занимается подобной деятельностью ? см. www.toggle.by
Раскруткой сомнительных стартапов? Вроде никто, мы тут о базах данных речь ведем.

Ребята, вы бы хоть для разнообразия написали, кто вы, в каких проектах участвовали, на кого работали, какими сертификатами обладаете. А то кроме голословного утверждения, что вы "команда высококвалифицированных специалистов" и очень эмоционального описания мытарств без вашей ценной помощи, у вас на сайте ничего нет.

П.С. Задачка для оптимизаторов уровня "детский сад, ясельная группа": По табличке 1 бегут запросы, после того, как напротив таблички 2 выполнили 10.000 апдейтов (ну, мейнтенанс такой был, баг правили), запросы по табличке 1 стали бежать в 3-5 раз медленнее. Что произошло и как лечить? . Привязка к ДБ2, если что.

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

Igoroshka Igoroshka в оффлайне

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

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

nati_vostrikova (24.04.13 06:03) писал(a):
Раскруткой сомнительных стартапов? Вроде никто, мы тут о базах данных речь ведем.

Ребята, вы бы хоть для разнообразия написали, кто вы, в каких проектах участвовали, на кого работали, какими сертификатами обладаете. А то кроме голословного утверждения, что вы "команда высококвалифицированных специалистов" и очень эмоционального описания мытарств без вашей ценной помощи, у вас на сайте ничего нет.

П.С. Задачка для оптимизаторов уровня "детский сад, ясельная группа": По табличке 1 бегут запросы, после того, как напротив таблички 2 выполнили 10.000 апдейтов (ну, мейнтенанс такой был, баг правили), запросы по табличке 1 стали бежать в 3-5 раз медленнее. Что произошло и как лечить? . Привязка к ДБ2, если что.
Я бы еще добавил вопросы: а доступ к базам данных обозначенных поставщиков решений есть? ну там MOS, IBM Support? А соответствующее "железо"?

Только, Нати, что-то мне подсказывает, что мы здесь тогле.бу больше не увидим.

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

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 807

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

Igoroshka (24.04.13 09:08) писал(a):
Я бы еще добавил вопросы: а доступ к базам данных обозначенных поставщиков решений есть? ну там MOS, IBM Support? А соответствующее "железо"?

Только, Нати, что-то мне подсказывает, что мы здесь тогле.бу больше не увидим.
Ну, некорректные вопросы про железо и связи с саппортами я решила не задавать. ИМХО, ответ и так ясен . Если ребята даже не сподобились оформить сайт более чем на 3 странички...

Мне вот тоже что-то подсказывает, что данных персонажей мы больше тут не увидим, и моя задачка останется без ответа .
"Жаль, что нам так и не удалось послушать начальника транспортного цеха" (с)

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

Igoroshka Igoroshka в оффлайне

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

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

nati_vostrikova (24.04.13 14:04) писал(a):
Ну, некорректные вопросы про железо и связи с саппортами я решила не задавать. ИМХО, ответ и так ясен . Если ребята даже не сподобились оформить сайт более чем на 3 странички...

Мне вот тоже что-то подсказывает, что данных персонажей мы больше тут не увидим, и моя задачка останется без ответа .
"Жаль, что нам так и не удалось послушать начальника транспортного цеха" (с)

Особенно понравилось:
"Требуется аналитик по производительности СУБД Oracle.
...
Требования :
...
Умение развернуть и оптимально настроить серверную и клиентскую часть, средства мониторинга
..."

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

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 807

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

Igoroshka (24.04.13 15:01) писал(a):
Особенно понравилось:
"Требуется аналитик по производительности СУБД Oracle.
...
Требования :
...
Умение развернуть и оптимально настроить серверную и клиентскую часть, средства мониторинга
..."
Спасибо за наводку. Получила массу удовольствия, читая вакансию.

"Мужчина" - Обожаю это требование
" , высшее техническое образование" - куда же без него

" Опыт работы DBA, PL\SQL- разработчиком от 3-х лет на промышленных системах" - и эти люди потом будут называться "Группой высококвалифицированных программистов" ?


" Знания технологий, решений и оборудования в области систем хранения и обработки данных"

" Умение развернуть и оптимально настроить серверную и клиентскую часть, средства мониторинга" - Угу, это как требование в вакансии "умение писать код без багов"...

"Умение создать\восстановить резервную копию" - О, Боги!

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

Ребята, вы сделали мое утро!

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

Igoroshka Igoroshka в оффлайне

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

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

nati_vostrikova (24.04.13 17:08) писал(a):
...
Особенно повеселило про удаленку
Ага, к, например, банковской системе или бухгалтерии. Через teamviewer.

Да ну их .
Нати, скажите, пожалуйста, попадался ли Вам детальный перечень функций ДБА?

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

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 807

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

Igoroshka (24.04.13 20:44) писал(a):
Ага, к, например, банковской системе или бухгалтерии. Через teamviewer.

Да ну их .
Нати, скажите, пожалуйста, попадался ли Вам детальный перечень функций ДБА?
как выдержка из должностных обязанностей или как часть описания вакансии? На всякий случай попробую найти свой контракт.

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

Igoroshka Igoroshka в оффлайне

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

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

nati_vostrikova (25.04.13 04:55) писал(a):
как выдержка из должностных обязанностей или как часть описания вакансии? На всякий случай попробую найти свой контракт.
Более подробно, наверное, будет в должностных обязанностях. В личку скину свой докУмент, который писал по просьбе одного из заказчиков.

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

publict publict в оффлайне

графоман
Сообщений: 10 662

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

Может быть здесь найдутся специалисты у которых 1С:Предприятие 8 использует PostgreSQL? Да и просто может те кто крутится около 1с8 выскажите свое мнение. Интересно будет услышать что-то на эту тему, спасибо.

--------------------
"Если перестанем пить вообще, то будет другая беда" (c) Лукашенко
 

U-Caesar U-Caesar в оффлайне

графоман
Сообщений: 5 780

U-Caesar отключил(а) отображение уровня репутации

publict (27.04.13 14:41) писал(a):
Может быть здесь найдутся специалисты у которых 1С:Предприятие 8 использует PostgreSQL? Да и просто может те кто крутится около 1с8 выскажите свое мнение. Интересно будет услышать что-то на эту тему, спасибо.
Мнение о чём? Постгрес - хорошая система, работаю (фактически изучаю, погружаясь всё "глубже") с ней. Считаю её перспективной. Можно ли на неё "навесить" 1С? Полагаю, да. Развернуть в принципе можно всё, что угодно можно. От экспертной системы до книгохранилища.
 

Igoroshka Igoroshka в оффлайне

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

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

Действительно, вопрос непонятен.
Официально постгрес поддерживается 1С -- http://v8.1c.ru/requirements/, причем на разных платформах.

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

publict publict в оффлайне

графоман
Сообщений: 10 662

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

Да, он поддерживается, но мне интересен практический опыт работы 1с8 в связке с постгрес. Может кто-то тестировал, сравнивал производительность postgres и mssql.
Ну и вообще интересно, заморачивается ли кто-нибудь на этом? Потому что большинство используют mssql.
Конечно хотелось бы увидеть живого человека, который скажет что у него 200 пользователей в 1с одновременно и база на postgres.

--------------------
"Если перестанем пить вообще, то будет другая беда" (c) Лукашенко
 

publict publict в оффлайне

графоман
Сообщений: 10 662

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

И самое главное что postgres был выбрал не потому что "люблю все бесплатное", а хотя бы логически понятно для бизнеса - сэкомил денег не потеряв в производительности (а лучше даже прибавив в производительности, или немного хуже производительность но взял в масштубируемости ) и т.д.

--------------------
"Если перестанем пить вообще, то будет другая беда" (c) Лукашенко
 

publict publict в оффлайне

графоман
Сообщений: 10 662

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

publict (27.04.13 14:41) писал(a):
Может быть здесь найдутся специалисты у которых 1С:Предприятие 8 использует PostgreSQL? Да и просто может те кто крутится около 1с8 выскажите свое мнение. Интересно будет услышать что-то на эту тему, спасибо.
хм. вроде довольно понятный текст

--------------------
"Если перестанем пить вообще, то будет другая беда" (c) Лукашенко
 

U-Caesar U-Caesar в оффлайне

графоман
Сообщений: 5 780

U-Caesar отключил(а) отображение уровня репутации

publict (29.04.13 20:59) писал(a):
Да, он поддерживается, но мне интересен практический опыт работы 1с8 в связке с постгрес. Может кто-то тестировал, сравнивал производительность postgres и mssql.
Ну и вообще интересно, заморачивается ли кто-нибудь на этом? Потому что большинство используют mssql.
Конечно хотелось бы увидеть живого человека, который скажет что у него 200 пользователей в 1с одновременно и база на postgres.
Нет, именно с 1С у меня опыта пока нет. Java + Postgres пока пытаюсь изучать.
Производительность Постгреса выше МС в относительном выражении. Смотря какая у Вас задача и нагрузка на СУБД. Смотреть нужно в комплексе, короче говоря.
Если у Вас есть возможность выбора инструментальных средств и Вы не ограничены во времени, советую.
Система открытая, значит есть возможность реализации своего интерфейса. Если это для Вас актуально.
 

Igoroshka Igoroshka в оффлайне

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

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

publict (29.04.13 21:04) писал(a):
И самое главное что postgres был выбрал не потому что "люблю все бесплатное", а хотя бы логически понятно для бизнеса - сэкомил денег не потеряв в производительности (а лучше даже прибавив в производительности, или немного хуже производительность но взял в масштубируемости ) и т.д.
Постгрес в бытность Ingres. Интересная СУБД была.
На предыдущей работе использовали mysql и постгрес. Первый работал пошустрее, но постгрес брала функционалом.
На счет масштабируемости. Масштабировать как? Горизонтально скорее всего не получится: распараллеливание в значительной мере определяется логикой приложения, плюс, насколько я понимаю, постгрес не поддерживает кластеризацию. Остаются гигагерцы. Ну и перенос файлов данных с локальных дисков на SANы (процессор на RISC/SPARC менять ведь не собираетесь) и настройка всего стека: диск(и), файловая система, параметры ОС, память.

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

U-Caesar U-Caesar в оффлайне

графоман
Сообщений: 5 780

U-Caesar отключил(а) отображение уровня репутации

Igoroshka (30.04.13 00:25) писал(a):
... постгрес не поддерживает кластеризацию...
Гуголь говорит: "Cybercluster" Решение на базе Постгреса.
Но это геморрой. Нужен ли он, большой вопрос. Если речь идёт только про 1С, то, ИМХО, лучше взять коммерческое решение. Тот же mssql

ЗЫ У меня был случай. Пригласили установить комплекс с базой. Установил, настроил по методичке и ушёл. Дык потом долго просили что-то донастроить. Специалист, который разрабатывал и вёл всё это дело (ЕМНИП, на основе mysql), уволился, а адекватной замены ему не нашли.
Это я к тому, что не нужно ничего фантазировать и впаривать отсебятину, чревато. Уж лучше договор заключить с кем-то, если нет возможностей пользовать платные решения.
Остаются гигагерцы.
Меня, честно говоря, всё это напрягает, погоня за герцами.
 

Igoroshka Igoroshka в оффлайне

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

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

U-Caesar (30.04.13 11:56) писал(a):
Гуголь говорит: "Cybercluster" Решение на базе Постгреса.
Но это геморрой. Нужен ли он, большой вопрос. Если речь идёт только про 1С, то, ИМХО, лучше взять коммерческое решение. Тот же mssql

ЗЫ У меня был случай. Пригласили установить комплекс с базой. Установил, настроил по методичке и ушёл. Дык потом долго просили что-то донастроить. Специалист, который разрабатывал и вёл всё это дело (ЕМНИП, на основе mysql), уволился, а адекватной замены ему не нашли.
Это я к тому, что не нужно ничего фантазировать и впаривать отсебятину, чревато. Уж лучше договор заключить с кем-то, если нет возможностей пользовать платные решения.

Меня, честно говоря, всё это напрягает, погоня за герцами.
Это не кластерное решение, насколько я понял после беглого просмотра страницы. Вернее, это активно-пассивный кластер. В таких кластерах о масштабировании можно говорить с натяжкой -- выполнение тяжелых запросов на резервной БД, резервное копирование, ну и, собственно, создание резервного сервера.

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

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

U-Caesar U-Caesar в оффлайне

графоман
Сообщений: 5 780

U-Caesar отключил(а) отображение уровня репутации

publict (29.04.13 21:04) писал(a):
И самое главное что postgres был выбрал не потому что "люблю все бесплатное"
Если Ваша организация может позволить себе держать специалиста, то, естественно, можно обратить внимание на опенсорсные решения.
 

U-Caesar U-Caesar в оффлайне

графоман
Сообщений: 5 780

U-Caesar отключил(а) отображение уровня репутации

Igoroshka (30.04.13 12:18) писал(a):
Погоня за герцами часто единственная альтернатива для приложений с плохим распараллеливанием или с принципиальной невозможностью распараллеливания. Понятно, иногда гораздо правильней было бы переписать код, но это далеко не всегда возможно.
Всё так, да.
За распараллеливанием перспектива, но специалистов дефицит.
 

Igoroshka Igoroshka в оффлайне

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

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

U-Caesar (30.04.13 14:42) писал(a):
Всё так, да.
За распараллеливанием перспектива, но специалистов дефицит.
Ну, не все задачи поддаются распараллеливанию. Логика может требовать именно последовательного доступа. В этом случае -- гигагерцы, большой процессорный кэш. Плюс оптимизация ОС: NUMA, дисковый ввод/вывод, флэш.
Если требуется большее -- путь к спаркам с их динамическим распределением процессорных ресурсов.
Сейчас многие системы умеют довольно неплохо распараллеливать нагрузку (в определенных пределах, конечно). Применительно к СУБД Оракл умеет это делать в своих СУБД. Очень хорошо это выражено в экзадатах.
У IBM ДБ2 наверняка умеет "раскладывать" запрос по отдельным процессам (Нати сможет прояснить ситуацию). Ну и купленная пару лет нетецца.
И, естественно, терадата со своими аппаратно-программными комплексами.
Но, надо сказать, все эти решения очень недешевые. Цена начинается с 5-значных чисел, очень быстро переходя к 6-7-значным.

Последний раз редактировалось Igoroshka; 30.04.13 в 16:46.
--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
Страницы: 1  2  3  4  5  6   из  8
Загрузка...
 
Быстрый переход
[]
Вверх
HOSTER.BY: профессиональный хостинг и регистрация доменов .BY
Более 35000 сайтов выбрали нас. Присоединяйтесь!