У кого стоит такой винегрет, собираюсь переходить на новые сервера, очень интересно отзывы, мелкософт не охота, интересна 1с 8.2 т.к. есть свой тонкий клиент, да и web-морда, объем базы ну пару гигов в год.
Производительность 1с сервера 8.1 в линухах такая же как и в винде. Все это упрется в производительность сервера баз данных. Постгри он и в Африке постгри. При очень больших объемах данных вы уткнетесь в его производительность. DB2 лучше, но мы его пробывали только в качестве теста. Реально на нем работать страшновато, хотя при серьезной подготовке специалиста можно было бы попробовать. Все это касаемо 8.1 и больших баз данных. На маленьких базах постгри вполне хватит. 8.2 пробуем только в тестовых режимах. И я думаю у многих так, поскольку готовых конфигураций под 8.2 со всеми документами управляемыми формами я еще не видел, УПП по крайней мере точно . Так что реальные данные о производительности, и что немаловажно, стабильности можно будет услышать только после февраля-марта.
мои коллеги неоднократно сталкивались с "экономией" денег предприятиями, когда они выбирали Postgres, через некоторое время они начинали сильно сожалеть об этом.
Если базы небольшие (менее 100 гигов) то с постгри (имею опыт только под мандривой) проблем не будет никаких (я так надеюсь), при условии что бэкапы делаются регулярно. При базе в 200 - 300 гигов я бы уже побоялся ставить постгри.. На такие объемы используем пока что только MS SQL. Переводить на другие платформы знаний не хватает да и острой необходимости пока что не было. Только из "спортивного" интереса пробуем. А так,Постгри для 1с 8.1 - вполне бюджетно. У нас на одном из заводов по финансовым причинам он стоит. За 2 года был только один затык но действительно серьезный. Решили проблему только снеся базу начисто с сервера и создав ее заново. Причем именно в новую базу!!! с загрузкой из dt и соответственно генерацией таблиц и индексов. Видимо серьезный косяк был в служебных данных, кэше или в планах запросов если даже поднятие бэкапов или загрузка dt в туже базу не приводило к востановлению работоспособности. ---------- Сообщение добавлено 16.11.2010 11:42 ---------- А можете привести примеры причин почему они начали жалеть об этом? Профессиональный интерес .. ---------- Сообщение добавлено 16.11.2010 11:48 ---------- У меня были случаи когда запрос с большим количеством объединений по куче полей просто отказывался работать в MS SQL2000. Потом конечно его переписали, разбив на временные таблицы, но в оригинале он выносил мозг MSSQL2000 (Расчет взносов ЕСН в одном из первых релизов ЗУП 2.5). Это я к тому что иногда и код не расчитан на возможности сервера БД.
потмоу что начиная уже с одного гигабайта стали возникать проблемы с производительностью, "слетом" индексом и т.д. количество админского труда возрастало в разы, а пользователи сидели и "курили" пока админ работал не покладая рук. ---------- Сообщение добавлено 16.11.2010 14:15 ---------- выдавал синтаксическую ошибку или медленно работал?
Вылетала Ошибка SQL с определенным кодом (сейчас уже не помню, но попытаюсь поискать). Как удалось расшифровать код ошибки - ошибка переполнения возникшая при большом количестве объединений (так по крайней мере отписалась 1с). Решили тогда эту проблему оперативно - перебросили базу на ms sql 2005 (как посоветовали 1с-ники) и забыли об этом. Благо было 2 сервера sql. Сейчас на одном из заводов крутится на postgreSQL 8.3 под федорой 8.0 несколько баз. Самая большая больше 40 гигов. Да запросы работают медленнее чем в MSSQL раза в 2 но они и нестоит ничего... Если говорить о привязке к 1с то кроме CAL 1c еще бы пришлось оплачивать CAL MS SQLServer`а (которые стоят кстати дороже CAL`а 1с). Падений индекса нет. Сервера загружены круглосуточно. Вот что наш админ конкретизировал ---------- Сообщение добавлено 16.11.2010 14:56 ---------- Вот кстати похожая ошибка, но не она... Тоже воспроизводилать только на 2000м. на 2005-м работала. http://www.forum.mista.ru/topic.php?id=364948 http://www.forum.mista.ru/topic.php?id=373135 http://www.buh.ru/forum/thread.jsp?id=481103 ошибки в данных (типе данных) там небыло!! Запрос прекрасно проходил в 2005-м. к сожалению ссылку на партнерский сайт, где обсуждалась эта ошибка, выложить не могу.
Skype использует PostgreSQL для хранения базы пользователей и ничего не боится. Я думаю, база у Skype будет побольше гигабайта. Возможно, конечно, что криворукие 1С-ники что-то поломали внутри постгреса своими патчами. Но я подозреваю, что "не покладающий рук" админ просто не в курсе про существование файла postgresql.conf.
Вопрос не в том, какая база лучше, а в том, какая, для чего подходит. Тот-же postrgre прекрасно подойдет для задач скайпа, (как мускул, тока с некими ограничениями), её основные задачи Ну, это я конечно грубо SELECT * from USERS Where id=.... на основании этого типа SELECT id.Contact where ... остальное делает клиентское ПО и сервер skype Ну и при регистрации, обновлении инфы, добавление контактов в 1с-ке дело на много корявее, там база значительно меньшн, но запросов типа Alter, join, update, insert и тд. при проведении однового документа в разы больше, а вот косяки и всем известные косяки http://www.postgresql.org/docs/current/static/explicit-locking.html ну не совсем они, но косяки имеются
с некоторыми ограничениями, это я про мускул, классный, быстрый - для простых запросов, не дружит с SMP, а для больших баз это критично, да и так по мелочи
http://v8.1c.ru/overview/postgresql.htm и http://v8.1c.ru/overview/Term_000000642.htm#1 особенно Если я правильно понимаю, то фраза (для postrgre) о том, что "в режиме автоматического управления блокировками в транзакции используются табличные блокировки СУБД" говорит о том, что MS SQL оно точно проиграет при тестах на производительность при многопотоковом проведении документов в типовых конфигурациях.
MenBS, все зависит от квалификации специалиста, занимающегося настройкой системы. Вот достаточно показательный пример: http://www.sql.ru/forum/actualthread.aspx?tid=528465
Beagle 2, это не показательный пример, это какой-то частный случай какой- то обработки в какой-то организации. за показательными примерами нужно сюда: tpc.org
AlTk, топикстартер вроде спрашивал не о производительности синтетических тестов, а как раз про частный случай обработки в организации, конкретно в 1С.
Beagle 2, да мало ли что он там накрутил в серверах. может если бы он дальше стал крутить - MS SQL быстрее оказался, с другой стороны может какая-то другая операция на постгресе теперь гораздо медленнее выполняется или на том же сиквеле. зачем на примере какого-то конкретного частного случая, приучастии человеческого фактора проводить обобщения? ПС. я уже писал как-то. вроде бы одна и таже БД, а на разных филиалах разная подкрутка нужна.
Странный вопрос. Постгрес на винде - это вообще не тест. Тест - это выполнение какой-либо задачи. Работа 1С на реальном наборе данных - это не синтетический тест.
Beagle 2, Выполнение одинаковой задачи на ксеоне с мсскл и селероне с постгресом - тоже будет реальным тестом? + конфиг не выложил тестер. Тот же мускул после ковыряния конфига в несколько раз быстрее будет работать. Не учли?
Вот мусклу я бы точно ничего ценного не доверил, особенно на штатной MyISAM... А если учесть его манеру работы со вложенными запросами, то неудивительно, почему 1С выбрала постгрес.