Коллокация: первое правило распределенного программирования

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

В моемВ предыдущем сообщении в блоге я показал, как размещать вычисления и данные, используя прямой API с помощью метода GridCache.mapKeyToNode (..) . Мы также добавили аналогичные методы в Grid API, чтобы обеспечить возможность обнаружения сходства данных на узлах, которые сами не кэшируют никаких данных. В нашем последнем выпуске 3.0.4 мы также добавили очень удобный способ обеспечения совместного размещения с помощью аннотации @GridCacheAffinityMapped .

Скажем, у вас есть 2 типа объектов: человек и компания . Несколько человек могут работать в одной компании. Это означает, что вы обычно можете получить доступ к объектам Person вместе с Компанией.на что они работают. Чтобы сделать это масштабируемым образом, вы можете убедиться, что все люди, работающие в одной компании, кэшируются на одном узле. Таким образом, вы можете отправлять вычисления на этот узел и получать доступ к нескольким людям из одной компании на местном уровне. Вот как это можно сделать в GridGain.

    public class PersonKey {  
      // Person ID used to identify a person.  
      private String personId;  
      
      // Company ID which will be used for data affinity.  
      @GridCacheAffinityMapped  
      private String companyId;  
      ...  
   }  
   ...  
   // Instantiate person keys with same company ID.  
   Object personKey1 = new PersonKey("myPersonId1", "myCompanyId");  
   Object personKey2 = new PersonKey("myPersonId2", "myCompanyId");  
     
   // Both, the company and the person objects will be cached on the same node.  
   cache.put("myCompanyId", new Company(..));  
   cache.put(personKey1, new Person(..));  
   cache.put(personKey2, new Person(..));  

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

G.grid().run(GridClosureCallMode.BALANCE, new Runnable() {
  // This annotation specifies that computation should be routed
  // precisely to the node where all objects with affinity key
  // of 'myCompanyId' are cached.
  @GridCacheAffinityMapped
  private String companyId = "myCompanyId";

  @Override public void run() {
      // Some computation logic here.
      ...
  }
};

Теперь, когда вы правильно разместите все свои данные в своей сетке данных, а затем направите свои вычисления на узлы, где ваши данные кэшируются, все операции кэширования станут
ЛОКАЛЬНЫМИ , что обеспечит лучшую производительность и масштабируемость без какого-либо
шума данных . В некотором смысле это соответствует
первому правилу распределенного программирования , которое
НЕ РАСПРОСТРАНЯЕТСЯ .

От http://gridgain.blogspot.com/2011/01/collocation-first-rule-of-distributed.html