The Ditto platform is a fully distributed database that runs in the cloud and on local devices. Each Ditto instance is a called a peer. There are two types of peers in the Ditto distributed database system: Big Peer and Small Peer. When you install Ditto in a client device like a web, desktop, mobile, or IoT application, you are installing a Small Peer. Running on the cloud is a Big Peer.
Big Peers and Small Peers can sync with eachother with a common appID. To get an appID, create an app on our portal.
- Big Peers will try to sync everything from the Small Peers. If a small peer adds, removes, or updates data, the big peer will be notified of these changes. We call this an altruistic replication strategy.
- The Big Peer is capable of storing a tremendous amount of data is capable of of sharding and partitioning. While it still looks like any peer, underneath the hood, it is capable of scaling to meet the demands of large amount of data. Read more about it's internal architecture here.
- To get data in or out of the Big Peer, you can use a Small Peer or the HTTP API, or using our Server Side Webhooks.
- Generally, a Small Peer is embedded in a web, mobile, desktop, or IoT application. We distribute the Small Peer as an SDK with several language bindings.
- Small peers will only sync data down from nearby Small Peers or Big Peers when it has a live query. We call this a selfish replication strategy. Small peers can stop syncing by disposing or stopping a live query.
- Small peers are not not capable of sharding or partitioning. It will use whatever storage size the device allows but not any more. When you buy a mobile phone with 256 GB of storage, you're stuck until you buy a new one.
- Small peers are capable of using device peer to peer communication tactics like Bluetooth Low Energy, Wi-Fi Direct, AWDL, Wi-Fi Aware, Local Area Network, and more to transmit data.