Chapter 2. Design Choices
Once the main components of the architecture have been decided, choices must be made on the overall design.
2.1. Dashboards
User dashboards may be very costly in a large-scale portal due to the information storage considerations for each user creating a customized page. While some measures have been taken to ameliorate this cost, it, by nature, cannot be avoided completely and should be taken into account when making design decisions in large organizations.
This overhead is difficult to estimate as it is dependent on how users navigate the portal. If only a minority use this functionality; the cost may be negligible. Alternately, the cost could be considerable if many users create custom spaces.
The impact of implementing this feature must be measured by:
- Estimating the number of dashboards and pages that will be created.
- Observing the impact on the database (through the JCR) in terms of size.
2.2. JCR Index Replication in a Cluster Setup
2.2.1. JCR Index Replication in a Cluster Setup
The JCR implementation uses Apache Lucene to index the data. The indexes are used to search for content (page nodes or WCM content for instance).
Lucene is not cluster-ready, but on a cluster, each node must be able to search for content and will need to have access to the Lucene indexes.
When optimizing searching, a balance must be struck between various goals, including:
- Speed.
- Fast indexing.
- Consistent results on a node.
- Data accuracy and longevity.
- Impact on system performance.
- Ease and impact of implementation.
However eXo JCR, the JCR implementation used by Red Hat JBoss Portal, makes it possible to configure the storage and retrieval of indexes according to the architect's decisions on constraint stringency.
See Also:
2.2.2. Standalone Index
Standalone Index is only suitable for a non-cluster environment but is the least complicated configuration, with a combination of in-memory and file based indexes. There is no replication involved so any entry can be found by a search as soon as it is created.
2.2.3. Local Index
In Local Index setup each node keeps a local copy of the full indexes so that when a search is requested on a node, there is no network communication required. However, the cost of this method is replication; when a node indexes an item, it is required to replicate that index on each node. If a node is unavailable at that time, it may miss an index update request and then the different nodes may be inconsistent.
Also when a node is added, it has to recreate its own full index.
An alternative to this configuration is to configure a node to retrieve the information from a coordinator on each search, which makes the startup of the new node faster, but impacts its performance during operation.
2.2.4. Shared Index
In this setup a unique index is created and shared among all the nodes. The Network File System (NFS) must be installed so that all nodes can read the index.
Advantages:
- Consistency: all the nodes see the same data.
Disadvantages:
- Requires a highly available NFS setup (NFS 3 is recommended).
- Increased network communication.
