Тогда мы идем к вам!
Некоторые авторитетные товарищи прямо и недвусмысленно отказываются отвечать на вопрос: «Какая СУБД лучше?». Другие — менее авторитетные товарищи — говорят: «Только MS SQL Server принесет счастье в ваш дом». Третьи — уже совсем не авторитетные товарищи — несут в массы мнение об опенсорсе как единственном обладающем реальной производительностью железа ПО; а в продуктах Microsoft через строчку Sleep(random) понатыкано.
В целях выяснения — кто же прав — и была задумана эта статья. А поскольку каждое мнение должно быть аргументировано — было проведено сравнительное тестирование производительности для следующих продуктов:
- Microsoft SQL Server 2008 R2
- PostgreSQL для Linux
- PostgreSQL для Windows
Oracle и DB2 решено пока не трогать. Они относительно малораспространены: немногие возьмутся их внедрять в продакшн и поддерживать. Да и официально рекомендуемого дистрибутива Oracle от 1С нет. К тому же пара «Postgre — MsSQL» — яркий пример противостояния «Блокировочник vs Версионник».
Впрочем в нашей задаче речь о многопользовательской работе — где разница между блокировками и версионированием особенно заметна — не идет: мы желаем лишь сравнить пропускную способность на запись.
И сравним!
И сравнили.
Результаты сравнения прилагаются.
Вкратце результат сравнения таков: производительность Microsoft SQL Server и PostgreSQL принципиально не отличается при условии: речь идет о PostgreSQL на Linux. А вот на Windows PostgreSQL ставить не следует — нерационально это.
А поскольку никакой тюнинг СУБД (кроме самого базового) не проводился — следует признать: правы первые — наиболее авторитетные товарищи.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
PS В силу неочевидности некоторых функций редактора публикаций файл прикрепляю в комментариях.
Прямая ссылка:
имхо тема теста не раскрыта…я уж молчу, что использовать в сравнении ms sql express как полноценный ms sql некорректно.
сферично, вакуумно…
(2) cool.vlad4, разъясните пожалуйста, в чем же некорректность? Чем так ограничен Express, что его нельзя использовать на базах, не достигающих и 100Mb?
(3) vano-ekt, ага, как любая чисто теоретическая задача.
Вы тесты от Гилёва проводили? Было бы неплохо сравнить эти показатели.
Ещё в выборе очень немалую роль играет сопровождение: как минимум, разностные бэкапы на Постгресе — дело нетривиальное в отличие от MS SQL. На базе в ~400ГБ мы в своё время сравнили тупо снятие и развёртку бэкапа, сравнили пересчёт итогов. Без тюнинга Постгрес в пролёте.
Для баз до 10 ГБ Постргес (за исключением работы под Linux) хорош только одним: если база перевалит за этот предел, вы этого не заметите. В случае с MS SQL Express раз в месяц приходилось залазить и чистить какие-нибудь старые логи загрузок или версии объектов, иначе база просто не работала.
(4) что за базы такие в 100 мб? вы писали, что ваш тест только для баз в 100 мб? нет? ну а чё тогда…читаем
особенно внимательно читаем про cpu и memory limits
(4) и такое замечание, тем у кого база 100 мб, кто использует ms sql express, поскольку его хватает, вообще по барабану тесты и что использовать, хоть ms, хоть postgre. разве, что вопрос в цене обслуживающего персонала.
А ведь для Windows они рассматриваются как альтернатива MS SQL чаще, чем Postgre. Стала бы 1С поддерживать Postgre, если бы не выход в Linux-среду?
Обычно выбор в пользу Postgre делается не на основе скорости работы в сравнении с MS SQL и даже не на основе надежности, а на основе стоимости лицензий и доступности специалистов.
В качестве примера приведу две крупные розничные сети. Первая использует только MS SQL. Стоимость лицензий на сервера Windows и MS SQL Server удерживает от того, чтобы перевести базы на SQL во всех магазинах, где есть более 4-ех компьютеров. Файловые базы иногда сыпятся, скорость работы при активном потоке покупателей снижается.
Вторая сеть свои магазины, где есть более 4-ех работающих с 1С компьютеров, переводит базы на PostgreSQL+Linux. Образ системы присылается из Москвы, где нужных специалистов найти не проблема. Бэкап уже настроен и местным спецам достаточно просто следить за «пульсом» сервера. Скорость баз на 1С 8.2 значительно повышается по сравнению с файловой версией, надежность — тем более. Базы падали только когда сервер сгорал в буквальном смысле этого слова.
PostgreSQL — это альтернатива файловой версии, когда хочется сэкономить и есть специалисты. А если сравнивать с MS SQL также необходимо учитывать стоимость покупки, стоимость владения, применимость для небольшого числа пользователей. Иначе сравнение будет необъективным и конечно всегда будет в пользу MS SQL.
К тому же Linux — более родная среда для PostgreSQL, а Windows — родная для MS SQL. При сравнении на Windows очевидно, кто победит.
(7) cool.vlad4, нет, Вы поясните, почему некорректно использовать Express для тестирования. И больше не путайте теоретический тест с продакшн-системой.
(5) baton_pk, повторяю, это теоретический тест, проведенный на оборцдовании, не превышающем ограничения Express версии. Если я вместо Express поставлю Standard или Enterprise, в результатах теста ничего не изменится.
Я же не говорю о постановке Express в продакшн, хотя такие внедрения есть.
(8) VladimirL,
Не всем. В этом направлении и работаем 😉
(9) эко вас понесло. я написал с самого начала, что меня не устроило. у вас в статье написано черным по белому ms sql. а в pdf файле express. и выводы вы делаете про ms sql. т.е. если бы по очкам ms sql express проиграл, вы бы и выводы написали про ms sql в целом. вот это я и написал. а вы тут про какие-то «путаете». это вы все путаете.
(12) cool.vlad4, Вы можете конкретно и по пунктам указать причины некорректности использования Express версии MSSQL в опубликованном тестировании? Или только передергивать умеете?
Ставим вопрос по другому: считаете ли Вы, что использование Standard версии что-либо изменило в результатах теста?
(13) Результаты могли бы быть другими, ведь Express версия не использует более 1 ядра процессора, не выходит за границы 1 ГБ оперативки и насколько помню в нем недоступны планы обслуживания.
То есть сравнивать можно на только «чистой» системе с 1 ГБ оперативки и 1 ядром ЦПУ, с отключенным полнотекстовым индексом и другими ограничениями.
(8) VladimirL,
Сомнительная экономия. Если у вас есть специалист по Postgre то он будет получать хорошую заработную плату. Что в итоге выльется в стоимость лицензий на MS SQL. Да и найти ещё такого надо. С Linux то же не всё так просто. Нормальный специалист по Linux стоит дороже чем Win специалист. И найти его сложнее.
Так же есть проблема с периодически возникающими ошибками решение которых бывает найти не просто.
У меня все сервера на MS, а у знакомого на Postgre были. Он год с ними промучился. Перешёл на MS.
Так как были проблемы производительности и вылетали непонятные ошибки. Решения которых он так и не нашёл.
(15) TODD22,
Разумеется в большинстве случаев это так. Но в (8) как раз приведен пример, когда это оправдано и проблем со специалистами не возникает.
(13)
Кстати, есть же по производительности равнозначный Enterprise и предназначенный как раз для тестирования и разработки.
(16) VladimirL, да что вы все к этому экспрессу прицепились? В условиях проведенного теста, повторяю, никакой разницы нет.
1) память у нас менее ограничения.
2) ядро CPU у нас одно.
3) партиционированием, сжатием бэкапов, кластеризацией и т.п. плюшками коммерческих версий мы не пользуемся.
В моей практике работы с PostgreSQL на Windows не показал хороших результатов с большими базами, так что луче его использовать по прямому назначению, то есть Linux системы, собственно под них он и писался а не под Windows.
Два нагрузочных теста Гилева. И что узнали? Да ничего интересного. Только в боевых условиях по-настоящему видно какая СУБД подойдет, т.к. уж слишком много факторов влияют на выбор. Об этом уже намекали в комментариях выше.
Будем считать это новогодней шуткой:)
Спасибо. Мы как раз думали — даст ли ускорение переход с постгри на мс, так что ваша работа нам своевременно помогла.
(20) Зеленоград,
А чего тут думать. Надо ставить и проверять.
(20) Зеленоград, Существенные проблемы производительности сменой СУБД, как правило, не решаются.
Зачем тесты старого доброго 2008R2 при наличии актуального 2013? Постгри тоже старенький?
(20) — улыбнуло.
(5) baton_pk, и что там с «тестами от гилева»? Я не один раз встречал ситуации, когда эти «тесты» мягко говоря, чудные посылы выдают. Так что я чихал на них и другим советую. Надо хотя бы чуток мозг свой использовать. Он не для ретрансляции чужих «удивительных вещей». Один(ну и те, кто имеет отношение к их «созданию») придумал эти тесты и пиарит их, другие, как желторотики, не хотят думать и чуть что — «тесты от гилева».
(24) OBEH,
с удовольствием выслушаю Ваш вариант использования собственного мозга по данному вопросу.
всем известно что на скуле работает быстрее чем на постгри, а так же в скуле есть встроенные функции по настройке обслуживания БД ке удобно настраивать при помощи плана обслуживания в отличии от того же постгри для которого придется писать батник чз который нужно будет запускать тот же ежедневный бэкап,
другое дело в цене 0 vs +100500, поэтому у кого нет проблем с производительностью лучше (дешевле) юзать постгри, а проблемы производительности, при условии надлежащего обслуживания БД, нужно искать в СУБД в последнюю очередь, а в первую — в самой конфигурации
Увы, я своими глазами видел в минувшем году попытку переноса базы на новые сервера. 1С сервер под Linux + Postgre под Linux . База не вынесла прежней нагрузки. Вернули на предыдущий сервер — всё работает. Попытка №2 1С под Linux + MS SQL — показатели работы базы вызывали нарекания. И, наконец попытка №3 — всё новое желело было под MS Windows Server и MS SQL — существенное улучшение по сравнению со старыми серверами. (Немудрено — новое железо было существенно мощнее прежнего. Но добиться улучшений удалось только под продуктами Microsoft) 🙁
(27) Sure, а исследование причин проводилось? Замер нагрузочных показателей, анализ ожиданий на блокировках? Напомню, в режиме автоблокировок в postgre блокируется таблица целиком. Да и конфигурация postgre по умолчанию для сколько-нибудь производительной работы шансов не оставляет.
Очень интересно. Вообще-то сервер приложения для Linux не работает с MSSQL. — читаем самый низ страницы.
А мне вот все лень сделать аналогичное. Только хотел проверить реальную базу на 300гигов. Поднять на скуле, на постгря, сделлать основные операции, типо проведения года, отмена проведения, тестирование и исправление со всеми галочками, бекапы, основные отчеты.
Но вот смотрю по заголовку вашей статьи и думаю — вау, круто… Теперь не надо париться, вот человек хороший сделал уже что то 🙂 Открываю статью… Ан нет, все то же — бесполезные тесты, тема ни о чем, еще и в пдф, еще и аж 2 страницы… И даже без объяснения тестов… Ну хорошо, что они от гилева или нет? Т.е. в статье ничего не подняли, перенесли все в пдф? зачем? $m мало? Попросите — я вам перечислю. Но не надо таких вещей, с такими умными анонсами — делать так убого. Люди не правильно поймут.
Ну теперь по делу давайте:
Кто эти авторитетные, и не очень, товарищи? Дайте линки на места, где они так говорят. Мне аж интересно стало, третью категорию пропустим 🙂
Microsoft SQL Server 2008 R2
PostgreSQL для Linux
PostgreSQL для Windows
Круто 🙂 Вот тут явно не хватает данных из пдф, так как если бы я тут увидел что вы все это разворачивали на XP, то я бы просто закрыл эту статью 🙂 Далее веселее — виндовс x86, сервер 1с x64, эммм… ну ладно.
Если бы вы читали анонсы 1С, то вы бы увидели, что они ооооочень много нового сделали именно под MSSQL2012, т.е. вы заведомо сравнивали не пойми что с не пойми чем.
Про разные уровни изоляций систем — вы сказали вскольз, это улыбнуло. Давайте подумаем — почему 1С вешают на скуль в 99% случаях? верно — многопользовательский режим, блокировки и т.д., но вы сочли это мелкой задачей — на которую не стоит обращать внимание 🙂
З.Ы. Все хорошо, продолжайте в том же духе, просто вы делайте немного более глубокие тесты, описывайте более детально — что вы делаете и почему. Рассказывайте про свои мысли в каждом этапе. Без этого всего — вес этой статьи равен нулю.
З.З.Ы. Ставлю плюс авансом и надеюсь на более расширенный анализ.
З.З.З.Ы. Приведите в публикации аналогичные статьи отсюда, с других ресурсов, покажите что ваши данные сходятся с ними, или нет, и почему? Я надеюсь вы диплом сами писали, а не покупали? Если да, то просто берите структуру построения диплома — за основу.
Мой выбор в пользу MS и вот почему:
имеем один физический и на нем 2 виртуальных сервера.
1. Win2008R2 x64, MSSQL 2005 SE x64, 6GB RAM, 4 CPU, динамический хард на RAID5 (HUS156030VLS600)
2. Ubuntu Srv 12.04 x64, PG 9×64, 8GB RAM, 4 CPU, динамический хард на RAID5 (HUS156030VLS600)
На 1-м основная база 54GB и еще 5 небольших, все самописки.
На 2-м основные 2 базы УНФ и БП3.0, в самой толстой 6ГБ и 3 мелкие.
В то время, как «виндовый» справляется с более объемной задачей на более скромных ресурсах «линуксовый» похабно себя ведет и капризничает. Проявляется это в регулярном зависании процесса сервера 1С и/или PG-сервера. Безусловно все зависит от того что там происходит на уровне обработки данных и вообще — разные базы, нельзя сравнивать. Также осознаем что правильность конфигурирования серверов — наше всё, мы своего спеца не имеем и нанимаем местных франчей как самых компетентных в linux+1C, надеюсь, ага. И практика показывает что как только «виновная» база переезжает на «винду» то все сразу устаканивается. И вот уже из изначально запланированных 10 баз на «убунте» остались всего 2 основные, которые продолжают время от времени зависать, и готовиться к переезду.
Поэтому, исходя из соображений экономии времени и нервов, чисто субъективно и без вникания в цифры предпочтение однозначно на стороне Win-систем.
ps: да, и еще время от времени о себе напоминают всякие там «OLE» и другие архитектурные тонкости в области применения ВК, драйверов и пр… 🙂
(29) DitriX, вот, первый человек, который понял, что я, собственно, сделал, и в чем бессмысленность этого тестирования. Я уже было отчаялся.
На самом деле, довольно смешно наблюдать, как многочисленные ораторы придираются к деталям, забыв о главном: ни один искусственный тест, не имитирующий реальную работу множества пользователей, не даст внятных показателей, позволяющих судить о производительности системы в реальных условиях.
Какого характера?
Для начала, давайте примем как данность, что без adpex в реально применимой аналитике делать нечего. Почему — думаю, понятно: в конечном итоге производительность программного комплекса субъективно оценивается пользователем.
Выберем тестируемую конфигурацию. Выделим базовые операции нашего теста (не забывая про чтение/открытие форм). Напишем клиента тестирования (про фоновые задания забываем, ибо формы), организуем клиентскую среду. Запустим тест, посмотрим на аналитику ЦУПа на предмет исправления явных огрехов конфигурации, посмотрим на нагрузку железа, поменяем видимокарту, ибо в нее уперлась производительность клиентской части и сервер недогружается. Добьемся воспроизводимости результатов. Найдем клиента под оптимизацию с хотя бы сотней юзеров и проделаем те же самые замеры в реальной среде, подумаем, почему результаты существенно различаются, побьемся головой об стенку, потом поймем, что в реальной работе пользователя есть место паузам и перекурам, меняющим картину блокировочной нагрузки, а еще местный админ кривые дрова на один из принтеров поставил, и когда туда печатают — все ложится, введем в аналитику еще и статанализ исходных данных…
Нет, в качестве того же диплома я бы, пожалуй, мог этим заняться бесплатно. Всего лишь для того, чтобы получить сходимые с опубликованным тестом результаты и комментарии в стиле написанных выше. 🙂
А сходимые потому, что в конечном итоге производительность многопользовательской работы (т.е. в существенной части длительности ожиданий на блокировках) все равно зависит в основном от производительности СУБД на запись. Естественно, при условии отсутствия избыточных блокировок и при управляемом режиме.
(30) UncleVader, а это закономерно, TCO для продуктов Microsoft традиционно ниже, чем для опенсорса.
Но у нас идет речь о производительности корректно сконфигурированной системы, а как раз в корректности конфигурации есть сомнения: франчи, как правило, занимаются 1С, и толковые DBA в них попадаются редко.
А что касается зависаний — ТЖ вам в руки.
(31) но так в этом то и вся суть.
Ну смотрите, когда я делал тестировании скорости мобильной платформы — я уше от синтетических тестов и взял более менее реальную ситуацию, т.е. скорость проведения документов с разным количеством товара, скорость получения данных из регистров и прочее. Собственно вот статья .
Т.е. идея в чем — вам никто не скажет что конкретно вам подойдет без анализа аналогичной БД.
Я, например знаю, что у меня в базе создается в среднем по 100 приходов и в кажом по 500 ед товара, тогда я в этой конфе — указываю эти данные и смотрю — какая скорость субд будет в этом случае. И, как вы догадались, она будет отлична от ситуации, когда у меня 5000приходов по 1 ед товара. Но вот вопрос — в каком случае и в какую сторону, ну и на какой субд.
Вы даже можете взять ту конфу — и запустить тесты А,Б,В и Г на ваших стендах и проверить — где чего будет, только данные увеличьте на порядок — два 🙂 Далее — поднять 5 клиентов и одновременно на них запустить эти тесты и показать, что в таких и таких случаях — выходит вот это и это.
Т.е. если у вас в базе около 1000ед товара и вы делаете не частые отгрузки оптовикам, но меняете цены раз в час, то вам подойдет вот это (так как по какой то причине — эта субд лучше работает с регистрами сведений) ну и т.д.
Мы все понимаем, что от версии к версии — данные будут меняться, но вот взять хоть какой то курс — уже хорошо.
Буквально недавно — появился новый клиент, у него винда с дб2. Я решил собрать статистику его базы данных ( и у него, на базу в 10гигов, отчет выводился около 5 минут. У меня на базе в 100гигов и скуле — за пару секунд. Вопрос — кто виноват? скуль или криворукие админы? или железо?
Ну как то так, т.е. я считаю, что все должно сводиться к практике, иначе — это все равно, что «чихнуть» в тазик 🙂
Естественно, «все должно сводиться к практике». И еще к соотношению цена/качество.
И еще.
Не надо забывать, что основной упор, при тестировании работы 1C делается на базу «собственного производства» и MS SQL.
Для многих контор связка 1С+PostgreSQL вполне приемлема и, желательно на Linux. Ставил в паре контор. Не сожалею. Базы до 19 гиг. уже. Они даже не понимают что там установлено. Работает железно.
Надеюсь, со временем ситуация 1С+PostgreSQL+Linux(и другими СУБД) будет только улучшаться.
Отчёт не богат. Жаль потраченного времени. Мог бы и в открытый доступ выложить.
(35) Трактор, кнопка «показать все сообщения», сообщение №1.
(34) OBEH, «Надеюсь, со временем ситуация 1С+PostgreSQL+Linux(и другими СУБД) будет только улучшаться.»
Оснований для таких надежд пока не наблюдается. Патчи 1С для PostgreSQL выходят раз в год…
(19) quebracho, Вот и я пытался тестировать и ни к какому выводу так и не пришел. Действительно, реальные боевые условия показывают куда лучше что нужно выбрать…
По своему опыту использования postgres под linux в боевых условиях скажу что много чего зависит от настройки постгриса, на одном и том же железе это может быть самолет или полный тормоз, особенно если конфиг по умолчанию. В MSSQL особо с настройками заморачиваться не надо, поставил и работает (по сравнению с постгресом) В общем у меня ушел где то месяц на подбор оптимальных настроек. Производительность была вполне приличная, на 5 баз хватало из них 2 УТ и 1 Комплексная. Но после перестановки через год системы уже другим человеком и использованием конфига по умолчанию под виндой жаловались что работать вообще стало невозможно. Так что если заморачиваться с оптимизацией настроек постгриса то имеет право на жизнь.
Я, как новичок в этом деле не понимаю большую часть комментарий. Я отлично понимаю про различную нагрузку на различные сервера. Но что бы спорить нужно проводить эти различные тесты на различные нагрузки и т.д. Я понял что данная публикация в основном для таких как я, и комментарии мне тоже помогли, но вот что я вижу: в теме есть результаты, а в комментариях лишь спор без циферок и буковок))) Уж простите) Хочу от каждого участника спора результатов тестов.)))))))
Данные сильно устарели. Выводы поспешны. Тестовая система демонстрирует низкие результаты, видимо из-за небрежности настроек.
Результаты тестирования на одном потоке не имеют смысла. SQL сервер работает эффективнее файловой базы только при больших нагрузках. Проще говоря быстродействие SQL сервера с увеличением числа пользователей падает медленнее, чем у файловой базы.
За работу однозначно минус. Впечатление что подгоняли под ответ и делали рекламу MS SQL.
Добавлю свои 3 копейки. Я свою базу 1с запускал в связке и с PGSQL9, и с MS SQL Express 2008, и IBM DB2 10. У меня несколько баз объемом 2-4Гб.
Заускал тест Гилева на PGSQL/windows2012 и MS SQL. Тут я могу подтвердить при максимальной нагрузке PGSQL/windows2012 проиграл 30% в производительности. Но это при максимальной нагрузке.
БД у меня небольшая, и потому важным факторами являются время простоя и время восстановления. Я не юниксоид, хотя несколько раз запускал сервера прокси и 1с на Linux (в стиле «читаю и перевожу со словарем»).
Так вот, если надо восстановить бэкап 1с: dt-шник грузится в MSSQL за 15 минут, PGSQL тоже 15, а DB2 за 2-3 часа. (Я в курсе , что можно средствами SQL бэкапить, но .DTфайл иметь под рукой удобнее)
Если накрылся целиком СУБД, то время восстановления включает в себя затраты на переустановку СУБД. и вот тут становится интересно… База 1с в MSSQL запускается в течении часа. А связка Linux+PGSQL — это как конструктор с плохой инструкцией.
В данный момент у меня несколько небольших баз, и я поставил 2 экземпляра MSSQL Express для распределения нагрузки. 3-й год всё работает без проблем. А PGSQL у меня накрылся тазом в процессе попыток оптимизации.
Резюмирую:
Выбор СУБД для маленьких баз это вопрос религии, навыков и финансов. Реальную производительность можно оценить только в реальных условиях. И если есть сомнения что выбрать — выбирать надо что лучше знаешь.
Для меня всё просто, как в анекдоте: «вам шашечки или ехать?» Поэтому использую пока MSSQL Express.
На этом всё. Можно кидать камни.
Коллеги тоже хочу поделиться результатами замеров:
Я дополнительно ставил эксперименты с использованием гипервизора KVM.
Выводы, в стиле КО (рекомендации от разработчиков платформы):
1. Режимы энергосбережения достаточно сильно влияют.
2. Ухудшение производительности дисковой подсистемы при использовании гипервизора
3. При разнесении сервера приложений и СУБД по разным компьютерам (виртуальным или физическим) узким местом выступает сетевой интерфейс — его загрузка около 100%.