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


1С:Предприятие :: 1С:Предприятие 8 общая

PostgreSQL 10 beta для 1С

PostgreSQL 10 beta для 1С
Я
   valcvalc
 
21.05.18 - 17:41
Случайно обнаружено на просторах бета 10го постреса от postgrespro ! Особенно интересно тем кто пользует DW на 1C http://repo.postgrespro.ru/1c-10-beta/
Теперь и параллельный скан индексов и нативное партиционирование !
 
 
   marty0701
 
1 - 21.05.18 - 17:42
(0)"нативное партиционирование" Своими словами сможешь?
   valcvalc
 
2 - 21.05.18 - 17:47
Доки : https://postgrespro.ru/docs/postgrespro/10/ddl-partitioning

Смысл в том, если большая таблица(например 100Гб и больше) в которой лежит аналитика с периодичностью, можно ее "разделить" например по месяцам и при последовательном чтении планировщик будет перебирать данные только из файлов этой "секции" а не всей таблицы.
   rphosts
 
3 - 21.05.18 - 17:48
(1) видимо партишент тэйбл. Оракл это умел начиная с 8ЕЕ
   Fragster
 
4 - 21.05.18 - 17:48
Partitioning refers to splitting what is logically one large table into smaller physical pieces. Partitioning can provide several benefits:

    Query performance can be improved dramatically in certain situations, particularly when most of the heavily accessed rows of the table are in a single partition or a small number of partitions. The partitioning substitutes for leading columns of indexes, reducing index size and making it more likely that the heavily-used parts of the indexes fit in memory.

    When queries or updates access a large percentage of a single partition, performance can be improved by taking advantage of sequential scan of that partition instead of using an index and random access reads scattered across the whole table.

    Bulk loads and deletes can be accomplished by adding or removing partitions, if that requirement is planned into the partitioning design. Doing ALTER TABLE DETACH PARTITION or dropping an individual partition using DROP TABLE is far faster than a bulk operation. These commands also entirely avoid the VACUUM overhead caused by a bulk DELETE.

    Seldom-used data can be migrated to cheaper and slower storage media.
   Вафель
 
5 - 21.05.18 - 17:49
(2) во всех системах это есть, но практически никто не использует
   sknhb
 
6 - 21.05.18 - 17:52
(2) а после рестуктуризации 1С это партиционирование сохранится?
   sknhb
 
7 - 21.05.18 - 17:53
(5) olap-системы практически все используют
   valcvalc
 
8 - 21.05.18 - 17:53
хз, надо смотреть и тестить официально пока нигде не заявлена поддержка 10й версии
   valcvalc
 
9 - 21.05.18 - 17:54
Подниму на тестовом серваке, погоняю, через пару часов станет ясно что и как
   Вафель
 
10 - 21.05.18 - 17:58
(7) олап системы на 1с? это где такие?
 
 Рекламное место пустует
   rphosts
 
11 - 21.05.18 - 17:59
(6) хороший вопрос, пока 1С это не поддерживает нативно партишен тэйбл - использование этого его это нарушение лицензинного соглашения. А вот распараллеленный скан ничего не нарушает.
   Fragster
 
12 - 21.05.18 - 18:05
(10) ну типа агрегаты под это и задумывались
   valcvalc
 
13 - 21.05.18 - 18:06
да, но агрегаты это тот еще гемор ) пользовали
   Fragster
 
14 - 21.05.18 - 18:08
(13) это да... вот мне не хватает дополнительных "оборотных" измерений в дополнение к остаточным (по образцу субконто). Ресурсы не очень подходят по причине отсутствия в итогах. Приходится делать два регистра или еще как извращаться.
   Вафель
 
15 - 21.05.18 - 18:09
(12) я про теорию знаю. Я спрашивал где они все?
   Fragster
 
16 - 21.05.18 - 18:10
(15) там же, где бизнес процессы
   valcvalc
 
17 - 22.05.18 - 09:22
Сервер PostgreSQL 10 нормально поднялся на Centos 7, в изначальном конфиге отсутствовали настройки plantuner и online_analyze, по какой-то причине теперь постргря лежит в /opt. 1С скушало 10ую версию без проблем, ИБ открывается. Если будет время - в течении дня замерю время исполнения большого аналитического отчета на 9.6.8 и на 10.4 при одинаковых настройках
   sknhb
 
18 - 22.05.18 - 09:35
(5) ты тупой? сам же пишешь - "во всех системах", а потом перескочил на 1С
   2S
 
19 - 22.05.18 - 09:40
(17) будь добр, очень интересно взглянуть
   Fragster
 
20 - 22.05.18 - 09:41
(17) очень круто! еще вот это запусти, если будет время: http://catalog.mista.ru/public/173394/
   valcvalc
 
21 - 22.05.18 - 10:41
(20) ок, думаю ближе к вечеру или завтра с утра поделюсь результатми
   Вафель
 
22 - 22.05.18 - 10:43
(18) во всех других бд, которые для 1с
   valcvalc
 
23 - 23.05.18 - 10:29
Выполнил,
9.6.8 - http://rgho.st/8qNjbTSBg
10.4 - http://rgho.st/7jb5S99mP

OS: Centos 7 3.10.0-862.2.3.el7.x86_64
FS: ZFS (recordsize 128K, compression lz4, atime off, logbias throughput)

PostgreSQL.conf:

max_connections = 128
shared_buffers = 1GB
temp_buffers = 256MB
work_mem = 512MB
maintenance_work_mem = 256MB
max_worker_processes = 8
max_parallel_workers_per_gather = 4
synchronous_commit = off
full_page_writes = off
random_page_cost = 1.5
parallel_tuple_cost = 0.02
effective_cache_size = 10GB
max_locks_per_transaction = 150

online_analyze.threshold = 50
online_analyze.scale_factor = 0.1
online_analyze.enable = on
online_analyze.verbose = off
online_analyze.min_interval = 10000 
online_analyze.table_type = 'temporary'
plantuner.fix_empty_table = false
   rustemg
 
24 - 23.05.18 - 10:40
Чето не радуют графики
   valcvalc
 
25 - 23.05.18 - 10:45
Как есть, может beta...
   valcvalc
 
26 - 23.05.18 - 10:47
Я больше ожидаю разницу при выборке данных с больших таблиц с большими индексами, будет время сегодня погоняю, выложу сравнение
   rustemg
 
27 - 23.05.18 - 11:14
Может zfs привносить свое влияние. Читал что для постгресс, лучше файловую систему ext3, как понял маленькая нагрузка на ЦП и выигрыш при больших количествах файлов.
   valcvalc
 
28 - 23.05.18 - 12:18
(27) будет время разверну на xfs и ext4 - запущу повторно
   Вафель
 
29 - 23.05.18 - 12:22
а зачем компрессию на файловой системе? не уж то такая большая база?
   valcvalc
 
30 - 23.05.18 - 16:15
(29) 4Tb
   МихаилМ
 
31 - 23.05.18 - 18:02
(30) реструктуризацию как делаете ?. сколько пользователей?
   Я вам не Димон
 
32 - 23.05.18 - 18:13
(30) а конфа какая?
   mistеr
 
33 - 23.05.18 - 18:37
Неужели решили поддержать секционирование в платформе? Что-то я сомневаюсь. Если решат, то как минимум скуль тоже поддержат. И интерфейс для администрирования должен появиться. И в Зазеркалье похвалятся обязательно. Пока ничего такого не видно.

А было бы круто, конечно.
 
 
   ERWINS
 
34 - 23.05.18 - 20:34
(33) С какого вы сделали вывод о поддержке секционирования в 1с?
   valcvalc
 
35 - 23.05.18 - 20:56
(31) (32) конфигурация самописная, основой объем в регистрах накопления, они изначально спроектированы весьма удачно, за 4е года пришлось сделать только одну реструктуризацию. Остальное маленькое и реструктуризация проходит быстро. Пользователей мало от 4 до 15, но оч.большая отчетность, база имеет смысл ETL + DW + ROLAP.
   Злопчинский
 
36 - 23.05.18 - 21:53
что такого можно спроектировать "очень удачно" в регистрах накопления...
   g00d
 
37 - 24.05.18 - 00:25
по гилеву между 9.6 и 10 разница на уровне погрешности.
возможно с большими базами и будут преимущества, но пока смысла связывать с бетой не вижу.
Тестил под линукс на xfs
   ansh15
 
38 - 24.05.18 - 11:28
(20) Нет там существенной разницы
PostgreSQL 9.6.7-1C - http://fragster.ru/perfomanceTest/result.php?guid=b2ca18be-5ee0-11e8-5e88-b06ebf2ee3f0
Postgres Pro 1C 10.4(beta) - http://fragster.ru/perfomanceTest/result.php?guid=041a4616-5ed8-11e8-9984-b06ebf2ee3f0
10.4 чуть шустрее будет, процентов на 10(кроме временных таблиц). Результаты теста Гилева практически одинаковые, 69-70.
   Fragster
 
39 - 24.05.18 - 11:39
(38) ИМХО 10% практически забесплатно - неплохой профит
   Fragster
 
40 - 24.05.18 - 11:40
а вот -10% во временных таблицах непонятно, в релиз нотесах вроде писали про их оптимизацию
   mistеr
 
41 - 24.05.18 - 21:40
Тем временем, Postgre выпустил 11-ю бету. С хэш-секционированием и прочими плюшками.
   ansh15
 
42 - 24.05.18 - 23:00
(39)Сделал чуть получше и на 9.6.7 и на 10.4
http://fragster.ru/perfomanceTest/result.php?guid=dedafd10-5f85-11e8-d38d-b06ebf2ee3f0
http://fragster.ru/perfomanceTest/result.php?guid=3f396d6a-5f6b-11e8-ad8a-b06ebf2ee3f0
Выключил spectre_v2 при загрузке ядра(nopti уже был).
   Fragster
 
43 - 25.05.18 - 12:12
(42) и еще + 10% (хоть их у нас раньше и отняли просто)
   ERWINS
 
44 - 25.05.18 - 12:58
Инмемори там нет....
   Локи-13
 
45 - 25.05.18 - 13:06
(11) >>>это нарушение лицензионного соглашения
этот пункт соглашения достаточно противоречивый на самом деле

т.к. база данных MS SQL является частью ПО MS SQL, значит лицензии 1С на него распространяться не могут. (ну и постгре аналогично)

то что работа 1ска не отвечает за работу программы из-за нарушения структура табиц - это уже другой вопрос.
   dmrjan
 
46 - 08.06.18 - 11:29
Рабочая версия PostgreSQL 10.3-2.1C выпущена, но использовате ее рекомендовано с версии 1С 8.3.13.
   ansh15
 
47 - 08.06.18 - 16:11
http://fragster.ru/perfomanceTest/result.php?guid=f7381b6a-6a2d-11e8-6581-b06ebf2ee3f0
Результат по временным таблицам  у PostgreSQL 10.3-2.1C чуть лучше, чем для Postgres Pro 1C 10.4(beta), хотя, может и платформа 8.3.13 что-то привносит. Если выполнять только тест временных таблиц в одном потоке, получается 26000. Результаты остальных тестов в пределах 1%.
   tesseract
 
48 - 08.06.18 - 23:14
(0) Они еще баг с Cross Join в последней версии не поправили. Пришлось конфы немножко править. Хотя за само использование его я бы сильно бил по рукам.

Около 2-х лет сидим плотненько на сборках от PostgresPro. Они побыстрее "1С-ных", при должной настройке.  

(2) Делали такое лет 5 назад. Слетало на любой чих. Реструктуризация/обновление сначала создает "Таблица"NG и туда впихивает данные. Так что любое деление по дате - отваливается сразу.

(17)  На centos она вроде всегда туда ставилась.


