Comments 81
По первой части сам давно пользуюсь скриптами ola.hallengren.com. Они учитывают особенности разных версий SQL Server умеют создавать job'ы, пишут логи и имеют кучу настроек.
Есть вопрос. Что лучше?
— Фронтэнд делает 500 async запросов выполняющихся на бд 0.5-2с каждый.
— Один запрос с портянкой на 500 параметров, которая будет работать через WHILE (или JOIN) в одой процедуре за 40 секунд?
И да, в любой момент все 100 подключений подключены.
— Фронтэнд делает 500 async запросов выполняющихся на бд 0.5-2с каждый.
— Один запрос с портянкой на 500 параметров, которая будет работать через WHILE (или JOIN) в одой процедуре за 40 секунд?
И да, в любой момент все 100 подключений подключены.
Если инфраструктура позволяет (в плане одновременных подключений), то лучше 1-ый вариант, тогда пользователь быстрее получит данные. А если и не позволяет, то организовать очередь на серверной стороне. Но если совсем уж грустно по кол-ву одновременных возможных подключений (напр, не более 10-ти) и еще задачи какие есть в реал тайм, то второй вариант. Но лучше от второго уходить
Спасибо за ответ, примерно так и поступаю, где-то все 500 запросов делаю, а где эти же 500 объединяю в один на клиенте и распаралеливаю на бэкенде, а где-то и то в самом скуле. Просто хотелось бы best practies по нагруженным asp.net/mssql решениям.
Почему нельзя растягивать пул?
А как?
Чем лучше? Почему?
Почему нельзя растягивать пул?
Старайтесь отправлять запросы к СУБД пачками, а не единичными
А как?
Подписывайте в строке подключения к БД компонент приложения в Application Name:
Чем лучше? Почему?
Application Name-просто потом легче анализировать от кого запрос пришел. Пул очень индивидуально-сколько он кэшировать может.
Запросы пачками-имеется в виду, не по одной строчке, а сразу одним запросом.
Например, удаляете 34 строки-удаляйте не тупо в цикле вызовом хранимки по 1 строке, а сразу 34. А еще лучше просто пометить на удаление сразу 34 строки одним запросом. А потом или ночью уже физически удалить
Запросы пачками-имеется в виду, не по одной строчке, а сразу одним запросом.
Например, удаляете 34 строки-удаляйте не тупо в цикле вызовом хранимки по 1 строке, а сразу 34. А еще лучше просто пометить на удаление сразу 34 строки одним запросом. А потом или ночью уже физически удалить
А чем пометить и ночью удалить лучше?
При обновлении (пометить) и построчном хранении насколько пос все старые строчки(условно, там ведь страницы) будут удалены, новые созданы + логи, при последующем удалении "ночью" будет повторное удаление строчек.
Или в mssql что-то сильно по другому?
Логическое удаление лучше, т к не фрагментирует индексы и не вызывает удаления в связанных таблицах
Лучше физическое удаление делать в минимальные нагрузочные часы
Лучше физическое удаление делать в минимальные нагрузочные часы
Так в том то и дело, что физически, при обновлении, старые записи(блоки) будут помечены как удалённые, а обновлённые будут записаны. Т.е. по факту в индексе логический адрес ячейки не сменится а физический будет заменён. Т.е. отложенное удаление в сумме приведёт к большему количеству операций ввода-вывода и потенциально большей фрагментации данных в файлах БД (износу ssd-ников в т.ч.) при этом ещё потребует изменения логики работы приложения (фильтровать придётся ещё и удалённые записи, возможно добавлять индексы в случае наличия большого количества удалений).
Для oltp ещё возникает проблема с unique key т.к. сценарий удалили запись — вставили такую-же удалили ещё раз приводит к нарушению уникальности даже в случае включения в constraint признака удаления.
В общем на мой взгляд выигрыш сомнителен, особенно если БД из Oracle, PG, firebird. Возможно с
MSSQL дела обстоят по другому всёже корни блокировочника могут давать особенности, не знаю.
Довольно часто пользователи, разработчики, администраторы и т д СУБД MS SQL Server встречаются с проблемами производительности БД или СУБД в целом.Пусть переходят на PostgreSQL и перестают жаловаться! Я у себя отмечал прирост скорости в 20 и более раз.
В каких задачах?
Выбор СУБД несомненно должен зависеть от инфраструктуры и задачах.
Однако, сама СУБД не решит все проблемы и не является унифицированным средством и подходом для решения всего на свете
То, что какая-то СУБД-это наше все-большое и распространенное заблуждение.
Каждая СУБД имеет и свои плюсы и свои минусы
Также важно еще сопоставлять с бюджетом, поддержкой и т д и т п
Бесплатно, тоже не всегда хорошо, т к порой поддержка будет значительно дороже платного аналога и более дешевой поддержки.
А уж тонкостей по настройке, оптимизации и эксплуатации везде хватает.
Нужно смотреть в комплексе, а не в вакууме
Однако, сама СУБД не решит все проблемы и не является унифицированным средством и подходом для решения всего на свете
То, что какая-то СУБД-это наше все-большое и распространенное заблуждение.
Каждая СУБД имеет и свои плюсы и свои минусы
Также важно еще сопоставлять с бюджетом, поддержкой и т д и т п
Бесплатно, тоже не всегда хорошо, т к порой поддержка будет значительно дороже платного аналога и более дешевой поддержки.
А уж тонкостей по настройке, оптимизации и эксплуатации везде хватает.
Нужно смотреть в комплексе, а не в вакууме
Маркетинговый бред. Полно фирм уже по постгресу предоставляющие поддержку. Вот например: postgrespro.ru/services/support — причём здесь поддержку оказывают сами разработчики — выше качества нет. На sql.ru дадут такую поддержку, что ни с каким МС не сравнится. Вот ещё: www.postgresql.org/support и ещё профи: www.postgresql.org/support/professional_support
А вообще попробуй сначала посгрес с его возможностями и функциями, которых на порядки больше, чем в мс, а потом поговорим. Ты и смотри в комплексе.
А вообще попробуй сначала посгрес с его возможностями и функциями, которых на порядки больше, чем в мс, а потом поговорим. Ты и смотри в комплексе.
Грубо как.
Как мне надоело ето восхваление постгрес. Где би что не обсуждалось по БД там уже расказивают какой постгрес крутой и сколько даст прироста. Да ето очень крутая БД. Точно лутшая с безплатных версионников. :)
А по факту:
1) В класе версионник он отстал от оракла навсегда.
2) Партиции которие дают реальний прирост и маштабируемость появилось буквально в 10 версии и назвать что ето уже продакшин — как-то язик не поварачивается. Про in-memory в посгри я тоже ничего не слишал. (Оракл 12, MSSQL 2014). Пускай реализация местами странная и ограничений вагон и тележка но оно работает и дает реальний прирост.
Если правильно настроить базу и експлуатировать ее как она «любит» то на одном и том же железе разница может бить в процентах а не в разы.
А по факту:
1) В класе версионник он отстал от оракла навсегда.
2) Партиции которие дают реальний прирост и маштабируемость появилось буквально в 10 версии и назвать что ето уже продакшин — как-то язик не поварачивается. Про in-memory в посгри я тоже ничего не слишал. (Оракл 12, MSSQL 2014). Пускай реализация местами странная и ограничений вагон и тележка но оно работает и дает реальний прирост.
Если правильно настроить базу и експлуатировать ее как она «любит» то на одном и том же железе разница может бить в процентах а не в разы.
И кто после этого маркетингом занимается? Да ещё с таким пристрастием и так грубо
Я тоже читаю про постгрес и как СУБД считаю её не плохой
Но повторюсь-все нужно смотреть в комплексе
Я тоже читаю про постгрес и как СУБД считаю её не плохой
Но повторюсь-все нужно смотреть в комплексе
Это ж каких там функций больше на порядки, позвольте узнать?
Любых: математических, стринговые, время, аггрегатные и т.д. и т.п.: www.postgresql.org/docs/current/static/functions.html
Там где в MS SQL приходилось писать простыни хранимок и писать велосипеды для распарсивания чего-то, или потом пришлось даже на CLR C# хранимки перейти, в PostgeSQL есть всё из коробки в SQL.
Там где в MS SQL приходилось писать простыни хранимок и писать велосипеды для распарсивания чего-то, или потом пришлось даже на CLR C# хранимки перейти, в PostgeSQL есть всё из коробки в SQL.
---Я у себя отмечал прирост скорости в 20 и более раз
Может не смогли настроить MSSQL? 20 выглядит фантастикой, давайте репо.
---с его возможностями и функциями
Давайте где там Graph DBMS в Постгрессе?
Go, JavaScript (Node.js), R, Ruby не поддерживаются.
Transact SQL and .NET languages в Server-side scripts тоже не поддерживается.
In-memory capabilities нет.
Может не смогли настроить MSSQL? 20 выглядит фантастикой, давайте репо.
---с его возможностями и функциями
Давайте где там Graph DBMS в Постгрессе?
Go, JavaScript (Node.js), R, Ruby не поддерживаются.
Transact SQL and .NET languages в Server-side scripts тоже не поддерживается.
In-memory capabilities нет.
Может не смогли настроить MSSQL? 20 выглядит фантастикой, давайте репо.А может вы PostgreSQL не пользовались?! Настраивать я MS SQL умею, мы базу и запросы ускоряли на порядки.
То есть репо не будет? Будем верить словам?
А учтивая что R не поддeрживается о каком BI вообще можно говорить?
А учтивая что R не поддeрживается о каком BI вообще можно говорить?
Не надо верить словам: просто возьми свою задачу и проверь её работу на постгресе — всё! :)
Очень спорное утверждение. Если вы правильно используете БД значит вы используете тригера, процедуры, пакеты, функции, особенности БД в запросах и вюхах а ето от несколько десятков тисяч до нескольких сотен тисяч строк.
Разница в запросах + их оптимизация, не говоря уже о разнице pl/sql t-sql и pg/sql настолько огромная что ето фактически наново писать всю логику. То есть ето в принципе невозможно. А переход с версионника на блокировщик или наоборот ето еще то приключение, вплоть то переписивания логики приложения.
А то о чем вы говорите — ето способ писать приложения только используя SQL, а всю логику вне БД. При етом вы используете только незначительную часть возможности БД.
P.S. Была попотка перенести приложение c оракла на IBM DB2 которий декларировал совместимость pl/sql на 99%. Так от все вкусняшки по быстродействию оракла в pl/sql DB2 там не реализованы. Хотя я уверен есть свои. Оценив неоходимое время — мы отказались.
Разница в запросах + их оптимизация, не говоря уже о разнице pl/sql t-sql и pg/sql настолько огромная что ето фактически наново писать всю логику. То есть ето в принципе невозможно. А переход с версионника на блокировщик или наоборот ето еще то приключение, вплоть то переписивания логики приложения.
А то о чем вы говорите — ето способ писать приложения только используя SQL, а всю логику вне БД. При етом вы используете только незначительную часть возможности БД.
P.S. Была попотка перенести приложение c оракла на IBM DB2 которий декларировал совместимость pl/sql на 99%. Так от все вкусняшки по быстродействию оракла в pl/sql DB2 там не реализованы. Хотя я уверен есть свои. Оценив неоходимое время — мы отказались.
Я бы сравнил, но боюсь моих познаний по оптимизации Постгреса не хватит и он проиграет.
Раз уж вы стесняетесь и читаете себя спецом в обоих серверах. Переведи это репо на новейший стандарт постгресса и скажите за сколько процедура отработает.
Раз уж вы стесняетесь и читаете себя спецом в обоих серверах. Переведи это репо на новейший стандарт постгресса и скажите за сколько процедура отработает.
CREATE DATABASE MSSQLtst ON PRIMARY(NAME = InMemoryData, FILENAME = 'c:\db\MSSQLtst.mdf', size=200MB),
FILEGROUP [MSSQLtst_FG] CONTAINS MEMORY_OPTIMIZED_DATA( NAME = [MSSQLtst_dir], FILENAME = 'c:\db\MSSQLtst')
LOG ON (name = [MSSQLtst_log], Filename='c:\db\MSSQLtst.ldf', size=100MB)
GO
USE MSSQLtst;
GO
CREATE TABLE MSSQLtbl (ID INT NOT NULL, Name VARCHAR(100) NOT NULL
CONSTRAINT ID_MSSQLtbl_Mem PRIMARY KEY NONCLUSTERED HASH (ID) WITH (BUCKET_COUNT=1000000))
WITH (MEMORY_OPTIMIZED=ON)
GO
CREATE PROCEDURE proc_MSSQLtst
WITH NATIVE_COMPILATION, SCHEMABINDING,EXECUTE AS OWNER
AS
BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL=SNAPSHOT, LANGUAGE='english')
DECLARE @counter AS INT = 1
DECLARE @start DATETIME
SELECT @start = GETDATE()
WHILE (@counter <= 100000)
BEGIN
INSERT INTO dbo.MSSQLtbl VALUES(@counter, 'SQLAuthority')
SET @counter = @counter + 1
END
SELECT DATEDIFF(SECOND, @start, GETDATE() ) [MSSQLtst in sec] END
GO
declare @start datetime2= getdate()
EXEC proc_MSSQLtst
select datediff(MILLISECOND, @start, getdate() )
GOМС славится своими костылями, когда приходится писать свои костыли в обход МС-овских. У нас SQL был близок к стандарту более не менее, поэтому на постгрес перевелось без проблем, почти 1 в 1, а там такие костыли, типа таблицы в памяти, не нужны как я уже неоднократно говорил. Это как раз от жуткой тормознутости МС появилось, чтобы хоть как-то быстрее работало. Мы использовали иногда в хранимках. А в постгресе для аналогичных задач есть массивы, например.
Попробуй один проект на постгресе начать — будешь недоумевать как на МС мог работать. Всё грамотно сделано.
Попробуй один проект на постгресе начать — будешь недоумевать как на МС мог работать. Всё грамотно сделано.
На любой СУБД нужно проводить регламентные работы и оптимизацию периодически, также нужна оптимизация и в ПО, которое взаимодействует с этим СУБД
В статье дана общая концепция и примеры на скуле и .NET
Перейдя на постгрес все равно придётся делать теже концепции, но другим кодом
И если ПО настроено неправильно или написано мягко сказать вычурно, то СУБД не во всех аспектах спасет
В статье дана общая концепция и примеры на скуле и .NET
Перейдя на постгрес все равно придётся делать теже концепции, но другим кодом
И если ПО настроено неправильно или написано мягко сказать вычурно, то СУБД не во всех аспектах спасет
Я так и понял, что все эти сказки пpо Постгресс таким и оказались.
На MSSQL мой пример отрабатывает за 83 ms, на Постгресс это будет работать в лучшем случае секунд 10-15.
Это я еще не рассматривают код где MSSQL может распаралелить запрос, а Постгресс нет.
На MSSQL мой пример отрабатывает за 83 ms, на Постгресс это будет работать в лучшем случае секунд 10-15.
Это я еще не рассматривают код где MSSQL может распаралелить запрос, а Постгресс нет.
А ниче, что MS — блокировщик, а Postgres — версионник?
И подходы для них в корне различны.
Лобовое сравнение одинакового кода для них — пригодно только для простейших тестовых ситуаций.
Для сложных — нужно отдельно оптимизировать под конкретный сервер.
И подходы для них в корне различны.
Лобовое сравнение одинакового кода для них — пригодно только для простейших тестовых ситуаций.
Для сложных — нужно отдельно оптимизировать под конкретный сервер.
То что вы написали было правдой лет десять назад, MSSQL уже не только блокировочник, но и версионник.
Более того я даже указал в моем примере уровень изоляции.
---пригодно только для простейших тестовых ситуаций.
Я привел концептуальную разницу, где постгресс серьезно проигрывает даже на простейших текстах. И мне этот пример в BI задачах принципиально нужен.
Второй пример приведенный ниже тоже показывает серьезное концептуальное отставание в производительности. На дворе 21 век, а до сих Постгресс не может распаралеливать запросы.
Более того я даже указал в моем примере уровень изоляции.
---пригодно только для простейших тестовых ситуаций.
Я привел концептуальную разницу, где постгресс серьезно проигрывает даже на простейших текстах. И мне этот пример в BI задачах принципиально нужен.
Второй пример приведенный ниже тоже показывает серьезное концептуальное отставание в производительности. На дворе 21 век, а до сих Постгресс не может распаралеливать запросы.
Прошу привести код в обоих СУБД и параметры компьютера, которые использовались в тесте
обычный дескторный компютер 5-летней давности.
2 экземпляра кода для MSSQL вам уже приведены. Вы эксперт в Постгрессе — приведите аналогичный, показывающий что я неправ.
Моя оценка основана понимании того что будет делать не-MSSQL сервер. Мой код простой — вставка ста тысяч значений в таблицу внутри процедуры.
2 экземпляра кода для MSSQL вам уже приведены. Вы эксперт в Постгрессе — приведите аналогичный, показывающий что я неправ.
Моя оценка основана понимании того что будет делать не-MSSQL сервер. Мой код простой — вставка ста тысяч значений в таблицу внутри процедуры.
Повторяю ещё раз: на постгресе такой запрос не нужен.
Могу допустить, что за последнее время особенно портировав МС на Линукс, могли произойти позитивные изменения — надо смотреть, но не таки кардинальные, как на постгресе.
Это я еще не рассматривают код где MSSQL может распаралелить запрос, а Постгресс нет.Лишний раз убеждаюсь, что Вы постгреса не знаете от слова совсем. Я работал на обеих базах: 5+ лет на МС и 7+ на постгресе, на двух проектах: BI и ETL — в обоих проектах при переходе на постгрес скорость вырастала на порядок.
Могу допустить, что за последнее время особенно портировав МС на Линукс, могли произойти позитивные изменения — надо смотреть, но не таки кардинальные, как на постгресе.
Лишний раз убеждаюсь, что Вы постгреса не знаете от слова совсем. Я работал на обеих базах: 5+ лет на МС и 7+ на постгресе, на двух проектах: BI и ETL — в обоих проектах при переходе на постгрес скорость вырастала на порядок.
А мужики то оказывается не в курсе…
Позвольте, а где же здесь Постгресс??
www.tpc.org/tpch/results/tpch_advanced_sort.asp?PRINTVER=false&FLTCOL1=ALL&ADDFILTERROW=&filterRowCount=1&SRTCOL1=h_sponsor&SRTDIR1=ASC&ADDSORTROW=&sortRowCount=1&DISPRES=100+PERCENT&include_withdrawn_results=none&include_historic_results=no
Наверное мешки таскать — не языком чесать?
Это что за табличка? МС заказала? Учитывая, что на ТОП-500 МС вообще нет, резонно спросить: где здесь МС?!
Делают эти тесты производители железа
А табличка, ну это самый известный в мире database benchmarks. Подробней можно почитать здесь:
www.tpc.org/information/about/abouttpc.asp
И что такое TOP-500?
А табличка, ну это самый известный в мире database benchmarks. Подробней можно почитать здесь:
www.tpc.org/information/about/abouttpc.asp
И что такое TOP-500?
Производители железа, которые давно и прочно, и это не для кого не секрет, завязаны на откаты МС — это не показатель: www.tpc.org/information/about/faq-generic.asp
TOP-500 — это линуксоиды знают: www.linux.org.ru/news/clusters/13823822
Но это всё таки не так интересно. Интересен свой опыт. А я пробовал на однотипных задачах обе СУБД. Был резкий контраст когда даже на старом железе запросы в постгре летали мсек, а при переходе на МС на порядок мощном железе аналогичный запрос тянул на секунды или даже десятки секунд — это было сильно заметно.
У людей вот тоже в одиночных тестах производительность отличается на порядок: www.enterprisedb.com/blog/postgresql-vs-microsoft-sql — надо всё пробовать самому!
По функциям — вот отличный обзор: www.pg-versus-ms.com
и вот: dba.stackexchange.com/a/77015/15730
Any company may join the TPC. A membership costs $15,000 per year.А постгрес не завязан на конкретную фирму.
TOP-500 — это линуксоиды знают: www.linux.org.ru/news/clusters/13823822
Но это всё таки не так интересно. Интересен свой опыт. А я пробовал на однотипных задачах обе СУБД. Был резкий контраст когда даже на старом железе запросы в постгре летали мсек, а при переходе на МС на порядок мощном железе аналогичный запрос тянул на секунды или даже десятки секунд — это было сильно заметно.
У людей вот тоже в одиночных тестах производительность отличается на порядок: www.enterprisedb.com/blog/postgresql-vs-microsoft-sql — надо всё пробовать самому!
По функциям — вот отличный обзор: www.pg-versus-ms.com
и вот: dba.stackexchange.com/a/77015/15730
UFO just landed and posted this here
Поправка-по первичным ключам и ограничениям уникальности скуль строит индексы, по FK-нет по умолчанию. Да это и навсегда нужно
Возможно неправильно обобщать свой опыт на всё — описал только то, с чем столкнулся. Проекта того нет, более подробно описать не смогу на данный момент.
По настройкам: МС был оптимизирован максимально: настройки, версионность, изоляция, индексы, запросы и т.п. Постгрес — дефолтный, данные не кешированные и БЕЗ ИНДЕКСОВ, повторюсь.
При переходе на Линукс из-за гораздо более грамотного проектирования системы, чем у МС, на том же железе всегда отмечал увеличение производительности как минимум в 2р: сети, ФС, IO, скорости скомпилированной программы и т.п. Тоже самое отметил и в случае с БД.
Не исключаю, что в последнее время они могли значительно увеличить производительность SQL Server-а, .Net Core и т.п. Какие-то серьёзные изменения у них вроде были.
Если в будущем будет подобный проект — отпишусь.
По настройкам: МС был оптимизирован максимально: настройки, версионность, изоляция, индексы, запросы и т.п. Постгрес — дефолтный, данные не кешированные и БЕЗ ИНДЕКСОВ, повторюсь.
При переходе на Линукс из-за гораздо более грамотного проектирования системы, чем у МС, на том же железе всегда отмечал увеличение производительности как минимум в 2р: сети, ФС, IO, скорости скомпилированной программы и т.п. Тоже самое отметил и в случае с БД.
Не исключаю, что в последнее время они могли значительно увеличить производительность SQL Server-а, .Net Core и т.п. Какие-то серьёзные изменения у них вроде были.
Если в будущем будет подобный проект — отпишусь.
Вы правы, до 2012 скуля у MS SQL Server были явные проблемы причем не только в производительности. Но с 2012 версии все кардинально изменилось. Особенно в более новых версиях
Тогда будет в двойне интереснее сравнить. Хотя вот эти таблицы в памяти как раньше могут определённые сомнения навеять… :-) посмотрим…
Берите сразу 2016 для сравнения, если успеете до конца этого года, иначе-тогда уже 2017 версию берите.
Когда планируете опубликовать результаты?
Когда планируете опубликовать результаты?
Бог планирует! :) Я же сказал, когда будет соответствующий проект.
И когда он будет? Без сроков не будет и результата обещанного Вами
Уважаемый, я ничего не обещал! :) Я описал свой опыт и сказал, что будет интересно сравнить.
«Да, было бы хорошо. Однако сейчас работа другого характера, доступа к тем данным нет. Будет возможность — с удовольствием: стараюсь теперь на хабре писать интересные вещи по ходу работы, чтобы не терялись и могли кому-то пригодиться»
Да, действительно
Но ладно нам-читателям, для своего же интереса или Вы позволите самообман? В итоге конечно решать Вам. Но либо факты с учетом текущих версий, а не 5-10 и более лет назад, или ничего. Предполагать все могут, а уж генераторов всяких идей на каждом шагу. Это малоценная информация (я бы даже сказал бесполезная или устаревшая).
Да, действительно
Но ладно нам-читателям, для своего же интереса или Вы позволите самообман? В итоге конечно решать Вам. Но либо факты с учетом текущих версий, а не 5-10 и более лет назад, или ничего. Предполагать все могут, а уж генераторов всяких идей на каждом шагу. Это малоценная информация (я бы даже сказал бесполезная или устаревшая).
Почему для BI не рассмотрели вертику? Одно из лучших решений, но дорогих.
Но BI-решения всегда были дорогими
Постгресс одна из самых лучших бесплатных СУБД-в этом нет сомнений, но если позволяет бюджет, то лучше рассмотреть для BI-вертику или скуль, если OLTP-скуль
Видел решение по финансовой бирже-более 100 ТБ БД на постгресе… скажу вам плачевно все-на поддержку тратятся суммы в разы больше, чем если бы купили вертику и 2-х спецов, а не целый штат
Но BI-решения всегда были дорогими
Постгресс одна из самых лучших бесплатных СУБД-в этом нет сомнений, но если позволяет бюджет, то лучше рассмотреть для BI-вертику или скуль, если OLTP-скуль
Видел решение по финансовой бирже-более 100 ТБ БД на постгресе… скажу вам плачевно все-на поддержку тратятся суммы в разы больше, чем если бы купили вертику и 2-х спецов, а не целый штат
Realy?
что бы не быть голословным можешь выкачать этот набор данных:
northcentr.blob.core.windows.net/tpcc/order_line.txt
(8,6GB)
Это CSV с разделителем tab
Загрузить в PostgreSQL
Прооптимизированный, куда же без этого :)
и выполнить запрос:
Жду время выполнения этого запроса.
Последняя версия, на которой я это тестировал была
И результат был мягко говоря не радостный.
Как по мне — типичная задача BI на не самых больших данных
что бы не быть голословным можешь выкачать этот набор данных:
northcentr.blob.core.windows.net/tpcc/order_line.txt
(8,6GB)
Это CSV с разделителем tab
Загрузить в PostgreSQL
Прооптимизированный, куда же без этого :)
и выполнить запрос:
SELECT row_number() over (order by ol_number) rnk,
ol_number
,sum(ol_quantity) AS sum_qty
,sum(ol_amount) AS sum_amount
,avg(ol_quantity) AS avg_qty
,avg(ol_amount) AS avg_amount
,count(*) AS count_order
FROM order_line
GROUP BY ol_number
ORDER BY ol_number;
Жду время выполнения этого запроса.
Последняя версия, на которой я это тестировал была
PostgreSQL 9.6.0 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit
И результат был мягко говоря не радостный.
Как по мне — типичная задача BI на не самых больших данных
Извини, у меня работа. Как пел Высоцкий: «Я себе уже всё доказал!» У меня на гораздо более сложном многоэтажном запросе с несколькими JOIN и агрегатами и базе в несколько гиг постгрес был в 20 раз быстрее на базе БЕЗ ИНДЕКСОВ, чем МС с индексами, включая кластерный, с индексированный VIEW WITH SCHEMABINDING, который как ты знаешь в МС работает гораздо быстрее обычного JOIN-а таблиц и т.п.
Так напишите об этом статью, особенно о сравнении производительности-при каких условиях, что и как тестировали и т д-это будет всем интересно, конструктивно, а не голословно
Блажен кто верует…
Но я ожидал такой ответ :)
Но я ожидал такой ответ :)
У меня на гораздо более сложном многоэтажном запросе с несколькими JOIN и агрегатами и базе в несколько гиг постгрес был в 20 раз быстрее на базе БЕЗ ИНДЕКСОВ, чем МС с индексами, включая кластерный, с индексированный VIEW WITH SCHEMABINDING, который как ты знаешь в МС работает гораздо быстрее обычного JOIN-а таблиц и т.п.
К сожалению, с Join'ами на больших таблицах все не так радужно… И мегаспецы с sql.ru так же бессильны. Это лично мой пример, и моя попытка получить помощь
www.sql.ru/forum/1199125/has-join
Я вас удивлю, но к сожалению на SQL.RU я вообще не мог получить ответа на все возникающие проблемы, потому только или иностранные ресурсы, или знакомые или эксперименты
Но в итоге как решили проблему на постгрессе?
Спасут ли индексы? Если да, то какие подошли оптимальное всего?
Или какое было ещё решение?
Спасут ли индексы? Если да, то какие подошли оптимальное всего?
Или какое было ещё решение?
Сравнивали 2016 скуль с постгресо: по тесту Гилева (запускали много раз) как раз получили, что постгре на линуксе с оптимизированными параметрами просела в среднем на 9%, также есть проседания до 9% и по комплексным операциям в 1С.
В итоге после прогонов разных тестов:
в общем получили почти ничью только из-за того, что файловая система лучше на UNIX-системах, чем в Windows, потому постгре и показывает хуже результаты в ОС Windows, чем скуль.
Вообще интересно было бы протестить скуль 2019 (как выйдет) на линуксе и постгре на линуксе, чтобы понять на скоько сильно и как отличаются в производительности две эти СУБД при одинаковой ОС.
Также такие статьи и им подобные не соответствуют действительности по тесту Гилева (возможно были проплачены, либо ради высокого рейтинга для пиара):
infostart.ru/public/962876
Так что не нужно вешать лапшу на уши-скорее всего Вы просто неправильно оптимизировали скуль или использовали старые его версии или редакцию урезанную
В итоге после прогонов разных тестов:
в общем получили почти ничью только из-за того, что файловая система лучше на UNIX-системах, чем в Windows, потому постгре и показывает хуже результаты в ОС Windows, чем скуль.
Вообще интересно было бы протестить скуль 2019 (как выйдет) на линуксе и постгре на линуксе, чтобы понять на скоько сильно и как отличаются в производительности две эти СУБД при одинаковой ОС.
Также такие статьи и им подобные не соответствуют действительности по тесту Гилева (возможно были проплачены, либо ради высокого рейтинга для пиара):
infostart.ru/public/962876
Так что не нужно вешать лапшу на уши-скорее всего Вы просто неправильно оптимизировали скуль или использовали старые его версии или редакцию урезанную
Postgres был 8.3 где-то, мсскл — 2005-2008, всё под виндой server 2003/2008. Может сейчас ускорили, но я сильно сомневаюсь, что его могли в разы ускорить.
постгрес был 10.5, ОС-CentOS 7, скуль 2016 Standard и винда 2012 R2 сервер
постгре дал сначала результат в среднем 8,8 при оптимизации для 1С, после всех оптимизаций (ядро CentOS, файловой системы и т д) в том числе и по следующему калькулятору подгоняли: pgconfigurator.cybertec.at
получили, что макс на постгре тест Гилева показал результат в 9,96, тогда как даже не в оптимизированном скуле (оптимизация была поверхностная-как указано в 1С) показатель был всегда выше 10, а именно 10,4-это среднее значение.
Итог: 3 дня подбирали оптимальные параметры для постгре, оптимизированного под 1С со всеми патчами, а скуль лишь немного настроили как рекомендует 1С. И в итоге-постгрес продул в производительности скулю, несмотря на то, что файловая система в линуксе лучше файловой системы в винде да еще и оптимизирована была. Вывод: СУБД постгре явно проигрывает в производительности СУБД MS SQL Server и только за счет ОС и файловой системы может приближаться к производительности скуля на винде. Но выход скуля 2019, который будет нормально работать в том числе и на линуксе все изменит
постгре дал сначала результат в среднем 8,8 при оптимизации для 1С, после всех оптимизаций (ядро CentOS, файловой системы и т д) в том числе и по следующему калькулятору подгоняли: pgconfigurator.cybertec.at
получили, что макс на постгре тест Гилева показал результат в 9,96, тогда как даже не в оптимизированном скуле (оптимизация была поверхностная-как указано в 1С) показатель был всегда выше 10, а именно 10,4-это среднее значение.
Итог: 3 дня подбирали оптимальные параметры для постгре, оптимизированного под 1С со всеми патчами, а скуль лишь немного настроили как рекомендует 1С. И в итоге-постгрес продул в производительности скулю, несмотря на то, что файловая система в линуксе лучше файловой системы в винде да еще и оптимизирована была. Вывод: СУБД постгре явно проигрывает в производительности СУБД MS SQL Server и только за счет ОС и файловой системы может приближаться к производительности скуля на винде. Но выход скуля 2019, который будет нормально работать в том числе и на линуксе все изменит
Вот читаю я эту статью и вижу, что написано человеком знающим и опытным — без иронии, действительно знающим и опытным. Но. Но ваши рекомендации опоздали лет на 8-10 — не для какого-то конкретного читателя опоздали, а в принципе опоздали. И по объёмам данных опоздали, и по конкретным приёмам опоздали.
Мне уже надоело переучивать DBA и разработчиков, начитавшихся "советов в энторнетах", подобных данной статье. Проблема не в советах, конечно же а в том, что их применяют не включая мозг. Эти статьи смешиваются, превращаются в опасные мифы и заблуждения.
Вот просто для иллюстрации, совет "сначала выберите удаляемые/изменяемые данные во временную таблицу". Совет для некоторых конкретных случаев весьма дельный. Но на самом деле часто это очень вредный совет:
- Не сильно заботясь воткнули stop-and-go.
- Потеребили tempdb
- Всё сложили в таблицу без индексов (кстати и в вашем примере), а если таких таблиц 10-20, то что потом в соединении?
- А если и создали, то воспроизводимость планов с индексами и таблицами в tempdb и их диагностика мягко говоря слабее, чем с продуманными постоянными
- И при создании/удалении временных таблиц можно легко нарваться на узкое место в виде перекомпиляции запросов.
Не бывает универсальных (или "вечных") рекомендаций. Рекомендации нужно применять либо как архитектурные принципы ("знаем, что есть исключения, но делаем так пока нет явных причин так не делать"), либо только после диагностики. А вот про диагностику у вас вообще почти ничего нет. Я не про ту диагностику где "индекс давно не используется", а про "что является узким местом данной системы и чем это обусловлено". Ну хоть бы sys.dm_os_wait_stats упомянули. А в идеале, чтобы велосипеды не изобретать, можно и тулзы Брента Озара упомянуть. Кстати, на его основном сайте очень много интересной, полезной и более актуальной информации о производительности MS SQL
И еще сильно напрягли рекомендации в стиле "делайте всё правильно", например:
- "Правильно задавайте уровень изоляции при работе с БД" — ахаха, 80% корпоративных БД на nolock до сих пор сидят, а из разработчиков, хорошо, если 20% могут осмысленно уровни изоляции обсуждать
- "используйте разумно хинты к запросам" — тоже прекрасно. Степени разумности, которые я видел — от "нельзя ничего" до "указать индекс для каждой таблицы".
Во-первых эти концепции скорее не устареют, а будут дополняться и более детализироваться
А во-вторых, здесь даны примеры. И как и любой пример он имеет свои преимущества и недостатки
И в-третьих, грубо, но для общего понимания вполне сгодится-всегда используется tempdb и если проблема с выделением временной таблицы, то либо вы обрабатываете слишком много данных за раз для вашей системы (тогда делайте порциями обработку), либо проблема не в запросе, а в tempdb-нехватка памяти, медленный ввод-вывод и т д
И итог-напишите свою статью, исходя из того опыта и знаний, что накопил и поделитесь с читателями
Вставка же небольшой порции данных во временную таблицу, позволяет минимизировать блокировки. Для систем, где есть проблема с tempdb разницы не будет, т к либо ожидание будет на блокировку у других запросов в том числе при не использовании временной таблицы, либо задержка будет в вводе-выводе. Но система сама сделает промежуточную таблицу при определённых условиях, а система, где с tempdb все нормально-данный запрос позволит другим не ждать окончания блокировки
И Вы правы-все нужно применять с головой
А во-вторых, здесь даны примеры. И как и любой пример он имеет свои преимущества и недостатки
И в-третьих, грубо, но для общего понимания вполне сгодится-всегда используется tempdb и если проблема с выделением временной таблицы, то либо вы обрабатываете слишком много данных за раз для вашей системы (тогда делайте порциями обработку), либо проблема не в запросе, а в tempdb-нехватка памяти, медленный ввод-вывод и т д
И итог-напишите свою статью, исходя из того опыта и знаний, что накопил и поделитесь с читателями
Вставка же небольшой порции данных во временную таблицу, позволяет минимизировать блокировки. Для систем, где есть проблема с tempdb разницы не будет, т к либо ожидание будет на блокировку у других запросов в том числе при не использовании временной таблицы, либо задержка будет в вводе-выводе. Но система сама сделает промежуточную таблицу при определённых условиях, а система, где с tempdb все нормально-данный запрос позволит другим не ждать окончания блокировки
И Вы правы-все нужно применять с головой
Sign up to leave a comment.
Три аспекта оптимизации (БД и ПО)