A novel approach to entity resolution using serverless technology • Hacker News Board

Re: A novel approach to entity resolution using serverless technology

#11

Post by ALLTaken » Wed, Aug 11, 2021, 8:18 AM UTC

Major_Grooves wrote: post #9

willvarfar wrote: post #7

Earlier quoted context omitted.

Very cool project. Setting up a business based on a new DB tech that has one user, though, is tricky. Playing devil's advocate, how do you plan to make money? Who are the users, why do they turn to TiloDB, how do they learn about it, how do they adopt it, how do they be convinced to pay you something for it? Etc

Thanks for your question. You are right - it is not an easy business to start. Investors are more used to open source projects that are already released and have community adoption that they can measure. We are kinda the opposite - enterprise ready software that wants to go open source. So we want to make the software open source, but restrict a few modules that would be necessary for enterprise customers, such as se…

Also highly interested! It would be awesome if the database could be accessible via C/C++ or Rust library in order integrate into existing applications, if that makes sense.

Re: A novel approach to entity resolution using serverless technology

#12

Post by Major_Grooves » Wed, Aug 11, 2021, 8:22 AM UTC

I'd be very interested to hear peoples' thoughts on OSS licences. We are rather new to that world so very rapidly learning about the difference between Open Core, Elastic 2.0 and Apache Licence etc.

What licence should a new company like us adopt when we want to build a community but we also want to commercialise the technology, especially when we already have a "enterprise ready" version of the tech?

Re: A novel approach to entity resolution using serverless technology

#13

Post by Major_Grooves » Wed, Aug 11, 2021, 8:23 AM UTC

ALLTaken wrote: post #11

Major_Grooves wrote: post #9

Earlier quoted context omitted.

Thanks for your question. You are right - it is not an easy business to start. Investors are more used to open source projects that are already released and have community adoption that they can measure. We are kinda the opposite - enterprise ready software that wants to go open source. So we want to make the software open source, but restrict a few modules that would be necessary for enterprise customers, such as se…

Also highly interested! It would be awesome if the database could be accessible via C/C++ or Rust library in order integrate into existing applications, if that makes sense.

You would be able to access everything via the GraphQL API to integrate into existing applications.

Re: A novel approach to entity resolution using serverless technology

#14

Post by trhway » Wed, Aug 11, 2021, 8:33 AM UTC

skafoi wrote: post #8

trhway wrote: post #5

from experience with similar product (where we had similarly sounding way of entity resolution based on rule based fuzzy indexes and fuzzy matching, and it was working for tens of millions of entities on regular, though beefy, RDBMS more than a decade ago) - the issue isn't that much technological, it is that each customer/client has custom everything when it comes to ER, and thus scaling that business is extremely h…

I would really love to hear more about your experience regarding the client customizations. So far the two things I can see are domain model customization and rule customization. Obviously with the rule customizations being the more challenging one.

the rule customization is match rules and index generation rules, and all these customizations are data source specific. And a large company with a lot of departments and divisions, some of them being former acquisitions, would have a number of different data sources, as well some external ones too, reference ones in particular. Beside the pure basic issue of connecting those data sources and pulling data from it, the data in them have different reliability/quality, different standard of maintenance, etc. as well as different role in the system - some of those sources are master sources, some are only used to extract matches without update, some are [also] consumers of the match/deduplication results, so they have to be updated back. As as result any of such actually implemented ER systems is totally one-off.

Re: A novel approach to entity resolution using serverless technology

#15

Post by skafoi » Wed, Aug 11, 2021, 8:42 AM UTC

trhway wrote: post #10

Major_Grooves wrote: post #6

Earlier quoted context omitted.

the real technical challenge is the "transitive hop" problem that we describe. The matching of the data is not so complicated - that can be done with any technology - but searching with Data A, and getting result Z - that was the tricky bit that took us years to solve and was only possible thanks to serverless tech.

in our case we didn't have explicit "transitive hop". Instead in this example it would be just one entity with a bunch of addresses (with related dates if configured so), and multiple known names, etc. attached. Granted in order to get to that state the data loading process would include a massive batch matching which would be performed on the array of worker nodes - the number could be configured for given run, so t…

That sounds mostly like deduplication which is often used in marketing contexts. There are indeed some good solutions out there, but from our experience they have difficulties handling huge amounts of data (>1 billion data sets) and they are often batch based, so your data is always outdated, whereas we constantly add new data in near real-time.

Re: A novel approach to entity resolution using serverless technology

#16

Post by skafoi » Wed, Aug 11, 2021, 8:47 AM UTC

trhway wrote: post #14

skafoi wrote: post #8

Earlier quoted context omitted.

I would really love to hear more about your experience regarding the client customizations. So far the two things I can see are domain model customization and rule customization. Obviously with the rule customizations being the more challenging one.

the rule customization is match rules and index generation rules, and all these customizations are data source specific. And a large company with a lot of departments and divisions, some of them being former acquisitions, would have a number of different data sources, as well some external ones too, reference ones in particular. Beside the pure basic issue of connecting those data sources and pulling data from it, th…

Thanks a lot. Sounds similar to the issues we had in our previous company. We provide some basic ETL functionalities to tackle these. Will be interessting to see where this will eventually end up and how much our solution does there or where it is better to use the probably in those companies existing ETL tools.

Re: A novel approach to entity resolution using serverless technology

#17

Post by trhway » Wed, Aug 11, 2021, 8:52 AM UTC

skafoi wrote: post #15

trhway wrote: post #10

Earlier quoted context omitted.

in our case we didn't have explicit "transitive hop". Instead in this example it would be just one entity with a bunch of addresses (with related dates if configured so), and multiple known names, etc. attached. Granted in order to get to that state the data loading process would include a massive batch matching which would be performed on the array of worker nodes - the number could be configured for given run, so t…

That sounds mostly like deduplication which is often used in marketing contexts. There are indeed some good solutions out there, but from our experience they have difficulties handling huge amounts of data (>1 billion data sets) and they are often batch based, so your data is always outdated, whereas we constantly add new data in near real-time.

Typically deduplication is more like clean, standartize and match (using relatively simple match approaches). Our process was much more complex (more along the lines of what another commenter linked https://blog.acolyer.org/2020/12/14/entity-resolution/) with more rich resulting functionality, and, yes, marketing was the segment where it started though i'd say it was only about 3rd of the business at the peak of it. Yep, performance for most of the solutions is an issue. We had to do significant re-engineering at one point to parallelize at much finer granularity and thus were able to scale much more. Our biggest number of entities counting across all the sources in the largest implementation was just under 200M. It was right pre-Nehalem hardware.

The batch mode had naturally orders of magnitude higher throughput. We did have real-time single-record mode which was pretty fast as long as the stream of the incoming single-records wouldn't saturate the worker array capacity (here is the difference from serverless as the worker array was limited by whatever was statically configured at the moment as adding/removing nodes wasn't an instant on the fly operation)

Couple years later i worked at another company on a similar, though somewhat simpler, project when it was in the process of total rewrite for performance reason - the old version was really slow - that rewrite failed spectacularly for a lot of reasons. So, yes, performance is a kind of a noticeable factor in the domain.

Re: A novel approach to entity resolution using serverless technology

#18

Post by lmeyerov » Wed, Aug 11, 2021, 10:50 AM UTC

ER for identity graphs is a great use case! We see teams do this a lot and with not-great tools. (Ex: users/IPs in splunk/elastic, which are better for simpler matches.)

For one Graphistry project, we run a single node neo4j with 0.5b nodes/edges, so something in the description isn't adding up for me here wrt perf. Maybe an open benchmark would help?

I do agree indexing matters, as that was night/day for our use cases. For ML workloads, we are looking at vector indexes, which graph DBs do not currently support. The ones in this article are on text and take > 100ms, so I'm curious..

Re: A novel approach to entity resolution using serverless technology

#19

Post by skafoi » Wed, Aug 11, 2021, 11:12 AM UTC

lmeyerov wrote: post #18

ER for identity graphs is a great use case! We see teams do this a lot and with not-great tools. (Ex: users/IPs in splunk/elastic, which are better for simpler matches.) For one Graphistry project, we run a single node neo4j with 0.5b nodes/edges, so something in the description isn't adding up for me here wrt perf. Maybe an open benchmark would help? I do agree indexing matters, as that was night/day for our use cas…

Regarding the performance on neo4j: the challenge for an honest and fair test towards this would be about how to properly compare a server-based solution vs. a serverless solution. TiloDB automatically scales up and down without any further interaction due to using Lambdas for all calculations. So would you compare it with a relatively small neo4j instance or with a large cluster? I honestly don't know. When we started doing this internally for our previous company, we obviously did test the edge cases. After all, we didn't want to create our own solution. For graph databases, the issue here are either a lot of edges leaving from one node or a long chain of edges. The first scenario was still handled okish: response times of around 6 seconds for 1.000 nodes if I remember correctly. The second scenario was a total fail. The problem for the later one lies in the transitivity as a graph database has to jump from one node to the next one and so on. To be fair though: when it comes to dynamic entities, so choosing which rules are relevant, graph databases might be the better choice - especially when response times don't matter.

The response times provided in the article are for the whole process of searching and returning the entity. The indexes themself are obviously a lot faster - to be precice we are using DynamoDB for storing the indexes, which most times return results in Hope that somehow makes sense what I wrote.

Re: A novel approach to entity resolution using serverless technology

#20

Post by Zababa » Wed, Aug 11, 2021, 11:16 AM UTC

Major_Grooves wrote: post #12

I'd be very interested to hear peoples' thoughts on OSS licences. We are rather new to that world so very rapidly learning about the difference between Open Core, Elastic 2.0 and Apache Licence etc. What licence should a new company like us adopt when we want to build a community but we also want to commercialise the technology, especially when we already have a "enterprise ready" version of the tech?

Here is the page of CockroachDB https://www.cockroachlabs.com/docs/stable/licensing-faqs.htm.... Their focus seems to be forbidding cloud vendors from selling their product as a service unless they allow it (a bit like Elastic).