Июн 17
Дорогие коллеги,
предлагаю обсудить кто чем пользуется для хранения и использования скважинной информации и выяснить какое из имеющегося на рынке ПО наиболее подходит для работы с: каротажными данными всех типов (в том числе имиджеров), данными газового каротажа, данными керна (стандартные и специальные исследования, фотографии разных типов и пр.), данными шлама (интервалы, описание, измененные параметры и пр.), собранной в процессе бурения геологической и геотехнической информацией, информацией об интервалах пластов, данными испытаний и измеренных давлений и разумеется данными интерпретации и использованных при этом параметрах.
С уважением.
Опубликовано
29 Июн 2017
Активность
23
ответа
3699
просмотров
12
участников
4
Рейтинг
Контекст
PetroExpert x2
также очень интересно и актуально.
Прайм + ResView
что позволяет хранить resview?
у нас Recall слегка обновленный с добавлением интерфейса смонтированного в интернет браузере который позволяет загрузку данных в систему, поиск по системе и выгрузку данных, но без некоторых проблем конечно не обходится
Всю ту информацию что Вы перечислили и даже больше (информацию по разработке, ГДИСы, карты и т.д. Но есть не большие косяки с выгрузкой кривых для проектов RMS.
В части простого хранилища - Система Мониторинга Недропользования от ООО "СибГеоПроект". там есть хранилка и просмотрщик. есть также модуль для кернохранилища.
Добрый день,
У нас для хранения каротажа используется Прайм, а для части остального, что вы перечислили, используется свое ПО в котором есть загрузка, просмотр, выгрузка в том числе каротажа. Судя по внутренним структурам хранения Прайм, сомневаюсь, что в него можно имиджи загрузить и эффективно с ними работать (быстро извлекать). API Прайм существует только для Windows и не очень стабильно работает с большими объемами данных обычного каротажа. Полагаю, изначально, Прайм был проектным решением, то есть для одного месторождения, а не в целом по всему объему данных компании. В плане одного проекта это хорошее ПО. С базами данных Прайм работает через виртуальные внутренние таблицы, что довольно оригинально и на мой взгляд неудобно.
ResView может быть использован для хранения всего остального. У него хорошие загрузчики, приятный интерфейс. Однако, удобно работать лишь с локальными проектами (хранение в одном файле (БД sqlite)). Если связываться с централизованной БД (Oracle), то начинается как в поговорке: "гладко было на бумаге, но забыли про овраги".
Если бы у меня был выбор, то как разработчик ПО, я бы каротаж хранил каротаж в BLOBах Oracle (в простых float или double массивах) в отдельном tablespace. Проверено, надежно, конфигурируется и оптимизируется очень гибко, очень быстро, могут воспользоваться все сторонние производители ПО.
Техлог. Тут вам и работа с каротажными кривыми, керновыми данными, фоточками. Легко грузятся различные результаты испытаний итд итп.
Не знаю на чем и как у вас настроен Prime и ResView.
У нас Prime стоит на серваке, под SQL и Windows Server 2012, в базе крутиться около 100 тыс скважин, полет нормальный.
ResView стоит под Oracle 11, в проекте около 100 месторождений ( с кол-вом скважин от 10 до 10000), работа в домене, без лагов и тд.
Главное при работе с любым сетевым хранилищем
1) Правильно подобранное железо
2) Хороший канал (желательно опто-волокно)
3) Правильно настроен доступ
Уважаемый, а мы с вами про один и тот же Прайм говорим? :) Я про Прайм primegeo.ru у которого индексная база на Firebird.
ResView под оракл не имеет всех функций, которые есть в локальных проектах RV. При частых обновлениях софта, требуется частое обновление схемы Оракл RV, пароли доступа clear text'ом в параметрах соединения прописаны что не есть хорошо, на каждой клиентской машине требуется настроенный оракл клиент и т.д.
и еще 10 пунктов, среди них на 1ом месте:
правильно спроектированная и реализованная структура хранилища и интерфейс доступа.
Железо далеко не всегда решающую роль играет. Можно и на супер железе сделать очень плохо, а можно и на среднем вытянуть.
Возможно удивлю Вас, но Прайм про который мы с Вами говорим, позволяет запиливать БД даже на оракле, в итоге я Вам говорю по факту, как все устроено у нас, и что нет никаких траблов в работе. Про какие ограничения работы с RV я не в курсе, но того объема информации что сейчас я имею с доступом через клиента оры, мне достаточно. Установка и настройка всего софта включая клиентов оры это не забота пользователя БД, а работа специально обученного персонала (сисадмин), и на работе специалиста геолога, геофизика у нас никак не сказывается. Конечно если у Вас в штате есть такой специалист.
А что касается железа, так из-за спецификации хранения данных Прайма, главное требование это наличие SAS и очень широкий канал. Эта особенность связана с большим количеством мелких файлов и то что эти файлы храняться не под управлением СУБД, поэтому файловый сервак предпочтителен.
Можно использовать PostgreSQL. "Полет" отличный.
Слышал что можно, но не видел.
Тип СУБД повлияет лишь на скорость работы интерфейса прайм Навигатор и не более того. Узкое место - медленный виндовый API вытаскивания самих кривых из .ws файлов. То что у вас траблов нет значит вам сравнить не с чем. 100 тыс скважин это несколькоа терабайт кривых в .ws файлах. Один процесс полной переиндексации занимает не часы, а дни
да около 1,5 Тб
именно так, но этим процессом вы занимаетесь только 1 раз, зачем каждый день переиндексировать
Техлог(для работы) + общая папка(для хранения) + соглашение об именовании и процедуры выгрузки/загрузки данных в техлоге (для управления данными).
Если стоит вопрос поиска (Где мы проводили дефектоскопию? В каких интервалах делали испытания и какой получили результат ?), то лучше всего сделать БД, хоть в постгре, хоть в акцессе. Если задача хранения - то пока лучше папки на общем диске ничего не придумали.
Софт, для управления этими данными, который доводилось видеть, потребляет много ресурсов и обслуживания.
Коллеги, для работы со скважинной информацией мы используем нашу систему PetroExpert, которая работает в связке с БД системы ReView (сейсмика). Это полноценная клинет-серверная архитектура, с возможностью работы широкого круга специалистов над одним проектом. Без проблем работаем с десятками тыс. скважин в одном проекте. На сервере, где располагаются проекты вообще нет ограничений на число скважин или объем скважинной информации по каждой скважине. Широкий функционал уже "из коробки", возможность заказать экзотику лично под себя. Серверная часть - Linux, клиентская Windows или Linux.
Архитектура построена на "легком" SQL индексе данных (можем легко добавлять типы данных или индексы свойств) и на файловом хранилище самих данных в двоичном формате, при этом всегда соблюдается обратная совместимость (мы легко работаем с нашими проектами которым 8 и более лет).
Все что Вы описываете в своем вопросе можно хранить в нашей системе, при этом данные можно легко получать с разных рабоичх мест, в том числе удаленно (не требуется супер скорость канала). "Проекты" это логическое разделение данных, поэтому нет никакой сложности организовать работу со всем массивом информации по керну или специфическим исследованиям, если эта задача потребуется от хранилища.
Для аналитики есть действительно прогрессивные возможности анализа данных, при этом пользователь не погружается в мир SQL запросов или классических интерфейсов БД ;) Планшеты, кросс-плоты, план скважин полностью интерактивны.
Все можно попробовать своими руками, в том числе на нашей тестовой интернет площадке.
Напишите запрос на info@pangea.ru и я с Вами свяжусь и мы установим клентское ПО, серверную часть можем развернуть у Вас по вашему желанию.
PS. Чуть мыслей вслух: в связи с активными атаками на нашу область (один Петя чего стоил), я бы не доверял решениям с расшаренными папками, хранением данных локально на Windows клиентах в БД "проекта" и подобным подходам.
это о чём
можно подробнее
Пожалуйства!
После успешной атаки вируса "Петя" минимум две нефтяных компании более недели восстанавливали работоспосбность своих офисов, часть данных безвозвратно утеряна! По понятным причинам Вы не найдете информацию об этом в открытых источниках! Предлагаю выдержку из нашего письма (реклама):
В свете последних хакерских атак на компьютерную инфраструктуру российских нефтегазовых компаний предлагаем ознакомиться с принципами построения компьютерной системы ПАНГЕЯ, минимизирующими риски утраты геолого-геофизической информации и практически исключающими несанкционированный доступ к данным.
Даже полная утрата рабочих мест пользователей системы ПАНГЕЯ (физическая или после вирусной атаки) не повлечет потери геолого-геофизической информации и текущих данных в проектах. Работа может быть возобновлена в течение 1-2 часов путем настройки новых рабочих мест для работы с сервером Системы. Для этого нами внедрены следующие принципы:
1. Хранение массивных данных и индексной БД Системы ПАНГЕЯ организовано на сервере под управлением Linux, что позволяет существенно упростить конфигурацию рабочих мест пользователей и избежать дополнительных временных файловых хранилищ, в том числе на рабочих местах.
2. Счетные задания над сейсмическими данными (зачастую имеющими размер десятки гигабайт) выполняются на сервере, позволяя избегать затратных процедур массового копирования внутри сети компании, а также централизованно проектировать и оптимально использовать вычислительные мощности компании.
3. С проектами на одном сервере может работать одновременно множество пользователей. Это не дополнительная возможность, как у большинства прикладных геофизических пакетов (Petrel, IHS Kingdom, Геопоиск, ГеоТЭК Прайм и др.), а базовое требование, заложенное при проектировании и реализации Системы ПАНГЕЯ.
4. У пользователей нет необходимости иметь прямой доступ к файлам и каталогам проекта, что минимизирует риски несанкционированного доступа к данным и полностью исключает их утрату, например, во время атаки вирусов на клиентские рабочие места под управлением ОС Windows.
5. Единое место хранения позволяет использовать централизованную систему резервного копирования, в том числе ежедневно выгружать дамп индексной БД MySQL и самих данных. Например, в АО ПАНГЕЯ организовано ежедневное резервное копирование геолого-геофизической информации по всем проектам на ленточные накопители.
Система ПАНГЕЯ создана и развивается единой командой российских разработчиков на основе промышленных решений Open Source в базовой части ПО, что исключает наличие «посторонних» функций, не нацеленных на решение задач хранения, обработки, интерпретации и анализа геолого-геофизических и промысловых данных.
Добрый день, Михаил!
Такая же система упоминается тут?
https://rogtecmagazine.com/газпром-нефть-с-партнерами-создает/?lang=ru
«Газпром нефть» с партнерами создает первую отечественную интегрированную IT-платформу по обработке и интерпретации данных сейсмики
Специалисты Научно-технического центра «Газпром нефти» в партнерстве с компаниями Яндекс.Терра (ООО «Сейсмотек»), ЗАО «Пангея» и МФТИ создают первую в России интегрированную платформу для обработки и интерпретации данных сейсморазведки, которая способна сопровождать весь цикл сейсмических исследований – от постановки задач до завершения проектов.
Да, это новость про наше сотрудничество с Газпромнефть НТЦ, в рамках которого разрабатывается ПО, объединяющее, в основном, Систему ПАНГЕЯ и Прайм (Яндекс Терра) в единое целое и куда предполагается включать стронние модули на последующих этапах.
Но в данном обсуждении, я предлагаю часть системы ПАНГЕЯ, которая может использоваться как удобная система хранения скважинной информации в рамках предприятия с возможностью дополнительной адаптации под конкретные задачи.
Если говорить открыто, то слили своих коллег из Прайма)))
Я не очень понял что Вы имеете ввиду, но сотрудничество 2 близких по духу коллективов над процессом доработки (разработки) и внедрения Российского ПО (для обработки и интерпретации данных сейсморазведки) для одного прогрессивного заказчика (надеюсь пока), мне кажется не только амбициозной, но и правильной задачей в целом для отрасли!
1. Сохранность данных (на что вам Михаил и намекнул) слабо зависит от софта, бакапы-бакапы-бакапы и хороший админ. Надёжность современных РБД (типа оракла, постгреса и пр.) это как сравнивать мягкое с тёплым, сохранности этот параметр не касается - она обеспечивается файловой системой. Современные файловые системы NTFS, Ext4 и пр. очень надёжны. Надёжность РБД описывает согласованность данных на уровне транзакции (что для геоданных практически не актуально)
2. Удобство использования - всё зависит от того, что вы будете делать с данными. Если ваш софт не умеет напрямую работать с хранилищем это значит, что придётся делать кучу промежуточных действий по импорту\экспорту.
3. Достоверность. Часть данных как правило вообще отсутствует, т.е. их нужно вбивать вручную. С учётом того, что непонятно зачем они вообще нужны, это большой ОПСССССсс...
4. Логическая связанность. Что бы обеспечивать данный параметр нужно иметь модель даннных, которые будут храниться. А это практически равноценно повторению софта обработки.
5. Альтернативы. Сырые данные: "А давайте всё в кучу набросаем, а наш 'высокоумный систем' будет вам по всему этому искать" (яндекс, гугл, бинг и пр. локальные версии поисковиков). На любителя, вариант: "гора родила мышь. Но вот если так уже сложилось, а "разгребание" слишком затратно, такой костыльный вариант, наверное, имеет право на жизнь.