Scaling¶
Running multiple instances of 3forge in the same host machine¶
Multiple 3forge instances can be run in the same host. Refer to this section for configuration details.
Running relay, center, web individually¶
The default installation runs all three components together in the same jvm. They can also be set to run individually. More details on configuration can be found here.
Connecting relay and web to multiple centers¶
Center can be scaled out to increase storage, processing power and add redundancy. By default, relay fans out the same data across all centers. Relay.routes should be configured if data distribution is conditional. The web will have access to tables from all centers where tables with the same names are unioned and rows can be distinguished by their center ids. When multiple centers are involved, one needs to be set as the primary center. See the last two sections for configuration details.
Connecting multiple web to a center¶
Scaling out the web is a crucial step as the user base grows. If a dashboard has lots of datamodels doing computatations and table transformations (aggregations, joins, copying tables etc.), the web memory will increase noticeably as more users interact with it. For multiple webs to connect to a single center, each web needs to know the host and port of the center.
Load balancing between multiple webs with webbalancer¶
Web balancer automatically distributes user traffic across multiple webs and ensures resiliencey by routing users to a different web instance in case one goes down. Webbalancer requires intructions on how to distribute user traffic. Routing rules are defined inside webbalancer.routes file. See here for more details
Serving layouts/preferences from Web Manager: A centralized file server.¶
By default, each web will store its own dashboards, and other user related files such as preferences, settings. However, those information cannot be retrieved if a user gets rerouted to another web instance by the webbalancer. Webmanager solves this by storing these information centrally and serving the web instances on demand. To configure webmanager, each web instance should know the host and port. See here for more details.
Putting it altogether¶
Master slave setup with Replication for faster reads¶
3forge applies a database level lock for realtime tables and table level lock for HDB tables during write operation. In most cases, there is no interruption reading from those tables since the writes are done in batches. To ensure non-interrupted and faster reads, master slave architecture can be setup using replication such that the source center is only processing writes and replicated center is serving reads.
Manage throttling with Replication¶
Replication is also used to control throttling. The source table can be setup to broadcast data at a slower rate to the target table. Broadcast rate can be configured by the RefreshPreiodMs option. For example, if RefreshPreiodMs is set to 500 milliseconds and a row in the source table gets updated 100 times between the last and next broadcast, only one update will be pushed to the target table on the next broadcast.
Sharding and Map Reduce¶
Sharding and Map reduce can be achieved in 3forge with just a few steps. The relay should be configured to send messages to multiple centers based on the sharding key defined in relay.routes file. Each center can then perform their aggregations locally and replicate the results to a downstream center, reflecting a global aggregated view.
Archiving directly to HDB¶
Data can streamed directly into HDB as opposed to archiving from realtime to hdb. The relay needs to be configured to route messages both into realtime and hdb tables.