https://wonderland.v8.1c.ru/blog/segmentatsiya-dannykh/

Эм... То есть то, что легко и гибко делается средствами СУБД, пихнули в платформу?)

работают люди.

Что-то странно. Заявлено только для клиент-серверной, а в примере путь к табличным пространствам указывается как путь в файловой системе. [Наx] зачем мне часть таблиц из скуля переносить в какое-то файло, не понимаю. Так что с одной стороны, вроде полезно, а с другой - ни[x]чего не понятно

Я нихрена не понял как они собираются влезать в "кишки" СУБД, чтобы раскидать таблицы по файлам

Ага, и что будет в dt?
Жаль, как обычно мало информации. Как с комьюнити-версией.

(1) ну, я бы не стал говорить, что прям "легко и гибко"

вылядит так как будто платформа будет работать с несколькими БД.

(5) возможно, в dt будет всё, а вот в скульном bak-е - не только лишь...

(7) а чё тогда не с несколькими инстансами СУБД? контрагентов на один сервер, номенклатуру на другой, остатки на третий. и молиться, чтобы чё-нить не свалилось

(6) ну я про то, что раскидать таблицы БД по дискам прекрасно можно средствами СУБД

(10) если одинесовцы это "колдунство" обернут в интерфейс платформы, да ещё это где-то в метаданных будет храниться, то будет хорошо, наверно.
или как обычно, скорее всего

теперь можно фильмы хранить в базе?

(10) то что вы навертите в СУБД будет порушено при первой же реструктуризации. без фичи из (0).
если колдунство (11) настроить на стороне 1с, то сервер приложений при работе с СУБД будет учитывать эти особенности.

(12) для кина делали отдельное Хранилище Двоичных Данных силами сервера приложений в выбранном хранилище в виде файлов.

А неплохо было бы, если бы сделали возможность хранить ИБ в нескольких базах СУБД, с разделением по этим самым "табличным пространствам", отображаемым на стороне SQL-сервера на базы sql. Для тех, кто юзает mssql-экспресс с ограничением на объем одной базы, это было бы полезно.

(12) Вы их еще не храите?
(8) Скорее всего в скульном бэкапе тоже будет все. Разве современные СУБД не позволяют делать отдельные файлы под конкретные таблицы?

(5) >> Ага, и что будет в dt?

В dt будет вся база. Выгрузка в dt это ведь не тупое копирование файлов СУБД. Это чтение из таблиц и запись этих данных в файл dt.

(3) >> в примере путь к табличным пространствам указывается как путь в файловой системе. [Наx] зачем мне часть таблиц из скуля переносить в какое-то файло, не понимаю.

А таблицы СУБД, по-твоему, не в файловой системе хранятся?
Это пути к месту хранения файлов СУБД.
Не знаю как в PostgreSQL, а в MS-SQL, это реализовано. И можно сделать и сейчас самому - разнести таблицы по разным файлам на разных носителях/хранилищах.
Проблема лишь в том, что за этим надо вручную следить и все сделанные настройки размещения исчезают после реструктуризации таблиц средствами платформы 1С.
1С-овцы сделали управление этим процессом на уровне платформы. Что очень удобно.

Например помимо примеров из статьи, можно будет в 1С:Документообороте не заморачиваться с хранением файлов документов в томах, указав место хранения файлов в базе данных. А уже в базе настроить размещение таблиц с файлами в каком-нибудь медленном, но большом хранилище.

(8) бекап средствами СУБД не зависит от того где настроено хранение физических таблиц. Так же как выгрузка dt.

Со всеми версиями СКЛ работает? Такое ощущение, что сделали нашлепку для СКЛ, чтобы программисты  1С не лазили своими прямыми руками в гущи СКЛ, а вся настройка была из клиента 1С. Удобно, поддерживаем.

Данные по времени нужно переносить в другое "табличное пространство".
Но у этих как всегда.
Заодно оптимизаторы запросов теперь припухнут.

(15) >> неплохо было бы, если бы сделали возможность хранить ИБ в нескольких базах СУБД.

А как реализовать синхронизацию данных в этих нескольких СУБД?
Кто и как гарантирует, что копии/бекапы нескольких баз, сделанные средствами СУБД будут синхронны и данные консистентны?
Например, документ пишется в БД1, а регистры в БД2. Делаем архив этих баз.
Разворачиваем (восстанавливаем) архивы в копию. Запускаем и получаем, что записи в регистрах в БД2 есть, а документа-регистратора в БД1 нет из-за того, что создание копий запустилось не одновременно.

(18) >> Со всеми версиями СКЛ работает?

Это интересный вопрос. В статье об этом ни слова. По всей видимости, со всеми (кроме файлового варианта 1С).

Эта фича нужна чисто для Фреша где PostgreSQL на Linux
И где с последними политическими веяниями начались проблемы с дисками

Тем временем:
"1С dev jobs: Java, JS, C++, Python, C#"
https://habr.com/ru/company/1c/blog/671454/

по идее нужно не тупо по метаданным, а по периодам.
Старые периоды на медленный диск

(26) В таком случае нужно сильно переделывать построение всех запросов к СУБД.

(27) мс скл из коробки умеет

вот интерсно что за пути - или это для файловой версии?

(30) Может кому то и подойдет (0), но большинству нужно именно (26).
А вот интересно движения и остатки по регистрам вместе или  раздельно можно?

(31) те чтобы не обрезание базы делать, а тупо историю на другие диски

(20) "Кто и как гарантирует, что копии/бекапы нескольких баз, сделанные средствами СУБД будут синхронны и данные консистентны?"
Хранение журнала регистрации вне СУБД вас почему-то не удивляет. Хотя в нём явные ссылки на объекты базы.
(32) Понятно, значит только для mssql подходит, и как средство обхода экспресс-ограничений не катит

(0)
1С развивается в крупном корпоративном сегменте.
Это очень хорошо. Очевидно, что такой опыт появился в результате крупных внедрений. Теперь лишь без косяков работало)

Очень надеюсь, что со временем 1С таки сможет выйти из своей песочницы СНГ и занять достойное место на мировой арене.

С точки же зрения нас, прикладников, данная фича бесполезна (но очень интересна).

(38) на мировой?

(37) выгода в цене хранения.
Частые запросы выполняются быстро.
Исторические запросы выполняются прозрачно

(13) ну тут смотря как всё организовано. У нас сто лет как секционирование в здоровых таблицах, и ничего не порушилось

А нафига?
Не такие уж и дорогие эти "быстрые" диски по сравнению со стоимостью разработки этого функционала

(39) регистры сведений с логами
а как туда писать не подтвержденные/упавшие транзакции?

(45) фоновым. Я например так лог действий тсд пишу

(44) Наверное в столь суровом энтерпрайзе такие объемы данных, что быстрые диски дороже стоимости разработки)

Это есть сейчас на уровне скл

Уже используем

(56) с какой стати?

БД попадает под:
Гражданский кодекс РФ от 18.12.2006 N 230-ФЗ - Часть 4 Статья 1280. Свободное воспроизведение программ для ЭВМ и баз данных. Декомпилирование программ для ЭВМ.


я с ней делаю чего хочу и ни одно лицензионное соглашение (даже с мелкософтом) не вправе мне это запретить...

Вероятно придумают новый вид монетизации идеи а ля "Лицензия: Сегментация данных КОРП".

По факту, в действительно оргомных базах данных важна сегментация не типу таблиц, а по периодам.
Например, массивную таблицу оборотного активно используемего в отчетах/документах регистра "СебестоимостьТоваров" мы кладем на быстрый диск, менее "популярную" таблицу на медленный и чё?

У крупных Корпов массивные базы итак на быстрых ссд интел/самсунг на нескольких картах 4-30 ТБ в рейдах.
Если это не так, то никакая сегментация вам не нужна - "не по сеньке шапка".

А вот что важно, так это сегментация по периодам. Допустим, документы и записи оборотных регистров этого и прошлого года на быстром сегменте, а позапрошлый год и далее на медленном. Тогда, если технология сегментов будет эффективной, то оперативный учет бизнеса здесь и сейчас мы получаем быстро, а аналические анализы прошлых лет можем и чуть помедленнее.

Короче, в том виде как заявленно - не взлетит, просто еще один доильный аппаарат с красивой презентацией.

(63) плевать чего написано в договоре/лицензии, это ничтожно если противоречит законам РФ

(64) только это тоже нужно доказать, что противоречит

Круто конечно, и они большие молодцы, да только расчёты себестоимости и взаиморасчётов при большом объёме данных и на рейде из SSD выполняется сутками.

(66) я тут не так давно УТ11 переводил на новый релиз, до этого расчет себестоимости занимал сутки, а то и двое суток. Сейчас себестоимость минут 5-10 рассчитывается)

(67) у меня начальник говорит что на 19-ой платформе перерасчёты в три раза ускорились,там какую то фичу запилили. Через месяцок опробуем платформу, а к НГ наконец то на 11.5 думаю сможем перейти. Но у нас документов многовато, возможно, ещё базу резать будем.

(68) решение систем ЛУ запилили. Но обычно это не самое тормозное место в расчете

(69) решение лу на платформе это 14

Или 18

(34) >> Хранение журнала регистрации вне СУБД вас почему-то не удивляет.

Нет не удивляет. Если бы было наоборот, я бы сильно удивился.
ЖР - это логи. Хранить логи в БД - идиотизм. Логи должны быть отдельно от БД.
Строить какую-то прикладную бизнес-логику на ЖР (ради чего он мог бы понадобится в БД) - крайне спорная и сомнительная идея.

>> Хотя в нём явные ссылки на объекты базы.

Да. И это логично. В том числе там ссылки на уже удалённые объекты базы данных. ЖР вовсе не обязан иметь консистентные данные. Например, восстанавливая из архива рабочую базу в какую-нибудь копию, никто не заморачивается с очисткой ЖР этой копии. Базу имеем свежую, а ЖР к ней от старой копии.
Сбой в базе не должен приводить к потере ЖР. И наоборот - проблемы с ЖР не должны влиять на базу.
ЖР - это не про данные вообще. Он для хранения истории действий с данными.

Если ты получаешь систему, где данные не синхронизированы между собой (условно документы в базе до 17:00:00, а регистры до 17:00:01), то польза от этой базы нулевая. Это неработающий мусор, в котором надо разбираться для исключения коллизий. А вот если потерялись какие-то записи ЖР, то на работоспособность базы и достоверность данных в ней это никак не влияет, и не мешает с ней работать.

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

*

(72) Странно а во времена 7-ки вполне себе хранились в разных базах (где база = dbf) и ничего

(74) В PostgreSQL тоже из коробки

Лучше бы сделали разделение таблиц на архивную и оперативную на уровне платформы.
Работаешь с текущими данными - вот тебе 1Гб. Нужен отчет за пять лет - идем в таблицы на 100500Гб.

(13) правда? Аналогия с индексами и снепшотом?

(0) не, ну а чё, если это есть - это хорошо! Смотришь, так постепенно и до Partition Table как у оракла дойдём...
Единственный момент что будет наверняка только для корп серверов...

Возможно ли сделать базу на арендованном сервере, а часть данных, например, на домашнем СУБД?

>>Повышение производительности отдельных операций (например, расчета себестоимости в 1С:ERP) за счет выноса индексов или части данных в отдельный сегмент на более быстрые диски
Имхо, лучше бы они логику самой себестоимости переделали...

(80) По-моему, дело там не в логике, а в реализации. Слишком много прослоек и уровней абстракции, жрущих вычислительные ресурсы без толку.

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

простым компаниям это нафиг не нужно... даже тем у кого базы по 200 гигов...

на сколько я понимаю это делается исключительно для фреша...

(80) Как сказал товарищь ниже, проблема в большом количестве абстракций, Например реализация проведения документа в ERP еще по одному регистру (механизмами ЕРП) увеличивает время проведение примерно на 3 секунды (замерял), если стандартным способом напрямую в модуле объекта писать классическим способом почти мгновенно. Нужно им большую часть функциональности БСП, да и многих других подходов спускать на более нижий уровень абстракции. Иначе тежелый энтерпрайз 1С не заместить.

(83) Когда-то кто-то слишком умный в фирме 1с сказал "обращаться через точку к реквизитам некомильфо, плохо влияет на производительность, потому что платформе приходится получать весь объект". Стали в типовых стараться получать реквизиты через запрос. Однако, это ещё хуже стало влиять на производительность, потому что при повторном получении того же или другого реквизита этого объекта раньше он брался из кэша, а теперь каждый раз происходит обращение к базе.
Зато отказаться от хранения монолитной конфигурации в виде блоба не хотят, это типа на производительность не влияет, ага..

(84) А потому что не надо каждый раз получать один и тот же реквизит запросом. Один раз получил структуру со значениями всех нужных реквизитов через ЗначенияРеквизитовОбъекта и работаешь с ними.

(85) У любого метода есть свои нюансы применения. Но когда эти нюансы заворачиваются в высокоуровневые абстракции - то те люди, которые используют эти абстракции, не в курсе нюансов. В результате получаем тупящий на элементарных вещах код..

А ведь было достаточно не получать данные ТЧ сразу при получении через точку

(0) Помойму шляпа какая-то. Прикрутили очередную свистоперделку

(83) давеча по кнопке Печать в ERP2.5.8 искал процедуру формирования табличного документа (печ.формы) :) прих.уел, когда в замере производительности посмотрел "стек вызовов"

(89) Если бы язык бстро отрабатывал проблем не было бы,  во всяких джавах потобных слоёв много, можно под капот заглянуть и посмотреть как то или иноное реализовано да еще с верху фейм ворк натянут. 1С язык же довольно тормознутый, добавить туда БСП + всякие универсальные механизмы в виде проведения или печати в результате получается один большой тормоз.

(90) Когда придумывали язык и среду исполнения 1с, ещё был лозунг "доступно и всерьез", вот для этого он был вполне уместен. А когда полезли в облака и корпорации с тысячами рабочих мест, возникла потребность в усложнении кода и в абстрактных уровнях. И вот этот усложненный под облака код стал очень тормозным даже для ларьков.

Глядишь, со временем и секционирование появится

Для размещентя данных в разных базах и управления ими Microsoft придумал координатор распределенных транзакций,и все транзакции в два этапа - сначала выполнение,потом фиксация.

(76) а разве за это не отвечает Механизм копий базы данных , которую 1с придумала 4 года назад?
https://its.1c.ru/db/metod8dev/content/5951/hdoc

(94) Думаешь, что теперь они снова придумали то же самое???

(95) И в мыслях даже небыло думать

(23) Так это - java - это на ЕДТ и перспективные разработки
c++ - платформа
javascript - платформа
Остальное - фреш.

(97) только с c# не понятно куда он

(98) ВК?

100