Базы данных для хранения каротажных данных

Последнее сообщение
bougulmann 65 11
Июн 17

Дорогие коллеги,

предлагаю обсудить кто чем пользуется для хранения и использования скважинной информации и выяснить какое из имеющегося на рынке ПО наиболее подходит для работы с: каротажными данными всех типов (в том числе имиджеров), данными газового каротажа, данными керна (стандартные и специальные исследования, фотографии разных типов и пр.), данными шлама (интервалы, описание, измененные параметры и пр.), собранной в процессе бурения геологической и геотехнической информацией, информацией об интервалах пластов, данными испытаний и измеренных давлений и разумеется данными интерпретации и использованных при этом параметрах.

С уважением. 

altair 77 5
Июн 17 #1

также очень интересно и актуально.

rbildano 237 9
Июн 17 #2

Прайм + ResView

altair 77 5
Июн 17 #3

rbildano пишет:

Прайм + ResView

что позволяет хранить resview?

bougulmann 65 11
Июн 17 #4

у нас Recall слегка обновленный с добавлением интерфейса смонтированного в интернет браузере который позволяет загрузку данных в систему, поиск по системе и выгрузку данных, но без некоторых проблем конечно не обходится

rbildano 237 9
Июн 17 #5

altair пишет:

что позволяет хранить resview?

Всю ту информацию что Вы перечислили и даже больше (информацию по разработке, ГДИСы, карты и т.д. Но есть не большие косяки с выгрузкой кривых для проектов RMS.

gloryvictory 16 6
Июл 17 #6

В части простого хранилища - Система Мониторинга Недропользования от ООО "СибГеоПроект". там есть хранилка и просмотрщик. есть также модуль для кернохранилища.

SolarisForever 16 9
Июл 17 #7

Добрый день,

У нас для хранения каротажа используется Прайм, а для части остального, что вы перечислили, используется свое ПО в котором есть загрузка, просмотр, выгрузка в том числе каротажа. Судя по внутренним структурам хранения Прайм, сомневаюсь, что в него можно имиджи загрузить и эффективно с ними работать (быстро извлекать). API Прайм существует только для Windows и не очень стабильно работает с большими объемами данных обычного каротажа. Полагаю, изначально, Прайм был проектным решением, то есть для одного месторождения, а не в целом по всему объему данных компании. В плане одного проекта это хорошее ПО. С базами данных Прайм работает через виртуальные внутренние таблицы, что довольно оригинально и на мой взгляд неудобно.

ResView может быть использован для хранения всего остального. У него хорошие загрузчики, приятный интерфейс. Однако, удобно работать лишь с локальными проектами (хранение в одном файле (БД sqlite)). Если связываться с централизованной БД (Oracle), то начинается как в поговорке: "гладко было на бумаге, но забыли про овраги".

Если бы у меня был выбор, то как разработчик ПО, я бы каротаж хранил каротаж в BLOBах Oracle (в простых float или double массивах) в отдельном tablespace. Проверено, надежно, конфигурируется и оптимизируется очень гибко, очень быстро, могут воспользоваться все сторонние производители ПО.

Burrito 31 5
Июл 17 #8

Техлог. Тут вам и работа с каротажными кривыми, керновыми данными, фоточками. Легко грузятся различные результаты испытаний итд итп.

rbildano 237 9
Июл 17 #9

SolarisForever пишет:

Добрый день,

У нас для хранения каротажа используется Прайм, а для части остального, что вы перечислили, используется свое ПО в котором есть загрузка, просмотр, выгрузка в том числе каротажа. Судя по внутренним структурам хранения Прайм, сомневаюсь, что в него можно имиджи загрузить и эффективно с ними работать (быстро извлекать). 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) Правильно настроен доступ

SolarisForever 16 9
Июл 17 #10

rbildano пишет:
У нас Prime стоит на серваке, под SQL и Windows Server 2012, в базе крутиться около 100 тыс скважин, полет нормальный.

Уважаемый, а мы с вами про один и тот же Прайм говорим? :) Я про Прайм primegeo.ru у которого индексная база на Firebird.

rbildano пишет:
ResView стоит под Oracle 11, в проекте около 100 месторождений ( с кол-вом скважин от 10 до 10000), работа в домене, без лагов и тд.

ResView под оракл не имеет всех функций, которые есть в локальных проектах RV. При частых обновлениях софта, требуется частое обновление схемы Оракл RV, пароли доступа clear text'ом в параметрах соединения прописаны что не есть хорошо, на каждой клиентской машине требуется настроенный оракл клиент и т.д.

 

rbildano пишет:

Главное при работе с любым сетевым хранилищем 

1) Правильно подобранное железо

2) Хороший канал (желательно опто-волокно)

3) Правильно настроен доступ

и еще 10 пунктов, среди них на 1ом месте:

правильно спроектированная и реализованная структура хранилища и интерфейс доступа.

Железо далеко не всегда решающую роль играет. Можно и на супер железе сделать очень плохо, а можно и на среднем вытянуть.

rbildano 237 9
Июл 17 #11

Возможно удивлю Вас, но Прайм про который мы с Вами говорим, позволяет запиливать БД даже на оракле, в итоге я Вам говорю по факту, как все устроено у нас, и что нет никаких траблов в работе. Про какие ограничения работы с RV я не в курсе, но того объема информации что сейчас я имею с доступом через клиента оры, мне достаточно. Установка и настройка всего софта включая клиентов оры это не забота пользователя БД, а работа специально обученного персонала (сисадмин), и на работе специалиста геолога, геофизика у нас никак не сказывается. Конечно если у Вас в штате есть такой специалист.

А что касается железа, так из-за спецификации хранения данных Прайма, главное требование это наличие SAS и очень широкий канал. Эта особенность связана с большим количеством мелких файлов и то что эти файлы храняться не под управлением СУБД, поэтому файловый сервак предпочтителен.

SolarisForever 16 9
Июл 17 #13

rbildano пишет:

Возможно удивлю Вас


Слышал что можно, но не видел.

Тип СУБД повлияет лишь на скорость работы интерфейса прайм Навигатор и не более того. Узкое место - медленный виндовый API вытаскивания самих кривых из .ws файлов. То что у вас траблов нет значит вам сравнить не с чем. 100 тыс скважин это несколькоа терабайт кривых в .ws файлах. Один процесс полной переиндексации занимает не часы, а дни

rbildano 237 9
Июл 17 #14

SolarisForever пишет:

100 тыс скважин это несколькоа терабайт кривых в .ws файлах. 

да около 1,5 Тб

SolarisForever пишет:
Один процесс полной переиндексации занимает не часы, а дни

именно так, но этим процессом вы занимаетесь только 1 раз, зачем каждый день переиндексировать

gotcha 87 13
Июл 17 #15

Техлог(для работы) + общая папка(для хранения) + соглашение об именовании и процедуры выгрузки/загрузки данных в техлоге (для управления данными).

Если стоит вопрос поиска (Где мы проводили дефектоскопию? В каких интервалах делали испытания и какой получили результат ?), то лучше всего сделать БД, хоть в постгре, хоть в акцессе. Если задача хранения - то пока лучше папки на общем диске ничего не придумали.

Софт, для управления этими данными, который доводилось видеть, потребляет много ресурсов и обслуживания.

Михаил ПАНГЕЯ 15 10
Окт 17 #16

Коллеги, для работы со скважинной информацией мы используем нашу систему  PetroExpert, которая работает в связке с БД системы ReView (сейсмика). Это полноценная клинет-серверная архитектура, с возможностью работы широкого круга специалистов над одним проектом. Без проблем работаем с десятками тыс. скважин в одном проекте. На сервере, где располагаются проекты вообще нет ограничений на число скважин или объем скважинной информации по каждой скважине. Широкий функционал уже "из коробки", возможность заказать экзотику лично под себя. Серверная часть - Linux, клиентская Windows или Linux.

Архитектура построена на "легком" SQL индексе данных (можем легко добавлять типы данных или индексы свойств) и на файловом хранилище самих данных в двоичном формате, при этом всегда соблюдается обратная совместимость (мы легко работаем с нашими проектами которым 8 и более лет).

Все что Вы описываете в своем вопросе можно хранить в нашей системе, при этом данные можно легко получать с разных рабоичх мест, в том числе удаленно (не требуется супер скорость канала). "Проекты" это логическое разделение данных, поэтому нет никакой сложности организовать работу со всем массивом информации по керну или специфическим исследованиям, если эта задача потребуется от хранилища.

Для аналитики есть действительно прогрессивные возможности анализа данных, при этом пользователь не погружается в мир SQL запросов или классических интерфейсов БД ;)  Планшеты, кросс-плоты, план скважин полностью интерактивны.

