8.х Хранение и обработка больших объемом данных

Тема в разделе "Общие вопросы "1С:Предприятие 8"", создана пользователем LesPaul, 17 ноя 2007.

  1. TopicStarter Overlay
    LesPaul
    Offline

    LesPaul

    Регистрация:
    17 ноя 2007
    Сообщения:
    10
    Симпатии:
    0
    Баллы:
    1
    Есть БД, в которую будут забивать по 200.000 - 250.000 записей в день.
    Итого: за 3 месяца будет 22.000.000 записей в регистрах.

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

    Вопрос касается только платформы 8.0.
    Так же вопрос: предельные ограничения на записи в таблицах, при которых база начинает существенно "тормозить"? Есть ли рекомендации по вычислению данного параметра (кол-во пользователей, тип серверов, размер БД), как можно вычислять?
  2. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Записи - это что? Документы, элементы справочников или записи в регистр?
    Если в документах допускается дублирование записей (товаров, например) - обязательно сворачивать при записи в регистр, к примеру, можно... Регистр чего будет - бухии, РС, РР или РН? Тоже влияет...
    Короче - всё зависит от конкретной задачи - подробней условия...

    ЗЫ. По поводу серверов - вот пример тут есть.
    ЗЗЫ. Однозначно не файловый вариант :)
  3. TopicStarter Overlay
    LesPaul
    Offline

    LesPaul

    Регистрация:
    17 ноя 2007
    Сообщения:
    10
    Симпатии:
    0
    Баллы:
    1
    Будет порядка 250 тысяч проводок по регистрам, конечно же....
    Движение инвентарных единиц в рамках всей страны
  4. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    В теории: взлетит - но на практики: искать грамотного спеца по настройке серверов.
    Да и от конфы зависит - на типовой - не взлетит - сдохнете на блокировках :)

    ЗЫ. Итог: маловато данных для анализа... Взлетит, но медленно-медленно :)
    ЗЗЫ. Да и задачу хранения всего в одной базе... Если хотите гарантированного геморроя - покупайте SAP - проблем с количеством пользователей и записей не будет - но бабла отвалите... Причём самосвалом :)
  5. TopicStarter Overlay
    LesPaul
    Offline

    LesPaul

    Регистрация:
    17 ноя 2007
    Сообщения:
    10
    Симпатии:
    0
    Баллы:
    1
    Вообщем, итоги:

    Данные в таком количестве в !!!одной!!! базе под MS SQL Server хранить можно, но придется создавать дополнительные регистры по периодам (в этом месяце один, в следующем другой и.т.д.), которые будут одинаковые
    +писать обработку закрытия периода, которая будет данные из "текущего" регистар переводить в "архивные"
    +обработку которая будет собирать эти данные из всех регистров в единый набор данных для вывода в отчет
    +обработку сторнирования проводок

    Вообщем, грязной работы будет немеряно...

    Кто-таки имеет что-то сказать против?

    Решение под SAP или ORACLE обойдется гораздо дороже, но!!!
    если бы база строилась под MS SQL, а не под 1С, то вероятность приведенного выше алгоритма могла бы быть эффективнее из-за использования другой среды разработки (напр. C# или Borland)в связи с тем что 1С обращается к MS SQL через внутренние мехнанизмы, которые недоступны разработчикам под 1С, а "полноценный язык программирования" обращается напрямую к СУБД и есть возможности тончайшей настройки
  6. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Естессно... Толкьол вот создавать разные регистры под периоды... Это весьма странно.. Проще тогда обертку для обращения к произвольной БД написать - будь то DBF или ORACLE...

    Не просто дороже - а офигенно намного дороже. А это две большие разницы (с) Одесские разговоры.
    Опять-таки - никто не запрещает написать обертку для обращения напрямую. Но тогда остается только интерфейс от 1С :)

    ЗЫ. Может задачу можно решить иначе? Архивирование периодов или что-нить в этом духе? Что за записи такие? Единственный вариант, который приходит в голову (что бы имело смысл хранить данные больше 3 месяцев такого объема) - это страхование, всё остальное - имеет путь решения.
  7. TopicStarter Overlay
    LesPaul
    Offline

    LesPaul

    Регистрация:
    17 ноя 2007
    Сообщения:
    10
    Симпатии:
    0
    Баллы:
    1
    Хранение движения инвентарных единиц по организации за период с момента покупки до момента утилизации отработанных.
    Кстати, в Рарусе сказали то что надо создаваь отдельные реигстры.
    Писать сою БД - это и есть аналог "архивных регистров", только в более сложном виде, т.к. вряд ли я смогу написать ее чтоб она работала быстрее 1С + MS SQL
    Так что, писать совю собственную БД на ORACLE - легче его купить.
    P.S. В организации очень строго соблюдается лицензионная политика в области покупки ПО.

    Мнения?
  8. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Хе-хе.. Почитай, как люди относятся к разработкам Раруса в соседней ветке :)

    Фигачить доп.регистры - это с ума сойти можно...
    А сколько троллей-то будет? База распределённая или в одном месте вся?

    Конфу-то свою писать надо будет (если только движения хранить). опять-таки: только движения или ещё что-то? Задачу полностью-то раскройте... Если только движения хранить-то - нафига 1С вообще?
  9. TopicStarter Overlay
    LesPaul
    Offline

    LesPaul

    Регистрация:
    17 ноя 2007
    Сообщения:
    10
    Симпатии:
    0
    Баллы:
    1
    Какая разница?
    Будет огромная база по учету ОС и МБП организации. Вопрос стоит в том, чтобы понять сможет ли 1С хранить эти данные и не рухнет ли.
  10. рамиль
    Offline

    рамиль Опытный в 1С

    Регистрация:
    12 мар 2006
    Сообщения:
    595
    Симпатии:
    0
    Баллы:
    26
    Позвоните в 1С или направьте им запрос.

Поделиться этой страницей