区块链可以存储在SQL甚至noSQL数据库中吗?

问题描述

我已阅读:

所以我的问题是我们可以在例如sql中存储区块链吗?还是只能将其存储在可单独运行的数据库中?

So my question is can we store blockchain in for example sql? or it can only be stored in a database that works on its own?

推荐答案

当前去中心化的区块链应用程序几乎没有存储数据的选项.分散存储选项包括:

Currently decentralized blockchain applications have few options to store data. Decentralized storage options are:

• 将所有内容存储在区块链本身中
• 对等文件系统，例如IPFS分散的云文件存储，例如Storj，Sia，以太坊群等.
• 分布式数据库，例如Apache Cassandra，重新思考数据库等.
• BigChainDB
• 领带数据库

• Storing everything in blockchain itself
• Peer to peer file system, such as IPFS Decentralized cloud file storages, such as Storj, Sia, Ethereum Swarm, etc.
• Distributed Databases, such as Apache Cassandra,Rethink DB, etc.
• BigChainDB
• Ties DB

让我们详细考虑它们:

1. 将所有内容存储在区块链本身中:将所有内容存储在区块链中是最简单的解决方案.当前，大多数简单的分散式应用程序正是以这种方式工作的.但是，这种方法具有明显的缺点.首先，到区块链的交易确认缓慢.资金转帐似乎很快(任何人都可以等待一分钟)，但是对于丰富的应用程序数据流来说却非常慢.丰富的应用程序每秒可能需要成千上万的事务.其次，它是不可变的.不变性是区块链的优势，使其具有很高的鲁棒性，但对于数据存储而言却是一个弱点.用户可以更改其个人资料或替换其照片，但之前的所有数据仍将永远位于区块链中，任何人都可以看到.不变性导致了另一个缺点-容量.如果所有应用程序将其数据保存在区块链中，那么区块链的规模将迅速增长，超过公共可用的硬盘容量.完整的节点可能需要特殊的硬件.这可能会导致危险的区块链集中化.这就是为什么对于丰富的分散式应用程序而言，仅将数据存储在区块链中不是一个好选择.
2. 对等文件系统，例如行星际文件系统. IPFS允许在客户端计算机上共享文件，并将它们合并到全局文件系统中.该技术基于BitTorrent协议和分布式哈希表.有几个好时机.它确实是点对点的-共享任何东西，首先将其放在您自己的计算机上.仅在任何人需要时才下载.它是内容可寻址的，因此不可能用给定的地址伪造内容.借助BitTorrent协议，可以非常快速地下载流行文件.但是它也有一些缺点.如果要共享文件，则应保持在线状态.至少在有人感兴趣并想要从您那里下载它们之前.它仅提供静态文件，上传后将无法对其进行修改或删除.当然，您不能通过它们的有意义的内容来搜索这些文件.
3. 去中心化云文件存储:也存在去中心化云文件存储，这些存储消除了IPFS的某些限制.从用户的角度来看，这些存储只是像Dropbox这样的云存储.区别在于，内容托管在提供硬盘空间供出租的用户计算机上，而不是数据中心中.如今有很多这样的项目.例如，Sia，Storj，Ethereum Swarm.您无需保持在线状态即可共享文件.只需上传文件，它就可以在云中使用.这些存储非常可靠，足够快，并且具有巨大的容量.它们仍然只提供静态文件，无论如何都不会搜索内容，而且由于它们是在租用的硬件上构建的，因此它们不是免费的.
4. 分布式数据库:由于我们需要存储结构化数据并寻求高级查询功能，因此我们可以查看分布式noSql数据库.为什么要使用NoSql?由于CAP定理的限制，不能真正地分发严格的事务处理SQL数据库.为了使数据库分布式，我们必须牺牲一致性或可用性. NoSQL数据库选择可用性而不是一致性，而用所谓的最终一致性"代替它，即网络中所有数据库节点在一段时间后变得一致.此类数据库有许多成熟的实现，例如MongoDB，Apache Cassandra，RethinkDB等.它们非常好-快速，可伸缩，容错，支持丰富的查询语言，但对于我们的应用程序仍然存在致命的缺点.它们不是拜占庭式的.集群中的所有节点都完全相互信任.因此，任何恶意节点都可能破坏整个数据库.
5. BigChainDB :还有另一个名为BigChainDB的项目，声称可以解决数据存储和事务处理速度问题.它也是一个区块链，但具有巨大的数据容量和非常快的交易.让我们看看这是怎么可能的. BigChainDB基于RethinkDB集群构建，我在上一张幻灯片中提到了此NoSQL数据库. BigChainDB使用它来存储所有块和事务.这就是为什么它显示出如此高的吞吐量的原因-它是底层的noSQL数据库之一.所有BigChainDB节点(在幻灯片上用BDB表示)都已连接到集群，并且具有对数据库的完全写访问权限.问题来了-整个BigChainDB都不是拜占庭式的！任何恶意的BDB节点都可以破坏RethinkDB集群. BigChainDB团队已经意识到了这一问题，并承诺会在未来某个时候解决这个问题，但这是架构的基石，并且可能无法对其进行更改.无论如何，BigChainDB可能对私有区块链非常有用.但我认为，为避免混淆，应将其命名为BigPrivateBlockchain.这不是公共存储的选项.
6. 关系数据库:当前可用的选项可以是一个很好的公共数据库.最接近理想的是noSql数据库.他们唯一缺少的是拜占庭式的容错能力. Ties.Network数据库:ties.network是对Cassandra数据库的深层修改，并提供了一种更好的解决方案:TiesDB继承了来自底层noSQL数据库的大部分功能，并增加了拜占庭式的容错性和激励机制.凭借这些功能，它可以成为公共数据库，并通过智能合约在以太坊和其他区块链上启用功能丰富的应用程序.该数据库可由任何用户写入.但是，用户通过其公钥进行标识，并且所有请求均已签名.创建后，记录会记住其创建者，该创建者成为记录的所有者.此后，记录只能由所有者修改.每个人都可以读取所有记录，因为数据库是公共的.根据请求和复制检查所有权限.可以通过智能合约来管理其他权限.

