Вопрос о терминах. Есть набор БД, с каждой из которых можно работать отдельно либо со всеми сразу. Как правильно называется такая система?

MichaelMelvin, Namudril, спасибо! А вот эта фраза:

В любой непонятной ситуации называй это "система".

просто гениальная, имхо!

Вопрос о терминах. Есть набор БД, с каждой из которых можно работать отдельно либо со всеми сразу. Как правильно называется такая система?

Вы создали иерархию независимых реплик и она никак не контролируется мастер-узлом.

Не совсем так. При такой архитектуре технически у нас вообще нет понятия мастер-базы (узла): все реплики равноправны. Но, в теории, они не должны расходиться между собой, так как на всех локальных компах клиент Я-диска запускается при входе в систему. Поэтому базы на разных компах, опять-таки в теории,

всегда синхронизированы друг с другом.

Да, Яндекс-диск - это сильно не идеальная среда для этого. Но мы его используем в силу простоты и дешевизны. У нас ведь нагрузка ничтожная: количество пользователей у каждой БД - единицы.

Что же касается мастер-базы, то по факту новые данные вводит обычно тот, кто их получает. А это один человек (одна локальная группа людей). То есть, проблема "мастера" решается не на техническом уровне, а на человеческом.
На самом деле "расхождение баз" в такой архитектуре возможно, но для этого нужно совпадение трех довольно редких условий:
1) два юзера подключились к одной базе одновременно (с разницей не больше нескольких секунд, т.к. небольшие файлы Я-диск обычно синхронизирует очень неплохо)
2) оба они собираются загружать туда новые данные (в 90% случаев к БД подключаются, чтобы что-то оттуда вынуть, а не загрузить)
3) оба они начали грузить (менять) данные немедленно после подключения к базе, т.е. быстрее, чем Я-диск

начал синхронизацию файлов

она начинается не в момент изменения данных в базе, а в момент подключения юзера. СУБД ставит соответствующий флаг в небольшом заголовочном файле. Как только Я-диск синхронизирует этот файл с облаком, а затем и другими локальными базами, все локальные клиенты поймут, что база занята, и запретят менять данные в ней, пока первый юзер не отключится

и СУБД обнаружила факт одновременного подключения к базе с двух компов.

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

нас устраивает...

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

Вопрос о терминах. Есть набор БД, с каждой из которых можно работать отдельно либо со всеми сразу. Как правильно называется такая система?

один из самых популярных инструментов в крупных проектах https://ru.wikipedia.org/wiki/Hadoop

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

В общем, у нас получилось по классике: "...не мышонок, не лягушка, А неведома зверюшка». Которая как-то работает и со своими задачами в общем справляется.

Но вот как все это назвать?!

Вопрос о терминах. Есть набор БД, с каждой из которых можно работать отдельно либо со всеми сразу. Как правильно называется такая система?

возможно вам сюда инструменты агрегирования баз данных или сюда распределенные базы данных

mindtester, спасибо за совет. Ссылки, конечно, полезные... но я не смог их "раскрутить" до решения.
Например, когда Вы едете в отпуск, то смотрите расписание поездов и полетов, выбираете рейсы, бронируете билеты, заказываете такси. Но можно назвать сам этот процесс покупки билетов агрегированием БД Экспресс, Леонардо и Яндекс-такси? Имхо, как-то не очень... Хотя все данные из них и правда используются совместно в какой-то момент. Вот и у нас то же самое: мы используем данные из разных баз в ходе решения какой-то задачи. Но эта задача больше напоминает не построение какой-то сводной таблицы (отчета), а сборку машинки из железячек и винтиков. Наши БД - это ящички с разными деталями, винтами и гайками. Когда я собираю машинку, то заглядываю в разные ящички, чтобы найти подходящий болтик/детальку. Но сами по себе эти ящики между собой не связаны абсолютно никак. Все, что у них есть общего - что я могу до любого из них дотянуться одной и той же рукой (читай, СУБД).
Что же касается второй ссылки, то она лишь подкрепила мою уверенность, что наша система не является распределенной БД в общепринятом понимании, т.к. у нее отсутствуют некоторые важные функции. И, значит, называть ее нужно не так.
НО КАК ????

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

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

У нас масштабы совершенно не те, чтобы собственную систему строить.
В нашем случае количество клиентов - это количество научных сотрудников, которые работают с общими данными.
Все данные сгруппированы в большое количество относительно компактных баз, содержащих пять-десять-двадцать временных рядов. Как правило, каждый ряд не больше гигабайта (измерения на частоте 0.01-10Гц длиной 1-20 лет). А часто и того меньше. При этом полный размер микро-базы часто бывает несколько Гб.
Обычно в каждой микро-БД хранятся сигналы, которые пишутся конкретной группой приборов. Также есть клоны этих баз, куда пишутся очищенные или преобразованные сигналы. Для транзакций такая микро-база блокируется целиком.
Как правило, каждая такая база сопровождается локально, одним-двумя конкретными сотрудниками, а всем остальным пользователям именно этой базы (их тоже всего несколько человек) нужен доступ почти только на чтение. Их повседневная работа - это анализ данных, который на 95% состоит из манипуляций с выборкой, которая хранится в локальном рабочем пространстве (в выборку, естественно, грузятся данные из нескольких таких микро-баз).
Обращение непосредственно к основной базе (чтобы эту выборку сделать или записать изменения) происходит довольно редко (несколько минут в сутки). Поэтому вероятность одновременного обращения нескольких клиентов к любой конкретной микро-базе есть, но она не очень высокая.
При этом флаг "база занята" пишется не в файлы с данными, а в небольшой отдельный файл, который синхронизируется гораздо быстрее.

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

небезопасные конфликты между клиентами

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

занята кем-то другим

так как некоторое время он видит ее несинхронизированую копию, где флаг "занято" еще не включен

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

Но в первом приближении система свои задачи как-то решает. Хотя она и сделана в стиле физических лабораторий середины прошлого века, когда приборы для самых передовых экспериментов нередко конструировались "на коленке" с использованием синей изоленты, пластилина и проволоки.

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

более развернутыми примерами

Причем описание хочется в стиле от общего к частному: то есть вот есть задача "А", в разных программных системах она решается вот так (описание и сравнение решений...). Вот задача "Б" (...), и т.д.
А не наоборот: "MongoDB умеет (список возможностей и ограничений); Couchbase умеет (список возможностей и ограничений); и т.д.

Если следовать вот этой классификации, то наша система на основе Я-диска похожа на гомогенную распределенную СУБД. Однако из 12 правил К.Дейта она реализует только первые 7 (и, с некоторыми натяжками, 8). А пункты 9-12 не просматриваются даже в конце тоннеля.

А еще в упомянутом обзоре мне не хватает чуть более подробного объяснения, как именно все эти пункты реализованы на практике в разных системах. То есть чего-то похожего на пункт 5.7, но только в виде "спойлера" к каждому пункту предыдущего текста.

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

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

UPD: И еще уточню, чтобы не было двусмысленности. Мы сейчас не планируем переходить на другую СУБД. Наша система и в плане интерфейса, и в плане производительности оптимизирована под временные ряды геофизического мониторинга. Для получения сравнимых характеристик от других инструментов потребуются на порядок более дорогие решения плюс куча программирования, так как стандартные SQL-запросы под наши задачи придется дорабатывать совсем не напильником.
Вместо этого стоят три другие задачи:
1) По факту, у нас родилась "не мышонок, не лягушка, А неведома зверушка" (с). Хочется для начала понять - что же это за зверь?
2) Также интересно узнать, как похожие задачи принято решать в других предметных областях. Вдруг существуют какие-то простые и полезные технические приемы, которые можно без больших усилий применить в нашей системе, чтобы пофиксить ее недостатки?
3) Также интересно составить более конкретный список возможных альтернативных технологий, и более четко сформулировать их плюсы и минусы по сравнению с нашей существующей схемой работы.

Почтовый клиент thunderbird перестал открывать вложения типа *.doc в ассоциированном приложении. Как исправить?

Совет правильный, но...
Я в курсе про сортировку столбцов, но у меня русскоязычная версия Windows. Поэтому и при сортировке по умолчанию, и при принудительной сортировке записи для doc и docx идут не подряд.
Насколько я смог догадаться, сортировка в этом списке идет не по самому расширению, а по "описанию расширения" (или как там оно правильно называется?). Поэтому docx в русскоязычной версии этой таблицы стоит то ли на букве "Д" ("Документ Word 2007"), то ли вообще на "A" ("Application..."). А doc-файлы стоят на букве "M" (от "Microsoft Word"). См.скриншоты ниже.
В общем, привет, сортировка!

Скриншоты диалога настройки файловых ассоциаций thunderbird. Таблица отсортирована по типу файла. Это первая страница списка:

А это третья страница. Глядя на первую страницу, не только лишь все могут сразу сообразить, что для настройки ассоциации документов Word типа *.doc надо спуститься на пару экранов ниже. Вот и я тоже такой ;-) Хотя вроде бы уже много лет в курсе, что в действительности все не так, как на самом деле :

Почтовый клиент thunderbird перестал открывать вложения типа *.doc в ассоциированном приложении. Как исправить?

Спасибо!!! Все решилось!

Конечно, я в это меню слазил еще до того, как этот вопрос задать. И я видел там ассоциацию с Word. Что она вроде бы настроена правильно.

Но я протупил, что в верхней части списка расширений была ассоциация строго с MS Word 2007. То есть, она подразумевает только и исключительно docx-файлы. А у меня файлы типа *. doc.
А ассоциация с *. doc- файлами, как я теперь понял, задается отдельно, на два экрана ниже! Надо было внимательнее читать пункт меню при проверке этой настройки.

Хотя, справедливости ради, на мой вкус было бы эргономичнее собрать все настройки ассоциаций, связанные с разными версиями документов одной программы, по соседству друг с другом. Тогда я бы не глюканул с этой настройкой, т.к. сразу увидел бы, что в списке есть несколько ассоциаций с документами Word разных версий, и что они заданы по-разному.
Если тут есть продвинутые пользователи thunderbird - как думаете, может быть, стоит отправить такое предложение разработчикам?

Еще меня немного интересует вопрос, по какой причине у меня эта настройка могла слететь (раньше-то все работало). Но это уже сугубо теоретический интерес.

Можно ли создать нейросеть, которая предсказывает числа из псевдослучайной последовательности?

Вообще-то, у генераторов ПСЧ есть цикличность, просто цикл очень длинный. Поэтому теоретическая возможность восстановить параметры алгоритма есть. Но для этого явно нужна не сотня чисел, а несколько больше.