(46) 1С наконец избавилась от патчей для слона и польностью перешла на расширения. Теперь не нужно добавлять репозиторий от Postgrespro. В 3.13 столько всего хорошего и долгожданного заявлено, что явно будет товарный поезд багов.  


(39) Гилевские попугаи многое не учитывают. В реальной работе прирост должен быть сильнее.
   nicxxx
 
49 - 08.06.18 - 23:18
(11) Что вы все уперлись в это лицензионное соглашение? Что вам 1С сделает, если в таблицы СУБД залезете? Отругает? По попе отшлепает? Может хватит уже...
 
 Рекламное место пустует
   tesseract
 
50 - 08.06.18 - 23:44
(49) Так никто его не читал, но все точно знают.
   Локи-13
 
51 - 09.06.18 - 09:13
(49) +1
тем более это незаконный пункт, база данных - отдельный продукт, что хотим то с ним и делаем
   Локи-13
 
52 - 09.06.18 - 09:15
у других вендоров тоже есть этот пункт, но он влияет только на поддержку, не лезешь в ядро - получаешь поддержку (за деньги), лезешь - сам копайся (даже если за деньги)
   1Снеговик
 
53 - 09.06.18 - 10:31
Народ, никто не подскажет что это такое было, когда поставил предыдущий релиз 9.6.7-1.1C на 8.3.11.2867 и словил отсутствие сортировки по наименованию в движениях и печатный форме?
Так и не понял как победить. В MS SQL Таких проблем не было, а тут даже непонятно по какому принципу - в документе одно, а при печати какой-то случайный порядок позиций.
Или Postgre не умеет сразу из коробки нормально работать, надо все допиливать?
   Fragster
 
54 - 09.06.18 - 11:01
>в документе одно, а при печати какой-то случайный порядок позиций.

Это ты сам виноват, если пользовался запросом и не указывал порядок сортировки. А с мсскулем тебе просто везло.
   Fragster
 
55 - 09.06.18 - 11:01
вот если обход в объектной методике выдавал строки не в том порядке - тогда косяк. только ведь такого не было, да?
   1Снеговик
 
56 - 09.06.18 - 11:10
(54) Вообще-то речь про свежую типовую УТ 11.4.
И по-умолчанию сортировка должна быть по номеру строки хотя бы, или запрос возвращает тот же порядок как в ТЧ документа, а там получался случайный разброс. Удивило то, что никогда ничего такого не встречал на MS, а тут сразу грабли какие-то.

При чем в движения документа когда смотришь, то одна таблица нормальная, другая в случайном порядке, третий регистр тоже с нормальным порядком. Прям чудеса.

Значит в 1С такие же писатели, сидят на MS SQL и не подозревают о неадекватном подведении типовых на Postgre.
   dmrjan
 
57 - 09.06.18 - 11:34
Насколько помню в MSSQL и PostgreSQL был разный порядок сортировки и как раз этот момент был учтен в однм из патчей PostgreSQL для 1с. Может с патчем что-то накосячили?
   Fragster
 
58 - 09.06.18 - 11:37
(57) нет, тот порядок сортировки связан со значением NULL
   Fragster
 
59 - 09.06.18 - 11:39
(56) тогда это ошибка конфигурации. в общем случае порядок возвращаемых строк в запросе неопределен, если не указана сортировка. то, что возврат в мсскуле идет по номеру строки - везение (связано с особенностями оптимизатора запросов). в постгре данные более размазаны физически - он все-таки версионник, и порядок чаще "произвольный". хотя после вакуума он и может быть некоторое время стабильным.
   dmrjan
 
60 - 09.06.18 - 13:30
Больше версий PostgreSQL Pro отдельно под 1С больше не существует? Теперь все патчи присутсвуют в самой PostgreSQL Pro?
   dmrjan
 
61 - 09.06.18 - 13:45
А вижу - "Доработки, реализуемые фирмой «1С» для СУБД PostgreSQL, реализованы в виде расширения." Тем самым - версия 8.3.13 теперь обязательна.


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