FAQs #

1. Would you be able to write IPLD Schemas and specs for the data structures you’re using? This would allow others to implement writers/readers for their data. #

Our current database underlying data storage engine implementation is divided into two categories:

• The first kind: build database synchronization technology based on RESP instructions and SQL statements, which can only grow and cannot be tampered with, and realize data synchronization and consistency guarantee between nodes based on decentralized instruction broadcasting and storage instruction playback.
• Type two: realize KV storage engine based on IPFS kv, and build rich nosql data structure by coding kv-value, so that the data of database can grow on ipfs completely, instead of relying on ipfs-log function.

At present, the first type of database is mainly implemented. We mainly use ipfs-log, an immutable and conflict-free replication data model for distributed systems. Based on ipfs-log, the kv engine is abstracted. Based on this kv engine, it is one of the storage drivers of IceFireDB. Other projects can rely on this kv engine to implement their own writers and readers, but we have not designed a proprietary IPLD data structure at present.

IceFireDB abstracts a data coding layer on the kv engine, which can support more complex data structures such as hash\list besides the basic KV operation. Currently, ipfs kv storage has been realized in the data storage directory of Icefire DB, and we hope that the data of the database can be fully grown on ipfs, but at present, we need to solve the need of kv key synchronization first. The expression of nosql and sql data relationship for ipfs kv is also conceiving the design of ipld, but it is not in the current major construction milestone. ipld is what we have been learning recently,If more complicated IPLD design is involved later, we will practice it in the process of learning.

2. How does the DB run? #

In this milestone, our implementation mode is the server running mode, which needs to run in a server somewhere. Our server will support Redis-RESP protocol and MYSQL communication protocol, and clients can use Golang, JS, PHP and other computer languages to connect.

There is also a framework way, which allows users to directly embed into the application code. This integration method is not in the current milestone, and we plan to concentrate on realizing it after this milestone.For example:redhub,IceFireDB-crdt-kv,ipfs-nosql-frame.These projects are open sourced by IceFireDB and are licensed under the Apache-2.0 open source license, and are mainly used to build ipfs-nosql-frame project, so that other Golang applications can be integrated more conveniently.

Compared with the framework mode, the server operation mode has the following advantages:

• Provide standard data protocols (RESP, MYSQL), which can make the application minimize changes and use decentralized database.
• Mask the complexity under IPFS, including libp2p, ipfs-log and crdt.

3. How will you address mutability of data? #

We know the immutability of IPFS itself, and now IceFireDB has two implementation models to solve the variability of data:

The first implementation: instruction broadcast model based on ipfs-log: Based on ipfs-log,crdt and libp2p(pubsub), an immutable and operation-based conflict-free replication data model for distributed systems is implemented. Based on ipfs-log, various data structures such as event and kv are encapsulated, and multi-node database instruction broadcast is implemented based on this engine;At that bottom of IceFireDB, we abstract the variable kv engine base on badgerdb and leveldb. any node will broadcast the whole network when it is writing instruction, and the bottom driver of IceFireDB of each node will execute the broadcast instruction to ensure the final consistency of data.

The second implementation: full storage model based on ipfs: In addition to the first implementation mode, we are also building the structure of the second type of data, so that the complete data will grow on ipfs. At first, there is an ipfs driver in the IceFireDB driver layer, which will encode and process the upper-level commands into a unified kv data structure, store and change the value, and the generated new cid will be connected with key. However, at present, there is no key broadcast network with multiple nodes and data synchronization. When we connect with the broadcast network, we can build a data model originally grown on ipfs.

4. What program languages are you targeting? #

Our program implementation is Golang.

We provide standard Redis-RESP and MYSQL communication protocols, so Redis and MYSQL clients of other computer programming languages can communicate with IceFireDB (JS, Rust)