ldbc_snb_bi
clair
ldbc_snb_bi | clair | |
---|---|---|
3 | 21 | |
33 | 10,070 | |
- | 0.8% | |
7.7 | 9.2 | |
4 months ago | 8 days ago | |
Python | Go | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
ldbc_snb_bi
-
Demand the impossible: rigorous database benchmarking
Rigorous database benchmarking is indeed very difficult and time-consuming. I spent the last ~7 years working on benchmarks for graph processing systems in the Linked Data Benchmark Council (LDBC) [1], originally established in 2012 as an EU research project.
LDBC creates TPC-style application-level database benchmarks which can be used for system-to-system comparison. We provide detailed specifications, data generators, benchmark frameworks, and multiple reference implementations. The benchmarks are implemented by vendors for their database products, and the implementations submitted to be run by independent third-party auditors to ensure their correctness and reproducibility.
We have found that there is a market for audits for graph processing systems, albeit it is quite small: over the last 4 years, we have published 34 audited results, see e.g. [2] and [3].
A major problem we face is that process of implementing the benchmark for a system and getting an audited result is long (and therefore expensive). Vendors spend months implementing the and tuning the benchmarks. It is also typical for the auditor to spend 50+ hours on the auditing process, which includes a lengthy code review step, setting up the system, running the experiments, testing ACID properties, writing a report, etc. The length of the process is exacerbated by the lack of standard graph query languages. This potentially necessitates the auditor to learn a new query language or programming language.
We have tried to mitigate this problem by improving our documentation, creating more reference implementation, distributing pre-generated data sets. There are new standard graph query languages (SQL/PGQ, GQL) but their adoption is still very limited. Overall, the auditing process is quite long, which is mainly caused by the essential complexity of the problem: implementing an application-level benchmark and getting reliable results is very difficult.
[1] https://ldbcouncil.org/introduction/
[2] https://ldbcouncil.org/benchmarks/snb-interactive
[3] https://ldbcouncil.org/benchmarks/snb-bi/
-
Benchgraph Backstory: The Untapped Potential
At first, the plan was to use only the LDBC dataset and write different queries for the dataset, but LDBC has a set of well-designed queries that were specifically prepared to stress the database. Each query targets a special scenario, also called “chock point.” Not to be mistaken, they do not have deep graph traversal doing around 100 hops, but they are definitely more complex than the ones written for the Pokec dataset. There are two sets of queries for the LDBC SNB: interactive and business intelligence. LDBC provides a reference Cypher implementation for both of these queries for Neo4j. We took those queries, tweaked the data types, and made the queries work on Memgraph. Again, to be perfectly clear, this is NOT an official implementation of an LDBC Benchmark; this goes for both interactive and business intelligence queries. The queries were used as the basis for running the benchmark.
-
Postgres: The Graph Database You Didn't Know You Had
I designed and maintain several graph benchmarks in the Linked Data Benchmark Council, including workloads aimed for databases [1]. We make no restrictions on implementations, they can any query language like Cypher, SQL, etc.
In our last benchmark aimed at analytical systems [2], we found that SQL queries using WITH RECURSIVE can work for expressing reachability and even weighted shortest path queries. However, formulating an efficient algorithm yields very complex SQL queries [3] and their execution requires a system with a sophisticated optimizer such as Umbra developed at TU Munich [4]. Industry SQL systems are not yet at this level but they may attain that sometime in the future.
Another direction to include graph queries in SQL is the upcoming SQL/PGQ (Property Graph Queries) extension. I'm involved in a project at CWI Amsterdam to incorporate this language into DuckDB [5].
[1] https://ldbcouncil.org/benchmarks/snb/
[2] https://www.vldb.org/pvldb/vol16/p877-szarnyas.pdf
[3] https://github.com/ldbc/ldbc_snb_bi/blob/main/umbra/queries/...
[4] https://umbra-db.com/
[5] https://www.cidrdb.org/cidr2023/slides/p66-wolde-slides.pdf
clair
-
I looked through attacks in my access logs. Here's what I found
Besides pointing pentester tools like metasploit at yourself, there are some nice scanners out there.
https://github.com/quay/clair
https://github.com/anchore/grype/
-
General Docker Troubleshooting, Best Practices & Where to Go From Here
Clair. Vulnerability Static Analysis for Containers.
-
Open source container scanning tool to find vulnerabilities and suggest best practice improvements?
https://github.com/quay/clair 9.4k stars, updated 17 hours ago
-
Postgres: The Graph Database You Didn't Know You Had
It scaled well compared to a naive graph abstraction implemented outside the database, but when performance wasn't great, it REALLY wasn't great. We ended up throwing it out in later versions to try and get more consistent performance.
I've since worked on SpiceDB[1] which takes the traditional design approach for graph databases and simply treating Postgres as triple-store and that scales far better. IME, if you need a graph, you probably want to use a database optimized for graph access patterns. Most general-purpose graph databases are just bags of optimizations for common traversals.
[0]: https://github.com/quay/clair
[1]: https://github.com/authzed/spicedb
-
Homelab vulnerability/virus scanner
Clair GitHub
-
Implement DevSecOps to Secure your CI/CD pipeline
Open source: Trivy, Gryp and Clair are widely used open source tools for container scanning.
-
Sublime Music - A FLOSS desktop client for Subsonic API servers (Airsonic, Navidrome, Gonic, etc)
Testing the image with github.com/fullhunt/log4j-scan and https://github.com/quay/clair shows no vulnerabilities
-
Automatically tag your Docker images as vulnerable in ECR
Amazon Elastic Container Registry is a fully-managed Docker container registry. It makes it easy for developers to store and manage Docker images inside their AWS environment. ECR supports two types of image scanning. Enhanced image scanning requires an integration with Amazon Inspector. It will scan your repositories continuously. Basic image scanning will use the Common Vulnerabilities and Exposures (CVEs) database (open-source Clair) to find vulnerabilities in your images. You can trigger scans on image push or manually.
- Clair – Vulnerability Static Analysis for Containers
What are some alternatives?
ldbc_snb_datagen_spark - Synthetic graph generator for the LDBC Social Network Benchmark, running on Spark
trivy - Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more
spicedb - Open Source, Google Zanzibar-inspired permissions database to enable fine-grained access control for customer applications
grype - A vulnerability scanner for container images and filesystems
ldbc_snb_interactive_v1_impls - Reference implementations for LDBC Social Network Benchmark's Interactive workload.
syft - CLI tool and library for generating a Software Bill of Materials from container images and filesystems
materialize - The data warehouse for operational workloads.
Harbor - An open source trusted cloud native registry project that stores, signs, and scans content.
Apache AGE - Graph database optimized for fast analysis and real-time data processing. It is provided as an extension to PostgreSQL.
dagda - a tool to perform static analysis of known vulnerabilities, trojans, viruses, malware & other malicious threats in docker images/containers and to monitor the docker daemon and running docker containers for detecting anomalous activities
quine - Quine • a streaming graph • https://quine.io • Discord: https://discord.gg/GMhd8TE4MR
kubescape - Kubescape is an open-source Kubernetes security platform for your IDE, CI/CD pipelines, and clusters. It includes risk analysis, security, compliance, and misconfiguration scanning, saving Kubernetes users and administrators precious time, effort, and resources.