What’s new with BigQuery federated queries

Home

The article Bring analytics to your data: What’s new with BigQuery federated queries that I'm co-author of was published on Google Blog so I'm happy to share it. From the article you will learn about new interesting features in BQ federation area like SQL Pushdown or Private IP Access. I had an opportunity (and not only me) to have my hands in some of these features so I'm happy to see them officially announced. Especially excited I'm about SQL Pushdowns. This was a challenging but also very interesting task which allow me to learn a lot about internals of a database engine.

^*The picture at the beginning of the post comes from Google Blog.

My presentation on Spotlight on Google Cloud Poland

Home

I prepared a presentation about federating BigQuery with external data sources. If you want to see this presentation but also panel discussions, lightning talks, and career-focused live sessions register at the virtual conference Spotlight on Google Cloud Poland which will take place on October 27.

Ethereum network and manipulations

Home

In cooperation with Nethermind, I published another research on EIP-1559.  If you don't remember or don't know it, EIP-1559 is an improvement that replaces the auction-based fee market in Ethereum network with a basefee and a tip. The difference between the basefee and the tip is that the first one is paid by a user and burned by the protocol, and the tip is paid directly to the miner. This time I focus on the possibility of the basefee manipulation. As everywhere where the money is involved, somebody can try to cheat the system. You can find the article here.

My first research on blockchain!

Home

In cooperation with Nethermind, I published my first research on EIP-1559. It is an extremely hot topic in Ethereum community nowadays. I analyze how legacy and EIP-1559 users will be treated by the network in post EIP-1559 world. The research, in the form of a Jupyter notebook, can be found here. Comments are welcome.

Neo4j Cypher is great but sometimes strange

Home

My journey with Neo4j started a few months ago and I really think that it is a great database and I'm in love with its query language called Cypher. However, especially having SQL background, some things might be surprising (in this negative way). I will give you an example. Let's assume that we have a graph that among other stores movies. We may write such a query to retrieve all the movies:

MATCH (m:Movie) 
RETURN m

Here is a sample result:

If we slightly modify this query we can select movies that were released in 1999:

MATCH (m:Movie)
WHERE m.released = 1999
RETURN m

This time we will get just 4 movies:

Now let's make something more complex i.e. additionally let's return information about producers of movies (if they exist):

MATCH (m:Movie)<-[:PRODUCED]-(p:Person)
WHERE m.released = 1999
RETURN m, p

This query has one small bug. The problem is that it returns only 1 movie while we know that there are 4 movies released in 1999. To fix a problem we need to use an equivalent of LEFT/RIGHT JOIN from SQL which is called OPTIONAL MATCH:

MATCH (m:Movie)
OPTIONAL MATCH (m)<-[:PRODUCED]-(p:Person)
WHERE m.released = 1999
RETURN m, p

Better but still something is wrong. Instead of getting 4 movies, we have dozens of them and if we analyze results we will notice something very strange. Movies returned by a query above were released in many different years e.g. in 1975 even though we have this condition WHERE m.released = 1999.

Does it mean that WHERE statement in Cypher does not work in some cases? Or maybe something is wrong with OPTIONAL MATCH. Well, everything is ok if we know how Cypher exactly works. What is not obvious is that:

OPTIONAL MATCH ... WHERE never removes rows from the result.

Yes, it is awkward but it is how Cypher works. Everything is also explained in this nice article from Neo4j. Any way to fix a problem we have 2 options. We can either change the order of statements in a query:

MATCH (m:Movie)
WHERE m.released = 1999
OPTIONAL MATCH (m)<-[:PRODUCED]-(p:Person)
RETURN m, p

Or use WITH statement:

MATCH (m:Movie)
OPTIONAL MATCH (m)<-[:PRODUCED]-(p:Person)
WITH m, p
WHERE m.released = 1999
RETURN m, p

And now results are perfect: