Проектирование базы данных для времени и геолокации

Question

Я успешно реализовал вариант использования временных рядов, как показано в документации. Данные (класс событий), на которые указывает наименьшая единица времени, индексируются пространственным индексом люцены.

У меня есть два типа событий: частные или публичные.

Как мне спроектировать базу данных и кластеры для моего варианта использования?

Было бы лучше использовать Edge или список ссылок, чтобы сделать ссылку от Min до Event?

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

Изучив документацию, вы увидите, что кластеры для данных геолокации были бы отличной стратегией.

Индекс можно использовать только для подзапроса:

select 
from 
  (select 
     expand(month["12"].day["25"].hour["17"].min["07"].events)
   from 
     Year 
   where 
     year = 2015)
where
   [lat,lng,$spatial] 
NEAR 
   [66,66,{"maxDistance":1}]

Документация по индексам говорит мне, что можно использовать индексы по свойствам ребер. Плохая сторона в том, что он занимает больше памяти, чем связанный список, который я протестировал, и он работает:

select 
  expand(inV())
from 
  (select 
      expand(month["12"].day["25"].hour["17"].min["07"].outE('MinPublicEvent'))
   from 
     Year 
   where 
     year = 2015)
where
   [lat,lng,$spatial] 
NEAR 
   [66,66,{"maxDistance":1}]

Answer 1

Что касается связи между ребрами и ребрами, взятой из документа OrientDB: легкие ребра, первое отличие состоит в том, что ребра могут хранить свойства, а ссылки - нет.

Вот плюсы и минусы легких краев против обычных краев:

ПЛЮСЫ:

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

МИНУСЫ:

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

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

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

Краевой подход более выразителен, но когда производительность действительно имеет значение, и существует риск узкого места, вы должны следить за показателями и производительностью, а также реорганизовать подход embed + link в случае возникновения проблем с производительностью.

Обновление:

Кластеры - это механизм разделения данных в OrientDB (учебник по кластерам), который работает как для ребер, так и для вершин.

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

• Оптимизация: более быстрое выполнение запросов к кластерам, учитывая, что вам нужно искать только подмножество кластеров в классе.
• Индексы. При хорошем разделении вы можете уменьшить или исключить использование> индексов.
• Параллельные запросы. Запросы могут выполняться параллельно, если данные передаются на несколько дисков.
• Sharding: вы можете расщеплять большие наборы данных в нескольких экземплярах.

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

Когда добавить больше кластеров? Метрики, метрики и метрики. Отслеживайте, как ваше приложение обращается к вашей базе данных, какие запросы, количество запросов и т. Д.