Github user roshannaik commented on a diff in the pull request:

    https://github.com/apache/storm/pull/1914#discussion_r99951845
  
    --- Diff: docs/Joins.md ---
    @@ -0,0 +1,102 @@
    +---
    +title: Joining Streams in Storm Core
    +layout: documentation
    +documentation: true
    +---
    +
    +Storm core supports joining multiple data streams into one with the help 
of `JoinBolt`.
    +`JoinBolt` is a Windowed bolt, i.e. it waits for the configured window 
duration to match up the
    +tuples among the streams being joined. This helps align the streams within 
the Window boundary.
    +
    +Each of `JoinBolt`'s incoming data streams must be Fields Grouped on a 
single field. A stream 
    +should only be joined with the other streams using the field on which it 
has been FieldsGrouped.  
    +Knowing this will help understand the join syntax described below.  
    +
    +## Performing Joins
    +Consider the following SQL join involving 4 tables called: stream1, 
stream2, stream3 & stream4:
    +
    +```sql
    +select  userId, key4, key2, key3
    +from    stream1 
    +join       stream2  on stream2.userId =  stream1.key1
    +join       stream3  on stream3.key3   =  stream2.userId
    +left join  stream4  on stream4.key4   =  stream3.key3
    +```
    +
    +This could be expressed using `JoinBolt` over 4 similarly named streams 
as: 
    +
    +```java
    +new JoinBolt(JoinBolt.Selector.STREAM, "stream1", "key1")               // 
from stream1  
    +                            .join     ("stream2", "userId",  "stream1") // 
join      stream2  on stream2.userId = stream1.key1
    --- End diff --
    
    Yes, not supported. Joining on a subset of grouping fields is not supported 
as it **will** lead to wrong results in a streaming system... unless you 
restrict it to 1 running instance of the Join bolt.  
    
    This is not a limitation of the JoinBolt per say, it is a limitation that 
it inherits from the nature of in which streaming data is routed.  Its a bit 
tricky to express, but let me give it a try:
    
    
    When we join with f1, the system **must** route the tuples based on 
hash(f1) to the right Join bolt instance.  If we want to join on both f1&f2, 
then routing **must** be based on hash(f1,f2).  
    Basically, if the join fields and the grouping/routing fields are not same, 
the bolt instance will not receive all the right tuples for the join.
    
    So there is an inherent contradiction when you try to route on hash(f1,f2), 
 then try to join on anything but those two fields. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to