Дизайн/класс кластеров OrientDB

Question

Я хотел бы создать следующие классы и кластеры, но ищет наиболее логичное и эффективное решение.

I, В основном есть 3 типа пользователей (очень разные), поэтому я разработал их как классы, которые расширяют абстрактный класс пользователя.

Мое приложение сильно основано на GeoLoc. Так что для того, чтобы дать лучший пользовательский опыт в вопросе скорости времени отклика (при выполнении сканирования и т.д ..) Я колебалась между 2 методами:

1. Возникли для каждого UserType столько кластеров, как количество стран, затем выберите цель для соответствующего кластера.

         _______________________ 
             | User (abstract class) | 
             |_______________________| 
               ^
                | 
                | 
   ___________________   ___________________   ___________________ 
   | UserType1 (class) |  | UserType2 (class) |  | UserType3 (class) | 
   |___________________|  |___________________|  |___________________| 
         |       |       | 
         |       |       | 
       US-Cluster_1    US-Cluster_2    US-Cluster_3 
       FR-Cluster_1    FR-Cluster_2    FR-Cluster_3 
       UK-Cluster_1    UK-Cluster_2    UK-Cluster_3 
   

2. Имея countryField для каждого UserType затем выбрать пользователей фильтрации с ним.

         _______________________ 
             | User (abstract class) | 
             |_______________________| 
               ^
                | 
                | 
   ___________________   ___________________   ___________________ 
   | UserType1 (class) |  | UserType2 (class) |  | UserType3 (class) | 
   |     |  |     |  |     | 
   | - countryField |  | - countryField |  | - countryField | 
   |___________________|  |___________________|  |___________________| 
   

   , а затем Select * from UserType1 where countryField = "US"

Что бы быть наиболее эффективным и логичным способом?

спасибо.

Answer 1

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

Вы действительно должны сгенерировать некоторые тестовые данные и сохранить их в обоих направлениях для проверки производительности запросов по сравнению с вашими требованиями. Нет 2 варианта использования.

Answer 2

Если количество записей будет расти миллионами внутри кластера, тогда у вас снова будут проблемы с извлечением записей внутри кластера, потому что согласно этому потоку [1] orient db не может использовать индексы, когда мы специально извлекаем записи из кластера.

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

Поэтому я предлагаю вам перейти ко второму подходу и эффективно использовать индексы или попытаться найти решение наследования на основе классов, как сообщается сообществу orient db в этой теме [1].

Ссылка [1] https://github.com/orientechnologies/orientdb/issues/4606