Здравствуйте. Собственно реализую щас через регистр сведений одну задачу, и в приоритете там будет хранится более 100 милионов записей. Регитр сведений переодический переодичность в пределах дня.

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

(0)самалично видел таблицу с 20 млн записями
а по существу смоделируй, чё там сложного?

(2) боюсь, что смоделирую, для 10 млн, а по факту получится 100 млн.

(3) смоделируй миллиард.

главное проиндексируй правильно и порядок измерений выстави и составные типы не используй, должно работать. унас 5 млн, нормально работает выбирает 100 записей  с такой же скоростью что и 100 из регистра в котором 1000 записей.

количество строк в таблице - ограничено доступным размером хранилища

Типовой срез последних тупить не будет ли на таких количествах? Вероятно, что придется использовать свой срез с временными таблицами.

(7) свой всегда медленней чем встроенный

Свой я и буду использовать, вопрос становится в том ниче не загнется ли раньше времени :)

(9) все зависит от степени кривизны твоих рук.

(7) а почему типовой должен тупить и чем свой лучше?

нафига в срезе последних какая то временная таблица... она там будет использоваться максимум 1 раз, так чем подзапрос, как во встроенном механизме, плох?

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

(12) нечеким планом запроса и именно на таках объемах от 100КК станет очевидной ущербность использования вложенных запросов в виртуальных таблицах

А как же мой вопрос ?

(7) В 8.3 есть отельная таблица для среза последних

(16) представляю ))

Интереса ради: а что это такое, что требует 100 миЛЛионов записей? И нельзи ли их "разложить" по нескольким регистрам для удобства построения запросов?

Запустил тест. Уже ~2 млн. записей залилось. Регистр ведет себя нормально.

я в файловом режиме создавал 200 млн. записей в непериодическом регистре с одним ресурсом (измерений не было)

(18) списания денег, почему через 1С, эт отдельная история.
Еще вопрос мб не по теме, как записать 1 000 0000 из справочника в регистр сведений, делал при записи вылетает.

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

(21) а зачем там РС?

(20) Что то слабо верится... По превышению внутренней таблицы вылететь должно было....

(22) РАУЗ, например. Сложно-составное решение :) Регистр - один, а вы посмотрите на его "окружение"... А справочники, связанные с регистрами сведений? Или, точнее сказать, записи регистров на которые "можно ссылаться"? Красивое решение (имхо).

(24) Там же ограничение только по размеру таблицы (для файловой базы), а не количеству записей, вроде.
Если одна запись 10 байт - то 200 млн записей это всего лишь 2Гб. Так что вполне нормально, регистр будет работать

(25) при чем тут рауз? я так понял человеку советуют разделить регистр просто из за того что там много записей. так для проблемы много записей существуют индексы.

(21) а как еще данные по данному набору контрагента его данных записывать.

(26) С одним ресурсом не проверял. Было что то в районе пяти измерений, пары ресурсов. Файловая уперлась в 4 ГБ уже где то при 15 млн. записей.

т.е (23). ребят так как оптимально записать 1 000 *100 000 записать в регистр, так чтобы меньше проблем было )

Тест продолжается. В регисре уже ~5 млн записей. Регистр ведет себя нормально.

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

(27) Предпологаю что критичным для тс встанет вопрос не "количество", а - "объём". Не зная конкретики тс, предположил "разложение" регистра на несколько. Например: "основной" регистр - только измерения. Ведь никому не потребуются все 100 миллионов записей сразу. Наверняка ведь будут использоваться только отборы.

(32) Имеет смысл разделять, если разные части хранить на разных дисках

Кстати: вспомнил про РАУЗ потому, что решил глянуть на регистр "Учет затрат" в УПП. Всего-то жалкие пару миллионов записей в год :)

(32) сделал один оперативный, который хранит списания за день, другой архивный, он хранит историю списания .
(33) объем эт я смотрю в будущее, далеко.
ребят так, как записать, чтобы ниче не вылетело сразу 100 000 0 записей, делаю набор записей 1 штуки, и записываю, думаю надо не набором писать, а допустим менджером записи, так меньше памяти и времени уйдет правильно думаю?

(31) база файловая или Клиент -сервер и какая СУБД  и платформа сервера.

(20) без измерения не интересно, как же я потом буду фильтровать и тд и тп )

(37) КлиентСервер. SQL 2008R2 Ent, 1С:Предприятие 8.2 (8.2.15.301). Да, тест идет на УФ. РС В пределах секунды, Режим записи независимый. 7 измерений, 1 Ресурс, 1 Реквизит. Все строка, длина 100. Сейчас уже ~6 млн. Регистр ведет себя нормально. :)

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

(36) ммм... по поводу использования менеджера: посмотри 8 в v8: Кто как записи в регистрах редактирует?

(40) Тупо циклом. Через менеджерЗаписи. С нескольких хостов.

   Для Х=1 По КолДляДобавления Цикл
       МенЗап=РегистрыСведений.Тест.СоздатьМенеджерЗаписи();
       МенЗап.Период=ТекущаяДата();
       МенЗап.Измерение1="Измерение1: "+Х;
       МенЗап.Измерение2="Измерение2: "+Х;
       МенЗап.Измерение3="Измерение3: "+Х;
       МенЗап.Измерение4="Измерение4: "+Х;
       МенЗап.Записать();
   КонецЦикла;


Можно Через набор сделать

   НабЗаписей=РегистрыСведений.Тест.СоздатьНаборЗаписей();
   НабЗаписей.Прочитать();
   ТЗ=НабЗаписей.Выгрузить();
   Для Х=1 По КолДляДобавления Цикл
       НоваяСтрока=ТЗ.Добавить();
       НоваяСтрока.Период=ТекущаяДата();
       НоваяСтрока.Измерение1=СтрЗаменить(Х,Символы.НПП,"");
   КонецЦикла;
   НабЗаписей.Загрузить(ТЗ);
   НабЗаписей.Записать();

, но тут при большом объеме записей в оперативную память упирается. Но, работает, правда, в разы бысрее.

(42) у меня к сожаленюи сразу 1 000 000 записей не пихается ...

набор записей быстрее работает чем менджер? мб стоит пихать пачками по 10 000 записей допустим а? или по 1000 ?

(44) Грузовик работате быстрее, чем водитель? :)

работает

Набором писать разумеется быстрее, чем по 1 записи

придумай измерение како-нибудь, которое меняется каждые 10 тысяч записей, делай набор с отбором

Измерение А1 + 10000 различных измерений Б
Измерение А2 + 10000 различных измерений Б
Измерение А10000 + 10000 различных измерений Б
Итого 10кк

1 измерение, меняется с 1000 записями. но там еще нужно учитывать еще 2 ключевых, по которым в основном и идет запись. Грубо говоря иерархия такая, Контрагент, Договор, ИзмеренияГлавное,ИзмерениеПОбочное.
ИзмерениеГлавное каждые 1000 записей меняется. Зачем делать НаборЗаписей Прочитать?
Тупо создать набор записей и записывать каждые 1000 записей можно же?

(50) Да

(50) "Зачем делать НаборЗаписей Прочитать" Что бы все что до этого было в регистре не затереть.
ЗЫ: А еще можно отборы использовать....

(51) спасибо, что разрешил ) Имел виду эффективнее же будет ?

(50) "Тупо созданный" менеджер набора записей без Прочитать не позиционируется и по действию Записать ничего не сделает

(54) оО

кто-нибудь знает, что за поле _SimpleKey?

(54) да ну?

(54) Выполните пожалуйста код:

НабЗаписей=РегистрыСведений.ВашРегистрКоторыйСамыйВажный.СоздатьНаборЗаписей();
НабЗаписей.Записать();

(53) Я так понял, что это вопрос был.
Чем по 1 записи - конечно, в десятки раз

(54) а у меня пишет, странно, я думал прочитать, эт когда ты делаешь Отбор по полям еще и он читает записи по данному отбору ...

(58) В рабочей базе и без бэкапа, все равно ведь "ничего не сделает"

(61) :)
верное замечание

(58) я как-то пробовал, но эффекта не увидел. сейчас попробую еще разок.

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

Если основной отбор по всем измерениям, то прирост от записи набором будет, но незначительный

(0) записей то наверное можно хоть миллиард. но вот сколько оно записываться будет....

нет, даже если в записи 100 байт, то это 100 гигабайт получится только один регистр.

В регистре уже ~9 млн. записей. Размер mdf ~4.7 ГБ.

(62) попробовал. нашел в чем у меня была ошибка.
нужно делать с установкой свойства Записывать

НабЗаписей=РегистрыСведений.Тест.СоздатьНаборЗаписей();
НабЗаписей.Записывать = Истина;
...
НабЗаписей.Записать();

В давнем своем варианте я об этом свойстве забывал и эффекта не получал.

(66) ну 9млн - это получается 0,9 ГБ. А если миллиард?

(6) индексы еще кучей создаются

(68) Откуда 0.9 ГБ?

(69) к (66)

(68) 1000000000 * 100 /1024/1024/1024 = 93 Gb :)

(70) 100 байт * 9000000 = 900 000 000 = 900 мБ

(0) 10 млн. Регистр ведет себя нормально. Дальше тестить? :)

ЗЫ: В общем, милион записывается за ~2,34 часа.

(74) если порциями писать по 1000 записей, наверно быстрее запишется.

у меня 2 млрд было в скл

(75) Это через менеджер. Код в (42)

(74) заливай пока не рухнет сервер скуля

смотрите на ОРТ - РС_стратос, минимальная планка 100 000 000

+(78) если 1С и сервак 64-битные ваще няха, возмем миллиард!

(74) Неоптимальный код, имхо. Должно быть значительно быстрее. Вон, например, КЛАДР (около полтара лимона записей) перезаписывается минут за 10-15.

(79) у меня на 32 бита было больше 2 млрд

(81) Номинация самый длинный?

(0) простой вопрос. Можешь сказать нафига и что этот регистр делает? с точки зрения учета.
Может ну его нах вообще 1С использовать. Сделать mysql базу. а в 1С запросы юзай к внешнему источнику.

(80) ну и посчитай. полтора миллиона против ста.

(82) ага...

(0) Интересно стало, по факту, если записывать в день по 1000 строк в секунду в РС получится 86400000 строк. За год наберется 48816000000. Теперь подумаем на счет нагрузки - 1000 строк в секунду - не слишком ли много, а возможно ли вообще записать столько строк в 1 секунду? Или будет записываться 1000 строк за 5 секунд? Тогда получаем 200 записей в секунду, а это уже в 5 раз меньше - 9763200000.
Реальное применение в принципе есть, допустим в организации 1000 автомобилей и нужно записывать данные с GPS. Это где-то раз в 5 секунд будет приходить сообщение с координатами и нужно его записать в 1С. Опять же 200 записей в секунду.
Таким образом делаем вывод - моделирую на 10 млрд записей :)
Я думаю, что есть такие организации с 1000 автомобилей, которые следят за каждым транспортным средством в 1С-ке. Как минимум знаю одну такую, но там пока что 300 машин :)

(80) 1.5 лимона у меня через наборЗапсей тоже залетает на ура. А когда я туда пихнул что то в районе 15 млн, то сервер по памяти глубоко в своп ушел.

(87) пихай 10 раз по 1.5 млн? :)

в 1 секунду? Или ... за 5 секунд? Тогда ... это уже в 5 раз меньше
Логично!

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

(86) если в организации 1000 автомобилей и их отслеживают по GPS, ту представляется расточительным тратить ресурс сервака с 1С на такое. Гораздо эффективней решать такое где-то вне 1С-ки

(90) в постах он написал, что расчеты с контрагентами хотят видеть с историей допреквизитов

(91) писать отдельный софт? зачем? А если весь учет построен на данных GPS? Примерный пробег? И т.п.? Если события прибытия в точку нужно видеть в 1С? Если нужно отмечать заявки о прибытии машины в точку и т.д.?

(83) технолгические данные такие регисры могут хранить, например показания приборов технолгических сетей с периодом опроса минуты секунды. А теперь представь, что это обширная сеть газопроводов со 100500 точек сьема данных, которые выгребаться из "мест" скопления этих данных в корпоративной сеты. Думаешь почему 1С милисекунды ввела?

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

(90) MySQL? Поржал, спасибо :)

(92) чо серъезно? ну и жесть)))

(90) в отчетах?

(95) а чо ты ржешь? текДок он выгружают в него а там поболя информации. зато в 1С все крутится вертится быстро с прямыми запросами к внешней базе.

(97) да хоть где. кто мешает.

(0) а сколько документов в день делается в организации? :)

(0) опиши РС, который ты хочешь сделать, какие измерения, ресурсы? :)

Однозначно вне 1С. В 1С пиши агрегационние данные. Например реструктуризацию устанешь под 1С делать.

(101) Ты это... "будь мужиком"(с) - прочти всю ветку :)

См.(50)

(0) обратитесь к (102) спец в этом роде.

(103) прочитал :) Спасибо.
(13) как вариант ПВХ
(0) А расскажи все-таки полностью, что ты хочешь сделать и какую цель преследуешь. А-то что-то почитал, но так и не вник в цель. Может быть есть какие-то другие варианты решения твоей проблемы?:) Какие-то расчеты с контрагентами по доп-реквизитам, но в целом задача не ясна.

(0) сделай тупо ДБФ файлы) внешние. в них пихай. с них считывай запросами) будет летать )))

(106) я смотрю Вы спец по быстродействию dbf, mySQL :) Что еще?

(106) А! Я знаю, excel запросом читать ;)

Кажется ТС ушел в бсод :D со своими тестами :D

(100) а причем тута документы ?

Короче так это грубо говорят телефонный модуль, оказание услуг, с переодическим списаниями.
Телефонный модуль, скидки на разные направления через клиентов, поэтому так много строк я буду писать со справочника. Грубо говоря справочник индивидуальные скидки, которые несет информативную информацию, РС Индвидиуальные скидки, переодичный несет информацию для просчета на текущий день скидки.
Далее почему вопрос встал много строк, история списания денег, сами деньги списываются в билинге UTM -5, историю я храню для себя зная, что туда ушло, что не ушло, причины и тд.Почему я заморачиваюсь, т.к сисадмины любят начесать, половина моих вопросов мисты, эт вопросы к сисадминам, нежели к 1С. Т.к. на практике узнаю много нового о людях, которые типа не знают, потом вспоминают и приходится проверять всю информацию

Думаю, потом сделаю какую нить СУБД, или Mysql базу , куда буду сливать годовалую информацию раз в год, и выгружать туда архивные данные, чтобы не нагружать 1С. А потом тащить данные из архива.

Смотрю тему просматривает ЖивойИскопаемый удивите своим мнением и советами :)

(108) Опыт анализа больших данных с помощью excel уже есть:
v8: Помните я говорил про отчеты в 100000 строк.

А ТЕПЕРЬ ВНИМАНИЯ КОНФИГУРАЦИЯ СЕРВЕРА ГДЕ СТОИТ 1С И СУБД, КИДАЮ В СТУДИЮ
Intel(R) Core(TM)2Duo CPU E6550 2.33GHz, 4,00 ГБ ОЗУ.

Винт посмотреть не могу прав нет.

но точно уж не SSD =)

(115) 4Гб - умрет твой сервер от такой нагрузки, думается мне.
(114) есть, только тут не каких-то 100т строк :)
(112) только не mySQL, MS SQL или Oracle или что-нибудь другое.
(111) а задним числом можно что-нибудь делать? :)

Почему не mySQL - ну хотя бы вот: http://forum.searchengines.ru/archive/index.php/t-22534.html

Если планы выполнения запросов будут несложными - почему бы не MySQL?

MySql чем он плох, если будет две функции. Select Insert и пару полей отборов.
(118) тьфу тьфу, но уже телефонию, тарификацию за 3 месяца держу около 600к строк, пока все хорошо ...

(121) тебе повезло, я держал игровой сервер .. смотреть на MySQL больше не хочу ...

(122) держу в 1С на СУБД IBM DB-2.
я думаю MySQL просто держать архив данных и все.
а вот люди держут IPTV на MySQL эт плохо ?

(24) МБ, по давности лет не помню точную цифру. Может на порядок ошибся, завтра напишу прожку и проверю ))

(123) видимо это моя личная нелюбофь к mySQL :)

для увеличения скорости записи на порядок, надо чтобы 1с переписала принцип добавления строк в таблицы.
надо данные писать не по 1 строке insert, а по 50.
больше уже хуже получается..
экспериментировал в свое время.

Пробывал в файловом варианте записать 100 млн строк сразу и вылетела ошибка ..

Типа переполнена внутренняя таблица, а кто то говорил что все впорядке с этим?

Ошибка СУБД:
Превышен максимально допустимый размер внутреннего файла 'C:\Users\Coldboy\Documents\ЕТК Рабочая/1Cv8.1CD'
по причине:
Превышен максимально допустимый размер внутреннего файла 'C:\Users\Coldboy\Documents\ЕТК Рабочая/1Cv8.1CD'


Вот такая ошибка при записи 100 000 000 записей :)

(129) 4гб превышено? :)

(129) Теоретически, в файловом варианте, можно записать максимум 4 000 000 000 записей, если размер одной записи будет равен 1 байт :)

7.30 ГБ дошло и слетело )

база сначала была 7.2 ГБ :)

(131) чет круто округляешь и это имеет место на 32битных систем, вроде как :)

Пока что, записей 200кк, все хорошо, база выросла на СУБД на 15 гб вроде бы .

Записей уже 400кк на СУБД IBM DB-2 Express размер 70 ГБ. В одном регистре :)

(136) не быстро записываются ))) прошло аж 4 часа на 200кк записей :)

14к в секунду

(137),(138) не я же не автоматом поставил писать, я там забиваю нужные данные по своим отборам и тд :)) эт грубо говоря справочник актуальный скидок по направлениям звонков)) а так он записал 100кк за пару часов что ли) Бесплатная СУБД с 2 ГБ оперативы используемой и моим МЕГА СЕРВЕРОМ )

(139) рад за тебя, что все получается :)