Teiid Review - Production quality, designer learning, support, maintenance

[mananpat]

Hello,

I have been playing with Teiid, (gone through few examples but none worked without much pain),  and various integrated components (Teiid Designer/Teiid/Jboos-cxf/Jboos-AS) recently to evaluate this product to apply in our team. I would like to touch upon some basics about it and invite some feedbacks from the community.

Hence, I have some common questions for those experienced users:

1. Production Quality- Is Teiid suitable for large scale application and data volume?

2. Caching Layer - Does it work well and easily to cache data as expected? 

3. Intregity & reliability of Teiid Designer - since most of the work is in the Teiid Designer- is it stable and handles all the ongoing devleopment/addition/refactoring well? does it have any issues?

4. Learning Curve of the Designer - subjective question and really depends on the existing staff -

5. ongoing changes and maintenance - is it easy to change VDB and models - does designer cooperate/is the deployment smooth? does it mess up other deployed VDB?

6. Does Teiid work on Tomcat? Any one tried?

7. What is the ideal development structure? sholud one put all the phaysical/relation views in the one project and put all the exposed VDB in other for ease of maintainance, etc and reference each? Should all the releated components be kept in one project?  We have many underlying source connected to many final data reports/VDB so just curious to know?

Any help/comment would be appreciated.

[shawkins]

Manan,

I'll touch on most of this, but it seems like that you may want to go beyond the community for more of a product level overview.  You can contact Redhat middleware sales to get more information on support, training, and professional services.

1. Yes, the engine is geared toward efficient and memory-safe processing against even very large data sets.

2. Yes, see the Caching Guide (https://docs.jboss.org/author/display/TEIID/Caching+Guide for the latest) to understand more about what is offered.

3. Designer is not required to use Teiid, but is typically used.  You can check the Designer JIRA for any specific issues - https://issues.jboss.org/browse/TEIIDDES

5. Each VDB artifact is indepedent of other VDBs.

6. The embedded Teiid engine will run in any standard 1.6+ JRE - see https://issues.jboss.org/browse/TEIID-2062.  The full Teiid server requires JBoss AS.

7. One project per VDB usually makes sense.

Steve

[markaddleman]

Hi, Manan -

I'm happy to share our team's experience with Teiid. 

1) We use Teiid with data sets ranging from a few hundred rows to a few hundred thousand rows.  Although query complexity and underlying data source capabilities vary widely and will dramatically impact performance, we have never experienced a performance bottleneck on Teiid itself.

2) We use caching and materialized views with great success.  In fact, one of our largest data sets, around 400,000 rows, is a materialized view using Teiid's internal materialization facility.

3) We don't use the designer, so I can't comment

4) ditto

5) ditto

6) We use the full Teiid server and are switching to Teiid 8.1 on JBoss 7.1.  We are very impressed with JBoss 7.1's footprint which makes it competitive with Tomcat.

7)  We have roughly two dozen different datasources comprising more than a thousand tables in a single, dynamic VDB.  To enhance modularity around the VDB, we have code that takes our own XML files and combines them to form the dynamic VDB which then gets deployed during the startup phase of our application.  Again, we don't use the Designer so I don't know how you can achieve modularity with that tool.

Not sure what information you're interested in, but please ask follow up questions.

[rareddy]

Manan,

I will not talk about all the  stuff you asked, as I would like somebody else to share their experiences. I would say this, for those exact concerns and to put you and your management folks at ease you may want to look into EDS subscription from Red Hat, which is based on Teiid. They will offer support and training you are looking for.

6. Does Teiid work on Tomcat? Any one tried?

No it will not as is. This is designed to work with JBoss AS. Teiid 8.1 will have a "embeddable" version. With some amount of integration work you can make it work in the Tomcat. I have seen some community interest from this. But this not something on Teiid's roadmap.

7. What is the ideal development structure? sholud one put all the phaysical/relation views in the one project and put all the exposed VDB in other for ease of maintainance, etc and reference each? Should all the releated components be kept in one project?  We have many underlying source connected to many final data reports/VDB so just curious to know?

Keeping related components together may work just fine. It really depends upon how your teams co-ordinate and how you share the projects. If you are thinking you have enterprise wide sources and views based on those sources and would like all other teams to make use of those views, then you should check out "vdb-reuse" feature in Teiid 8.1.

Thanks

Ramesh..

[markaddleman]

HI, Ramesh -

The vdb-reuse feature sounds interesting.  What's the JIRA?

[rareddy]

Mark,

See https://issues.jboss.org/browse/TEIID-1366

Ramesh..

[mananpat]

Hi Mark,

you mentioned that you guys don't use Teiid Designer so i am curious to know how do you prepare vdb and model view etc....perhaps the connection files are easy to create since they are xml.

[markaddleman]

We use Teiid's Dynamic VDB feature.  We have a very large and distributed team that works on various pieces of the virtual database (this includes defining models as well as creating custom translators for highly specialized data sources).  All of these teams operating on a single VDB artifact, whether it is in the Designer or as a single XML file, is very problematic for us.  Further, we allow our customers to optionally deploy data sources so it is quite possible that, in any particular deployment, pieces of the complete VDB won't exist.  That implies that our runtime VDB must be constructed dynamically.

To achieve this, we have defined our own XML configuration files that conceptually mirror Teiid's dynamic VDB XML.  Each XML configuration file represents a separately deployable portion of the VDB.  Each of our teams is responsible for one or more of these configuration files.  At startup, our server reads all of the configuration files and, using Teiid's Admin API, we programmatically construct Teiid's complete VDB.  During steady-state of our server, we monitor for changes in these XML configuration files and redeploy the Teiid VDB if the user changes them.

The XML configuration files and their processing is an evolving feature.  Originally, their structure wasn't very well aligned with Teiid's own VDB XML and we are moving to better align them to Teiid, especially as Teiid enhances its own capabilities with things like view definitions in the VDB XML.