Choosing a shard key in InterSystems IRIS for long-term scalability involves the following best practices:
-
Default System-Assigned Shard Key (SASK): Using the RowID as the shard key usually guarantees an even distribution of data and supports efficient parallel data loading and query processing. This approach is often the best for workloads where queries are randomly distributed across the dataset [1][2].
-
Cosharded Joins: If your application performs frequent joins between large tables, using shard keys that enable cosharded joins is critical. Tables that share the same shard key allow local joins within each shard, improving query performance significantly. Equivalent user-defined shard keys (UDSKs) or the use of the
COSHARD WITHkeyword can ensure this optimization [1][3][2]. -
Unique Constraints: Ensure that unique constraints on sharded tables include the shard key as part of the unique key. Unique constraints that span across shards can severely impact performance [1].
-
Consider Query Patterns: Analyze queries to ensure shard keys align with frequent filter conditions, joins, and group-by operations. This will reduce cross-shard data movement and improve efficiency [1][3].
-
Avoid Sharding Complex Transaction Tables: Tables involved in complex atomic transactions should not be sharded because sharding complicates ensuring atomicity [1].
-
Flexible Schema Design: Plan for scalability by co-sharding related tables or combining sharding with vertical scaling as necessary. InterSystems IRIS also supports hybrid arrangements where application servers work with data shards for distributed computing [4][2].
By adhering to these practices, you reduce the likelihood of encountering performance bottlenecks and avoid requiring major refactoring as your database scales. [1][2]
Sources:
The InitialExpression keyword works for setting initial values during object instantiation via %New() in certain types of classes, such as %Persistent, %RegisteredObject, etc., but this behavior does not apply consistently to %CSP.Page or its subclasses. %CSP.Page utilizes specific mechanisms for customization and instantiation, which differ from standard object creation through %New() [1][2][3].
Key points to consider:
1. Initialization Mechanism: %CSP.Page class is designed for web-based processing, with lifecycle methods like OnPage(), OnPreHTTP(), and OnPostHTTP() controlling request and response handling rather than relying on object instantiation semantics from %New() [3][2].
-
Property Initialization: For most applications, properties in
%CSP.Pageare set during request handling or by explicitly overriding lifecycle methods. Using parameters or configuration settings might be more effective to achieve default values during response construction [3][5]. -
Alternative Callbacks for Initialization: Override lifecycle methods like
OnPreHTTP()orOnPage()within your subclass of%CSP.Pageto implement default value assignments or initialization logic explicitly [2].
For further details regarding limitations or behaviors specific to %CSP.Page, you can consult its related documentation on callbacks, lifecycle management, and property interactions [2][5][6].
Sources:
Yes, it is possible to send different request classes to the same BPL. You can define a BPL process and set its "Request Class" property in the "Context" tab of the BPL designer. This allows the BPL to handle incoming requests of different types as long as they adhere to the defined structure and logic within the process. You can also use context properties or logic within the BPL to handle variations based on the actual type of the request received [1][2].
Sources: