|
|
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
Уважаемые!!! Есть 200 тыс. товарных позиций + учет по партиям + 50 торговых точек. Меня мучает вопрос способна ли 1С8 оперативно все это хозяйство обрабатывать. Или организовывать кросс-базоводы (буферные базы, с натяжкой центральная свалка/хранилище к примеру на oracle или db2), чтоб вся эта затея пошустрей. Если бы 1С7.7 то вопроса бы не было (кросс-базовод необходим!!!). 1С8 – вроде бы пошустрей, запросы более «прямые» стали, да и клиентская разработка уже не так хромает (немного работал с ней, но опыт только на «маленьких» объемах данных). А на больших объемах - только кросс-базоводами заведал, а именно oracle, db2 …). Заранее спасибо за ваши комментарии… ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2007, 07:09 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
Зависит от оборота и от того чего вы вообще хотите то от системы :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2007, 08:41 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
Ну, я думаю, что логистический фронт всяко не через "бухгалтерскую интерпретацию" формироваться будет, естественно распределение и перераспределение будут не только по товарному отчету делаться. Главное необходимо как-то организовать «открытость» к данным, желательно быстрый доступ к операциям с начало времен, ну сами понимаете многое в анализе основано на выявления отклонений в процессе складских приблуд (продажа, перемещение, списание и т.д.), так что оптимизация основанная на «закрытие периодов» - смущает. Еще одна загагулина – обмен данными… за день может “приехать” 20 тыс. строк по одной торговой точке в месяц 600 тыс. (20*30), а в целом по компании – 600*50 = 30.000 тыс. (20*30*50), это сами понимайте не малое. Что-то у меня было лет так много назад (7 лет назад где-то), но даже oracle, с механизмом партицирование, тяжеловато было … Заранее спасибо за комментарии!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2007, 10:15 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
200 000 номенклатурных позиций и партионный учет по складам даже УПП легко переживает, определись с количеством строк в документах, на мой взгляд это ключевой параметр ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2007, 10:40 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
автор определись с количеством строк в документах, на мой взгляд это ключевой параметр Ну, я вроде бы объем данных обозначил автор ... Еще одна загагулина – обмен данными… за день может “приехать” 20 тыс. строк по одной торговой точке в месяц 600 тыс. (20*30), а в целом по компании – 600*50 = 30.000 тыс. (20*30*50) .... - 30.000.000 (как раз строчки документов) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2007, 05:42 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
Народ, ну добавьте еще комментарии!!! ЗАранее спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2007, 11:43 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
Ну да, конечно зависит от количества накладных и количества строк в накладных БП потянула в оооочень сильно переделанном виде (собственный минималистический регистр без партий, с измерением "товар" числового типа (экономия на размере поля)) правда накладные грузим за месяц пачками из другой системы, но всё равно мееедленно пробовал те же накладные грузить теми же пачками в типовую УПП - ну просто ооочень медленно. Порядка 10 сек одна накладная, за месяц загрузить просто нереально - нужно много суток с другой стороны для онлайнового ввода и ненадо так быстро... короче надежда есть )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2007, 11:52 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
Да, но, согласись оптимизация number/varchar2 - ну не очень эффектна. А "онлайн" в связи с объективными российскими обстоятельствами (провайдер просто оперирует – «…извините, но мы временно не работаем и пошли все на….!!!) будет больше является “узким” местом, чем положительным аспектом. Плюс к этому, так называемая стоимость владения всего огорода будет весьма и весьма (и не за весь комплекс автоматизации, а только за его техническую составляющую … ). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2007, 12:13 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
вполне потянет если проведение документов переложить на филиалы то-есть УРБД размер справочника у меня был и под 1 000 000 элементов - нормально, обмен нужно делать средствами платформы - она при обмене не занимаеться перепроведением а отдельно грузит регистры и регистраторы, стоит ее немного подправить для создания системя централизованного накопления, и исключить попадание информации из одной перефирии в другую (тоесть полная копия только в центре звезды, а в лучах только то что им необходимо) единственый затык это оперативное проведение не выйдет.... по скольку сливаться будет из нескольких баз то в центре не будет соблюдаться правило 1док в 1 сек ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2007, 14:01 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
грузинДа, но, согласись оптимизация number/varchar2 - ну не очень эффектна. чисто "на ощупь" - эффект есть не в разы, но десятки процентов. Точно не замерял говорят, дело в индексах - индексы по GUID плохо работают и размер индекса получается большим - много страничек при поиске пролистать надо - и двоичный поиск по случайным данным не эффективен Я бы сказал что это "оптимизация последней надежды", т.к. после этого уже нельзя к 1С предъявить претензии что она "как-то не так" работает с MS SQL теперь - точно так же как любая другая программа Ещё большие надежды появились в 8.1 на отключения расчёта актуальных итогов это и блокировки уменьшает и время записи правда увеличивает время выполнения отчётов, т.к. итоги рассчитываются не от текущей точки, а от начала месяца ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2007, 14:57 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
говорят, дело в индексах - индексы по GUID плохо работают 1С их хранит в бинарном виде ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2007, 16:43 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Ответ - не способна однозначно, у нас сейчас идет работа по оптимизации базы, в которой всего лишь 5 000 000 строк документов за больше чем полгода. Там конечно есть, что оптимизировать и база у нас написана полностью с нуля и похоже надо ее еще раз переписать, но 30 000 000 строк в месяц - НЕТ без вариантов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2007, 17:39 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
Imho потянет 1Совцы прекрасно понимаю проблемы больших внедрений - и готовят специалистов способных сопровождать такие системы, думаю Вам стоит пройти такой курс либо связаться с людьми которые его проходили. http://www.1c.ru/news/info.jsp?id=7135 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2007, 19:48 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
грузинЕсть 200 тыс. товарных позиций Чем Вы торгуете? Интуитивно я догадываюсь, что всем, начиная от скрепок и заканчивая Шатлами... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2007, 15:17 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
Юрец грузинЕсть 200 тыс. товарных позиций Чем Вы торгуете? Интуитивно я догадываюсь, что всем, начиная от скрепок и заканчивая Шатлами... Наивный. К примеру запчасти Камаза примерно столько позиций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2007, 15:33 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
200 тысяч?!? Дай ссылку на фирму торгующую запчастями КАМАЗ. А еще лучше на прайс :-) :-) :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2007, 15:59 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
Юрец200 тысяч?!? Дай ссылку на фирму торгующую запчастями КАМАЗ. А еще лучше на прайс :-) :-) :-) Ты не учитываешь что даже отдельный болт или гайка или шайба - это запчасть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2007, 16:17 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
Я тебе конкретно говорю, дай ссылку. Я больше 7000 наименований запчастей на КАМАЗ в прайсах не нахожу! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2007, 16:20 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
Там конечно есть, что оптимизировать и база у нас написана полностью с нуля Вот. К вопросу о самописках и демоверсиях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2007, 09:38 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
Отвлеклись. Ближе к теме, пожалуйста. Тема: 1С8 и большой объем данных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2007, 12:37 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
2 грузин Вот ответ на ваш вопрос gybsonЗависит от оборота и от того чего вы вообще хотите то от системы :) .. я вам его просто переведу с русского на русский, это значит - НЕТ ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 12:24 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
грузин за день может “приехать” 20 тыс. строк по одной торговой точке в месяц 600 тыс. (20*30), а в целом по компании – 600*50 = 30.000 тыс. (20*30*50), это сами понимайте не малое. Что-то у меня было лет так много назад (7 лет назад где-то), но даже oracle, с механизмом партицирование, тяжеловато было … Милион строчек накладных в день - не реально это при "обычных затратах на внедрение". В принципе, есть известный мне пример обработки примерно полумилиона строк в день, но это предел. Резервы оптимизации исчерпаны, конфигурация нестандартная, задача тоже, железо "лучшее из обычного" ... Если использовать серверное железо с шестизначными-семизначными ценами и соответсвующую инфраструктуру включая админов, программистов-оптимизаторов и т.п. можно выжать больше конечно, но вот нужно ли оно кому за такие деньги? Нужна ли кому 1С по цене Dinamix AX (а может и SAP R/3)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2007, 13:04 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
Не потянет однозначно. Хранить сможет, но провернуть не сможет. Все встанет колом на рассчетах итогов и проведении документов. В таких случаях надо что-то простенькое, но под путевый СКЛ-сервер искать или писать, а в 1С уже свернуто загонять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2007, 22:48 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
Давайте прикинем 1млн строчек. Реально сделать 100 строчек проводимых в секунду. Можно и больше но уже в разы...(правда зависит от метода учета если по среднему то все ОК) Считаем 1.000.000/100=10.000 10.000/60/60= 3 часа. Плюс неравномерность данных получения данных*3 = 9 часов. По моему все вытягивает нормально. olegov - вы знаете 1с? Или от балды пишите? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 11:10 |
|
||
|
1С8 и большой объем данных
|
|||
|---|---|---|---|
|
#18+
Программист 1сДавайте прикинем 1млн строчек. Реально сделать 100 строчек проводимых в секунду. Можно и больше но уже в разы...(правда зависит от метода учета если по среднему то все ОК) Считаем 1.000.000/100=10.000 10.000/60/60= 3 часа. Плюс неравномерность данных получения данных*3 = 9 часов. По моему все вытягивает нормально. olegov - вы знаете 1с? Или от балды пишите? А 100 строк в секунду - это разве реально? У меня что-то сильно меньше получается. Правда измерений много на регистрах (до 8), но метод средних кстати. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 11:18 |
|
||
|
|
start [/forum/topic.php?fid=28&msg=34830383&tid=1525289]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
169ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
2ms |
| others: | 12ms |
| total: | 283ms |
| 0 / 0 |
