Our own Ines Sombra interviews Andreas Kollegger about the present and future of Neo4j, how to get started, and a likely Graph Conference in San Francisco.
Andreas on Twitter: https://twitter.com/#!/akollegger Neo Technology: http://www.neotechnology.com/
Discussion * 0:00 All about Andreas * 3:00 Working with graphs * 5:00 Trends with Neoj4 * 6:00 Mistakes people make with Neo4j * 8:45 Areas of improvement for Graph Databases * 14:00 Getting started with Neo4j for Ruby and PHP * 15:45 What's coming up in the Neo4j world * 22:30 Neo4j user groups * 23:15 Cat's out of the bag: Graph Conference in SF
Links * Neo4j - http://neo4j.org/ * Neograph by Max de Marzi - https://github.com/maxdemarzi/neography * NoSQL - http://nosql-database.org/
Ines Sombra: Hello, everybody, and welcome to our second data podcast. This is Ines. I am a data engineer at Engine Yard and I’m interviewing Andreas Kollegger from Neo Technology. Hello, Andreas.
Andreas Kollegger: Hello, Ines. Nice to meet you.
Andreas Kollegger: – And hello everybody out there in Radio Land.
Ines Sombra: Yeah, thank you for stopping by. Andreas is here in our office, so we’re gonna have a little bit of a conversation and we decided to record it. We hope everybody enjoys it.
So, Andreas, tell us a little bit more about yourself.
Andreas Kollegger: Yeah, so, I’m Andreas Kollegger, as Ines said. I’m with Neo Technology. Neo Technology is the commercial sponsor of Neo4j, which is an open-source graph database. So, it’s an open-source project with a, you know, commercial backing, if you have a commercial project yourself.
I’m one of the community engineers. So, because as an open-source project, we’re very committed to actually developing an open-source ecosystem around the product, and that’s where I spend most of my time is actually out supporting other projects that are either developing drivers or the frameworks around, you know, the database, and also doing things like connecting a lot of our meet-ups. So, I travel around a good bit speaking about Neo4j and, you know, sharing the love of graph.
Ines Sombra: Cool. So, can you tell us how you got started with Neo? Well, actually, with Neo, also, I know, SQL in general because that represents a niche within the NoSQL – like the SQL paradigm. So, can you tell us a little bit more of how you started?
Andreas Kollegger: Exactly as you’re implying here. Like so, when first introducing graphs to people, we always try to paint it within the picture of like, “What’s happening in the overall NoSQL movement?”
And we talk about NoSQL as being really – it’s the set of technologies that are a reaction to the big data trend. These are all these new databases that people have written for themselves because, suddenly, you have more data than you used to have before, and the kinds of things you’re doing are different, and so, there’s all these specialized databases that have come up.
Everyone is familiar with – obviously – like key value stores; that’s up in corner. And then, we see really four categories. So, there’s key value stores, with a very simple data model that can scale very well. And then, you enrich that data model a little bit, essentially, and you get a second category that suddenly it’s the column family stores.
Ines Sombra: Yeah.
Andreas Kollegger: Still, essentially, a key value but you got a little bit more structure. Elaborate the structure a little bit more and, suddenly, you have a document; still, effectively, a key value. You get something, but the value you get back has a very nice structure to it, and can, you know, have very rich data.
Elaborate the model a little bit more, and you actually come around to the graph database space where – along as you’ve sorta been taking those transitions – the data model has become more elaborate, and it still scales very nicely, but the challenge of scaling becomes a little bit more difficult as you add more structure to the data model itself because you have to think a little bit more about, “Where do you want the data to be for running queries?” The worst thing, of course, is writing a query that has to go across an entire set of machines.
So, the graph database ends up being on the corner where we have a very rich data model, still accompanying a line of data, but for now, don’t scale quite as well. We could – it’s a little bit more challenging to fill a warehouse full of machines with a graph database.
Ines Sombra: So, can you tell us a little bit more about what kinda problems a graph database can solve?
Andreas Kollegger: Yeah, the classic thing, of course, is the simple model of, if you think of social networking, people talk about the social graph and say, “Social graph. I should have a graph database just through my social graph.” That’s also the most intuitive thing when we’re introducing the idea of graphs to people, is to think in terms of querying when you wanna do questions like, if you look around a roomful of people – or everybody who’s listening to this right now – and you wanna figure out, you know, “What’s the average age of people in the audience?” Ask a relational database that. That’s perfect for a relational database.
But if you wanna know, “Well, how do I know you?” And it’s – you know, for me, to somebody else, to somebody else, and then finally, around to you, that’s a very simple thing like to think about, but running that query in a relational database is actually complicated because it’s a couple of joins to do. And the classic thing with the graph database is that’s perfect; we’re awesome at answering those kinds of questions when you’re interested in how things are related.
So, the thinking in social terms – and like it’s the Kevin Bacon problem. It’s the Bacon path, right?
Ines Sombra: Yes.
Andreas Kollegger: You know? How many people between me and you is the most intuitive thing, I think, for people to first start getting down the path of working with graphs. And then, once you’ve understood that, and it’s like this small mental shift that ends up occurring where you just kinda change your perspective from thinking about sets to thinking about the locality of data and other data that’s related.
And then, people start seeing graph, you know, problems and graph questions in lots of different areas because, really, that initial problem of like the doing multiple joins is usually characterized with a relational scheme of having a join table, right?
Ines Sombra: – Yes.
Andreas Kollegger: Almost every scanner on the planet, somewhere, has a join table and you know that doing lots of work with your join table ends up, at some point, being a challenge and you try to minimize how many of your joins you’re doing. You modify your schema a little bit to try to do fewer joins.
Ines Sombra: Yeah.
Andreas Kollegger: – So that you still have good performance. For us, we essentially love joins. We are optimized for doing those kinds of queries.
Ines Sombra: So, what are the trends that you see when people are starting to construct applications and they use Neo? Do they normally pair it up with something else to represent the type of relationships that are, like, traditional from application development? And do they use Neo to navigate through those – to like parse those – relationships quicker? Or do they actually do – do they tend to do the mental shift, and then, think about the problem in terms of graphs and how – how do you see the evolution of an application when somebody chooses to use a graph database?
Andreas Kollegger: – Yeah, we’ve actually been seeing a very even split between people, and it falls along the lines of people who already have an application, and that are having problems with a query, and they go off looking for a way to do it better. And then, they come to the graph, and then, they’ll take parts of their data and move it into the graph.
And so, easily, you know, half the people who come around to finding Neo4j keep their data that they already have. They don’t migrate everything over. They just migrate parts of it over; that makes sense. Or if people are doing fresh development, if they’re doing a social application for instance, it’s very common to like – you’re coding from scratch. You think social graph, graph database, and you just do everything in the graph. And then, it’s, you know, easier that way, right?
Ines Sombra: What are the mistakes that you see people making whenever they’re starting? And then, what are the beginners’ mistakes that you see? What advice do you have?
Andreas Kollegger: It’s interesting – it’s back to that initial sorta shifting of your perspective where we are so – all of us in the computer science, you know, almost from the womb, we are all born knowing how to do relational – maybe not knowing, but, you know? We’ve done it so much like that’s – you don’t even think about. Of course we know how to do relational queries; we know how to structure things the right way to get good performance there. And so, the early mistakes are when people are still in that mindset of thinking about sets, and filtering their sets, and doing aggregate queries because you can express queries within Neo4j. With our query language, you can express queries that look as if you’re doing set-like operations. It’s a little bit of a trap. It’s like, “Oh, it’s – this is just like using, you know, SQL. So, fine. I can just write my SQL sequence.” Except if you haven’t taken the time to shift, and think more in terms of structuring your data in the graph, you’re still doing relational-type queries. We’re not good at relational queries. What you do is you shift from the schema to the structure of a graph, and then, you’ve gotten over the initial challenge.
So, the initial newbie mistake, I guess, is still thinking in relational terms.
Ines Sombra: So, what do you see though? What are the disadvantages? Well, we’ve already covered like, you know, the main problem of graph databases, but what do you see them involved in?
So, right now, we have a graph database. It offers you a very new paradigm, a new paradigm to think about it. It could be argued that the paradigm is not necessarily new because relational wasn’t really the only paradigm a long time ago.
Andreas Kollegger: – Absolutely.
Ines Sombra: So, we could talk about this as maybe like a hierarchical or a network-type of –?
Andreas Kollegger: Exactly right, yeah.
Ines Sombra: So, we’re going back to like probably the foundations that were like talked about 40 to 50 or maybe even 70 years ago. I think it’s like the relational was like 60 years ago.
Andreas Kollegger: Depending on what you track back to, yeah.
Ines Sombra: Yeah, so, we have this thing. So, we now have – it’s becoming popular again because the nature of the problems force us to start thinking about how data is generated, and if your data has a natural format that has to fit into a graph, then the process of deconstructing it into a relational, and then, like trying to optimize the handling of the data becomes annoying and becomes – not annoying, but it’s just like it’s wasteful.
Andreas Kollegger: Right.
Ines Sombra: So, we have graph databases and people are starting to think about the problems in those terms. What are the defect – the maybe areas of improvement right now? Because other than the new paradigm, what do you see the graph databases going towards?
Andreas Kollegger: Yeah, it’s an interesting question and there’s – I’ve participated in a few different roundtables with other SQL players, and, you know, it’s a very small community to some extent. We know who everybody else, and every now and again, we end up in a room and we’re arguing on a panel about exactly this question. Where are things going? How will this play out?
And, as you alluded to, there was a time when there was more than just relational and relational wasn’t the only database. There used to be network databases, hierarchical databases – all kinds of other options. And, at that time, the initial database wars, relational came out on top because it was exactly right for the questions that people were asking of the data at the time.
Ines Sombra: It was the right time in history, so yeah.
Andreas Kollegger: Exactly right. And I don’t know that we are mature enough, really, in how the paradigm shift has been happening now to know, “Are we all – we’ll split out and we’re gonna converge again to something else?”
Of course, you know, as a graph person, I now see only graphs everywhere. It’s hard for me to think in other terms because it is the most natural way for me to now think. But you could – you know, in terms of the key value people, they could say, “Well, of course, with our key value store, we can store anything, and we can map anything to it.”
Ines Sombra: But do you think like maybe – you know, right now, you see things like the Mongo document. And then, right now, you have people that are – grew up with the guarantees that Asset gave you. Then, all of a sudden, you start choosing a new database that doesn’t provide you those guarantees. And then, you want them back.
Andreas Kollegger: Right.
Ines Sombra: So, it almost seems like it’s a small evolution between just like, “Okay, we’re gonna give you something completely different.” And then, “We’re gonna start putting some of those guarantees in.”
Andreas Kollegger: Yeah.
Ines Sombra: – So what will that the graph database give us?
Andreas Kollegger: – Well, it’s – we are unique, of course, within the NoSQL space there because we always have been Asset-compliant. So, we –
Ines Sombra: – Oh!
Andreas Kollegger: – have only been fully transactional – when the Swedes, back in the day in the cold north, when they were off in their log cabins or whatever, you know, developing the original project, it was always important to them to be a proper database. And they have, you know, down to the file system, custom structures for being fast and optimized for graph operations, but always transactional.
It was always that, when you write, we flush down the disk. Everything is committed; we’ve got transaction logs. All the sorta proper database-y things, we’ve always had, which is a mixed blessing, of course, because then, having transactions ends up meaning, “Well, you’re only gonna write this task as your disk is,” right?
Ines Sombra: – Yes.
Andreas Kollegger: And so, we’re on the other corner of the NoSQL space where – so, we have the NoSQL aspect of like not having schema. We have no – you know, we’re semi-structured, but we do have things like Asset transactions.
So, our challenge then ends up being – for graphs, actually, sorta the challenge right now is that we have – when we wanna grow past a single machine, “How – what’s the generic way to do that and still have a well-balanced graph?”
Ines Sombra: Okay.
Andreas Kollegger: Now, we’ve had all kinds of grad students researching this for years now. We’ve come up with different ways of doing this and that’s a very, very difficult problem to do well because it all depends on, “What is the usage pattern?” So, you have to have some level of application knowledge to have a good, balanced graph that will still perform well for your queries.
Ines Sombra: Yes.
Andreas Kollegger: And so, we actually have a team off that’s sequestered, in some landlocked location in the British Islands somewhere, actually. They’re off trying to actually solve this. So, the next big step for Neo4j itself, actually, is gonna be that we will have a solution for being able to scale a graph across as many machines as you can throw at it, and have a compromise of like you can choose how that’s gonna happen and recognizing that there’ll be a little bit of a performance tradeoff there, but for the individual on each shard, effectively, you’ll still get obviously very fast queries.
Ines Sombra: Yeah. So, I don't know if our listeners know, but when you interact with Neo4j, you’re talking about – you can talk to it in two different languages, but can you tell us a little bit more about that?
Andreas Kollegger: Yeah, so, Neo4j, of course it’s – you know, has a proper database. It is just a server that has a REST API, so any language that can talk rest can talk to our database. Our structured query language, of course, is independent of any other language so you can just pass, like as if you were talking to a SQL database. You just pass queries across. You get responses back and you can access them from any place you’d like to.
Or, because we’re actually developed – so, the “J”, of course, is the 4j; it’s because we’re running on the JVM. So, as a JVM product, it’s also possible to take Neo4j and just embed it as a library within your application.
Ines Sombra: Oh, nice.
Andreas Kollegger: So, if you’re doing – for instance, if you’re a Spring developer, we have a lovely, you know, wraparound Neo4j called Spring Data Neo4j. And you can do all your traditional go-ahead-and-write-your Java objects, annotate them, and just say, “Okay, great. This is gonna be saved down to a graph.”
And you get all the nice transactionality. You get everything you could possibly want out of it, but you’re talking directly to the graph, rather than talking across a network.
Ines Sombra: Okay.
Andreas Kollegger: And what’s interesting about the embedded mode is that you still have all the options of running it as a cluster if you want to. You just tell it – when you instantiate the graph database, you say, “Okay, by the way, you’re gonna be part of a cluster. Here is the information you need about the cluster.” But then, when that machine comes up, even though it’s embedded in, let’s say, you know – it’s running on Tomcat, it’ll come up. It’ll connect with the cluster – anybody else who’s connected – and it’ll go ahead, and choose a master, and then, you have an embedded database, but still operating as a full cluster.
Ines Sombra: Cool. Our community is, like, Ruby developers –
Andreas Kollegger: Yeah.
Ines Sombra: – and we also have PHP now. So, how would a person that is in Ruby or PHP get started? Can you –?
Andreas Kollegger: – Yeah, so, we actually have a lovely community around Ruby, and given that we are either embeddable or just you can talk to us through REST, there are two big drivers for using Neo4j. There’s a driver called Neography. A good friend of ours, Max Demarzi, out of Chicago has written this.
And if you’re just dealing with Neo4j as a server, it’s a lovely interface for just dealing with the REST API. Then, it’s pure Ruby at that point, and you’re completely happy.
If you’re happy running under JRuby, there’s a lovely Neo4j.rb Gem that you can get, and that like integrates nicely with Rails itself, so it looks like it’s active record stuff, and you can just do everything you’re used to doing. But then, when you want to, you can also do graph-like traversals and matching in that.
Ines Sombra: Cool.
Andreas Kollegger: Yeah.
Ines Sombra: What is the thing in PHP? So, you’re saying that you have the REST API that is just like standard. And then, this PHP, how does it communicate?
Andreas Kollegger: Yeah, there’s not an option right now for sorta running with PHP and then having an embedded database, of course. So, for PHP, it is purely just talking with the REST API.
Ines Sombra: Okay, so –
Andreas Kollegger: – And there’s a nice driver that’s been developed for, you know, PHP as well.
So, at this point, we actually have language drivers from Ruby and PHP to Clojure. There’s a Google Go driver. There’s a .NET driver. Of course, we have Java, Scala, all of those kinds of things as well. We have – it’s the usual suspects. I mean, down to like Mugsy, like Node.js, and, you know, everything you would expect to have a modern driver for; there’s a language option for it.
Ines Sombra: What does your road map look like? What other features are you guys working on? What is coming up in the Neo4j world?
Andreas Kollegger: The big feature is what I alluded to – is gonna be the sharding. We’ve had –
Ines Sombra: – Okay, so, clustering like –
Andreas Kollegger: It’s clustering out, you know? So, being able to scale for having a huge global-spanning graph that has billions, and billions, and billions, and billions, and billions of nodes in it.
And so, I – of course – just said nodes. I’m assuming, of course, our audience is very computer science-savvy. We know when we’re talking about a graph we’re talking about nodes and relationships. So, circles and lines can give us circles; where nodes are just the data. It’s just the data record, right?
And so, the big things coming up will be sharding – is a huge thing that’s important for us. And the other direction, actually, is just that we’ve been developing this query language that we call Cypher. It’s a declarative language. It’s a pattern-matching language. It’s actually kinda nice when – I wish you guys could see the whiteboard I’m about to turn to, but imagine that – I’m at a whiteboard, and I’m just drawing a circle, and then, a line to another circle, and the circle, and – both the circle and the line can have properties on them. So, you, effectively, have data records that are just stand-alone records, and then, the join table, effectively, says, “If each record has it’s own join table to other records.”
And you can put any number of columns that you want to on the data records. The Cypher query language actually kinda takes what you would draw on a whiteboard, and imagine typing that in an e-mail to a friend, right? And you would use parentheses, and then, dash-dash-arrow, parentheses to kinda show circle, line, circle, right?
Ines Sombra: So, you can actually represent that.
Andreas Kollegger: – And – exactly. And you end up using that kinda notation for just expressing, “Okay, I’m at this node. What are the nodes I wanna get to?” So, if you think of like the friends of a friend query, like, “How do I know you?” It’s me dash-dash-arrow to you. And I could even say, “I wanna follow the people I know.” So, for me, to people I know, up to three away, and it’s just like Star 3, and then, to you.
Andreas Kollegger: And then, run that as a query. It’s almost like having – it’s a little bit – of course, it’s pattern-matching, so it’s a little bit like Regex.
Ines Sombra: – Regex, yeah.
Andreas Kollegger: But, you know, with data, with, you know, proper data records and stuff.
Ines Sombra: – Wow.
Andreas Kollegger: It’s a fun, fun language. And, of course, it’s – you know, it’s a declarative language. The motivation for us there is that it’s easy for you to express what you’re looking for, and then, let us worry about how to actually do that really well so we can optimize –
Ines Sombra: – So you can optimize –
Andreas Kollegger: Exactly, and that’s the key for it, of course. That’s why you go to declaratives – so that you can understand the patterns of usage and optimize for those patterns of usage.
Ines Sombra: So, do you have the concept of indexes or like the set, the way that I structure –? I mean, obviously, the way that a structure of my graph must be that, the only – so, if I structure a graph incorrectly, then I lose out on just like all the advantages that I would have gained; it would be completely out of the window.
Andreas Kollegger: Yeah.
Ines Sombra: So, when you index something, are you indexing that relationship between the two, the two nodes, or how does indexing –?
Andreas Kollegger: – Yeah, so you can index either nodes or relationships within Neo4j. So – and when you’re doing this pattern-matching stuff, you can – for the initial part of the pattern, for like – for the me, “How do I find me before I worry about, ‘How do I get to you?’?”
Ines Sombra: Yes.
Andreas Kollegger: That ends up just being an index lookup. So, we know that there’s a set of nodes that are people nodes, let’s say. So, I can look to the people index and grab the one that has, you know, the name Andreas.
Ines Sombra: Yes.
Andreas Kollegger: And then, I’ve got a place to start.
Ines Sombra: Cool.
Andreas Kollegger: So, we use indexing for the initial lookups of how to do, you know, traversals. And then, also, of course, we take advantage of it when we can, when we’re optimizing the queries. When it’s appropriate – we know that there’s an index there – we’ll take advantage of that.
And that’s what you – and so, whether it’s for the nodes themselves, but also for the relationships, you can just, you know, look up what relationships that you know if you have them typed in because all – while the nodes don’t have any schema and don’t have any type, within Neo4j, you do have the notion of type for relationships.
Although, it’s not like a type system type; it’s really just a label for like friend. So, you can find –
Ines Sombra: Can you customize this label?
Andreas Kollegger: – And it’s completely customizable and you don’t have to determine it up front. So, you can do – as you’re creating a relationship, you can say, “All right, there’s a relationship from me to you and we’re friends.”
And so, I can then say, “When I know about the Andreas Kollegger node, I can just find all the friends of Andreas Kollegger by finding – following the friends’ relationships.” So, it’s a very quick way to just express the traversals and the structure of the graph.
And you’re right though; it ends up being a little bit of a trick to have sets of the best practices for how to structure a graph so that you’ll be able to find what you need to. You’re trading off knowledge of how to do good schemas with the knowledge of, “How do you actually arrange things effectively?’
Ines Sombra: And it’s also a matter of how you access this type of relationship because something could be very specific to your use case, too.
Andreas Kollegger: That’s right.
Ines Sombra: So, seeing as you know CS well – and I know you’re a graph guy, so what are the things that are actually – what other technologies are you interested in? What do you think that there is out there that it just actually like sparks your interest and you’re just kinda like keeping an eye out? Where do you see these things?
I wanna take that next step and actually have that data structure bind to – not just being some objects, but it’s the object graph, of course. So, you should be able to do traversals of that object graph that maybe traverse locally within the client, but if that traversal happens to extend off to another server, then off to another server, you have this fun parallelized querying.
So, I’m kinda obsessed about having a binding that lets me talk to an entire – and this gets back to the sharding, talk to an entire – array of services, and just one traversal out. I just have an initial place to start, and let it – you know, let my minions of querying run out, and fetch all the information needed, and then, pull it back up the browser.
Ines Sombra: Yeah, that’s pretty cool.
Andreas Kollegger: You find there’s a lot of good stuff do.
Ines Sombra: So, this is like only for, I guess, San Francisco people, but I guess we can talk about also like your – the new conference that is starting to like kick out. And then, I was wondering if you could tell our listeners, “What resources do we have in Neo4j?” Like so, in San Francisco, you have a graph user group.
Andreas Kollegger: Yeah.
Ines Sombra: So, what other ways – well, which conferences are you guys presenting at? So, we have the San Francisco Usage Group. Do you have other user groups that you participate in as well or –?
Andreas Kollegger: Yeah, we’ve been happy that we have, around the planet now, we’re close to – I think we have like 18 or 19 user groups around the world and around 2,000 members. So, all of the major metropolitan areas around, certainly, the United States, throughout much of Europe, there’s a Neo4j user group that’s locally.
And, if we don’t have a Neo4j-specific group, we’ve been dealing a lot with just, you know, Java user groups, or Big Data, or NoSQL data groups. We have a very – like I love – as being an open-source community, you know, sometimes, it’ll be me that like I’ll just travel around a little bit and go speak at places; but then, I’m always pleased to find out that like just people who are in our community, who also love working with Neo4j, are just speaking in kinds of occasions, right?
Ines Sombra: Oh, that’s great.
Andreas Kollegger: And now, we have a nice mix of being at conferences, being at meet-up groups. We just had a local meet-up group here. We had like 40, 50 people just learning about Cypher, and it was from zero to hero. It was, “You know nothing about Neo4j; we’ll introduce Neo4j. Then, we’ll teach you how to do queries.” And, by the end of the night, people were able to, you know, write queries, and actually use the graph, and that was fun.
So, we’re gonna be doing more and more of that in the Bay Area, and for conferences, actually, I think this is maybe letting the cat out of the big: we’re planning to have a graph conference.
Ines Sombra: – Oh, cool.
Andreas Kollegger: You know, here in San Francisco, we’re gonna have the Graph Connect Conference, the first international gathering of all graph minds.
Ines Sombra: Oh, cool.
Andreas Kollegger: And we’re gonna, you know, have a lot of fun. Obviously, it’ll be the classic. We’ll have some unconference stuff where it’s just fun, hanging out. We’ll hack a lot. We’ll see what the community has been doing.
And a fun thing about graphs is that it is a database. We have very practical things that we do, but it’s also – it’s a way of thinking, right?
Ines Sombra: Yeah.
Andreas Kollegger: And we have, as many developers do, we have a great love of just hacking in any kinda way. So, whether it’s 3D printers, or art stuff, or music stuff, or our unconference is actually gonna be kinda a multimedia playground of just things that have – that we’re enjoying doing because we care about how things are related. And it’s not just technology; it’s how technology can be used creatively.
Ines Sombra: Oh, that’s great.
Andreas Kollegger: Yeah. So, it’ll be a good amount of fun. That’s happening in the fall. We’ll probably have some official announcements about that now. Everyone who is listening now will – has advanced notice.
Ines Sombra: Wow.
Andreas Kollegger: – You know, this is an exclusive scoop for you, Ines. You –
Ines Sombra: Yes. So, this is great! Okay, so, I guess I’m just going to be attending that conference. That will be great. So –
Andreas Kollegger: We would love to have you there. That would be great.
Ines Sombra: – Yeah, that will be fantastic to see.
So, thank you so much again for coming and visiting us. It was a pleasure to have you and I hope to talk to you again some time soon so we can have an update.
Andreas Kollegger: Thank you so much for having me. This has been a lot of fun.
Ines Sombra: Thanks.