document store databases allow you to "basically store anything". this freedom makes it extremely difficult to analyze the results, especially with large amounts of data. graph databases handle wildly recursive relationships, but that often isn't good
Post by twetch#7453
if you really care about graph like data, geospacial indices within relational systems are probably one of the most interesting methods you could use to scale
i would love to see someone pull off a graph db equivalent using spacial indices in SQL. really wouldn't be that hard, could probs beat neo4j performance on high d recursion pretty easily
What the chain says
- Block
- 660 013
- Time
- 2020-11-05T19:57:45Z
- Signer
- 1F8LZF7xb8a7aSnGV226bXECALFP9u8gsQ
- App
- twetch
- Type
- post
- Content type
- text/plain
- Name in tx
- twetch#7453
Fields the transaction did not carry are omitted. Open the payload to see the bytes as stored.
1F8LZF7xb8a7aSnGV226bXECALFP9u8gsQ VerifiedReposted by (1)
Replies (9)
i havent really looked into urbit's graph store yet, but i just don't think mongo is that interesting or useful for scalable systems. i hope that there is more to it than that tbqh
I use foundationdb also. It’s not even meant for other than a datacenter really, running it on localhost isn’t it.
oh that looks pretty interesting, quite scalable lol
I run over 10 machines and a shadow for backup. The timeout is hardcoded to 5 seconds, so app devs need to take that into account
handling it.
the reason this is important is bc mongo isn't particularly difficult to implement and i wouldn't call it a graph. frankly, it's just not that useful for scalable applications imo. i have not looked at urbit's yet implementation though so i can't judge
interesting that it's more like mongo than neo
To a noob like me this kinda sounds like #21e8
hahahaha in many ways you're spot on. indices off of a hash based placement model are basically that, just in abstract space https://infolab.usc.edu/DocsDemos/yao_vldbjournal.pdf (i *think h/t @1623)
😏
#21e8masterplan