Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
mapleeman
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
7 ms
·
1.
▲
The language debate is back!
(antejavor.github.io)
3 points
by
mapleeman
5mo ago
|
1 comments
2.
▲
by
mapleeman
6mo ago
The Bitter Lesson says general methods win. So which data model is least "human-sophisticated" for AI? I think it comes down to two metrics: flexibility and structure.
3.
▲
What is the best data model for AI?
(antejavor.github.io)
2 points
by
mapleeman
6mo ago
|
1 comments
4.
▲
by
mapleeman
7mo ago
I would highlight the whole repo approach -> https://github.com/cloudflare/skills Particulary -> https://github.com/cloudflare/skills/blob/main/skills/cloudf...
5.
▲
by
mapleeman
7mo ago
So this is not necessarily the tool that should help you with building your own skills, but rather the tool that will help you search so you can dynamically fetch skills that are relevant to you. Think: fetch me the Rust skills for kube.rs
6.
▲
by
mapleeman
7mo ago
Hi all, author of the skillinsight.io[1] A bit of a personal reflection on this, from a non-technical standpoint, Agent Skills are the procedural memory you keep in your head on how to solve a particular problem, which can be very valuable,
7.
▲
Show HN: We build a Graph of public Skills
(skillinsight.io)
11 points
by
mapleeman
7mo ago
|
5 comments
8.
▲
by
mapleeman
3y ago
Yeah, size classification is always tricky since the reference point always moves. If you deal more with large datasets, the spectrum would ideally move to the right for you, as you have described, since you probably need a trillion on that
9.
▲
by
mapleeman
3y ago
Relational databases have a much longer history of development, and much more engineering time has went into designing RDBMS. It is not a surprise that they are mature on more levels. By looking at the age of a product, you can get a sense
10.
▲
Memgraph Helm Chart
(memgraph.com)
2 points
by
mapleeman
3y ago
|
0 comments
11.
▲
Introduction to Benchgraph and Its Architecture
(memgraph.com)
1 points
by
mapleeman
3y ago
|
0 comments
12.
▲
by
mapleeman
3y ago
A few months ago, we shared an initial version of Benchgraph[1] here on HN[2]. There was a lot of debate about benchmarking, both positive and negative[3]. Based on your feedback, we have updated the process with new queries, datasets, vulc
13.
▲
Show HN: Benchgraph – Run graph database benchmark on your own dataset
11 points
by
mapleeman
3y ago
|
1 comments
14.
▲
by
mapleeman
4y ago
This is true regarding the transactions and cypherl. All data is cypherl transactions because memgraph can handle a large volume of transactions. mgbench was designed to run in-house CI/CD, and mgBench is still tightly coupled with Mem
15.
▲
by
mapleeman
4y ago
This is indeed a good industry leading benchmark.
16.
▲
by
mapleeman
4y ago
Hi! I'm the author of the blog post, and I'd be more than glad to answer any of your questions. I've already covered a lot of things in related Show HN last week ( https://news.ycombinator.com/item?id=33813781
17.
▲
by
mapleeman
4y ago
The difference comes from several things, JVM being the first and obvious one. It takes as much memory as whole Memgraph + small dataset in this case. Second is the overallocation that JVM/Neo4j is doing, taking a bit more memory to ha
18.
▲
by
mapleeman
4y ago
Exactly, you are right. We were able to decrease Memory usage to 1GB in Neo4j case, but then experienced some crashes. We then just removed the limit, and let it take us much as it needs.
19.
▲
by
mapleeman
4y ago
Yep, you are right. We will expand the quantity, complexity, and variety of queries in future versions.
20.
▲
by
mapleeman
4y ago
Glad you found them. Thanks for the tip!
21.
▲
by
mapleeman
4y ago
No, currently, Memgraph is loaded 100% in RAM. Agree with the point about latency regarding I/O. The story with Neo4j is a bit more complex one. They are loading graph in memory, and using disk storage, doing both. But take a look at m
22.
▲
by
mapleeman
4y ago
You are right about this 100% percent, performance is not the only factor, especially in an established DB space such as a relational DB world. There is a lot of things to consider before moving/or picking the database.
23.
▲
by
mapleeman
4y ago
Added Dgraph to the reported ideas/request for the next benchmark version: https://github.com/memgraph/memgraph/issues/689 :D. What are you doing with Dgraph, and what are the requirements for use-case?
24.
▲
by
mapleeman
4y ago
Yep, that is possible. Actually, one of the community members few days ago did this: https://gigi.nullneuron.net/gigilabs/using-the-neo4j-bolt-dr... You just need to tell driver, it is not Neo4j. If you want to continu
25.
▲
by
mapleeman
4y ago
Thanks for all the comments and inputs. I have added the suggestions that we plan to implement: https://github.com/memgraph/memgraph/issues/689 . Both on Memory usage tracking and precise data on load/inp
26.
▲
by
mapleeman
4y ago
So these results were not cherry-picked since the same queries were run previously in our CI infrastructure. Yep, as you have said, performance is just one of the things that matter. A lot of things matter when picking a vendor, some are me
27.
▲
by
mapleeman
4y ago
Thanks for the input. It is a fair point. It is hard to create benchmark that is universally fair. But both things serve the same/similar purpose, on top of that, Neo4j also loads a bunch of stuff into RAM, consuming more memory than M
28.
▲
by
mapleeman
4y ago
Yes, good point, but both Neo4j and Memgraph( https://memgraph.com/product ) are ACID-compliant and have on-disk persistent storage. Memgraph is currently RAM constricted, while Neo4j is not but it is hungry for RAM.
29.
▲
by
mapleeman
4y ago
This is a great idea, with one relational database as a reference point for every query on the graph database. I added it to the backlog: https://github.com/memgraph/memgraph/issues/689 Thanks for the idea! :
30.
▲
by
mapleeman
4y ago
We plan to add more graph database vendors to this benchmark, this will not be just Memgraph vs Neo4j comparison, hence the name "bench graph". You are 100% right about comparing architecturally different database systems, it is
More ›