|
Имеет ли смысл париться по поводу количества записей в таблице? | ☑ | ||
---|---|---|---|---|
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)
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |