您当前的系统语言是中文，可以点击进入 https://www.ultipa.cn 获得更好的体验
Change Password
Change Email
Change Nickname
Your privacy
By clicking “Accept all cookies”, you agree Ultipa can store cookies on your device and disclose information in accordance with our Cookie Policy.
Pain Points (Case Study)
Here is one such challenge faced by local, state, and federal authorities in San Francisco, in the past decade San Francisco’s real-estate properties that were supposedly allocated to low-income local families have been bought up by LLCs (Limited Liability Companies) that are hard to trace their UBOs. The issues were so prevalent that this has become a major concern, government agencies like IRS (Internal Revenue Services) and local law enforcements are interested in understanding what parties are hiding behind these LLCs, manual exploration process can be very labor intensive and time consuming, because the eventual UBO parties may hide many hops (layers) behind the surface LLCs, and often times these UBOs intentionally hide and cross-owning their shares, making the overall ownership structures highly complicated. An automated white-box AI solution is desired.
Data Presentation: Intuition Matters
Traditional databases all use columns and rows to store data and present the data using tables which are counter intuitive in many real-world applications. For instance, to understand a business entity’s ownership structure, the most intuitive way is to present the relevant data in a graphical and correlated fashion. If a person acts as the legal representation of a company, in a graph setup, this is an edge connecting two nodes, one node being the person, pointing at the other node which is the company, and the edge (relationship) is labeled “Legal”.
Data Connection: High-dimensional Graph
Assuming we have collected all data of a business entity, starting from the business entity node, recursively, all entities that are linked with it can be retrieved and form a sub-graph. Note that the resulting collection of nodes and edges may form a graph instead of a tree, a tree does NOT have circles, but a graph may, and this reflects real world scenarios better, because business entitles and persons may form circles or cross-investment/owning business structures, which can NOT be represented with a hierarchical tree structure.
Data Exploration: Exponential Complexity
In real world setup, it is NOT uncommon to see the eventual owners (aka Ultimate Business Owners, or majority- stake holders) that are many hops away from the business entity that are being examined. A traditional RDBMS or document database (or even most graph databases) is NOT capable of addressing such exploration (deep penetration) in a fast and timely fashion due to the joining of multiple tables will inevitably create the “cartesian product” problem, therefore making the query complexity exponentially difficult and slow.
Innovation
If we are NOT equipped with a system with appropriate graph computing power, we are not going to solve the challenges above. Fortunately, Ultipa Graph is designed to address such challenges with extremely high efficiency and efficacy via high-concurrency data structure, system architecture, and algorithm hyper-parallelization.
Deep Graph Traversal
The below diagram shows that the UBOs are many hops away from the subject business entity, sometimes the computation complexity is overwhelming for traditional DBMS or non-real-time graph databases. Each business entity can have many owners (business or personnel), the mathematical calculation can be exponentially complex every time we dig a hop deeper. Let’s do the simple math here:
- Assuming there are on average 25 owners for an entity
- If we are to dig 5 layers deep: 25 * 25 * 25 * 25 * 25 = 9,765,625(~)10M
- If we are to dig 10 layers: 1014 = 100 trillion
Ultipa Graph identifies the UBOs in pure real-time (micro-second execution time) because we deep- traverse the graph many times (100x or more) faster than other graph systems. RDBMS/SQL are totally incapable of such scenarios, the above diagram illustrates the difference between the 2 types of query languages SQL of RDBMS and GQL or Graph DBMS, for a small table of only 10,000 rows, a 5-hop penetration takes SQL 38 seconds, while GQL takes only 0.001 second (1 millisecond), the difference is 38,000 times. On the other hand, micro-second turn-around time means much higher concurrency and system-level throughput, it’s 1,000x times faster and more concurrent than systems claiming with millisecond turnaround time!
A Company’s UBOs May be Hiding Layers Behind Surface
The Problems with SQL: Rigid, Slow and Incapable of Recursive Queries
Massive Computing in Real Time
In a large stock exchange, the auditing department has the need to examine all possible links between the 4,000 publicly listed companies and 10,000 key persons. The computational complexity is unrealistically high, because one query between one public company and one key person may have 1,000 links (or shortest paths) not to mention the same kind of queries have to be conducted 40,000,000 times, the resulting paths could be in the range of 40,000,000,000. The stock exchange tried to solve the problem with Neo4j only to find out that on average one query takes more than 0.5 second, finishing the entire queries would take forever (~100 years). By adopting Ultipa Graph, they were able to finish this large-scale batch processing in a T+0 fashion (minutes to hours), and on average each path-query takes only 0.46 milliseconds! Ultipa on average is 1,000+ times faster than Neo4j, in complex queries, Ultipa tends to be 10,000s of times faster. The table below captures systemic differences between Ultipa and Neo4j:
| Smart Enterprise Graph | Ultipa Graph v4.0 | Neo4j Enterprise 4.x |
|---|---|---|
| Cluster Size (instances) | 3 (HTAP) | 3 (Hot-standby) |
| Data Volume (Nodes & Edges in Millions) | 1,000 | 1,000 |
| Max Concurrency (Threads or vCPUs) | 80 | 4 |
| Max Query Depth (Hops or Layers) | >32 | ≤5 |
| Avg. Query Processing Time (ms) | 0.46 | 500 |
High Visualization
Presenting entity relationships in a networked and animated fashion is both intuitive and productive. The diagram below shows how the query results can be shown visually and intuitively using Ultipa Manager, the web-frontend of Ultipa Graph DB system, and users can interact and explore with the graph in real-time to expand on their findings, such as:
- Finding connections (paths) from an existing entity to any other entity
- Finding most similar entities across the entire network
- Edit/Update any entity or relationship
- Show, hide or delete any entity/relationship
- Customize the graph in anyway that’s possible
- Launch a new search/query
A Company’s UBOs (Top stakeholders) That are 4-hop Away
Significance
Unlike traditional knowledge graph (since when knowledge graph is considered “traditional”?) which is powered by a backend server that’s based on RDBMS or NoSQL (i.e., document based like MongoDB), the Smart Enterprise Graph is powered with real-time graph DBMS, it’s exponentially faster (real-time), flexible, white-box, and capable of fulfilling business needs that are previously impossible with traditional architecture.