1. Storing everything in blockchain itself: Storing everything in blockchain is the simplest solution. Currently most of the simple decentralized applications work exactly this way. However, this approach has significant drawbacks. First of all transactions to blockchain are slow to confirm. It may seem to be fast for money transfer (anyone can wait a minute), but it is extremely slow for a rich application data flow. Rich application may require many thousands transactions per second. Secondly, it is immutable. The immutability is the strength of blockchain that gives it high robustness but it is a weakness for a data storage. User may change their profile or replace their photo, still all the previous data will sit in blockchain forever and can be seen by anyone. The immutability results in one more drawback - the capacity. If all the applications would keep their data in blockchain, the blockchain size will grow rapidly, exceeding publicly available hard drive capacity. Full nodes can require special hardware. It may result in dangerous centralization of blockchain. That’s why storing data in blockchain only is not a good option for a rich decentralized application.
2. Peer to peer file system, such as InterPlanetary File System. IPFS allows to share files on client computers and unites them in the global file system. The technology is based on BitTorrent protocol and Distributed Hash Table. There are several good moments. It is really peer to peer - to share anything first put it on your own computer. It will be downloaded only if anyone needs it. It is content addressable, so it is impossible to forge content by the given address. Popular files can be downloaded very quickly thanks to BitTorrent protocol. However it also has some drawbacks. You should stay online if you want to share your files. At least before someone becomes interested and wants to download them from you. It serves only static files, they can not be modified or removed once uploaded. And of course you can not search these files by their meaningful content.
3. Decentralized cloud file storages: There are also decentralized cloud file storages that lift some of IPFS limitations. From the user’s point of view these storages are just cloud storages like Dropbox, for example. The difference is that the content is hosted on user’s computers who offer their hard drive space for rent, rather than in datacenters. There are plenty of such projects nowadays. For example, Sia, Storj, Ethereum Swarm. You don’t need to stay online to share your files anymore. Just upload the file and it is available in the cloud. These storages are highly reliable, fast enough, have enormous capacity. Still they serve static files only, no content search anyway and, since they are built on the rented hardware, they are not free.
4. Distributed Databases: Since we need to store structured data and seek for advanced query capabilities we may look at the distributed noSql databases. Why noSql? Because strict transactional SQL databases can not be truly distributed due to the restrictions of the CAP-theorem. To make a database distributed we must sacrifice either consistency or availability. NoSQL databases choose availability over consistency replacing it with so called "eventual consistency" where all the database nodes in the network become consistent some time later. There are many mature realizations of such databases, for example MongoDB, Apache Cassandra, RethinkDB and so on. They are very good - fast, scalable, fault tolerant, support rich query language but still have fatal drawback for our application. They are not Byzantine-proof. All the nodes of the cluster fully trust each other. So any malicious node can destroy the whole database.
5. BigChainDB: There is another project called BigChainDB that claims to solve the data storage and transaction speed problem. It is also a blockchain but with enormous data capacity and really fast transactions. Let us see how it is possible. BigChainDB is build upon RethinkDB cluster, I mentioned this NoSQL database on the previous slide. BigChainDB uses it to store all the blocks and transactions. That is why it shows such a high throughput - it is the one of the underlying noSQL database. All the BigChainDB nodes (denoted BDB on the slide) are connected to the cluster and have full write access to the database. Here comes a problem - the whole BigChainDB is not byzantine-proof! Any malicious BDB node can destroy the RethinkDB cluster. The BigChainDB team is aware of this problem and promises to solve it sometime in the future, however it is the corner stone of the architecture and changing it may not be possible.Anyway, BigChainDB may be good for a private blockchain. But in my opinion, to avoid confusion it should have been named BigPrivateBlockchain. It is not an option for a public storage.
6. Ties DB: The currently available options could be a good public database. The closest to the ideal are the noSql databases. The only thing they lack is byzantine fault tolerance. The Ties.Network Database: ties.network is a deep modification of the Cassandra database and offers a preferable solution: The TiesDB inherits the majority of features from the underlying noSQL databases and adds byzantine fault tolerance and incentives. With these features it can become a public database and enable feature-rich applications on Ethereum and other blockchains with smart contracts. The database is writable by any user. But the users are identified by their public key and all the requests are signed. Once created, record remembers its creator who becomes an owner of the record. After that the record can be modified only by the owner. Everyone can read all records, because the database is public. All the permissions are checked on request and replication. Additional permissions can be managed via a smart contract.

来源:此处

这篇关于区块链可以存储在SQL甚至noSQL数据库中吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！