Cassandra: Kundendaten pro Schlüsselbereich

Question

Problem: Einer unserer neuen Kunden möchte, dass die Daten in seinem eigenen Land gespeichert werden (gesetzliche Bestimmungen). Wir verwenden jedoch Daten von bestehenden Kunden, die auf wenige Rechenzentren in verschiedenen Ländern verteilt sind.

Frage: Wie können wir neue Kundendaten trennen, um in ihrem eigenen Land zu wohnen, ohne die bestehende Cassandra-Architektur zu verändern?

Mögliche Lösung # 1: separaten Schlüsselbereich für diesen Kunden verwenden. Schemata sind zwischen den Schlüsselbereichen identisch, was die Komplexität der Datenmigration erhöht und so weiter. Die DataStax-Unterstützung hat bestätigt, dass es möglich ist, den Schlüsselbereich pro Region zu konfigurieren. Spring Data Cassandra, die wir verwenden, erlaubt es jedoch nicht, den Schlüsselraum dynamisch zu wählen. Die einzige Möglichkeit ist, CqlTemplate zu verwenden und use keyspace blabla jedes Mal vor dem Anruf oder um Schlüsselbereich vor der Tabelle select * from blabla.mytable hinzufügen, aber es klingt wie ein Hack für mich.

Mögliche Lösung # 2 separate Umgebung für neue Client verwenden, aber das Management lehnt es ab.

Andere Möglichkeiten, dieses Ziel zu erreichen?

Answer 1

Update 3

Beispiel und unter Erklärung ist die gleiche wie in GitHub

Update 2

Das Beispiel in GitHub arbeitet nun. Die zukunftssicherste Lösung schien die Verwendung von Repository-Erweiterungen zu sein. Wird das folgende Beispiel bald aktualisieren.

aktualisieren

Beachten Sie, dass die Lösung, die ich ursprünglich hatte einige Mängel geschrieben, die ich während JMeter Tests entdeckt. Die Datastax-Java-Treiberreferenz rät, das Festlegen des Schlüsselbereichs durch Session Objekt zu vermeiden. Sie müssen den Schlüsselbereich in jeder Abfrage explizit festlegen.

Ich habe das GitHub-Repository aktualisiert und auch die Beschreibung der Lösung geändert.

sehr vorsichtig sein, aber: wenn die Sitzung von mehreren Threads gemeinsam genutzt wird, den Schlüsselraum zur Laufzeit Schalt leicht unerwartete Abfrage Fehler verursachen könnten.

Im Allgemeinen wird empfohlen, eine einzelne Sitzung ohne Schlüsselbereich zu verwenden und alle Ihre Abfragen mit einem Präfix zu versehen.

Lösung Beschreibung

Ich würde einen separaten Schlüsselraum für diesen speziellen Kunden Set-up und Unterstützung Schlüsselraum bei der Anwendung zu ändern. Wir haben diesen Ansatz zuvor mit RDBMS und JPA in der Produktion verwendet. Also würde ich sagen, dass es auch mit Cassandra funktionieren kann. Lösung war ähnlich wie unten.

Ich werde kurz beschreiben, wie Sie Spring Data Cassandra vorbereiten und einrichten, um den Ziel-Keypace bei jeder Anfrage zu konfigurieren.

Schritt 1: Vorbereiten der Dienste

definiere ich würde zunächst, wie die Mieter ID auf jede Anfrage zu setzen. Ein gutes Beispiel wäre in-case-of seinen REST API ist einen bestimmten HTTP-Header zu verwenden, die es definiert:

Tenant-Id: ACME 

Ebenso auf jedem Remote-Protokoll Sie Mieter ID bei jeder Nachricht weiterleiten können. Angenommen, Sie verwenden AMQP oder JMS, können Sie diese interne Nachrichtenkopfzeile oder Eigenschaften weiterleiten.

Schritt 2: Erste Mieter ID in Anwendung

Als nächstes sollten Sie den eingehenden Header gespeichert auf jede Anforderung in Ihrem Controller. Sie können ThreadLocal verwenden oder Sie können versuchen, eine beanspruchte Bean zu verwenden.

@Component 
@Scope(scopeName = "request", proxyMode= ScopedProxyMode.TARGET_CLASS) 
public class TenantId { 

    private String tenantId; 

    public void set(String id) { 
     this.tenantId = id; 
    } 

    public String get() { 
     return tenantId; 
    } 
} 

---

@RestController 
public class UserController { 

    @Autowired 
    private UserRepository userRepo; 
    @Autowired 
    private TenantId tenantId; 

    @RequestMapping(value = "/userByName") 
    public ResponseEntity<String> getUserByUsername(
      @RequestHeader("Tenant-ID") String tenantId, 
      @RequestParam String username) { 
     // Setting the tenant ID 
     this.tenantId.set(tenantId); 
     // Finding user 
     User user = userRepo.findOne(username); 
     return new ResponseEntity<>(user.getUsername(), HttpStatus.OK); 
    } 
} 

Schritt 3: Einstellen Mieter ID in Datenzugriffsschicht

Schließlich sollten Sie Repository Implementierungen erweitern und Set-up Schlüsselraum entsprechend der Mieter ID

public class KeyspaceAwareCassandraRepository<T, ID extends Serializable> 
     extends SimpleCassandraRepository<T, ID> { 

    private final CassandraEntityInformation<T, ID> metadata; 
    private final CassandraOperations operations; 

    @Autowired 
    private TenantId tenantId; 

    public KeyspaceAwareCassandraRepository(
      CassandraEntityInformation<T, ID> metadata, 
      CassandraOperations operations) { 
     super(metadata, operations); 
     this.metadata = metadata; 
     this.operations = operations; 
    } 

    private void injectDependencies() { 
     SpringBeanAutowiringSupport 
       .processInjectionBasedOnServletContext(this, 
       getServletContext()); 
    } 

    private ServletContext getServletContext() { 
     return ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()) 
       .getRequest().getServletContext(); 
    } 

    @Override 
    public T findOne(ID id) { 
     injectDependencies(); 
     CqlIdentifier primaryKey = operations.getConverter() 
       .getMappingContext() 
       .getPersistentEntity(metadata.getJavaType()) 
       .getIdProperty().getColumnName(); 

     Select select = QueryBuilder.select().all() 
       .from(tenantId.get(), 
         metadata.getTableName().toCql()) 
       .where(QueryBuilder.eq(primaryKey.toString(), id)) 
       .limit(1); 

     return operations.selectOne(select, metadata.getJavaType()); 
    } 

    // All other overrides should be similar 
} 

---

@SpringBootApplication 
@EnableCassandraRepositories(repositoryBaseClass = KeyspaceAwareCassandraRepository.class) 
public class DemoApplication { 
... 
} 

Lassen Sie mich wissen, wenn es Probleme mit dem obigen Code gibt.

Beispielcode in GitHub

https://github.com/gitaroktato/spring-boot-cassandra-multitenant-example

Referenzen

• Example: Using JPA interceptors
• Spring @RequestHeader example
• Spring request-scoped beans
• Datastax Java Driver Reference

Answer 2

Hinweis mit 2 Schlüsselräumen ist korrekt. Wenn Frage nur zwei Schlüsselbereiche hat, warum nicht 2 Schlüsselräume konfigurieren. für Regionsabhängiger Client - Schreiben Sie in beide
für andere - Schreiben Sie nur in einen (Haupt-) Schlüsselbereich. Es ist keine Datenmigration erforderlich. Hier ist Probe, wie Spring Repositorys konfigurieren verschiedene keyspaces treffen: http://valchkou.com/spring-boot-cassandra.html#multikeyspace

die Wahl des Repository kann einfach sein, wenn sonst

if (org in (1,2,3)) { 
    repoA.save(entity) 
    repoB.save(entity) 
} else { 
    repoA.save(entity) 
} 

Answer 3

Nach vielen hin und her, haben wir beschlossen, nicht die Dynamik zu tun Schlüsselraumauflösung innerhalb derselben JVM.

Es wurde die Entscheidung getroffen, dedizierten Jetty/Tomcat pro Schlüsselbereich und auf Nginx-Router-Ebene zu definieren, auf welchen Server die Anfrage umgeleitet werden sollte (basierend auf CompanyId von der Anfrage-URL).

Zum Beispiel haben alle unsere Endpunkte /companyId/<value>, also können wir basierend auf dem Wert die Anfrage an den richtigen Server umleiten, der den richtigen Schlüsselraum verwendet.