1.1, Аноним (-), 23:48, 12/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +20 +/– |
Это очень круто. Один из тех продуктов, который стабильно из года в год вызывает уважение.
| |
1.2, Аноним (-), 23:54, 12/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Раньше они вначале альфы выпускали, а потом бету. А сейчас сразу бета-версия вышла и на пару месяцев раньше. Какие-то изменения в подготовке релизов?
| |
|
2.7, Аноним (-), 07:51, 13/05/2016 [^] [^^] [^^^] [ответить]
| +4 +/– |
Никак. Не умеет 1с с полноценной, некастрированной постгрей работать. А умеет работать со спецсборками, и сборки эти очень даже не 9.6 версии.
| |
|
3.8, Аноним (-), 08:36, 13/05/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Никак. Не умеет 1с с полноценной, некастрированной постгрей работать. А умеет работать
> со спецсборками, и сборки эти очень даже не 9.6 версии.
ну ка раскрой суть кастрации постгреса одинесовыми патчами? И да, там 9.4 уже, при том, что в шестой шапке 8.4, а в седьмой 9.2
| |
|
4.15, none_first (ok), 13:21, 13/05/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Никак. Не умеет 1с с полноценной, некастрированной постгрей работать. А умеет работать
>> со спецсборками, и сборки эти очень даже не 9.6 версии.
> ну ка раскрой суть кастрации постгреса одинесовыми патчами? И да, там 9.4
> уже, при том, что в шестой шапке 8.4, а в седьмой
> 9.2
"там" http://1c.postgrespro.ru/rpm/ уже и 9.5
| |
|
5.41, Аноним (-), 19:02, 13/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
я на users.v8.1c.ru смотрел, а 9.5 ещё рано, на мой взгляд, в продакшин тянуть
| |
|
|
|
4.56, Tihon (??), 21:59, 29/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
Ок. А что в этом патче может понравится, если вместо реализации платформы для версионных БД ребята попытались сделать из Postgres - блокировочник? Видимо мне никогда не понять почему массивы, иерархия и текст имеет всегда один тип - 'bytea'... Почему 1с (по-умолчанию, без возможности от их отказаться) создает мне индексы размером с таблицу и использует их чуть реже чем никогда?
Про возможность поставить более эффективный GIN/GiST-индекс вместо B-tree для многопользовательского отчета с огромным количеством зависимостей - умолчу...
Резюмирую - это охерительных размеров костыль, который к тому же не применим к актуальным релизам без внесения правок к патчам.
| |
|
3.13, Онаним (?), 11:04, 13/05/2016 [^] [^^] [^^^] [ответить]
| –5 +/– |
А вот как патчи сделают да к 1С прикрутят - тогда и посмотрим.
9.4 запрос на одном процессоре выполняет, оттого получается долго и печально. MS SQL куда шустрее работает.
Интересно будет 9.6 сравнить с MS SQL.
| |
|
4.16, none_first (ok), 13:23, 13/05/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
> А вот как патчи сделают да к 1С прикрутят - тогда и
> посмотрим.
> 9.4 запрос на одном процессоре выполняет, оттого получается долго и печально. MS
> SQL куда шустрее работает.
куда шустрее? нука побалуйте бенчмарками
> Интересно будет 9.6 сравнить с MS SQL.
не интересно
| |
|
5.42, Аноним (-), 19:04, 13/05/2016 [^] [^^] [^^^] [ответить]
| +4 +/– |
>> А вот как патчи сделают да к 1С прикрутят - тогда и
>> посмотрим.
>> 9.4 запрос на одном процессоре выполняет, оттого получается долго и печально. MS
>> SQL куда шустрее работает.
> куда шустрее? нука побалуйте бенчмарками
>> Интересно будет 9.6 сравнить с MS SQL.
> не интересно
у него в торгашиной методичке написано, что надо старательно игнорировать настройки постгреса, а то мсскуль соснёт нечаянно
| |
|
4.19, Клыкастый (ok), 13:54, 13/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
оказывается проблема не в невменяемых портянках запросов, а в том, что они на одном ядре пашут.
| |
|
5.25, Онаним (?), 15:03, 13/05/2016 [^] [^^] [^^^] [ответить]
| –3 +/– |
Почему-то портянки запросов из 1С в MS SQL отрабатываются обычно в 2 раза быстрее.
Некоторые - в 5-10 раз быстрее (данные из логов 1С, Постгре и MS SQL).
На наших задачах в 1С MS SQL отрабатывает в 3-4 раза быстрее, чем Постгре на том же оборудовании. При тестах явно видно, что MS SQL нагружает 2-3 процессора, Постгре - всегда только 1.
Поэтому и интересно будет посмотреть на Постгре с распараллеливанием обработки...
| |
|
6.26, Клыкастый (ok), 15:13, 13/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Почему-то портянки запросов из 1С в MS SQL отрабатываются обычно в 2 раза быстрее.
Есть подозрение - потому что изначально затачивались именно под планировщик ms-sql.
> На наших задачах в 1С MS SQL отрабатывает в 3-4 раза быстрее, чем Постгре на том же оборудовании. При тестах явно видно, что MS SQL нагружает 2-3 процессора, Постгре - всегда только 1.
Есть подозрение, что если составлять запросы с учётом планировщика постгри - всё будет несколько иначе. Есть очень сильное подозрение, что если бы разрабы 1С ориентировались на постгрю изначально, никаких бы патчей не понадобилось.
Но да, я в курсе - у кровавого энтерпрайза никогда нет денег делать как положено и потому все сидят и ждут, когда наконец дома будут строить так, чтобы влезали их окошки.
> Поэтому и интересно будет посмотреть на Постгре с распараллеливанием обработки...
Будет лучше, но это слабое утешение.
| |
|
7.27, 123 (??), 15:22, 13/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>Есть подозрение, что если составлять запросы с учётом планировщика постгри - всё будет несколько иначе.
Там патчи в основном на сравнение данных без учета регистра.
>>Есть подозрение, что если составлять запросы с учётом планировщика постгри - всё будет несколько иначе.
Там два косяка - медленная работа при соединении живых таблиц с виртуальными (срез последних надо пихать в отдельную таблицу и тд) и работа с таблицами регистров бухгалтерии - очень часто приходится перегружать слона ибо дедлоки валят массово. ИМХО реализация Cross Join в слоне кривовато сделана.
| |
7.43, _ (??), 19:10, 13/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
> у кровавого энтерпрайза никогда нет денег делать как положено
Клыкастый, это шедевр!!! (С)Сергей Светлаков
| |
7.49, none_first (ok), 13:58, 14/05/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Почему-то портянки запросов из 1С в MS SQL отрабатываются обычно в 2 раза быстрее.
> Есть подозрение - потому что изначально затачивались именно под планировщик ms-sql.
>> На наших задачах в 1С MS SQL отрабатывает в 3-4 раза быстрее, чем Постгре на том же оборудовании. При тестах явно видно, что MS SQL нагружает 2-3 процессора, Постгре - всегда только 1.
> Есть подозрение, что если составлять запросы с учётом планировщика постгри - всё
> будет несколько иначе. Есть очень сильное подозрение, что если бы разрабы
> 1С ориентировались на постгрю изначально, никаких бы патчей не понадобилось.
причина описана здесь http://www.silverbulleters.org/ne-obizhayte-linux-oida-ili-osobennosti-patcha
и патчи ничего вредного не несут, тем более что делаются в плотном сотрудничестве 1С и профессиональной команды PostgreSql
> Но да, я в курсе - у кровавого энтерпрайза никогда нет денег
> делать как положено и потому все сидят и ждут, когда наконец
> дома будут строить так, чтобы влезали их окошки.
>> Поэтому и интересно будет посмотреть на Постгре с распараллеливанием обработки...
> Будет лучше, но это слабое утешение.
а бенчи есть здесь http://efsol.ru/articles/performance-1s-postgre-ms-sql.html
там нет никаких 3-4 раза, есть полтора, но кривость рук разработчиков может может сотворить чудо ;)
и это "без распараллеливания" как тут выразились
| |
|
6.51, Вареник (?), 19:53, 15/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
Если долго-долго (десятилетие+) затачивать продукт под целевую базу - то ничего удивительного, что на ней будет выигрыш в скорости.
Oracle для типичной установки 1C, среднеторговой фирмочки - слишком дорого. Требуемый DBA отдельный - тем более.
Предлагать опенсорс - непонтово. Нет "синэргетики бизнеса", т.е. взаимного проталкивания продаж. Не на кого потом переводить стрелки, "это не мы, это XXX глючит"...
Что можно еще впарить, если Oracle дорого? Вывод очевиден и иднозначен. MS SQL. Не Линтер же :)
| |
|
|
|
|
|
1.9, Аноним (-), 08:50, 13/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
А аналог MS-SQL BACKUP LOG имеется в слонике? Или там надо как и раньше плясать с бубнами и настраивать резервного слона, что бы можно было восстановить архив на произвольный момент времени?
| |
1.14, Stax (ok), 11:55, 13/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ай-яй-яй, ну как так можно, *самое* замечательное, что ждем в этом релизе, и не упомянуть! Теперь GIN-индексы можно создавать с любым maintenance_work_mem. Сейчас постоянно для пересоздания каких-то индексов приходится его до гига урезать, а для одного уже до 500 мегабайт, иначе создание падает с нехваткой памяти (а так как GIN загаживаются быстро, пересоздавать приходится регулярно). Из-за чего pg_repack автоматом не запустить и прочие радости...
| |
|
2.17, Аноним (-), 13:23, 13/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
Распараллеливание, ИМХО, более фундаментальное и ожидаемое улучшение
| |
|
1.24, Аноним (-), 15:00, 13/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
подскажите пожалуйста я правильно понимаю что в синхронном режиме пришедший update сначала идет на slave сервер, записывается, делается fsync (если разрешен), далее master записывает себе, делает fsync (если разрешен) и только затем говорит клиенту что update прошел?
те при падении master мы можем сразу переключиться на slave потому что он гарантированно синхронен?
а как сюда вяжется "synchronous_commit = remote_apply"?
объясните пожалуйста если знаете как это работает, заранее большое спасибо!
| |
|
2.29, Аноним (-), 15:47, 13/05/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
Пришедший апдейт сначала пишется в журнал WAL и оттуда отправляется на слейв, на слейве он применяется, об этом уведомляется мастер, и только тогда мастер завершает исполнение запроса, пока уведомление не придет мастер тупо ждет. Да, при падении мастера можно сразу переключится на слейв, он синхронен. Это и есть remote_apply. Как происходит обработка если от слейва ответ не пришел не знаю, могу предположить что запись в журнале "остается непримененной"
| |
|
|
4.34, Аноним (-), 16:42, 13/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
Если on то мастер считает что изменение прошло не когда оно было применено слейвом, а когда оно было только принято им
| |
|
5.36, Аноним (-), 17:20, 13/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
выходит remote_apply наиболее синхронный и безопасный к падению и переключению режим. спасибо!
| |
|
|
|
|
1.31, Аноним (-), 16:26, 13/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
подскажите когда в postgres появиться master-master? знаю про BDR, когда это будет в официальном postgres?
| |
|
2.33, Andrey Mitrofanov (?), 16:38, 13/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
> подскажите когда в postgres появиться master-master? знаю про BDR, когда это будет
> в официальном postgres?
Никогда потому, что это не SQL.
| |
|
3.37, Аноним (-), 17:23, 13/05/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
>Никогда потому, что это не SQL.
Что за бред? я тестировал летом связку из трех серверов в BDR - создавал таблицы, делал в них insert, добавлял поля, менял типы полей - все менялось на всех трех серверах с какого бы я это не делал. в продакшене не использовали, просто поигрались и убедились что изменения синхронизируются без всяких триггеров.
| |
|
4.39, 123 (??), 18:06, 13/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
>>Никогда потому, что это не SQL.
> Что за бред? я тестировал летом связку из трех серверов в BDR
> - создавал таблицы, делал в них insert, добавлял поля, менял типы
> полей - все менялось на всех трех серверах с какого бы
> я это не делал. в продакшене не использовали, просто поигрались и
> убедились что изменения синхронизируются без всяких триггеров.
Попробуй поменять на 100 гиговой базе с внешними ключами. Просто интересно сколько это займет.
| |
|
|
2.35, Аноним (-), 16:51, 13/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
насколько я понял из заявлений квадратов (разработчиков BDR) они готовы, но сообщество не чешется) Также слышал о том что BDR не поддерживает некоторые базовые фичи постгреса, и возможно поэтому с BDR не спешат. Хрен бы еще с BDR, вот это бы хотябы - http://www.postgresql.org/about/news/1666/ ))
| |
|
3.44, Andrey Mitrofanov (?), 21:00, 13/05/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> насколько я понял из заявлений квадратов (разработчиков BDR) они готовы, но сообщество
> не чешется) Также слышал о том что BDR не поддерживает некоторые
> базовые фичи постгреса, и возможно поэтому с BDR не спешат. Хрен
UDR уже "завбросили". И кому оно впилось?
Ты внимательно читал мануал того BDR? В части "у нас БЫСТРО* и многомастерно! <small>просто скажите вашим программерам переписать эти с-ные приложения</small> *без блокировок, прогремссивно!"
> бы еще с BDR, вот это бы хотябы -
Табе вот уже подавай каких-то "новых" блестящек.
Про ужасы блестяшек [или примерно]
http://bonesmoses.org/2016/05/06/pg-phriday-big-data-is-hard/
| |
|
4.47, Роман (??), 00:43, 14/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
Да одна вещь по большому счету нужна, чтобы не весь кластер реплицировался, а только схема по выбору..
| |
|
|
|
|