1С 8.2 хранение большого количества записей - Справочник vs Регистр сведений #706994

Вопрос, наверное, о максимальном количестве записей в справочнике. Где хранить, например, несколько миллионов записей об запчастях? Задача: хранение большого количества пар "Наименование товара" - "ID товара". Либо, при наличии нескольких источников, хранение записей "Наименование товара" - "URL источника" - "ID товара в источнике". Точной формулировки задания пока нет. Цель - составление товарного каталога автозапчастей. Источники - общедоступные каталоги в сети. Конфигурация: разработка "с нуля", специально оптимизированная для хранения большого количества записей. ПО: SQL Server 2008 R2 SP1

Вопрос, наверное, о максимальном количестве записей в справочнике. Где хранить, например, несколько миллионов записей об запчастях? Задача: хранение большого количества пар "Наименование товара" - "ID товара". Либо, при наличии нескольких источников, хранение записей "Наименование товара" - "URL источника" - "ID товара в источнике". Точной формулировки задания пока нет. Цель - составление товарного каталога автозапчастей. Источники - общедоступные каталоги в сети. Конфигурация: разработка "с нуля", специально оптимизированная для хранения большого количества записей. ПО: SQL Server 2008 R2 SP1

Ну ежели у тебя нетленко и УЖЕ "специально оптимизированная для хранения большого количества записей", тогда что ты тут делаешь? Хвастаешься?

Хранить - пофигу. А вот обращаться и работать с ним...

а мощности связей какие нужны? если многие ко многим - три таблицы - 2 спр + 1 рс.

обязательно эту дрянь в 1с тащить? пусть снаружи в sql валяется...

Не парься. Справочник для сабжа однозначно удобней, а РС не настолько экономней, чтобы ради этого чем-то жертвовать.

слово УЖЕ вы написали >обязательно эту дрянь в 1с тащить? Согласен с тем, что тащить результаты парсинга в рабочую базу в номенклатуру не нужно. Поэтому я подумываю об отдельной базе 1С, специально оптимизированной для хранения большого количества записей. то есть справочник, где 5 миллионов записей, может существовать?

>Поэтому я подумываю об отдельной базе 1С зачем она должна быть базой 1с?

В базе 1С хранится только то, что было заказано. Подбор по марке, модели, году, вину - в отдельных актуальных обновляемых БД. Они разные, с разной защитой, за разные деньги. Обновлять свою БД ты же не будешь? Значит, она будет И большой, И неактуальной в части подбора.

На практике не встречал. Про пару миллионов слышал. Явных ограничений на количество элементов не существует. Как и каких-то специфичных для справочника механизмов, генерирующих тормоза пропорционально количеству элементов. В конце концов, это элементарно проверяется на практике.

это точно должна быть конфигурация 1С, так как придется решать много типичных для 1С задач - обмен данными и т.п. Но то, что сами данные - вот эти здоровые таблицы с товарами -должны храниться именно в 1С я не утверждаю. Возможно, таблица товаров может храниться непосредственно в SQL. Но тогда вопрос - а это точно лучше, чем хранить данные средствами 1С?

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

"На практике не встречал. Про пару миллионов слышал." автозапчасти иномарок влегкую дают 15-40 млн. Промышленные системы Европы (САП так нелюбимый одноэсниками) тянет и обрабатыввает это влегкую (2-5 сек в базе сайта с запросом к основной удаленной базе данных). 1С - шуршит до 15 минут, а то и вовсе отлуп дает, не могу, дескать, обработать столько всего...

да лана че такого, из рабочей базы

у РС индексирование сразу на измерения а у справочника... а индексы надо еще обновлять при записи...а оно надо ?

Извините, я должен отъехать. Тему не бросаю, вечером вернусь.

"генерирующих тормоза пропорционально количеству элементов." динсписки, нет? Не спецтормозной механизм при отображении?

В плане специфичных алгоритмов подбора и поиска - непосредственно в SQL гибче. Можно настроить нужные индексы и реализовать оптимальные по производительности алгоритмы. Если логика использования больших классификаторов прозрачна и ограничена, то в 1С их держать смысла нет.

"Но тогда вопрос - а это точно лучше, чем хранить данные средствами 1С?" потому что 1С не предназначена хранить и обрабатывать гигантские объемы сообразно приведенным уровням. Как пособие по учету для ларьков - самое оно.

1) динсписки сами по-себе тормозят в зависимости от размера таблицы? Чорд. Я я-то думал их придумывали для прямо противоположного. Не, если конечно нафигачить в запрос-источник кучу соединений по неиндексированным полям, можно многого достичь. 2) не факт, что они нужны

"то в 1С их держать смысла нет." в 1С с ними просто невозможно работать нормально (при таких объемах), т.к. реальных механизмов оптимизаций поиска в 1С нет. Так, декларации о "индексации"...

"динсписки сами по-себе тормозят в зависимости от размера таблицы? " то, что там список постоянно "запросит" - это как-бы за рамками?

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

И чо? Он по-разному запросит в зависимости от размера таблицы? Или запросит неоптимально, ежели разработчик не "помог", конечно?

"Ох уж эти сказочки, ох уж эти сказочники" (с)

Просто если уже есть мысли о выносе классификатора в отдельную базу 1С, то обойтись вообще без 1С - гемора уже не добавит. А гибкости и производительности - добавит.

не гони на 12 млн не сделаешь ты реструктуризацию, недельку покурить надо после запуска

это да... реструкторизация на таких базах - просто песТня... то что скуль делает за минуты 1с буробит сутками

Дык у 1С тупая схема схема реструктуризации. Он же полностью копию таблицы готовит и лопатит. Ессно, что самому можно на порядки оптимальнее реализовать для прозрачных случаев.

Длительность реструктуризации помимо количества записей зависит от мощности сервера, величины одной записи и ряда других факторов. в моем случае 12 часов хватает.

Ага и 12 часов никто не работает в базе

РЕструктуризацию огромных таблиц можно и нужно делать прямыми руками, а не полагаться на рукопопие пейсателей платформы.

+ и регламентные задания не выполняются

нарушение лиц соглашения?

Восстановление здравого смысла

а как приятно было получить граблями по хребту - нехватка памяти после пары дней ожидания

гы, +100

"специально оптимизированная для хранения большого количества записей. " - SP, индексы, insert`ы, update`ы?

да не, просто кроме этого справочника ниче больше нет =)

:). Если структура разработана - в принципе, хранить все равно где, обращаться для скорости лучше через SP. Индексы и на табличках 1с можно достроить ручками.

А вчем проблема? Далеко не все организации работают в режиме 7x24. У нас остановить систему на выходные (если это происходит не каждые выходные, а досточно редко) проблемы особой нет.

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

Только внешняя база. Без вариантов. Иначе намучаетесь с бэкапами и реструктуризацией. Прикиньте, сколько будет идти выгрузка в dt и ремонт базы.

Я работал с таблицей в 40 млн записей, держал ее в отдельной БД.

у вас все запросы на количество? Тогда поздравляю, будет все летать.

несколько миллионов это немного

справочник нужен ТОЛЬКО тогда когда нужна ССЫЛКА

Не знали наши мамы Не знали наши папы, Что дети не простые У них в семье растут.

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

я думаю из внешнего справочника переползет в основную базу учета заявок/покупок/продаж 1%-10%

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

тогда внешняя СКЛ-база и подходы уже описали выше бывалые коллеги.

коллеги, не дайте умереть в темноте и невежестве.. чего-то меня не штырит/штырит когда вижу типа запись: > у РС индексирование сразу на измерения а у справочника... а индексы надо еще обновлять при записи... // это как "индексирование сразу  на измерения" - типа из ниоткуда индекс по ищмерениям обновился при записи? а у справочника что - как-то иначе?

Упертый автор, ему отдельная нужна, для хранения большого кол-ва... база... на 1С :)

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

Вообще апдейт регистра сведений ср-вами 1С это полный звиздец... при наличии нормальных, простейших и быстрых инструментов SQL

"это как "индексирование сразу  на измерения"" это всего лишь значит, что у РС ключ создается и индексируется по измерениям, а у Справочника - по жестко заданным стандартным полям.

нет, я тебе показываю сколько записей в РС. Это рабочая база, в ней работает около 700 пользователей,я думаю ты знаешь как используется регистр Версии объектов и какие запросы к нему идут.

точнее не пользователей, а активных подключений

Хм Шибанов Алексей

Пусть делает внешний коннект к, допустим, MongoDB. Если хочет поэкспериментировать. Либо просто табличку сделает в MsSql-e. Какая-то расплывчатая тема.

а какая разница для записи?

Неа)

В плане производительности наверное разницы между справочником и регистром сведений нет. Дело в другом, если тебе ссылки на элементы нужны то однозначно - справочник, а так РС лучше.

почему РС лучше?

нормальная тема) + присоединяюсь к вопросу. тоже слышал об этом, но, наконец, хотелось бы узнать - а почему же РС лучше?

можно поиграть измерениями (индексами), добиваясь большей селективности

необъектная модель записи РС несколько быстрее - нет никаких проверок ссылочной целостности например при штатном удалении позиции, нельзя задвоить данные по измерениям (в справочнике - элементарно, проверки прописывать самому) и прочие приятные мелочи... но нет ссылки, хотя в принципе никто не мешает прикрутить справочник на используемые элементы и ссылку на него в ресурс кинуть

+1