Все можно попробовать своими руками, в том числе на нашей тестовой интернет площадке.

Напишите запрос на info@pangea.ru и я с Вами свяжусь и мы установим клентское ПО, серверную часть можем развернуть у Вас по вашему желанию.

PS. Чуть мыслей вслух: в связи с активными атаками на нашу область (один Петя чего стоил), я бы не доверял решениям с расшаренными папками, хранением данных локально на Windows клиентах в БД "проекта" и подобным подходам.

GRR 589 5
Окт 17 #17

Михаил (ПАНГЕЯ) пишет:

PS. Чуть мыслей вслух: в связи с активными атаками на нашу область (один Петя чего стоил), я бы не доверял решениям с расшаренными папками, хранением данных локально на Windows клиентах в БД "проекта" и подобным подходам.

это о чём

можно подробнее

Михаил ПАНГЕЯ 15 10
Окт 17 #18

GRR пишет:

Михаил (ПАНГЕЯ) пишет:

PS. Чуть мыслей вслух: в связи с активными атаками на нашу область (один Петя чего стоил), я бы не доверял решениям с расшаренными папками, хранением данных локально на Windows клиентах в БД "проекта" и подобным подходам.

это о чём

можно подробнее

Пожалуйства!

После успешной атаки вируса "Петя" минимум две нефтяных компании более недели восстанавливали работоспосбность своих офисов, часть данных безвозвратно утеряна! По понятным причинам Вы не найдете информацию об этом в открытых источниках! Предлагаю выдержку из нашего письма (реклама):

В свете последних хакерских атак на компьютерную инфраструктуру российских нефтегазовых компаний предлагаем ознакомиться с принципами построения компьютерной системы ПАНГЕЯ, минимизирующими риски утраты геолого-геофизической информации и практически исключающими несанкционированный доступ к данным. 

Даже полная утрата рабочих мест пользователей системы ПАНГЕЯ (физическая или после вирусной атаки) не повлечет потери геолого-геофизической информации и текущих данных в проектах. Работа может быть возобновлена в течение 1-2 часов путем настройки новых рабочих мест для работы с сервером Системы. Для этого нами внедрены следующие принципы: 
1. Хранение массивных данных и индексной БД Системы ПАНГЕЯ организовано на сервере под управлением Linux, что позволяет существенно упростить конфигурацию рабочих мест пользователей и избежать дополнительных временных файловых хранилищ, в том числе на рабочих местах.
2. Счетные задания над сейсмическими данными (зачастую имеющими размер десятки гигабайт) выполняются на сервере, позволяя избегать затратных процедур массового копирования внутри сети компании, а также централизованно проектировать и оптимально использовать вычислительные мощности компании.
3. С проектами на одном сервере может работать одновременно множество пользователей. Это не дополнительная возможность, как у большинства прикладных геофизических пакетов (Petrel, IHS Kingdom, Геопоиск, ГеоТЭК Прайм и др.), а базовое требование, заложенное при проектировании и реализации Системы ПАНГЕЯ.
4. У пользователей нет необходимости иметь прямой доступ к файлам и каталогам проекта, что минимизирует риски несанкционированного доступа к данным и полностью исключает их утрату, например, во время атаки вирусов на клиентские рабочие места под управлением ОС Windows.
5. Единое место хранения позволяет использовать централизованную систему резервного копирования, в том числе ежедневно выгружать дамп индексной БД MySQL и самих данных. Например, в АО ПАНГЕЯ организовано ежедневное резервное копирование геолого-геофизической информации по всем проектам на ленточные накопители.

Система ПАНГЕЯ создана и развивается единой командой российских разработчиков на основе промышленных решений Open Source в базовой части ПО, что исключает наличие «посторонних» функций, не нацеленных на решение задач хранения, обработки, интерпретации и анализа геолого-геофизических и промысловых данных.
 

Faza 86 7
Окт 17 #19

Добрый день, Михаил!

Такая же система упоминается тут?

https://rogtecmagazine.com/газпром-нефть-с-партнерами-создает/?lang=ru

«Газпром нефть» с партнерами создает первую отечественную интегрированную IT-платформу по обработке и интерпретации данных сейсмики

Специалисты Научно-технического центра «Газпром нефти» в партнерстве с компаниями Яндекс.Терра (ООО «Сейсмотек»), ЗАО «Пангея» и МФТИ создают первую в России интегрированную платформу для обработки и интерпретации данных сейсморазведки, которая способна сопровождать весь цикл сейсмических исследований – от постановки задач до завершения проектов.

 

 

Михаил ПАНГЕЯ 15 10
Окт 17 #20

Faza пишет:

Добрый день, Михаил!

Такая же система упоминается тут?

https://rogtecmagazine.com/газпром-нефть-с-партнерами-создает/?lang=ru

Да, это новость про наше сотрудничество с Газпромнефть НТЦ, в рамках которого разрабатывается ПО, объединяющее, в основном, Систему ПАНГЕЯ и Прайм (Яндекс Терра) в единое целое и куда предполагается включать стронние модули на последующих этапах.

 

Но в данном обсуждении, я предлагаю часть системы ПАНГЕЯ, которая может использоваться как удобная система хранения скважинной информации в рамках предприятия с возможностью дополнительной адаптации под конкретные задачи.

 

rbildano 237 9
Окт 17 #21

Михаил (ПАНГЕЯ) пишет:

Да, это новость про наше сотрудничество с Газпромнефть НТЦ, в рамках которого разрабатывается ПО, объединяющее, в основном, Систему ПАНГЕЯ и Прайм (Яндекс Терра) в единое целое и куда предполагается включать стронние модули на последующих этапах.

 

Но в данном обсуждении, я предлагаю часть системы ПАНГЕЯ, которая может использоваться как удобная система хранения скважинной информации в рамках предприятия с возможностью дополнительной адаптации под конкретные задачи.

 

Если говорить открыто, то слили своих коллег из Прайма)))

Михаил ПАНГЕЯ 15 10
Ноя 17 #22

rbildano пишет:

Если говорить открыто, то слили своих коллег из Прайма)))

Я не очень понял что Вы имеете ввиду, но сотрудничество 2 близких по духу коллективов над процессом доработки (разработки) и внедрения Российского ПО (для обработки и интерпретации данных сейсморазведки) для одного прогрессивного заказчика (надеюсь пока), мне кажется не только амбициозной, но и правильной задачей в целом для отрасли!

kealon 120 12
Ноя 17 #23

bougulmann пишет:

Дорогие коллеги,

предлагаю обсудить кто чем пользуется для хранения и использования скважинной информации и выяснить какое из имеющегося на рынке ПО наиболее подходит для работы с: каротажными данными всех типов (в том числе имиджеров), данными газового каротажа, данными керна (стандартные и специальные исследования, фотографии разных типов и пр.), данными шлама (интервалы, описание, измененные параметры и пр.), собранной в процессе бурения геологической и геотехнической информацией, информацией об интервалах пластов, данными испытаний и измеренных давлений и разумеется данными интерпретации и использованных при этом параметрах.

С уважением. 

если честно, в такой постановке вопроса - никакой

1. Сохранность данных (на что вам Михаил и намекнул) слабо зависит от софта, бакапы-бакапы-бакапы и хороший админ. Надёжность современных РБД (типа оракла, постгреса и пр.) это как сравнивать мягкое с тёплым, сохранности этот параметр не касается - она обеспечивается файловой системой. Современные файловые системы NTFS, Ext4 и пр. очень надёжны. Надёжность РБД описывает согласованность данных на уровне транзакции (что для геоданных практически не актуально)

 2. Удобство использования - всё зависит от того, что вы будете делать с данными. Если ваш софт не умеет напрямую работать с хранилищем это значит, что придётся делать кучу промежуточных действий по импорту\экспорту. 

3. Достоверность. Часть данных как правило вообще отсутствует, т.е. их нужно вбивать вручную. С учётом того, что непонятно зачем они вообще нужны, это большой ОПСССССсс...

4. Логическая связанность. Что бы обеспечивать данный параметр нужно иметь модель даннных, которые будут храниться. А  это практически равноценно повторению софта обработки.

5. Альтернативы. Сырые данные: "А давайте всё в кучу набросаем, а наш 'высокоумный систем' будет вам по всему этому искать" (яндекс, гугл, бинг и пр. локальные версии поисковиков). На любителя, вариант: "гора родила мышь. Но вот если так уже сложилось, а "разгребание" слишком затратно, такой костыльный вариант, наверное, имеет право на жизнь.

Go to top