Имя: Пароль:
1C
1С v8
Имеет ли смысл париться по поводу количества записей в таблице?
0 MrAvPika
 
14.05.18
09:52
Есть ли смысл разделять большое количество данных по таблицам?

Например разделить остатки магазинов по регионам? (Сеть очень большая поэтому записей тоже очень много) В МСК 20 млн
1 MrAvPika
 
14.05.18
09:52
В питере чуть меньше, в регионах больше
2 Cyberhawk
 
14.05.18
09:53
Эскалацию словишь - задумаешься. Один из примеров.
3 Cyberhawk
 
14.05.18
09:53
Распределенную сеть инфобаз не предлагать?
5 MrAvPika
 
14.05.18
09:57
(2) Можно пример?
6 MrAvPika
 
14.05.18
09:57
(2) Это не значит что для каждого города своя таблица
просто хотяб Москву и питер вынести
7 Serg_1960
 
14.05.18
09:59
(4) Попробуйте сформулировать свою мысль так, чтобы её можно было прочитать без мата.
9 MrAvPika
 
14.05.18
10:01
(8) Это только для веб сервиса. На уровне запроса указывается конкретный магазин, далее идет определение таблицы и запрос
10 aka MIK
 
14.05.18
10:04
20 млн - это не много )
11 aka MIK
 
14.05.18
10:05
Хотя это остатки, движений думаю поболе
12 arsik
 
гуру
14.05.18
10:05
Мне кажется субд практически пофигу сколько в таблице строк. Главное не больше максимального предела. Но тебе до него несколько десятков лет еще таблицу эту наполнять.  Скорость выборки практически не изменится. Главное правильные индексы.
13 Timon1405
 
14.05.18
10:06
план запроса или хотя бы сам запрос в студию
14 MrAvPika
 
14.05.18
10:06
Короче в целом вопрос такой:
Сильно ли падает производительность
20 млн записей
60
100
15 ptiz
 
14.05.18
10:06
(14) Смотря что ты с ними делаешь.
16 MrAvPika
 
14.05.18
10:07
(13)
Все очень просто
StoreId
GoodsId
Where
StoreId = x
17 MrAvPika
 
14.05.18
10:07
Просто запросы и запись с отбором по магазину
18 MrAvPika
 
14.05.18
10:07
индексировано по 2ум полям
19 arsik
 
гуру
14.05.18
10:08
Если есть индекс по StoreId, то разделение на скорость никак не повлияет.
20 MrAvPika
 
14.05.18
10:10
А запись с отбором по магазину
21 Cyberhawk
 
14.05.18
10:10
(17) Структуру регистра (картинкой) и запрос в студию
22 MrAvPika
 
14.05.18
10:11
(19)  было бы очень круто если был бы какой-то источник факта)
23 Cyberhawk
 
14.05.18
10:11
24 MrAvPika
 
14.05.18
10:13
(21)  картинку скинуть не могу, сейчас не за компом
Измереня
Store
Goods

Ресурсы
Quantity
Price

Реквизиты
StoreId
GoodsId

И просто плоский селект без соединений
25 arsik
 
гуру
14.05.18
10:15
(24) Store и StoreId - это как и для чего? не проще в указать условием Store?
26 ptiz
 
14.05.18
10:17
(24) Если при чтении и записи всегда накладывается отбор на измерение Store, то блокировок лишних не будет и делить смысла нет.
27 Serg_1960
 
14.05.18
10:23
(13) Поддерживаю. В смысле о важности плана запроса - ссылка (много буковок в статье, но ничего лишнего, всё по делу, доступно о сложном):

"Влияние оптимизатора запросов на производительность 1с"
http://www.gilev.ru/optimquery/
28 H A D G E H O G s
 
14.05.18
10:27
Я один задался вопросом - а сколько миллионов строк будет выбрано даже при отборе по одному магазину?
29 H A D G E H O G s
 
14.05.18
10:28
Магазинов же не миллионы , а максимум 1000
30 MrAvPika
 
14.05.18
10:28
(29) Москва это 10 тыс~. Регионы 5-6 тыс~
31 Cyberhawk
 
14.05.18
10:31
(24) "просто плоский селект без соединений" // Ты точно отвечаешь на мой вопрос-запрос?
32 H A D G E H O G s
 
14.05.18
10:32
Хрена себе. Технопоинт перешёл на 1с?
33 MrAvPika
 
14.05.18
10:33
(31)
Выбрать
*
Из Stocks как Stcs
Где
Stcs.Store = Store

Может я не правильно понимаю вопрос?
34 arsik
 
гуру
14.05.18
10:33
(32) Они давно на нем. Даже на кассах я помню был 1С.
35 MrAvPika
 
14.05.18
10:36
В общем если подытожить:

Если писать с отбором по магазину блокировок не будет - логично, скорость записи тоже не меняется (check)

Если поля отбора индексированы, то время запроса не увеличивается вне зависимости от размера таблицы (1 таблица, без соединений) (check)
36 MrAvPika
 
14.05.18
10:36
Все согласны?
37 Cyberhawk
 
14.05.18
10:37
(33) Ну раз в условиях запроса есть условие на первое (по порядку) измерение регистра, тогда не все так плохо. Нет смысла разделять таблицу (с точки зрения какой-то там производительности), если конечно ты не хочешь положить таблицу для Мск / Спб на быстрые диски, например.
https://its.1c.ru/db/v8std#content:-2145782995:hdoc
38 Cyberhawk
 
14.05.18
10:38
Но че-то раньше ты писал в (16), что условие не на измерение, а на реквизит регистра
39 Timon1405
 
14.05.18
10:39
разве в плане запроса (33) "выбрать все" не будет скана?
40 MrAvPika
 
14.05.18
10:39
(38) Они тоже индексированы
41 MrAvPika
 
14.05.18
10:40
(39) мне было лень писать все поля, звездочку я не использую, с телефона сложно писать
42 aka MIK
 
14.05.18
10:42
(35) ну время записи с индексами немного возрастает
(39) с чего бы
43 aka MIK
 
14.05.18
10:43
У меня в одной из табличек 1.2 млрд записей - все норм выбирается, если по индексу разумеется
44 Cyberhawk
 
14.05.18
10:44
(40) Так реквизит регистра не используется в таблице остатков. Ты из какой таблицы выбираешь записи?
45 MrAvPika
 
14.05.18
10:47
(44) http://shot.qip.ru/00V0at-1ZCpdk7i4/
Вот регистр
46 MrAvPika
 
14.05.18
10:48
пример регистра*
47 Cyberhawk
 
14.05.18
10:48
(45) Ну это ты в (24) написал, Я верю. Ты текст запроса не показал
48 Cyberhawk
 
14.05.18
10:49
Если запрос к основной таблице с условием по реквизиту, то почему не заменить его запросом к таблице остатков с условием по измерению? Накуя у тебя в реквизитах регистра реквизиты объектов БД, ссылки на которые сидят в измерениях?
49 MrAvPika
 
14.05.18
10:52
(48) Думал так будет лучше, чтоб не обращаться через точку, типа исключить левое соединение со справочником.
50 MrAvPika
 
14.05.18
10:53
(48) Я неправильно думаю?)
51 Cyberhawk
 
14.05.18
10:54
(49) Зачем левое соединение? Формируй список ссылок и условие на измерение В
52 Базис
 
naïve
14.05.18
11:04
(32) Но как, Холмс?
53 Serg_1960
 
14.05.18
11:04
(50) Не знаю как ты думаешь :) Но, если запрос к основной таблице по неиндексированному реквизиту - то Clustered Index Scan, иначе - Clustered Index Seek (+Nested Loops). Две большие разницы.

А если запрос к виртуальным таблицам остатков/оборотов - то там нет реквизитов (только измерения и ресурсы) и нет смысла "в дублировании" измерений в реквизитах.
54 MrAvPika
 
14.05.18
11:05
(53) Виртуальных таблиц не будет, плоский, индексированный по всем полям, регистр сведений
55 H A D G E H O G s
 
14.05.18
11:05
(53) Nested Loops при кластерном индексе - лишнее.
56 Cyberhawk
 
14.05.18
11:19
(54) Ну тогда учитывай, что реквизиты перед измерениями в индексе идут. В таблицах БД позырь, в каком порядке твои реквизиты идут в платформенных индексах
57 Serg_1960
 
14.05.18
11:20
(55) Эээ... может быть и не прав, но там ДВА индекса в запросе участвуют.
58 Serg_1960
 
14.05.18
11:30
(54) Остатки в регистре сведений? Эээ... без комментариев :)
59 Cyberhawk
 
14.05.18
11:32
(58) Так это пади у него срез регистра накопления регламентом формируется для выгрузки на сайт и помещается в этот отдельный регистр сведений, и сайт спокойно забирает
60 Serg_1960
 
14.05.18
11:34
(59) Ах, да, sorry, забыл. Замечание снимается :)
61 Serg_1960
 
14.05.18
11:41
+(56) "Индексы таблиц базы данных"
https://its.1c.ru/db/metod8dev#content:1590:hdoc:spr
62 xXeNoNx
 
14.05.18
12:27
(39) "Вы не понимаете о чем пишите"(с)
63 xXeNoNx
 
14.05.18
12:36
Подытожу: Разносить ничего не надо по таблицам(если не используется какой-то хитрый замысел), нужно попадать в индексы и использовать максимальные отборы, следить что бы не было эскалации (вроде 100к записей для ms sql)