приветствую!
есть задача хранения (фактически без обработки) довольно больший объемов информации...
до 100млрд. записей на горизонте 10лет.
"запись" - строка (до 50символов), дата, число
источник данных - датчики на производстве
никаких алгоритмов обработки не предусматривается... только запросы к этим данным из "управленческой" 1С (УТ)...
какую использовать архитектуру для такой задачи?
есть задача хранения (фактически без обработки) довольно больший объемов информации...
до 100млрд. записей на горизонте 10лет.
"запись" - строка (до 50символов), дата, число
источник данных - датчики на производстве
никаких алгоритмов обработки не предусматривается... только запросы к этим данным из "управленческой" 1С (УТ)...
какую использовать архитектуру для такой задачи?
По теме из базы знаний
- Приемы обработки больших данных в 1С
- Опыт успешного внедрения УТ 11 в небольшом подразделении большой компании
- Отказ от работы с временными файлами при работе с двоичными данными или Потоки как простая замена ADODB.Stream и временным файлам
- Управляемая консоль отчетов – новый функциональный инструмент для работы с запросами и СКД в управляемых формах
- Скальпель, зажим, … пластырь, валерьянка. Мы закончили..: инструменты работы бизнес-аналитика
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)Может их агрегировать?
Вообще видел подобное и на Постгри и на Оракл.
Можете в одной базе не хранить все периоды. Делать на каждый период свою базу и хранить эти копии 10 лет.
Смотря какая обработка требуется.
А то можете рассмотреть хранение и не в базе данных если нет задач получения моментальных выборок со сложными отборами или например в nosql базе можно хранить.
Вы в УТ какие данные от оборудование хотите получать? Там же они в каком то уже обработанном виде нужны?
Вообще видел подобное и на Постгри и на Оракл.
Можете в одной базе не хранить все периоды. Делать на каждый период свою базу и хранить эти копии 10 лет.
Смотря какая обработка требуется.
А то можете рассмотреть хранение и не в базе данных если нет задач получения моментальных выборок со сложными отборами или например в nosql базе можно хранить.
Вы в УТ какие данные от оборудование хотите получать? Там же они в каком то уже обработанном виде нужны?
Любую архитектуру, кроме 1С.
Для снятия сырых данных с датчиков и записи их в СУБД лучше всего использовать что-то как можно более примитивное, зато шустрое и высоконадежное. Обычно от поставщиков оборудования уже есть нужные предложения. А в 1С сырые данные нафиг не нужны.
В 1С можно будет затягивать агрегаты при необходимости или вообще тупо фигачить внешние запросы.
Для снятия сырых данных с датчиков и записи их в СУБД лучше всего использовать что-то как можно более примитивное, зато шустрое и высоконадежное. Обычно от поставщиков оборудования уже есть нужные предложения. А в 1С сырые данные нафиг не нужны.
В 1С можно будет затягивать агрегаты при необходимости или вообще тупо фигачить внешние запросы.
(12) Да любая "нормальная" СУБД должна вытянуть если говорить про запись и хранение. И не забывай еще про вопрос отказоустойчивости. Допустима потеря данных или нет. Нужен кластер, не нужен. Зеркалировать, не зеркалировать.
А в этом твоем "только запросы к этим данным из 1С" - вообще отряд дьяволов сидит. Писать - это пол-беды. Можно вообще в nul писать, если читать не нужно.
Ты же понимаешь, надеюсь, что "запросики" к такому объему данных - это не хухры-мухры?
Все очень сильно будет зависеть от профиля нагрузки, специфики запросов и требований к производительности.
Если типичные запросы будут покрывать данные за весь период, то скорее всего придется еще что-то сверху прикручивать.
Если данные заведомо не влезают в память, а результат нужен быстро - то чуда не произойдет. Нужны будут либо агрегаты в том или ином виде, либо в худшем случае - распределенные вычисления.
ЗЫ. Пожалуй, выше я погорячился, заявив что распределенные хранение и вычисления не нужны. Вполне может оказаться, что таки нужны. И тогда при худших раскладах SQL может оказаться не лучшим выбором.
А в этом твоем "только запросы к этим данным из 1С" - вообще отряд дьяволов сидит. Писать - это пол-беды. Можно вообще в nul писать, если читать не нужно.
Ты же понимаешь, надеюсь, что "запросики" к такому объему данных - это не хухры-мухры?
Все очень сильно будет зависеть от профиля нагрузки, специфики запросов и требований к производительности.
Если типичные запросы будут покрывать данные за весь период, то скорее всего придется еще что-то сверху прикручивать.
Если данные заведомо не влезают в память, а результат нужен быстро - то чуда не произойдет. Нужны будут либо агрегаты в том или ином виде, либо в худшем случае - распределенные вычисления.
ЗЫ. Пожалуй, выше я погорячился, заявив что распределенные хранение и вычисления не нужны. Вполне может оказаться, что таки нужны. И тогда при худших раскладах SQL может оказаться не лучшим выбором.
(15) риски потерь данных я не анализирую
запросы...
возможны два варианта:
Вар.1:
выгрузка данных в "управленческую" 1С... здесь данные будут браться за кранею смену, т.е. глубина минимальна, объем выборки соответствеено тоже небольшой, но скорость здесь нужна...
Вар.2:
"расследование" аварий, форс-мажоров различных... скорость в этом случае не имеет значения...
запросы (поиск данных) могут быть по всему периоду хранения
думаю оба варианта не поставят неразрешимых проблем...
запросы...
возможны два варианта:
Вар.1:
выгрузка данных в "управленческую" 1С... здесь данные будут браться за кранею смену, т.е. глубина минимальна, объем выборки соответствеено тоже небольшой, но скорость здесь нужна...
Вар.2:
"расследование" аварий, форс-мажоров различных... скорость в этом случае не имеет значения...
запросы (поиск данных) могут быть по всему периоду хранения
думаю оба варианта не поставят неразрешимых проблем...
(18)"Файлики" это не "уже совсем". Это вполне оправданный подход для решения определённых задач хранения больших объёмов данных.
Прогрессивное берите СУБД и делайте на СУБД. Можете взять PostgreSQL и сделать хранение в ней как писал уже выше встречал такое на Постгри и на Оракл. Можете разделить производственные линии по разным базам например.
Или логировать все данные в файлики, а те данные что нужны для анализа в 1С можно отдельно грузить в какую то СУБД.
Например снимаете данные по температуре с 1000 датчиков и тд. Но в 1С вам нужны только данные по выпуску ГП с датчиков показывающих выпуск и расходу материалов. Тогда данные с датчиков температуры можете писать в "файлики", а данные по выпуску ГП в СУБД и из неё получать запросами.
Не понимая какие данные вам нужны для анализа и в каком объёме, можно дать только общие советы.
Прогрессивное берите СУБД и делайте на СУБД. Можете взять PostgreSQL и сделать хранение в ней как писал уже выше встречал такое на Постгри и на Оракл. Можете разделить производственные линии по разным базам например.
Или логировать все данные в файлики, а те данные что нужны для анализа в 1С можно отдельно грузить в какую то СУБД.
Например снимаете данные по температуре с 1000 датчиков и тд. Но в 1С вам нужны только данные по выпуску ГП с датчиков показывающих выпуск и расходу материалов. Тогда данные с датчиков температуры можете писать в "файлики", а данные по выпуску ГП в СУБД и из неё получать запросами.
Не понимая какие данные вам нужны для анализа и в каком объёме, можно дать только общие советы.
(23) ничто не мешает потерять любые файлики (в т.ч. и файлы СУБД). Если писать файлы будет отдельный процесс от отдельного пользователя, которому даны права на этот каталог и больше никому, то потерять файлы можно будет только при выходе из строя файловой системы, но тут и субд не спасет. А вот бэкап этих файлов будет происходить куда быстрее бэкапа субд, ибо можно эвридай это делать, отбирая файлы по дате.
В действительности, файловый вариант решает множество проблем, которые создают прочие варианты, при этом все "проблемы", которые видятся с первого взгляда, решаются куда проще. СУБД нужна для хранения связанных таблиц, индексов, туевой хучи всего прочего. Для решения данной задачи этого всего не надо.
В действительности, файловый вариант решает множество проблем, которые создают прочие варианты, при этом все "проблемы", которые видятся с первого взгляда, решаются куда проще. СУБД нужна для хранения связанных таблиц, индексов, туевой хучи всего прочего. Для решения данной задачи этого всего не надо.
(24) а как например в варианте "файлов" контролировать целостность данных? положим через 5 лет таких файлов будет миллионы... как понять что за это время не потерялсь часть из них? или не вирусы их не "погрызли"? это ведь надо строить некие алгоритмы над полем этих файлов... по сути изобетать некий аналог процесса тестирования и исправления данных в 1С (если языеом 1С говорить...)
(25) а если я удалю часть строк из базы данных через DELETE table WHERE id LIKE XXX, то как я узнаю, что я удалил через дцать лет? Для этого архивирование есть - в архивах есть контрольная сумма, могут быть данные для восстановления и прочее. Прое потерять данные можно в любом хранилище - почитайте, сколько на форуме вопросов о том, как восстановить базу данных (хоть SQL, хоть файловую).
(23) СУБД - это тоже файловая система. И от человеческого фактора она тоже не страхует.
Просто если у тебя в самом деле будет писать один процесс в одну логическую таблицу, то использование SQL СУБД явно избыточно. Основные плюшки зачем она нужна - это конкурентный доступ с обеспечением строгих требований ACID и универсальная модель доступа к данным (SQL). В данном случае тебя это не держит. Зато файлики ты можешь писать хоть каждый час новые, складывая в папочки по дням/месяцам/годам. И бэкапить удобно и шардить легко можно и map/reduce наколеночный прикрутить элементарно при необходимости.
Только писать эту систему желательно не на 1С и не одинэснику :) Чтобы не было глупостей вроде "ааа че-то сбойнуло и не пишется, ааа время перевели и все сломалось, ааа 1С лицензию потеряла и не запустилась"
Просто если у тебя в самом деле будет писать один процесс в одну логическую таблицу, то использование SQL СУБД явно избыточно. Основные плюшки зачем она нужна - это конкурентный доступ с обеспечением строгих требований ACID и универсальная модель доступа к данным (SQL). В данном случае тебя это не держит. Зато файлики ты можешь писать хоть каждый час новые, складывая в папочки по дням/месяцам/годам. И бэкапить удобно и шардить легко можно и map/reduce наколеночный прикрутить элементарно при необходимости.
Только писать эту систему желательно не на 1С и не одинэснику :) Чтобы не было глупостей вроде "ааа че-то сбойнуло и не пишется, ааа время перевели и все сломалось, ааа 1С лицензию потеряла и не запустилась"
(27) да, действительно потоков на входе не много (десятки), каждый генерит десятки записей в секунду, можно на каждый поток создать "папку" и писать в нее файлы с разрезанием по времени (например производственные смены)... и действительно можно найти "правильного" спеца который сможет все это создать, прикрутить контроль целостности, бэкапы, контроль доступа....
1Сник напишет запросы к файлам...
НО! хранилище получится 100% "наколеночным"... потерялся спец, и придется долго разбираться что и зачем в нем построено...
а если тоже самое на SQL, все таки там будет все более-менее прозрачно....
ну и вопрос... как обосновать заказчику почему мы отказываемся от "общепринятых" решений в пользу некоего эксклюзива ... это конечно не имеет отношения к теме, но в конечном счете может оказаться решающим вопросом...
1Сник напишет запросы к файлам...
НО! хранилище получится 100% "наколеночным"... потерялся спец, и придется долго разбираться что и зачем в нем построено...
а если тоже самое на SQL, все таки там будет все более-менее прозрачно....
ну и вопрос... как обосновать заказчику почему мы отказываемся от "общепринятых" решений в пользу некоего эксклюзива ... это конечно не имеет отношения к теме, но в конечном счете может оказаться решающим вопросом...
(28) Чем скульная база прозрачнее файловой структуры, на которую без всяких студио смотришь и сразу смекаешь что к чему? И какая разница, какой спец потеряется - писания в файлы или писания в SQL? По твоему описанию, это из тех систем, которые пишутся один раз и работают десятилетиями. При этом не требуя никакого middleware и потребляя минимум ресурсов на забытых всеми серверах с космическим uptime.
Заказчик только спасибо должен сказать за то, что теперь ему не нужны еще и DBA для этой задачи. И вообще, нам теперь за тебя еще и продавать? :)
Заказчик только спасибо должен сказать за то, что теперь ему не нужны еще и DBA для этой задачи. И вообще, нам теперь за тебя еще и продавать? :)
(51) Вроде как наоборот. Центральная концепция - это распределенный полнотекстовый индекс. То, что его можно использовать в качестве своеобразной nosql БД - как бы побочный эффект. Авторитетно заявляю, как только что внимательно прочитавший википедию :)
Да и из того что я слышал краями ушей - вроде как его все-таки чаще используют "поверх" чего-то.
Да и из того что я слышал краями ушей - вроде как его все-таки чаще используют "поверх" чего-то.
Просто текстовый дописываемый файл, если только хранить. Прикрутить к нему индекс по дням, который заполнять раз в сутки после окончания формирования очередного файла. Если число - это уникальный идентификатор датчика, а строка - считанные данные, то лучше сразу писать столько файлов, сколько уникальных датчиков имеется, чтобы разделить данные и ускорить поиск в них.
Ну, я читал только обзоры, и то немножко. Из обзоров понятно, что такие СУБД обеспечивают очень быструю и надёжную запись в БД, особенно когда порции данных такие вот коротенькие. Ну и отсутствие структурированности данных в данном случае тоже хорошо - пиши что прилетело, и не парься.
(34)
ну почему же... есть например couchDB. Она вполне под задачи ТС подошла бы как мне кажется, только я с ней поверхностно знаком и не имею большого опыта эксплуатации, но по надёжности она как хранилище будет лучше чем SQL, потому что нет структуры данных и при частичной потере реляционная структура станет не работоспособной, в отличие от "ключ-значение".
Но это так сказать в теории :)
Так по скорости и надежности ТС и SQL устроит.
ну почему же... есть например couchDB. Она вполне под задачи ТС подошла бы как мне кажется, только я с ней поверхностно знаком и не имею большого опыта эксплуатации, но по надёжности она как хранилище будет лучше чем SQL, потому что нет структуры данных и при частичной потере реляционная структура станет не работоспособной, в отличие от "ключ-значение".
Но это так сказать в теории :)
(38) Очень много лукавости и умолчаний скрывается в этом утверждении, как по мне.
1) SQL не теряет работоспособность прям напрочь прям при любых бяках в базе
2) уверен, что коуч не останется работоспособной при ЛЮБЫХ бяках в базе, но вполне могу допустить, что она более "живуча"
3) в SQL есть эффективные средства восстановления данных, которые эффективны не в последнюю очередь именно потому, что данные имеют структуру
4) бяка в базе - это разовые форсмажоры, связанные с хадваре, которые так или иначе требуют немедленного вмешательства. Удовольствие иметь в процессе "полуживую" базу, а не остановленную - весьма сомнительное. Когда лучше одно, когда - другое.
5) очень часто стратегия "упасть" как можно раньше при наличии проблемы - выигрышная
1) SQL не теряет работоспособность прям напрочь прям при любых бяках в базе
2) уверен, что коуч не останется работоспособной при ЛЮБЫХ бяках в базе, но вполне могу допустить, что она более "живуча"
3) в SQL есть эффективные средства восстановления данных, которые эффективны не в последнюю очередь именно потому, что данные имеют структуру
4) бяка в базе - это разовые форсмажоры, связанные с хадваре, которые так или иначе требуют немедленного вмешательства. Удовольствие иметь в процессе "полуживую" базу, а не остановленную - весьма сомнительное. Когда лучше одно, когда - другое.
5) очень часто стратегия "упасть" как можно раньше при наличии проблемы - выигрышная
(39)
нет там никаких лукавостей и умолчаний....
Коуч разрабатывался на сколько помню как очень надёжное хранилище пар "ключ-значение". Так как база структуры не имеет то по сути при повреждении части записей на диске остальные записи остаются работоспособными чего нельзя сказать о таблицах.
Средства восстановления и тд это хорошо, но речь не про это.
Очень много лукавости и умолчаний скрывается в этом утверждении
нет там никаких лукавостей и умолчаний....
Коуч разрабатывался на сколько помню как очень надёжное хранилище пар "ключ-значение". Так как база структуры не имеет то по сути при повреждении части записей на диске остальные записи остаются работоспособными чего нельзя сказать о таблицах.
Средства восстановления и тд это хорошо, но речь не про это.
(40) Ок, ок. А то мы по второму кругу пошли.
Я всего лишь хотел сказать, что не всегда это хорошо. Если не подстраховаться комплексом дополнительных мер, то нет ничего хорошего в том, что ты продолжаешь писать в разваливающуюся базу. При этом пополнительные меры для обеспечения надежности и для SQL есть.
Я всего лишь хотел сказать, что не всегда это хорошо. Если не подстраховаться комплексом дополнительных мер, то нет ничего хорошего в том, что ты продолжаешь писать в разваливающуюся базу. При этом пополнительные меры для обеспечения надежности и для SQL есть.
поступила вводная: в БД должен быть механизи автоматической печати...
т.е. при поступлении внешей команды (сигнал от датчика), некий алгорим, должен делать выбору данных (небольшую), формировать печатную форму и отправлять на принтер... это все без участия человека...
я так понимаю вариант с файликами теперь отпадает...
т.е. при поступлении внешей команды (сигнал от датчика), некий алгорим, должен делать выбору данных (небольшую), формировать печатную форму и отправлять на принтер... это все без участия человека...
я так понимаю вариант с файликами теперь отпадает...
(54)
Нет не правильно понимаете.
Вам нужно как минимум абстрагировать функционал, от хранения. Хранится может и в СУБД и файликах. Вопрос в том какое приложение получает сигнал и вот оно уже читает откуда то данные и что то с ними делает.
я так понимаю вариант с файликами теперь отпадает...
Нет не правильно понимаете.
Вам нужно как минимум абстрагировать функционал, от хранения. Хранится может и в СУБД и файликах. Вопрос в том какое приложение получает сигнал и вот оно уже читает откуда то данные и что то с ними делает.
(56)ты уже решил, как хранить будешь?
Если скуль нормальный - то триггер, вызывающий что нужно. Или обработка ожидания, смотрящая в таблицу.
Если файлы - то внешняя программа с подпиской на появление в каталоге нужного файла, или опять же обработка ожидания с НайтиФайлы()
Если скуль нормальный - то триггер, вызывающий что нужно. Или обработка ожидания, смотрящая в таблицу.
Если файлы - то внешняя программа с подпиской на появление в каталоге нужного файла, или опять же обработка ожидания с НайтиФайлы()
согласен... пока нет уменя инфы по датчикам... все пока в пролоскости разговоров... пока есть желание хотя бы общую концепцию понять... как в принципе "правильно" решать такие задачи... чуствую для 1С здесь места нет...
(60) С очень большой долей вероятности 1С не подойдет для снятия информации с датчиков. То есть в любом случае будет другая программа, которая это делает и куда-то пишет.То есть можешь вообще сильно не зацикливаться на деталях. Так как реализовывать их будешь не ты :)
А когда найдется спец на эту задачу, то он как-нибудь и без консультаций одинэсников обойдется. Сейчас нужно сосредоточиться на полной, подробной и понятной постановке задачи. Потому что с этим, судя по всему, большие проблемы.
А когда найдется спец на эту задачу, то он как-нибудь и без консультаций одинэсников обойдется. Сейчас нужно сосредоточиться на полной, подробной и понятной постановке задачи. Потому что с этим, судя по всему, большие проблемы.
(63)Нужно в первую очередь исходить из интерфейсов оборудования, у меня как то была задача, у оборудования был Net интерфейс и описание как связаться с этим оборудованием, я накидал програмку на c++ и поставил ее в планировщик на сервере, опрашивала все железки и считывала нужную информацию, весь этот хлам писался в dbf файлы, на каждый день по 1 файлу.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот