Would a language like C or rust make more sense for development of Dgraph, where memory needs to be carefully looked at?
Is the api stabilized for Dgraph? Who are using dgraph for production?
Would a language like C or rust make more sense for development of Dgraph, where memory needs to be carefully looked at?
The tradeoffs for each solution (i will group C/C++/Rust as assembly DSLs) :
For operation with I/O
Assembly DSLs
The constant need to create threads to handle concurrency adding threads which have a memory/cpu overhead (google cpu context switching to get the visualization of what happens to threads blocked on a system call). You can read about nginx vs apache performance (both written in C but under different designs for thread management end up with different performance).
Golang
Basically abstracts the concepts of concurrency threads become goroutines ( which by default are set to spread the workload equally between cpu cores). It has also an api for efficient concurrency and i will let this quote from the golang documentation for the runtime illustrate the underlying thread system :
The GOMAXPROCS variable limits the number of operating system threads that can execute user-level Go code simultaneously. There is no limit to the number of threads that can be blocked in system calls on behalf of Go code; those do not count against the GOMAXPROCS limit. This package’s GOMAXPROCS function queries and changes the limit.
For latency
Assembly DSLs
going back to first point. managing threads and allocating/freeing memory is expensive in time .
Golang
has been optimized for low latency above all else (binary size, memory usage …) please refer to the link in the next section.
For memory
Assembly DSLs
No argument you are right you have better control on the memory requirements
Golang
Nothing i can say about it isn’t illustrated here. On modern databases memory issues are common enough (Elasticsearch has a track record for high memory usage even though it uses java and all the GC algorithms it has) but in the case of Golang the low latency comes at higher memory usage spikes under high load as the only implemented algorithm for it is mark and sweep.
For security/Resiliency
Assembly DSLs
You have to think everything from the ground up and even the smartest people make mistakes and you have to constantly use libraries to avoid reinventing the wheel hence increasing the attack surface.
Golang
Core api is maintained by google and it has a nicer error handling system.
As you can see golang isn’t such bad options when take it into consideration all the things that you miss out with other languages. I would also point out that Golang comes with a framework for benchmarking at that for having debugged goroutines spikes it usually happens when you have a high workload for a long period of time which in a realistic application context never happens unless you under provisionned in which case just add more ram it’s cheap enough.
the lines below are only my opinion so take it with a grain of salt
Is the api stabilized for Dgraph?
It depends on what you consider stable :
→ If you’re working on a quick and dirty project that you’re not looking to maintain/scale/improve i would advise you to seek some old database system.
→ If you’re building your startup i would advise going for dgraph (it will pay for itself in a few months)
Who are using dgraph for production ?
i couldn’t find any information but i think most people would not go out screaming that they use a new database system that is marginal in its market share. The saying Nobody ever got fired for buying IBM works the other way around.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.