ArangoDB сравнение документов в разных базах данных

Мне интересно, можно ли сравнить два документа с одинаковыми "_id" (одинаковыми именами коллекций и "_keys"), которые хранятся в разных базах данных.

Мой вариант использования - это настраиваемый «механизм карты / макета», который «в основном» питается «заданиями автоматического импорта / преобразования» из внешней системы геоданных.

Пока все работает нормально.

Однако в некоторых случаях необходимо настроить вручную, например. "x / y" -координаты некоторых объектов, чтобы сделать их более удобными. При повторном запуске любого задания импорта (например, для получения последних данных) все ручные настройки теряются, так как они просто перезаписываются "автоматическими" данными.

Поэтому я думаю о настройке системы, состоящей из нескольких идентично структурированных баз данных ArangoDB, используемых на разных «этапах» жизненного цикла данных, например:

  • "staging" - сюда помещаются вновь "автоматически импортированные" данные.
  • «производство» - здесь хранятся «окончательные данные», которые представляются пользователю, включая все последние ручные настройки.

Соответствующий (упрощенный) жизненный цикл будет таким:

  1. Автоимпорт в "постановку"
  2. Сравните и импортируйте все ручные настройки из «производства» в «стадию».
  3. Разверните «объединенное» содержимое из 1. и 2. как новую «производственную» версию.

Итак, эта тема посвящена этапу «сравнения» шага 2 между «производственными» и «промежуточными» значениями данных.

В SQL я бы выразил это с помощью sth. нравится:

SELECT
x, y
FROM databaseA.layout AS layoutA
JOIN databaseB.layout ON (layoutA.id = layoutB.id) AS layoutB
WHERE
...

Спасибо за любые подсказки о том, как решить эту проблему в ArangoDB с помощью запроса AQL или службы FOXX!


aql arangodb arangodb-foxx foxx
person vlabmichl    schedule 02.09.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

  1. При первом импорте вставьте новые данные, создав новую ревизию R0 для каждого вставленного узла.
  2. Вручную измените некоторые поля узла, скажем N в этих данных, что приведет к новой ревизии N, скажем R1. Ваша предыдущая версия R0 не потеряна.
  3. Повторите шаги 1 и 2 столько раз, сколько захотите.

Наконец, когда вам нужно показать эти данные конечному пользователю, используйте пользовательскую логику приложения, чтобы объединить столько предыдущих версий, сколько вы хотите, с текущей версией, выполняя слияние n-way, а не 2-way.

Если вы думаете, что это могло быть потенциальным решением, вы можете взглянуть на CivicGraph, версию слой управления построен поверх ArangoDB.

Примечание. Я являюсь создателем CivicGraph, и этот ответ можно квалифицировать как продвижение продукта, но я также считаю, что он может помочь решить вашу проблему.

person adityamukho    schedule 09.10.2019