Для большого количества данных есть еще один важный момент, о котором не часто упоминается. Если в справочнике есть табличная часть, то количество строк в ней не может быть более 100000 В базе, где будет много данных и в ТЧ будут так же что-то храниться не стоит об этом забывать.

Еще у меня есть отдельный вопрос: если все-таки хранить информацию в Справочнике и позиций 5млн. (цифра взята от потолка), то не будет ли лучше создать 10 справочников (с одинаковой структурой) и хранить в каждом по 500.000 элементов? Вопрос именно о производительности (от логики такого решения временно абстрагируемся).

в MSSQL есть настоящий полнотекстовый поиск, а не такой бесполезный как в 1с. Хотя бы ради полнотекстовых индексов надо хранить огромные базы на MSSQL :)

правила нормализации баз данных запрещают делать такую хрень "10 справочников (с одинаковой структурой)"

Жизнь не загонишь в правила. Пример: каталог Яндекс-Маркет. Для разных категорий товаров структура товаров отличается. Готов поспорить, что не в одной таблице Яндекс хранить сотовый телефоны и детские игрушки.

смотря как она описывается. может это тупо кусок xml

, Это как вопрос: А с чем в лес за грибами лучше ходить, с чемоданом или с сундуком. Ответ - это смотря за какими грибами...

Можно и в справочнике . Почему нет. Индексируйте поля поиска .

+  убедитесь штаа оптимизатор  юзает именно их .

Вопрос  опять политический . А на выходе все сводитяс к обычной таблице.

Я бы задал вопрос с другого конца..... когда понадобится  запись в справочник то ..... наборов у него нет.

И когда  понадорбится лить 5 000 000 на вставку ....

Код, да наименование - индексируются по-умолчанию в справочнике.

А  другие поля  разве нельзя  индексировать ?

Если память не изменияет   индекс по полю  - на выходе имеем индекс ( ссылка-код-нименование-нашеполе) .  Ну в любом случае  на план Вам придется посмотреть.

наше поле первое в индексе, а код или наименование добавляются, только если с доп. упорядочиванием.

Ну и собственно  "о максимальном количестве записей в справочнике. "  это в  мануале на ограничение объема данных SQL Server 2008 R2 SP1

Возможно . Спорить не буду .  Привел как пример.

Посыл ишо в том ... что несмотря на то что ... справочник ли это или регистр сведений может приключится иакая штука  когда и индексы расставлены и в условиях поля используются верно ....... а  план  строит scan и все тут .

И .... что мало вероятно  придется ваять свой индекс  и принудительно его использовать  и прибегать к ADO.

Смотря что будут запросом выбирать - если всё подряд, то зачем тогда вообще индексы нужны.

Очень советую сразу определить возможную-среднюю и максимальную длину наименования. Иначе в случае справочника потом могут быть проблемы ну или вместо наименования использовать реквизит. Еще если действительно миллионы и даже 10-ки миллионов записей то лучше вынести этот полный справочник во внешнюю БД например тот же Oracle весьма шустр. А в конфигурации справочник номенклатуры использовать только для заполнения в документах. Это можно через обработки сделать к примеру при выборе наименования открывается спец форма в которой идет поиск по внешней БД, при выборе ищется уже созданный элемент справочника номенклатуры (для ускорения можно во внешней БД хранить гуид 1с-го справочника) если не найден то создается по выбранным данным. Это самый оптимальный по быстродействию вариант.

в 5 000 000 таблице  уж должны будут ... Да если и не будут отбор и так стоит по условию ограничения вывода на экран. Дейстивтельно пока на экран вывод 5 лямов - это долго :)

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

Хотя, прямое сканирование 5 млн записей - это получается где-то 5 секунд, если не требуется установка блокировок и прочей многосеансовой фигни.

Простите темного. а что - у РС набор измерений не жестко задан?

А, я про то, что это с диска прочитать нужно забыл - 5 Гб - в 23-битах у нас полностью в память не поднимется.

Нет, как раз он задан и по нему строится основной индекс. Могут быть ещё и дополнительные, по дочерним измерениям и т.п. У справочника же основной индекс по идентификатору. Вопрос - какой индекс будет работать быстрее - открыт. Чай GUID - это 16 байт, а если строка, то 32 символа. Если же измерения числа, то можно сделать работу быстрее, чем справочник.

Вижу отличия такие Справочник: Минусы - Есть поле Ссылка. Т.е. размер +16 байт на каждую запись - Индексы по коду и наименованию некластерные на кластерном индексе т.е. размер индексов соответствующий и появляется затратный Key Lookup при поиске - Появляются фактически неиспользуемые поля ПометкаУдаления, Версия(8 байт) Регистр сведений: Плюсы - Составной кластерный индекс начинающийся с первого измерения т.е. быстрый Clustered seek по данному измерению