Вход | Регистрация

  1  2  3  4   

MS SQL vs PostgresSQL

MS SQL vs PostgresSQL
Я
   PR
 
06.11.18 - 15:49
8. Свое мнение35% (9)
1. В Винде MS лучше Postgres31% (8)
4. В Линуксе Postgres лучше MS27% (7)
2. В Винде Postgres лучше MS4% (1)
3. В Линуксе MS лучше Postgres4% (1)
5. В Винде оба равны0% (0)
6. В Линуксе оба равны0% (0)
7. IBM DB все-равно всех делает0% (0)
Всего мнений: 26

Послушал тут разные мнения, в том числе Антона Дорошкевича по поводу того, кто кого заборет, MS Postgres или наоборот
С удивлением выясняется, что Postgres мало того, что как минимум почти везде не уступает MS, так еще и местами делает его, а вот это уже интересно
Кто что имеет сказать?
Мнение интересно с учетом всего: скорости, надежности, работы при перегрузках, цены, удобства, автоматических архивных копий, копий без выгона пользователей и т .д. т. п.
 
 
   daixiao
 
101 - 07.11.18 - 08:28
(97) это важно. Повторю, нелишне будет, - мой опыт - средненькая такая загрузка, как у 80% клиентов.

В среде с высокой загрузкой всё сразу по-другому становится.


(99) Могу только посочувствовать. Загрузка никакая, дело явно не в ней.

(100) То, что я рассказываю - в моём настоящем. Две УПП работают, без вопросов. Но у меня они обновляются, и платформа, и конфа.

"Не дружит она с утилитами бакапа" - для меня звучит прямо дико: как конфигурация может не дружить с утилитами бекапа и почему вообще она должна с ними дружить?! До чего удалось докопаться? В чём причина такого поведения?
   Фрэнки
 
102 - 07.11.18 - 08:46
(101) По моим наблюдениям - это какой-то глюк с двумя видами конфигураций УПП 1.3 и КА 1.1 - исключительно с ними. Обходится этот глюк очень просто. Сама база на сервере не должна сидеть в режиме включенных изменений сохранением поддержки. Если нужны обновления с внесенными изменениями в типовую, то готовишь локально (на тестовой копии разработчика) файл-конфиг в виде CF, готового к применению к базе, затем Сравнением, объединением устанавливаешь на продакшн базу и все.

Зачем нужно в продакшн версии базы с конфигурацией с изменениями дополнительно хранить конфигурацию поставщика - вероятно просто шаблон какой-то, от которого многие не могут отказаться
   Фрэнки
 
103 - 07.11.18 - 08:47
   mgk2
 
104 - 07.11.18 - 08:50
(102) Ты на реальных базах эту методику обновления применяешь?
   stopa85
 
105 - 07.11.18 - 08:53
Одно время у меня было две инсталляции моей самописки. Первая работала в условиях линуха и постгреса (по моему аж 8.x.x), вторая на MS SQL 2005 с железом похуже .

Был один запрос, мне он казался тяжелым, на постгресе 3-5секунд, на MS 1-2сек.

А потом наступила беда. Запрос этот начал тупить на постгресе: 10-30сек. Сделаешь вакуум и реиндекс, все норм, но через пару дней опять.

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

8. Свое мнение
   daixiao
 
106 - 07.11.18 - 08:58
(102) "Зачем нужно в продакшн версии базы с конфигурацией с изменениями дополнительно хранить конфигурацию поставщика - вероятно просто шаблон какой-то, от которого многие не могут отказаться"

очень жаль, что не понятно. У меня вот в декабре обновление ERP после таких вот непонятливых грядёт ;o( Будем вспоминать времена семерки.
   Фрэнки
 
107 - 07.11.18 - 08:59
(104) Конечно. Посуди сам. База все нормальное рабочее время в режиме работы хотя бы нескольких десятков пользователей. Любая длительная процедура в монопольном режиме вызывает колапсс.
И что тогда толку от сохранения конфига поставщика в продакшн, если попытка именно использования инфы из этого конфига (фактическое исполнение процедуры обновления с учетом изменений, дописок и т.д.) обязательно поставит базу в позу на несколько десятков минут или даже часов. И это еще без учета вероятных ошибок. Т.е. по любому вылизываешь конфу на тестовом компе или хотя бы на тестовой базе разработчика и только на финише объединяешь ее с боевой.
   NorthWind
 
108 - 07.11.18 - 09:02
(101) падала табла configsave, кажется. Причем не сразу, с определенного релиза, где она разрослась. Там есть колонка с бинарем толстым. Вот этот бинарь не вывозился. Утилита падала по нехватке памяти.
   Фрэнки
 
109 - 07.11.18 - 09:03
(106) и если требования к надежности и непрерывности работы очень высокие, то и два сервера 1С ставить приходится - клиенты соглашаются с их установкой. Хотя это как минимум покупка доп ключей 1С-серверов, чтобы можно было разработчикам и саппортам тестить проблемы, дописывать и допиливать с минимальными рисками для пользовательской работы.
   NorthWind
 
110 - 07.11.18 - 09:03
(100) ну а как еще. Есть опыт, он вот такой. Есть информация, которую давали на вебинаре, она вот такая - про кучу скриптов и кучу секса с ними. Я сразу написал дисклеймер, что если что-то за эти годы существенно изменилось - беру свои слова назад. А там как знаете.
 
 Рекламное место пустует
   daixiao
 
111 - 07.11.18 - 09:43
(109) как вариант: обновить, подготовить и оттестить конфу на девелоперской базе. Потом на боевой - накатываем типовые обновления (они обновят конфу поставщика), потом накатываем готовый cf-ник с изменениями, и заканчиваем применением конфы в БД.

Разницы для пользователей - никакой, время перерыва в работе 1С остаётся тем же. Зато есть актуальный шаблон поставщика.

А то ведь оно как: допускаю, что можно и забить на конфу поставщика, не смертельно. Но ведь это читает вчерашний студент или падаван, для которого словосочетание "конфигурация поставщика" - это нечто туманное, непонятное и с виду бесполезное. И для простоты и логичности решает эту стороннюю практику применить не в рамках организованного и контролируемого IT-отдела, а у разового заказчика, которому надо "вот тут чуть-чуть поправить". А там все прелести - база девелоперов непонятно где, доработки то через девелоперскую базу, то напрямую в боевую, девелоперская база с наработками перетирается свежей копией рабочей, в общем, обычный бардак.
   А вот в моей грядущей ERP ещё прикольнее трагедия: другой студент начал это дело обновлять и не придумав ничего лучше, вместо переноса доработок заказчика на новую типовую, сравнил конфы и перенёс доработки 1с на конфу заказчика. Ясное дело, не всё, а "самое важное и нужное".

Так что я за то, чтобы не пренебрегать конфигурацией поставщика.
   arsik
 
112 - 07.11.18 - 09:51
(64) Вот же в видео реклама Дорошкевича. Обратись туда. https://is1c.ru/optimus/
   Фрэнки
 
113 - 07.11.18 - 09:59
(111) ну это тема для отдельного холивара :-)

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

з.з.ы. // сравнил конфы и перенёс доработки 1с на конфу заказчика // Ну и как, его смогло остановить наличие в базе конфиги поставщика? Он ее из базы удалил, т.е. снял ее с поддержки или просто на...кодил (мягко говоря)?
   daixiao
 
114 - 07.11.18 - 10:28
(113) "Ну и как, его смогло остановить наличие в базе конфиги поставщика?" 
Предположу логику такую:
  Если видишь, что поддержка соблюдается, конфа поставщика актуальна, сравнение выдаёт все доработки, то ты не рискуешь  последствиями небрежной работы, обновляешь по-правильному.
  А если видишь, что конфа поставщика или двухлетней давности, или вообще конфигурация снята с поддержки, то делаешь вывод, что на её соответствие типовой и изоляцию доработок давно забили, а значит, что можно не париться, не конструировать cf-ник старого релиза, который как всегда быстро взять негде, быстренько перенести чего просят из нового релиза, подписать акт и свободен.
   Fragster
 
115 - 07.11.18 - 10:30
(106) в смысле? должна быть база с измененной типовой (в хранилище, git или еще как), из которой делается свой поставка, которая через .cfu накатывается на прод, который закрыт для изменений.
   daixiao
 
116 - 07.11.18 - 10:44
(115) ну ага, это так выглядит большинство заказчиков? С 1с-никами на фиксях, хранилищем-гитом-ещё-как'ом, фикси-админом, который не забудет при апгрейде железа про этот тестовый сервак с базой разработки?

Для себя - да делайте как хотите. Хоть публичный проект на гитхабе организовывайте. А если заказчику ещё жить и может быть, даже не с вами, а ещё лучше с кучей других и может даже франчами, то будьте, добры, минимизируйте количество сущностей, предусмотрите, что пропажу боевой базы - заметят сразу, а пропажу вашей девелоперской - только через год, когда ставка НДС поменяется.
   Nikoss
 
117 - 07.11.18 - 11:35
(105) для 1С в постгри нужно ставить "автовакуум"=on, иначе происходит именно то что ты написал - со временем все хуже и хуже, вплоть до очередного вакуума. А может в бородатой 8.х.х версии автовакуума вообще не было...
   daixiao
 
118 - 07.11.18 - 11:50
(117) что-то знакомое, только не помню, почему.

Посмотрел конфиг на одном серваке, по-умолчанию autovacuum включён (закомментирован). Не думаю, что его специально отключают без дальнейшей настройки скриптов обслуживания.

Я пользую сборку Postgres с сайта 1С, на винде.
   Йохохо
 
119 - 07.11.18 - 12:05
(118) в (27) об этом доступно и всерьёз
   Пузан
 
120 - 07.11.18 - 12:44
Тут многие пишут что именно Постгрес Про соперничает с МС Скулем по производительности. Но давайте не будем забывать, что Постгрес Про уже ни разу не бесплатный, а это уже как бы совсем другой коленкор.

8. Свое мнение
   Fragster
 
121 - 07.11.18 - 12:48
(120) бесплатный. платная поддержка, которую можно и не покупать.
   Пузан
 
122 - 07.11.18 - 12:52
(121) Это Стандарт. А все фишки реально ускоряющие работу входят в версию Ентерпрайз, а она уже денег стоит.
   g00d
 
123 - 07.11.18 - 13:10
С большой нагрузкой и большим количеством клиентов постгрес на линуксе лучше, а мс очень ресурсоемкий.
У нас 3 сервера постгрес + 6 серверов 1С и около 400 одновременных пользователей.

4. В Линуксе Postgres лучше MS
   dk
 
124 - 07.11.18 - 13:38
200 пользователей на базе в полтерабайта SQL 2000 на 36 гб оперативы

1. В Винде MS лучше Postgres
   H A D G E H O G s
 
125 - 07.11.18 - 13:47
(0) Теоретически, производительность должна быть одинаковой, физические законы одинаковые.
Теоретически, на большие проекты - однозначно MS SQL, просто потому что спецов по нему - больше. В Postgree админ так и будет сидеть на тормозной базе и "вакуум" делать, разводя руками - "Это все ваша 1С тормозит, кривые вы люди."

8. Свое мнение
   ansh15
 
126 - 07.11.18 - 13:55
(117) В 7.4 уже был, как contrib-расширение.
   Пузан
 
127 - 07.11.18 - 15:06
(125) Причем тут физические законы? Вопрос в алгоритмах и их реализациях, к физике вообще никакого отношения не имеет.
   rphosts
 
128 - 07.11.18 - 15:08
(101).3 с полным соединением просто швах у постгри был совсем недавно (с полгода назад последний раз проверяли)... т.к. у нас крайне старый релиз УПП(думаю в новых как минимум отчасти учтено) перепиленный вдоль и поперёк - упыпырище решили оставить на сиквеле... единственное что на нём оставляем.
   rphosts
 
129 - 07.11.18 - 15:13
(125) спорно, страничник и версионник работают несколько по разному. У каждого есть свои моменты
   H A D G E H O G s
 
130 - 07.11.18 - 15:14
(129) Ну, я не про это.
Я про поиске, сортировку, соединение таблиц, индексацию.
   rphosts
 
131 - 07.11.18 - 16:14
(130) не, ну конечно сики сканы, нестедлупы и прочее и там и там ибо на одной теории БД, а вот реализация и детали уже могут очень различаться
   Вафель
 
132 - 07.11.18 - 16:16
(125) это предельная теоретическая производительность  одинаковая. а в реальности конечно же разная
   Fuas4
 
133 - 07.11.18 - 19:30
(96) g3nbuk1n@yandex.ru Вот сюда можно написать
 
 
   МаленькийВопросик
 
134 - 07.11.18 - 19:41
(59) что за безобразие - dt-шник 41гб - за базой вообще никто не следит что-ли
   МаленькийВопросик
 
135 - 07.11.18 - 19:47
(99) это не хайлоад - это смех - на складе дистрибьюции - до 3 тыс док делаем - работают 15 торговых - скидывают заказы - потом регламентом отрабатываем создаем реализацию и пко. - неприрывная работа винтов ссд - заказ каждую секунду....

оператора - всего 2 человека..

на первом этапе у нас сильно конфликтовали база вебсервиса агентов с базой скл УТ

но я думаю посгр рядом не стоял с мсскл все равно
   Nyarlathotep
 
136 - 07.11.18 - 20:20
На Windows однозначно MS лучше Postgres, но

4. В Линуксе Postgres лучше MS
   la luna llena
 
137 - 08.11.18 - 11:15
(79) я не согласна, по MS SQL всё достаточно просто, работает нормально "из коробки", можно сделать бекапы автоматом по инструкции в сети с картинками, разобралась сама за пару дней, работает без проблем уже 10 лет переезжает на разные сервера. (щас сглажу)
В постгри пыталась разобраться неделю, плюнула. Все семинары, что смотрела, пугают пипец как, туда не ходи, сюда не ходи, шаг вправо, шаг влево всё рухнет.
   Фрэнки
 
138 - 08.11.18 - 11:27
(137) так все видосики как записали 10 лет назад, раз указано о "уже 10 лет переезжает", так они и валяются до сих пор с кривыми инструкциями
   Вафель
 
139 - 08.11.18 - 11:29
(138) в этом вся и проблема, что все вермя все менятеся, как прям в ерп.
только выучил - уже все устарело )))
   Cyberhawk
 
140 - 08.11.18 - 11:35
(139) В Постгри меняется или где?
   Alexey_Morov
 
141 - 08.11.18 - 15:12
PostgreSQL существенно хуже MS SQL по ряду показателей:
1. По производительности - в разы, на некоторых запросах даже в десятки раз. Глубого тюнинга и оптимизации как запросов, так и самого движка тут не сделать. В PostgreSQL нет даже элементарного AWE (address windowing extension), нет GAM, IAM (index allocation map), нет плотной работы с extent. Для сравнения запустите select c(*) from [table], где table - имя вашей наиболее загруженной таблицы. Уверен, что даже при наличии достаточного количества индексов PostgreSQL пойдёт путём тупого сканирования таблицы и, кроме того, это займёт неадекватное время. В Инете найдёте много интересного про то, как народ корячится и делает костыли для оптимизации даже такого простого запроса.
2. Нет оптимизации под оперативную память и количество ядер.
3. Абсолютно нет онлайн построения индексов. Грубо говоря, если есть таблица в PostgreSQL, в которой построены индексы на некоторые столбцы, то после вставки КАЖДОЙ записи в таблицу для индексирования необхоидмо делать принудительное реиндексирование (тут гуглим про VACUUM, REINDEX).
4. Абсолютно ужасный набор штатных утилит. Про "функциональность" и глючность pgAdmin уже спето много песен на stackoverflow. Сторонние утилиты также глючны, дороги и не поддерживают многих вещей, которые появились в PostgreSQL 11. Зачастую то, что есть в одной платной утилите - нет в другой. Но зато в другой есть то, чего нет в первой. По факту ничего толкового в IDE для PostgreSQL нет. В штатной pgAdmin ужасно работает intellisense. Вдобавок pgAdmin очень медленная.
5. Удивительно, но PostgreSQL жалуется на нехватку памяти даже когда в сервере стоит 64 Гб ОЗУ и вся она свободна (работает только PostgreSQL) и тупо прекращает работу, подвесив свои сервисы, а инлгда даже и сервер перестаёт отвечать.
6. Отказоустойчивость и работа с аварийным режимом (emergency mode в рамках MS SQL) не реализована даже на минимальном уровне. В итоге нет даже таких понятий, как torn pages и прочее.
7. По синтаксису и сложности написания запросов, скудности своих возможностей, отсутствию джобов, интеграции с внешней средой (в PostgreSQL нет даже аналога для xp_cmdshell) PostgreSQL топчется на уровне MS SQL 7.0 или даже хуже. Во.

1. В Винде MS лучше Postgres
   Alexey_Morov
 
142 - 08.11.18 - 15:26
Переходить на PostgreSQL имеет смысл только если база данных не очень большая и иммеет смысл кое-как поставить её на Линукс и сэкономить чуть-чуть за счёт лицензий Windows и MS SQL. Только остаётся открытым вопрос сколько будет стоить установка и настройка, поддержание Линукса + PostgreSQL. Во.
   tesseract
 
143 - 08.11.18 - 15:29
(141) Это что за школьная чушь?

(142) 8 300 гиг+ баз 100 с лишим пользователей. Не тормозит от слова совсем.
   tesseract
 
144 - 08.11.18 - 15:30
(137) Ну если по картинкам настраивать тут да.... только MS SQL.
   rphosts
 
145 - 08.11.18 - 15:44
(141)это уже не трава...
   Alexey_Morov
 
146 - 08.11.18 - 15:45
(145) Вот именно, что PostgreSQL корявый настолько, что нужно вешаться сразу.
   tesseract
 
147 - 08.11.18 - 15:51
(146) Это кто-то админом называется по ошибке.
   rphosts
 
148 - 08.11.18 - 15:51
(146) ну ок, давай мериться... на какой у тебя базе (конфа, размер базы, сеансов в пике) проблемы с 1С при использовании постгри?
   olo_lo1
 
149 - 08.11.18 - 15:56
народ есть ли нормальный, человеческий способ архивации и восстановления баз через PostgresSQL ? приведите пож инструкцию
 
 Рекламное место пустует
   Alexey_Morov
 
150 - 08.11.18 - 15:58
(148) 1С не использую.
Имеются 3 базы по 11, 39 и 8 Тб. Всё тормозит. Не получить даже select count(*) from t;
Базы данных - структурированные, приведённые к нормальной форме. Содержат информацию о котировках бумаг, рыночные данные, индексы и прочее.
   rphosts
 
151 - 08.11.18 - 16:00
(149) меня устраивает pg_dump с выгрузкой в формате plane text
   rphosts
 
152 - 08.11.18 - 16:01
(150) 39 ТБ?
   rphosts
 
153 - 08.11.18 - 16:04
Для картины "охотники на привале" не вы позировали?
   Alexey_Morov
 
154 - 08.11.18 - 16:07
(152) Да. 39 Тб. Это немного.
Под базы данных организованы RAID 0 массивы из быстрых дисков. Всего у нас 5 полок хранения для сервера HP 360DL Gen10.
   tesseract
 
155 - 08.11.18 - 16:08
(149) Чем pg_dump / pg_restore не устраивает? В 

(150) План запроса посмотреть вера не позволяет?
   Вафель
 
156 - 08.11.18 - 16:09
(155) смотреть план для запроса select count(*) ???
   Fragster
 
157 - 08.11.18 - 16:25
(156) если нет кластерного индекса (таблица типа куча), то должен быть скан
   Fragster
 
158 - 08.11.18 - 16:26
ну или первичного ключа
   Fragster
 
159 - 08.11.18 - 16:27
а вообще если часто происходит запрос select count(*), проще добавить пару триггеров и еще одну таблицу с одной строкой, в которой будет одно значение.
   Alexey_Morov
 
160 - 08.11.18 - 16:29
(159) Во-во.
А потом ещё замучаетесь поддерживать этот костыль, когда присходит как вставка, так и удаление строки. Во.
   Fragster
 
161 - 08.11.18 - 16:43
(160) если руки прямые - то не намучаетесь
   tesseract
 
162 - 08.11.18 - 16:53
(160) Это не костыль, это ты просто не знаком с оптимизацией.


Как пример :

SELECT reltuples::bigint AS estimate
FROM   pg_class
WHERE  oid = 'Схема.Таблица'::regclass;

Выдаст тебе колзаписей практически мгновенно.
   Alexey_Morov
 
163 - 08.11.18 - 17:26
(162) ИМХО это всё равно костыль, если не предусмотрено штатной функции.
   Fragster
 
164 - 08.11.18 - 17:30
(163) незнание инструмента с которым работаешь - вот костыль.
   Alexey_Morov
 
165 - 08.11.18 - 17:30
Кроме того, reltuples - это ПРИБЛИЗИТЕЛЬНОЕ число строк:

Вот что говорят спецы:
"Number of rows in the table. This is only an estimate used by the planner. It is updated by VACUUM, ANALYZE, and a few DDL commands such as CREATE INDEX."
   rphosts
 
166 - 08.11.18 - 17:31
Сдается мне кто-то тут балаболит...
Уж не в отделении ли предыдущей империи зла он работает?
Ну или другая причина откровенно брехать, возможно.
   rphosts
 
167 - 08.11.18 - 17:31
(165) пруф?
   rphosts
 
168 - 08.11.18 - 17:33
(157) у 1c и без кластерного? Ну разве что основная таблица у РР и какие-то таблицы по РБ... но там есть первичный (разделитель+набор измерений).

Ох кто-то же фантазирует...
   Fragster
 
169 - 08.11.18 - 17:34
(168) ну так в (150) пишет, что не 1с
   rphosts
 
170 - 08.11.18 - 17:34
+ (168) даже для временных таблиц, если их индексировать, в 8.3 строится кластерный индекс
   Alexey_Morov
 
171 - 08.11.18 - 17:34
   rphosts
 
172 - 08.11.18 - 17:37
(169) а никто не говорил что грамотное проектирование базы архитривиальная задача... для одинэснегов тут желтокрасные много чего продумали.
   tesseract
 
173 - 08.11.18 - 17:41
(165) Точное число строк в версионнике - величина плавающая, да и обычно нафиг не нужное. Это же не лист с Excel.
   Фрэнки
 
174 - 08.11.18 - 17:42
(173) тем более, что в объяснении человеческим языком указано, после каких процедур это число строк в таблице меняется - вполне ожидаемо, что оно должно меняться из-за VACUUM
   la luna llena
 
175 - 08.11.18 - 17:47
(144) если есть возможность держать админа, который будет полгода ковырять настройки то да, если нужно сделать чтоб работало и без осообых вопросов, то ms
   tesseract
 
176 - 08.11.18 - 17:52
(175) У меня больше 15 минут на установку не уходило :-)
   la luna llena
 
177 - 08.11.18 - 19:52
(176) за 15 минут настроить Postgres, чтобы ничего не лагало, всё летало, бекапилось и не упало через полгода. Научите?
   Alexey_Morov
 
178 - 08.11.18 - 19:53
(172) получается, что использовать Postgresql в случае не 1С приложений категорически сложно, так как много всего нужно самому делать вручную?
   rphosts
 
179 - 08.11.18 - 20:01
(178) Во первых: если вы не обратили внимание в этой ветке обсуждение базоводов в контексте использования их с 1С, а вы оффтопите.
Во вторых: если есть голова и прямые руки - многие проблемы оказываются разрешимы... Но если вы привыкли забивать молотком шурупы - это не шурупы уступаю гвоздям, а они немного другие и требуют другого инструмента.
   tesseract
 
180 - 08.11.18 - 22:57
(177) А что MS SQL уже не лагает и летает? После перехода на Postgres в 2015 у нас скорость как раз выросла :-)


Не благодарите, дешевле чем ms sql на 8 ядер. https://postgrespro.ru/education/courses
   la luna llena
 
181 - 08.11.18 - 23:50
(180) не лагает,
Это уже 2 недели с отрывом от работы и приличная сумма
   tesseract
 
182 - 08.11.18 - 23:56
(181) MS SQL у вас на сколько ядер лицензирован? А сервер? И там Видеокурсы таки нашару дают. Только учись.
   tesseract
 
183 - 09.11.18 - 00:20
(179) Да ему DBF хотя бы освоить, судя по заявлениям, что MS SQL настолько крут, что не требует дефрага индекса. Ну да закладка "Job" в менеджере для полных идиотов предназначена и SQL Agent - это старшный и не нужный зверь.

MS SQL качественная и хорошая СУБД, особенно после 2003, когда все наследие sybase в виде жора памяти, косяков оптимизатора с зависанием запросов с полным table scan  и косяков с временными таблицами были порешены - так топовая по качеству планировщика. Только самонастраиваться она то-же не умеет. И в настройке и оптимизации еще посложнее Postgres, хотя Oracle переплевывает всех.
   DGorgoN
 
184 - 09.11.18 - 03:06
(0) Если постгри настроить то будет лучше работать чем скуль + ведь можно в исходниках покопаться - тут аналогия с ручной коробкой и автоматом при равных остальных ттх.

8. Свое мнение
   rphosts
 
185 - 09.11.18 - 03:59
(184)вот попрошу!!! Копаться в исходниках да ещё и хотя-бы с самым минимальным выхлопом - удел тех кто только этим и занимается большую часть рабочего времени.
   rphosts
 
186 - 09.11.18 - 04:00
(183) sybase? Кто-то ещё помнит откуда взялся (у кого был куплен) сиквел!
   Гобсек
 
187 - 09.11.18 - 04:12
Даже чтение этого форума показывает, что стоимость владения MS SQL ниже стоимости владения Postgres. Если в организации и найдется сотрудник, который в разумное время в нем разберется, то после его ухода возникнут проблемы.

1. В Винде MS лучше Postgres
   rphosts
 
188 - 09.11.18 - 04:13
(180) спс, как-же мир тесен... Давно не видел Павла Лузанова...
   Гобсек
 
189 - 09.11.18 - 04:14
(187) + Если в организации и найдется сотрудник, который в разумное время разберется в Postgres, то после его ухода возникнут проблемы.
   rphosts
 
190 - 09.11.18 - 04:19
(187) >Если в организации и найдется сотрудник, который в разумное время в нем разберется, то после его ухода возникнут проблемы.

точно! В одной конторе однажды.... в общем когда обратились ко мне выявил что база сиквела не обслуживалась минимум полгода (полгода как уволился тот кто занимался СУБД, причем ушёл по травме на длительный бл с последующим увольнением, так что диверсия исключена)... база тормозила обычно и часто повисала на пару минут... итого: сделал регламентное обслуживание - примерно минус 30% к времени выполнения, макспараллелизм сменил с 0 на 1 - подвисания пропали... сделал ещё кое что.
На выходе отсутствие провалов и почти двухкратное ускорение... сам был в шоке от такого выхлопа! а вы мне про изкаробки впариваете.
Будет изкаробки и даже норм, но только если железо с несколькократным заделом по производительности. Все готовы переплачивать по железу и лицензиям?
   rphosts
 
191 - 09.11.18 - 04:21
(189) если сотрудник не чудак на букву М и его не ушли по плохому - он передаст дела. Если его нач адекватен - он позаботится о том что-бы его обязанности кто-то мог  подхватить
   Nikoss
 
192 - 09.11.18 - 06:43
(180) а ну вот теперь ясно, откуда столько позитива к PG... засланец от postgrespro)))
   rphosts
 
193 - 09.11.18 - 07:17
он где-то солгал? Если нет - это не относится к теме никаким боком
   Nikoss
 
194 - 09.11.18 - 07:48
(193) относится. Очевидно предвзятое мнение.
   rphosts
 
195 - 09.11.18 - 08:14
(194)ок, но почему лично вы видите это за tesseract но не замечаете за Alexey_Morov ?
Вы свое мнение считаете не предвзятым?
   Cyberhawk
 
196 - 09.11.18 - 08:15
(190) "макспараллелизм сменил с 0 на 1 - подвисания пропали" // Многопроцессорный хост что ли был? Ведь если проц один, то этот параметр ни на что не влияет
   Nikoss
 
197 - 09.11.18 - 08:21
(195) У Alexey_Morov не заметил рекламы в сообщениях. Я вижу просто его мнение, как и других кто в этой теме.
   rphosts
 
198 - 09.11.18 - 08:26
(196)угу, но параметр не по процам а по ядрам
   rphosts
 
199 - 09.11.18 - 08:27
(197) если вы откроете глаза пошире то увидите, что то что касается базоводов имеет прямое отношение к этой ветке.
А уж халява напрямую не может считаться рекламой
   Фрэнки
 
200 - 09.11.18 - 08:37
(197) А Вы ни разу не слышали о том, что в структуре компаний, занимающихся продвижением продуктов Майкрософт есть даже штатные должности Евангелисты? Нет? Очень интересные вещи могут рассказывать такие специалисты. Не думаю, что здесь в ветке есть евангелисты, но причастность к продажам продуктов майкрософт вполне может быть
  1  2  3  4   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует