adeshere
@adeshere
РАН, Фортран, временные ряды

Распределенная одноранговая сеть кластеров с данными — где получить базовые знания (хочу учебник)?

Добрый день всем!
Прежде, чем спросить, преамбула. В силу чудовищного стечения обстоятельств я внезапно узнал, что всю жизнь "говорил прозой". Образно говоря, мы занимались изготовлением неких "стульев" (они в нашем случае довольно специфические, поэтому был смысл их делать самим, а не покупать на заводе). Но вдруг оказалось, что если поставить этот "стул" на Яндекс-диск, то он превращается в велосипед. Причем тоже с некоторыми специфическими особенностями, которые, возможно, даже оправдывают такое велосипедостроение.
Проблема в том, что будучи специалистом по стульям, я вообще ничего про "велосипеды" не знаю. Мне нужен простой и доступный, но достаточно фундаментальный (т.е. не устаревающий за несколько лет!) учебник, который объяснит: что такое обычный велосипед. Зачем там нужны колеса, педали и руль, и почему их делают именно так. И заодно намекнет на существование двухподвесов, тандемов, фат-ов и прочего.

Теперь более конкретно по делу.
У нас есть несколько сотрудничающих научных групп в разных местах. Каждая такая группа ведет какие-то наблюдения за так называемыми
геофизическими полями
Например, в скважине на глубине 1км стоит высокочувствительный геофон,и пишет трехкомпонентный звук на разных частотах. Или в землю стационарно закопаны десятки электродов, на питающие подается знакопеременный сигнал, а на приемных регистрируется разность потенциалов, из которой благодаря накоплению можно довольно точно получить кажущееся сопротивление на разных разносах. Или в глубокой штольне на специальном постаменте стоит прецизионный наклономер, который пишет отклонение нормали к поверхности постамента от вертикали. И так далее.
На выходе получаются так называемые временные ряды. Задача - понять: как связаны сигналы такого рода друг с другом, а также с геодинамикой, включая техногенно индуцированные процессы, процессы подготовки землетрясений и пр.

Каждая из этих групп накапливает и хранит результаты своих наблюдений в виде базы данных временных рядов, которая реализована в среде нашей самодельной программы (это и есть тот самый упомянутый выше "стул"). И в этой же программе ведет их анализ и обработку, и т.д. и т.п.
Но с появлением Яндекс-диска внезапно выяснилось, что если эти базы записать на Я-диск, то та же самая программа начинает их воспринимать, как одну базу данных. Т.е. можно из Москвы работать с камчатскими наблюдениями, а из Пущино - с теми и другими вместе. Сперва это вызвало у авторов программы определенный ступор, так как она задумывалась, как
однопользовательское рабочее место
и все средства разделения доступа у нее сводятся к тому, что второй пользователь ставится в очередь, и ждет, пока база освободится. Но оказалось, что для наших задач этого, в общем достаточно. Делать что-то более капитальное нет смысла, поскольку кластеров с данными всего несколько штук. Распределенные вычисления просто не дадут выигрыша в такой ситуации, так как алгоритмы существенно усложнятся, и появятся накладные расходы на оперативную пересылку данных (для чего Я-диск не очень-то приспособлен). Проще, когда каждая группа использует свой компьютер локально. Поэтому называть все это распределенной базой данных, вероятно, неправильно?
В общем, у нас встал вопрос про осмысление происходящего.

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

Будучи чайником в мире "правильных" СУБД. я просто не сумел найти простое и понятное изложение базовых принципов построения и классификации подобных систем. Нужно что-то вроде введения в тему распределенных баз данных для продвинутых школьников, причем, в идеале, на русском (английский у меня исключительно с переводчиком). Вместо этого поиск дает кучу статей по очень конкретным вопросам. Но ведь прежде, чем изучать различия между переключателями Шимано и SRAM, мне сперва надо понять, зачем вообще нужен переключатель скоростей на велосипеде!

В сухом остатке.
Пожалуйста, посоветуйте:
1) базовый учебник, который может дать достаточно простое, но в то же время фундаментальное (то есть не устаревающее с появлением любой новой технологии) введение в тему
2) общий сравнительный обзор систем, которые используются сейчас для решения подобных задач, т.е. для экспертного анализа разнородных временных рядов, которые накапливаются и хранятся распределенно. Без излишнего погружения в детали реализации, т.е. скорее с точки зрения гендиректора, который решает - какая из этих систем лучше подойдет для его предприятия с учетом ее возможностей, цены, требований к эксплуатантам и т.д. Но и без явной рекламной направленности на какую-то одну конкретную технологию.
  • Вопрос задан
  • 33 просмотра
Пригласить эксперта
Ответы на вопрос 1
@rPman
с точки зрения гендиректора
в некотором смысле тут все просто

Либо ты своими силами на своих или арендуемых мощностях (т.е. буквально свой компьютер-сервер, выделенный сервер провайдера DS/виртуальный сервер провайдера VDS/VPS) с реализуешь хранение данных, для этого более чем много инструментов, и если данных относительно мало (миллионы записей) то возможно вам хватит любой sql базы (бесплатные postgres/mysql).

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

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

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

По факту у тебя выбор - плавное перераспределение средств между сделать у себя своими силами до отдать всю работу на сторону. Иногда второе выгоднее и удобнее (когда работы не регулярные, эпизодические).

Теперь вопросы - чем вас не устраивает текущее облачное решение от яндекса? Что вы пробовали локально?

Как именно происходит работа с данными (пример схемы - кусок нужных данных выгружается локально в виде копии, анализируется, удаляется... общая база как накопление данных, т.е. в них другие люди записывают и накапливают данные)?

От того, как именно происходит работа зависит выбор инструмента.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы