0. asved.ru 36 28.12.13 15:55 Сейчас в теме

MSSQL или PostgreSQL? Тестирование.

Вы все еще ставите PostgreSQL на Windows?
Тогда мы идем к вам!

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. asved.ru 36 29.12.13 12:08 Сейчас в теме
PS В силу неочевидности некоторых функций редактора публикаций файл прикрепляю в комментариях.

Прямая ссылка: Отчет о тестировании
Прикрепленные файлы:
Сравнительное тестирование производительности MS SQL Server и PostgreSQL.pdf
Сравнительное тестирование производительности MS SQL Server и PostgreSQL.pdf
Maxisussr; +1 Ответить
2. cool.vlad4 45 29.12.13 15:42 Сейчас в теме
имхо тема теста не раскрыта...я уж молчу, что использовать в сравнении ms sql express как полноценный ms sql некорректно.
Caligare; AlexGroovy; BorovikSV; NecroJew; check2; ZLENKO; FractalizeR; +7 Ответить
4. asved.ru 36 29.12.13 19:43 Сейчас в теме
(2) cool.vlad4, разъясните пожалуйста, в чем же некорректность? Чем так ограничен Express, что его нельзя использовать на базах, не достигающих и 100Mb?

(3) vano-ekt, ага, как любая чисто теоретическая задача.
6. cool.vlad4 45 29.12.13 22:40 Сейчас в теме
(4) что за базы такие в 100 мб? вы писали, что ваш тест только для баз в 100 мб? нет? ну а чё тогда...читаем
http://en.wikipedia.org/wiki/SQL_Server_Express
http://blogs.msdn.com/b/sqlexpress/archive/2008/02/22/sql-express-behaviors-idle-time-resources-usage-auto-close-and-user-instances.aspx
http://msdn.microsoft.com/en-us/library/cc645993(v=SQL.100).aspx
особенно внимательно читаем про cpu и memory limits
7. cool.vlad4 45 29.12.13 22:46 Сейчас в теме
(4) и такое замечание, тем у кого база 100 мб, кто использует ms sql express, поскольку его хватает, вообще по барабану тесты и что использовать, хоть ms, хоть postgre. разве, что вопрос в цене обслуживающего персонала.
Bryuhanov; w-divin; +2 Ответить
9. asved.ru 36 30.12.13 05:18 Сейчас в теме
(7) cool.vlad4, нет, Вы поясните, почему некорректно использовать Express для тестирования. И больше не путайте теоретический тест с продакшн-системой.
12. cool.vlad4 45 30.12.13 06:40 Сейчас в теме
(9) эко вас понесло. я написал с самого начала, что меня не устроило. у вас в статье написано черным по белому ms sql. а в pdf файле express. и выводы вы делаете про ms sql. т.е. если бы по очкам ms sql express проиграл, вы бы и выводы написали про ms sql в целом. вот это я и написал. а вы тут про какие-то "путаете". это вы все путаете.
13. asved.ru 36 30.12.13 06:51 Сейчас в теме
(12) cool.vlad4, Вы можете конкретно и по пунктам указать причины некорректности использования Express версии MSSQL в опубликованном тестировании? Или только передергивать умеете?

Ставим вопрос по другому: считаете ли Вы, что использование Standard версии что-либо изменило в результатах теста?
14. Vladimir Litvinenko 30.12.13 07:19 Сейчас в теме
(13) Результаты могли бы быть другими, ведь Express версия не использует более 1 ядра процессора, не выходит за границы 1 ГБ оперативки и насколько помню в нем недоступны планы обслуживания.

То есть сравнивать можно на только "чистой" системе с 1 ГБ оперативки и 1 ядром ЦПУ, с отключенным полнотекстовым индексом и другими ограничениями.
3. vano-ekt 526 29.12.13 16:25 Сейчас в теме
сферично, вакуумно...
GreenDragon; +1 Ответить
5. baton_pk 396 29.12.13 22:28 Сейчас в теме
Вы тесты от Гилёва проводили? Было бы неплохо сравнить эти показатели.
Ещё в выборе очень немалую роль играет сопровождение: как минимум, разностные бэкапы на Постгресе - дело нетривиальное в отличие от MS SQL. На базе в ~400ГБ мы в своё время сравнили тупо снятие и развёртку бэкапа, сравнили пересчёт итогов. Без тюнинга Постгрес в пролёте.

Для баз до 10 ГБ Постргес (за исключением работы под Linux) хорош только одним: если база перевалит за этот предел, вы этого не заметите. В случае с MS SQL Express раз в месяц приходилось залазить и чистить какие-нибудь старые логи загрузок или версии объектов, иначе база просто не работала.
10. asved.ru 36 30.12.13 05:22 Сейчас в теме
(5) baton_pk, повторяю, это теоретический тест, проведенный на оборцдовании, не превышающем ограничения Express версии. Если я вместо Express поставлю Standard или Enterprise, в результатах теста ничего не изменится.


Я же не говорю о постановке Express в продакшн, хотя такие внедрения есть.
24. OBEH 01.01.14 10:28 Сейчас в теме
(5) baton_pk, и что там с "тестами от гилева"? Я не один раз встречал ситуации, когда эти "тесты" мягко говоря, чудные посылы выдают. Так что я чихал на них и другим советую. Надо хотя бы чуток мозг свой использовать. Он не для ретрансляции чужих "удивительных вещей". Один(ну и те, кто имеет отношение к их "созданию") придумал эти тесты и пиарит их, другие, как желторотики, не хотят думать и чуть что - "тесты от гилева".
25. baton_pk 396 01.01.14 12:06 Сейчас в теме
(24) OBEH,
с удовольствием выслушаю Ваш вариант использования собственного мозга по данному вопросу.
8. Vladimir Litvinenko 30.12.13 04:04 Сейчас в теме
Oracle и DB2 решено пока не трогать. Они относительно малораспространены: немногие возьмутся их внедрять в продакшн и поддерживать

А ведь для Windows они рассматриваются как альтернатива MS SQL чаще, чем Postgre. Стала бы 1С поддерживать Postgre, если бы не выход в Linux-среду?

уже совсем не авторитетные товарищи - несут в массы мнение об опенсорсе как единственном обладающем реальной производительностью железа ПО; а в продуктах Microsoft через строчку Sleep(random) понатыкано

Обычно выбор в пользу 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 очевидно, кто победит.
11. asved.ru 36 30.12.13 05:24 Сейчас в теме
(8) VladimirL,
При сравнении на Windows очевидно, кто победит


Не всем. В этом направлении и работаем ;)
15. TODD22 18 30.12.13 07:28 Сейчас в теме
(8) VladimirL,
PostgreSQL - это альтернатива файловой версии, когда хочется сэкономить и есть специалисты.

Сомнительная экономия. Если у вас есть специалист по Postgre то он будет получать хорошую заработную плату. Что в итоге выльется в стоимость лицензий на MS SQL. Да и найти ещё такого надо. С Linux то же не всё так просто. Нормальный специалист по Linux стоит дороже чем Win специалист. И найти его сложнее.

Так же есть проблема с периодически возникающими ошибками решение которых бывает найти не просто.
У меня все сервера на MS, а у знакомого на Postgre были. Он год с ними промучился. Перешёл на MS.
Так как были проблемы производительности и вылетали непонятные ошибки. Решения которых он так и не нашёл.
16. Vladimir Litvinenko 30.12.13 07:42 Сейчас в теме
(15) TODD22,
Нормальный специалист по Linux стоит дороже чем Win специалист. И найти его сложнее.

Разумеется в большинстве случаев это так. Но в (8) как раз приведен пример, когда это оправдано и проблем со специалистами не возникает.

(13)
Кстати, есть же Developer Edition по производительности равнозначный Enterprise и предназначенный как раз для тестирования и разработки.
17. asved.ru 36 30.12.13 08:54 Сейчас в теме
(16) VladimirL, да что вы все к этому экспрессу прицепились? В условиях проведенного теста, повторяю, никакой разницы нет.

1) память у нас менее ограничения.
2) ядро CPU у нас одно.
3) партиционированием, сжатием бэкапов, кластеризацией и т.п. плюшками коммерческих версий мы не пользуемся.
18. alex_sh2008 4 30.12.13 09:21 Сейчас в теме
В моей практике работы с PostgreSQL на Windows не показал хороших результатов с большими базами, так что луче его использовать по прямому назначению, то есть Linux системы, собственно под них он и писался а не под Windows.
19. quebracho 24 30.12.13 10:09 Сейчас в теме
Два нагрузочных теста Гилева. И что узнали? Да ничего интересного. Только в боевых условиях по-настоящему видно какая СУБД подойдет, т.к. уж слишком много факторов влияют на выбор. Об этом уже намекали в комментариях выше.
В целях выяснения - кто же прав - и была задумана эта статья.

Будем считать это новогодней шуткой:)
cleaner_it; BorovikSV; NecroJew; cool.vlad4; w-divin; azubar; amon_ra; +7 Ответить
38. madmpro 29.07.14 17:12 Сейчас в теме
(19) quebracho, Вот и я пытался тестировать и ни к какому выводу так и не пришел. Действительно, реальные боевые условия показывают куда лучше что нужно выбрать...
20. Зеленоград 30.12.13 11:13 Сейчас в теме
Спасибо. Мы как раз думали - даст ли ускорение переход с постгри на мс, так что ваша работа нам своевременно помогла.
21. TODD22 18 30.12.13 13:05 Сейчас в теме
(20) Зеленоград,
Мы как раз думали - даст ли ускорение переход с постгри на мс

А чего тут думать. Надо ставить и проверять.
22. asved.ru 36 30.12.13 13:47 Сейчас в теме
(20) Зеленоград, Существенные проблемы производительности сменой СУБД, как правило, не решаются.
23. OneS 5 31.12.13 11:15 Сейчас в теме
Зачем тесты старого доброго 2008R2 при наличии актуального 2013? Постгри тоже старенький?
(20) - улыбнуло.
26. artfa 43 02.01.14 01:02 Сейчас в теме
всем известно что на скуле работает быстрее чем на постгри, а так же в скуле есть встроенные функции по настройке обслуживания БД к\е удобно настраивать при помощи плана обслуживания в отличии от того же постгри для которого придется писать батник ч\з который нужно будет запускать тот же ежедневный бэкап,
другое дело в цене 0 vs +100500, поэтому у кого нет проблем с производительностью лучше (дешевле) юзать постгри, а проблемы производительности, при условии надлежащего обслуживания БД, нужно искать в СУБД в последнюю очередь, а в первую - в самой конфигурации
27. Sure 141 02.01.14 15:51 Сейчас в теме
Увы, я своими глазами видел в минувшем году попытку переноса базы на новые сервера. 1С сервер под Linux + Postgre под Linux . База не вынесла прежней нагрузки. Вернули на предыдущий сервер - всё работает. Попытка №2 1С под Linux + MS SQL - показатели работы базы вызывали нарекания. И, наконец попытка №3 - всё новое желело было под MS Windows Server и MS SQL - существенное улучшение по сравнению со старыми серверами. (Немудрено - новое железо было существенно мощнее прежнего. Но добиться улучшений удалось только под продуктами Microsoft) :-(
28. asved.ru 36 02.01.14 16:16 Сейчас в теме
(27) Sure, а исследование причин проводилось? Замер нагрузочных показателей, анализ ожиданий на блокировках? Напомню, в режиме автоблокировок в postgre блокируется таблица целиком. Да и конфигурация postgre по умолчанию для сколько-нибудь производительной работы шансов не оставляет.

Попытка №2 1С под Linux + MS SQL

Очень интересно. Вообще-то сервер приложения для Linux не работает с MSSQL. http://v8.1c.ru/overview/Term_000000666.htm - читаем самый низ страницы.
29. DitriX 1718 03.01.14 18:35 Сейчас в теме
А мне вот все лень сделать аналогичное. Только хотел проверить реальную базу на 300гигов. Поднять на скуле, на постгря, сделлать основные операции, типо проведения года, отмена проведения, тестирование и исправление со всеми галочками, бекапы, основные отчеты.
Но вот смотрю по заголовку вашей статьи и думаю - вау, круто... Теперь не надо париться, вот человек хороший сделал уже что то :) Открываю статью... Ан нет, все то же - бесполезные тесты, тема ни о чем, еще и в пдф, еще и аж 2 страницы... И даже без объяснения тестов... Ну хорошо, что они от гилева или нет? Т.е. в статье ничего не подняли, перенесли все в пдф? зачем? $m мало? Попросите - я вам перечислю. Но не надо таких вещей, с такими умными анонсами - делать так убого. Люди не правильно поймут.

Ну теперь по делу давайте:
Некоторые авторитетные товарищи прямо и недвусмысленно отказываются отвечать на вопрос: "Какая СУБД лучше?". Другие - менее авторитетные товарищи - говорят: "Только MS SQL Server принесет счастье в ваш дом". Третьи - уже совсем не авторитетные товарищи - несут в массы мнение об опенсорсе как единственном обладающем реальной производительностью железа ПО; а в продуктах Microsoft через строчку Sleep(random) понатыкано.


Кто эти авторитетные, и не очень, товарищи? Дайте линки на места, где они так говорят. Мне аж интересно стало, третью категорию пропустим :)

В целях выяснения - кто же прав - и была задумана эта статья. А поскольку каждое мнение должно быть аргументировано - было проведено сравнительное тестирование производительности для следующих продуктов:

Microsoft SQL Server 2008 R2
PostgreSQL для Linux
PostgreSQL для Windows

Круто :) Вот тут явно не хватает данных из пдф, так как если бы я тут увидел что вы все это разворачивали на XP, то я бы просто закрыл эту статью :) Далее веселее - виндовс x86, сервер 1с x64, эммм... ну ладно.

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

Про разные уровни изоляций систем - вы сказали вскольз, это улыбнуло. Давайте подумаем - почему 1С вешают на скуль в 99% случаях? верно - многопользовательский режим, блокировки и т.д., но вы сочли это мелкой задачей - на которую не стоит обращать внимание :)


З.Ы. Все хорошо, продолжайте в том же духе, просто вы делайте немного более глубокие тесты, описывайте более детально - что вы делаете и почему. Рассказывайте про свои мысли в каждом этапе. Без этого всего - вес этой статьи равен нулю.

З.З.Ы. Ставлю плюс авансом и надеюсь на более расширенный анализ.

З.З.З.Ы. Приведите в публикации аналогичные статьи отсюда, с других ресурсов, покажите что ваши данные сходятся с ними, или нет, и почему? Я надеюсь вы диплом сами писали, а не покупали? Если да, то просто берите структуру построения диплома - за основу.


creatermc; brunen9; BorovikSV; NecroJew; gigapevt; blackjack666; w-divin; +7 Ответить
31. asved.ru 36 03.01.14 21:46 Сейчас в теме
Про разные уровни изоляций систем - вы сказали вскольз, это улыбнуло. Давайте подумаем - почему 1С вешают на скуль в 99% случаях? верно - многопользовательский режим, блокировки и т.д., но вы сочли это мелкой задачей - на которую не стоит обращать внимание :)


(29) DitriX, вот, первый человек, который понял, что я, собственно, сделал, и в чем бессмысленность этого тестирования. Я уже было отчаялся.

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

надеюсь на более расширенный анализ

Какого характера?
Для начала, давайте примем как данность, что без adpex в реально применимой аналитике делать нечего. Почему - думаю, понятно: в конечном итоге производительность программного комплекса субъективно оценивается пользователем.

Выберем тестируемую конфигурацию. Выделим базовые операции нашего теста (не забывая про чтение/открытие форм). Напишем клиента тестирования (про фоновые задания забываем, ибо формы), организуем клиентскую среду. Запустим тест, посмотрим на аналитику ЦУПа на предмет исправления явных огрехов конфигурации, посмотрим на нагрузку железа, поменяем видимокарту, ибо в нее уперлась производительность клиентской части и сервер недогружается. Добьемся воспроизводимости результатов. Найдем клиента под оптимизацию с хотя бы сотней юзеров и проделаем те же самые замеры в реальной среде, подумаем, почему результаты существенно различаются, побьемся головой об стенку, потом поймем, что в реальной работе пользователя есть место паузам и перекурам, меняющим картину блокировочной нагрузки, а еще местный админ кривые дрова на один из принтеров поставил, и когда туда печатают - все ложится, введем в аналитику еще и статанализ исходных данных...

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

А сходимые потому, что в конечном итоге производительность многопользовательской работы (т.е. в существенной части длительности ожиданий на блокировках) все равно зависит в основном от производительности СУБД на запись. Естественно, при условии отсутствия избыточных блокировок и при управляемом режиме.
33. DitriX 1718 03.01.14 22:18 Сейчас в теме
(31) но так в этом то и вся суть.
Ну смотрите, когда я делал тестировании скорости мобильной платформы - я уше от синтетических тестов и взял более менее реальную ситуацию, т.е. скорость проведения документов с разным количеством товара, скорость получения данных из регистров и прочее. Собственно вот статья http://infostart.ru/public/238799/.

Т.е. идея в чем - вам никто не скажет что конкретно вам подойдет без анализа аналогичной БД.
Я, например знаю, что у меня в базе создается в среднем по 100 приходов и в кажом по 500 ед товара, тогда я в этой конфе - указываю эти данные и смотрю - какая скорость субд будет в этом случае. И, как вы догадались, она будет отлична от ситуации, когда у меня 5000приходов по 1 ед товара. Но вот вопрос - в каком случае и в какую сторону, ну и на какой субд.

Вы даже можете взять ту конфу - и запустить тесты А,Б,В и Г на ваших стендах и проверить - где чего будет, только данные увеличьте на порядок - два :) Далее - поднять 5 клиентов и одновременно на них запустить эти тесты и показать, что в таких и таких случаях - выходит вот это и это.
Т.е. если у вас в базе около 1000ед товара и вы делаете не частые отгрузки оптовикам, но меняете цены раз в час, то вам подойдет вот это (так как по какой то причине - эта субд лучше работает с регистрами сведений) ну и т.д.

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

Буквально недавно - появился новый клиент, у него винда с дб2. Я решил собрать статистику его базы данных (http://infostart.ru/public/19916/) и у него, на базу в 10гигов, отчет выводился около 5 минут. У меня на базе в 100гигов и скуле - за пару секунд. Вопрос - кто виноват? скуль или криворукие админы? или железо?

Ну как то так, т.е. я считаю, что все должно сводиться к практике, иначе - это все равно, что "чихнуть" в тазик :)
30. UncleVader 128 03.01.14 19:00 Сейчас в теме
Мой выбор в пользу MS и вот почему:
имеем один физический и на нем 2 виртуальных сервера.
1. Win2008R2 x64, MSSQL 2005 SE x64, 6GB RAM, 4 CPU, динамический хард на RAID5 (HUS156030VLS600)
2. Ubuntu Srv 12.04 x64, PG 9x64, 8GB RAM, 4 CPU, динамический хард на RAID5 (HUS156030VLS600)

На 1-м основная база 54GB и еще 5 небольших, все самописки.
На 2-м основные 2 базы УНФ и БП3.0, в самой толстой 6ГБ и 3 мелкие.

В то время, как "виндовый" справляется с более объемной задачей на более скромных ресурсах "линуксовый" похабно себя ведет и капризничает. Проявляется это в регулярном зависании процесса сервера 1С и/или PG-сервера. Безусловно все зависит от того что там происходит на уровне обработки данных и вообще - разные базы, нельзя сравнивать. Также осознаем что правильность конфигурирования серверов - наше всё, мы своего спеца не имеем и нанимаем местных франчей как самых компетентных в linux+1C, надеюсь, ага. И практика показывает что как только "виновная" база переезжает на "винду" то все сразу устаканивается. И вот уже из изначально запланированных 10 баз на "убунте" остались всего 2 основные, которые продолжают время от времени зависать, и готовиться к переезду.
Поэтому, исходя из соображений экономии времени и нервов, чисто субъективно и без вникания в цифры предпочтение однозначно на стороне Win-систем.

ps: да, и еще время от времени о себе напоминают всякие там "OLE" и другие архитектурные тонкости в области применения ВК, драйверов и пр... :)
32. asved.ru 36 03.01.14 21:53 Сейчас в теме
(30) UncleVader, а это закономерно, TCO для продуктов Microsoft традиционно ниже, чем для опенсорса.

Но у нас идет речь о производительности корректно сконфигурированной системы, а как раз в корректности конфигурации есть сомнения: франчи, как правило, занимаются 1С, и толковые DBA в них попадаются редко.

А что касается зависаний - ТЖ вам в руки.
34. OBEH 04.01.14 05:50 Сейчас в теме
Естественно, "все должно сводиться к практике". И еще к соотношению цена/качество.
И еще.
Не надо забывать, что основной упор, при тестировании работы 1C делается на базу "собственного производства" и MS SQL.
Для многих контор связка 1С+PostgreSQL вполне приемлема и, желательно на Linux. Ставил в паре контор. Не сожалею. Базы до 19 гиг. уже. Они даже не понимают что там установлено. Работает железно.
Надеюсь, со временем ситуация 1С+PostgreSQL+Linux(и другими СУБД) будет только улучшаться.
37. ZLENKO 23.06.14 16:40 Сейчас в теме
(34) OBEH, "Надеюсь, со временем ситуация 1С+PostgreSQL+Linux(и другими СУБД) будет только улучшаться."

Оснований для таких надежд пока не наблюдается. Патчи 1С для PostgreSQL выходят раз в год...
35. Трактор 1191 09.01.14 13:33 Сейчас в теме
Отчёт не богат. Жаль потраченного времени. Мог бы и в открытый доступ выложить.
36. asved.ru 36 09.01.14 16:23 Сейчас в теме
(35) Трактор, кнопка "показать все сообщения", сообщение №1.
39. quick 573 27.11.14 17:39 Сейчас в теме
По своему опыту использования postgres под linux в боевых условиях скажу что много чего зависит от настройки постгриса, на одном и том же железе это может быть самолет или полный тормоз, особенно если конфиг по умолчанию. В MSSQL особо с настройками заморачиваться не надо, поставил и работает (по сравнению с постгресом) В общем у меня ушел где то месяц на подбор оптимальных настроек. Производительность была вполне приличная, на 5 баз хватало из них 2 УТ и 1 Комплексная. Но после перестановки через год системы уже другим человеком и использованием конфига по умолчанию под виндой жаловались что работать вообще стало невозможно. Так что если заморачиваться с оптимизацией настроек постгриса то имеет право на жизнь.
40. woozee 48 06.02.15 09:28 Сейчас в теме
Я, как новичок в этом деле не понимаю большую часть комментарий. Я отлично понимаю про различную нагрузку на различные сервера. Но что бы спорить нужно проводить эти различные тесты на различные нагрузки и т.д. Я понял что данная публикация в основном для таких как я, и комментарии мне тоже помогли, но вот что я вижу: в теме есть результаты, а в комментариях лишь спор без циферок и буковок))) Уж простите) Хочу от каждого участника спора результатов тестов.)))))))
41. Ликреонский 202 07.07.16 20:15 Сейчас в теме
Данные сильно устарели. Выводы поспешны. Тестовая система демонстрирует низкие результаты, видимо из-за небрежности настроек.
Результаты тестирования на одном потоке не имеют смысла. SQL сервер работает эффективнее файловой базы только при больших нагрузках. Проще говоря быстродействие SQL сервера с увеличением числа пользователей падает медленнее, чем у файловой базы.
За работу однозначно минус. Впечатление что подгоняли под ответ и делали рекламу MS SQL.
42. sdd101 25.10.16 08:31 Сейчас в теме
Добавлю свои 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.
На этом всё. Можно кидать камни.
43. _evgen_b 151 09.03.17 09:46 Сейчас в теме
Коллеги тоже хочу поделиться результатами замеров: Файл-отчет
Таблица с замерами

Я дополнительно ставил эксперименты с использованием гипервизора KVM.

Выводы, в стиле КО (рекомендации от разработчиков платформы):
1. Режимы энергосбережения достаточно сильно влияют.
2. Ухудшение производительности дисковой подсистемы при использовании гипервизора
3. При разнесении сервера приложений и СУБД по разным компьютерам (виртуальным или физическим) узким местом выступает сетевой интерфейс - его загрузка около 100%.


Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Ведущий программист 1С
Омск
зарплата от 70 000 руб. до 110 000 руб.
Полный день

Программист 1С
Екатеринбург
зарплата до 120 000 руб.
Полный день

Консультант-аналитик 1С
Рязань
зарплата до 80 000 руб.
Полный день

Программист 1С
Рязань
зарплата от 90 000 руб.
Полный день

Бизнес-архитектор 1С, ведущий консультант
Санкт-Петербург
Полный день