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:
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?
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?
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.