Здравствуйте, _ABC_, Вы писали:

_AB>It depends...

_AB>В общем, не зная твоей БД и тому, каким нагрузкам она подвергается сказать что-то точно нельзя.
_AB>На каждый ответ — может повлиять, а может и не повлиять или влияния ты даже не заметишь.
Конкретно эта — 3ТБ 1С база со склонностью к росту. Т.е. много таблиц со схожей структурой.

_AB>Единственное — я бы всё-таки на каждую таблицу завел свою функцию и схему. Разделяемых таблиц не должно быть
_AB>много, поэтому это не очень сильно усложнит администрирование, а по опыту могу сказать, что то, что предполагается
_AB>изначально универсальным/одинаковым очень быстро приобретает индивидуальность.
Ну вообще-то их прилично (хотя опять-же, смотря что считать "много") и разбиты они будут по одной схеме (речь о логической схеме, а не объекте базы) на активные данные (за последние 2-3 месяца), которые читаются и пишутся, и архив за предыдущие года (только чтение). Архив будет сжат. С моей точки зрения это должно упростить и ускорить обслуживание базы (дефрагментацию индексов, бэкап и т.д.), и возможно позволит хранилке лучше разместить горячие данные на ssd-кэше.

S>>Есть 2 таблицы: документ и его строки, дата указана в документе, строки ссылаются на id документа. Есть ли возможность разделить обе таблицы по дате документа и стоит ли вообще смотреть в эту сторону (с учётом того что запрос строк происходит по id документа)?
_AB>Только если ввести дату еще и в строки.
_AB>А насчет того, имеет ли смысл смотреть в эту сторону... Ну ты ответ уже знаешь, да?
Ну, да... в принципе... идеально было бы ремап ключей сделать, заменив псевдослучайный guid на year-month-guid... мечты, мечты...

S>>Есть ли смысл разбивать таблицы по каким-либо другим критериям (запись по итогу будет идти во все разделы)?
_AB>Очевидно, что заявленная цель (уменьшить стоимость хранения именно архивных данных) достигнута не будет.
_AB>Хотя не так уж мало случаев, когда сжатие данных улучшало производительность системы.
А вот тут я в раздумьях — может ли повыситься скорость работы с таблицей, при уменьшении размера её индекса? т.е. если, к примеру, поделить таблицу по GUID PK на 256 частей, и, соответственно, уменьшить индексы в ~256 раз, ускорит ли это обновление индексов (а возможно и поиск по ним)?

_AB>А с какой целью ты хочешь уменьшить объем файла с оперативными данными?
Выше ответил.

Здравствуйте, _ABC_, Вы писали:

_AB>It depends...

_AB>В общем, не зная твоей БД и тому, каким нагрузкам она подвергается сказать что-то точно нельзя.
_AB>На каждый ответ — может повлиять, а может и не повлиять или влияния ты даже не заметишь.
Конкретно эта — 3ТБ 1С база со склонностью к росту. Т.е. много таблиц со схожей структурой.

_AB>Единственное — я бы всё-таки на каждую таблицу завел свою функцию и схему. Разделяемых таблиц не должно быть
_AB>много, поэтому это не очень сильно усложнит администрирование, а по опыту могу сказать, что то, что предполагается
_AB>изначально универсальным/одинаковым очень быстро приобретает индивидуальность.
Ну вообще-то их прилично (хотя опять-же, смотря что считать "много") и разбиты они будут по одной схеме (речь о логической схеме, а не объекте базы) на активные данные (за последние 2-3 месяца), которые читаются и пишутся, и архив за предыдущие года (только чтение). Архив будет сжат. С моей точки зрения это должно упростить и ускорить обслуживание базы (дефрагментацию индексов, бэкап и т.д.), и возможно позволит хранилке лучше разместить горячие данные на ssd-кэше.

S>>Есть 2 таблицы: документ и его строки, дата указана в документе, строки ссылаются на id документа. Есть ли возможность разделить обе таблицы по дате документа и стоит ли вообще смотреть в эту сторону (с учётом того что запрос строк происходит по id документа)?
_AB>Только если ввести дату еще и в строки.
_AB>А насчет того, имеет ли смысл смотреть в эту сторону... Ну ты ответ уже знаешь, да?
Ну, да... в принципе... идеально было бы ремап ключей сделать, заменив псевдослучайный guid на year-month-guid... мечты, мечты...

S>>Есть ли смысл разбивать таблицы по каким-либо другим критериям (запись по итогу будет идти во все разделы)?
_AB>Очевидно, что заявленная цель (уменьшить стоимость хранения именно архивных данных) достигнута не будет.
_AB>Хотя не так уж мало случаев, когда сжатие данных улучшало производительность системы.
А вот тут я в раздумьях — может ли повыситься скорость работы с таблицей, при уменьшении размера её индекса? т.е. если, к примеру, поделить таблицу по GUID PK на 256 частей, и, соответственно, уменьшить индексы в ~256 раз, ускорит ли это обновление индексов (а возможно и поиск по ним — первое поле ключа индекса — PK)?

_AB>А с какой целью ты хочешь уменьшить объем файла с оперативными данными?
Выше ответил.