Rust-rocksdb: TxnDB : Transaktionen über rocksdb_transaction_t

Erstellt am 19. Okt. 2017  ·  7Kommentare  ·  Quelle: rust-rocksdb/rust-rocksdb

Die Transaktionsfunktionalität wird in rocksdb über eine parallele Implementierung von rocksdb_t namens rocksdb_transaction_t bereitgestellt. Jetzt, da wir bindgen (#143) haben, bekommen wir "kostenlos" Zugriff darauf.

Zunächst schlage ich der Kürze halber ein neues Akronym vor, das die RocksDB-Parallele zu CRUD ist, ich nenne es
PIGMED , das ist Put Iterate MErge Delete. Nicht eingängig, ich weiß.

Die Frage ist, wie man die Transaktionsfunktion am besten verfügbar macht, während:

  1. Nicht die gesamte DB impl für TxnDB duplizieren
  2. Aufrechterhaltung der Typsicherheit.

Es gibt einige neue Methoden für TxnDb, die gewickelt werden müssten, einige davon könnten als Guards oder sogar Closures sinnvoll sein.

Ich glaube nicht, dass es eine Möglichkeit gibt, die PIGMED-Operationen von DB und TxnDB zu vereinheitlichen und gleichzeitig die Typsicherheit oder sogar die Ergonomie beizubehalten. Aber es gibt nicht wirklich eine Menge PIGMED-Funktionalität in DB.

Ich schlage vor, dass wir die gesamte Utility-/Umgebungsfunktionalität, also alles, was kein rocksdb_t erfordert, in ein oder mehrere separate Utility-Module verschieben (z. B. rocksdb::cf::create für rocksdb_create_cf ).

Dann reduzieren wir die DB auf die PIGMED-Operationen.

Meine Hoffnung ist, dass wir in der Lage sein würden, die gleiche Iterator-Funktionalität zu nutzen. Es gibt ein rocksdb_transaction_create_iterator , aber das iterator_t ist dasselbe.

Die Gedanken?

enhancement

Hilfreichster Kommentar

@hnakamur reichte facebook/rocksdb#5077 ein, um die fehlenden APIs hinzuzufügen. Sobald sie in einer Version verfügbar sind, werde ich daran arbeiten, sie hier in der Rust-Bindung zu unterstützen.

Alle 7 Kommentare

Sieht so aus, als wäre das schon eine Weile da. Ich dachte nur, ich schaue mal kurz vorbei, um zu sehen, ob es dazu ein Update gibt? Aufgrund von Transaktionen halte ich mich davon ab, rocksdb für einige Rostdienste zu verwenden.

Ist dies durch #250 erfüllt?

Ich glaube schon. Freue mich schon auf die Fusion :)

Ich habe frühere Kommentare von @rrichardson noch einmal gelesen und denke, dass sich dieses Problem auf die „pessimistische“ Version von transaktionaler RocksDB bezieht, während Nr. 250 die „optimistische“ Version hinzufügt. Ich denke, wir sollten in der Lage sein, beide zu landen, indem wir einen Großteil der Arbeit in Nr. 250 nutzen.

Ich arbeite derzeit an einigen internen Umstrukturierungen in #268, die es einfacher machen werden, sowohl TransactionalDB als auch OptimisticTransactionalDB ohne viel Codeduplizierung zu implementieren.

Es gibt einige fehlende Methoden in der C-API, um TransactionalDB ungefähr äquivalent zu DB zu machen (siehe facebook/rocksdb#4999). Das muss gelöst werden, bevor wir diese Funktion landen können.

@hnakamur reichte facebook/rocksdb#5077 ein, um die fehlenden APIs hinzuzufügen. Sobald sie in einer Version verfügbar sind, werde ich daran arbeiten, sie hier in der Rust-Bindung zu unterstützen.

@iSynaptic
https://github.com/facebook/rocksdb/pull/5077 bereits zusammengeführt, und ich habe gesehen, dass das Update in der neuesten Release-Version erschienen ist.

Können Sie bitte die aktuelle PR erneut aufrufen?

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen