Chapter 13. Performance Tuning

• Study the documentation, particularly the Getting Started Guide, to find out what data federation can do for your enterprise.
• Use a standard naming convention for JNDI Data Source names to enable VDBs to be portable across EAP/DV server environments because the JNDI references defined in the VDB do not have to be changed as its being ported from server to server.

  Note

  You can reset the JNDI name by using the AdminConsole, without having to modify the VDB.
  b) For consistency, decide on naming conventions so that it does not lead to confusion of the different types. Items to consider include Designer project names, source model names, new model names, function/procedures names, data sources, VDB names, and web service names.
• Standardize on a common JDBC driver version across server instances. That is, if the source is MySQL, all servers should use the same MySQL JDBC driver JAR.
  It is preferable to use JDBC type 4 drivers, if you can, for ease of deployment and when doing data previews in Teiid Designer. Otherwise, you can manually change the driver to type 4 or configure the module on the server for the driver, prior to use.
• Include UDF jars with your VDB when packaging it in Teiid Designer as this makes it easier to deploy and does not require you to undertake server module configuration.
• Use VDB Versioning of the format vdbname.version.vdb. If you do so VDB updates can be deployed without impacting current processing. It will also be easier for you to visually identify what version of the VDB is utilizing, without having to open it up.
• Pick a suitable deployment strategy:
  • JBoss Operations Network – good for pushing a VDB to a cluster of Teiid instances all at once.
  • Admin shell – a command line tool which can be useful for scripting and automating task, and incorporating into other tools (see example: DeployAndVerifyVDB.groovy in the DV kit)
  • Admin-console can be used to deploy the VDB
  • Teiid Designer can deploy the VDB, but Red Hat recommends that you do not use it beyond the development phase
  • Manual copying of artifacts - you are likely to do this only during upgrades or as a means for promoting through your development life cycle.
• With regard to the software development lifecycle, consider the following VDB connection type changes during the deployment life cycle:
  • When a VDB is deployed, use connection type default of BY_VERSION
  • When the VDB is to be updated on the server with a new version change the current VDB (if exist) connection type from ANY to NONE (to stop allowing connections), so new connections will go to new version and now change the newly deployed VDB connection type from BY_VERSION to ANY, making it the target VDB to be connected to, and positioning it for the next time a new version is to be deployed.
  • If rollback is required, change the new (bad) VDB connection type from ANY to NONE and change old VB connection type from NONE to ANY
• When you are in a multi-developer environment, use an SCM (such as github, SVN, or CVS) to manage your artifacts. Red Hat does not recommend any particular source control management system, but does advise you to use one that integrates with JBoss Developer Studio
• Consider using the VDB reuse feature with DV 6 via import-vdb. This allows VDBs to import other VDBs at deploy/startup time. This allows a bigger project to be broken out into separate VDBs that work together at runtime. This will allow developers to work on different VDB's that reference the same underlying models. By partitioning and layering, it can limit the impact of deployment changes.
• Decide on a VDB / Model design pattern.
  a) A general design approach is based on building a Data Virtualization Abstraction layer (also referred to as Enterprise or Federated Data Layer) The Abstraction Layer is what client applications use. Its referred to as the abstraction layer because the underlying data sources are abstracted away from client use. A recommended approach to building the abstraction layer is to start by creating a Virtual Base Layer (VBL) between the 'Data Source Layer' and the 'Abstraction Layer'. This decouples the physical data from the canonical business model, allowing flexibility to change the data layer without affecting the client and providing a level of isolation on top of the physical sources. This is a one-to-one mapping of each physical source to a virtual model. These VBL components can then be used as building blocks for higher level services; all of the transformations built on top of them will not need to be changed should the need arise to accommodate a change in the source(s)
  b) In laying out your design pattern, consider using VDB reuse (multiple VDBs) such as VDBs at the abstraction layer and VDBs at the physical layer

Performance Tips

• Consider your naming conventions. The naming convention you use can reduce the size of messages.
• Remember to undeploy any unused old VDBs.

JBDS Teiid Plug-In Tips

• When you are developing in a collaborative environment, developers need to use the same project names. There can be multiple projects (for example, by application) and there can be sharing of models across projects when creating a VDB. However, in the designer, the references from a VDB to a model includes the project name, so using a different project name will result in the VDB's models not being resolved correctly.
  Establish a standard naming convention and configuration for Connection Profiles across eclipse/JBDS environments Otherwise, when a model is imported and the connection profile does not match, the connection profile will need to be reset for the source model before data previewing or VDB deployment can be done.
• When modelling, and you go to build a View model, create children of type "Base Table". Do not use "View Table". There is no functional difference. The problem comes in later when you want to create PK/FK/Indexes on the table. The "View Table" does not allow you to do this.
  (a) If you are going to be doing updates, it is recommended to use XA data sources. Therefore, do not use Designer to create the data sources. This is due to a limitation in DTP, which will create a 'local' data source, not an XA data source. To create XA data source, look in JBoss AS "doc" directory for example templates, or use the "admin-console" to create the XA data sources

Tips for Custom Translators and Connectors

• Use the Teiid translator and/or connector archetypes.
  When used, they will create the project template, with resources, to immediately begin adding your custom code and compiling to package for deployment.
  Using JBDS, create a new Maven project by creating the project from the archetype. In the wizard, select the “JBoss Nexus Archetypes” catalog, and filter on “teiid”.