51–60 of 84 posts
TerarkDB was acquired by Bytedance two years ago and is now using widely in Bytedance's database services. I am one of the maintainers of this project you can ask any question here.
Is there a backdoor for Chinese?
Earlier quoted context omitted.
There are mainly three reasons here: 1. We changed the source code too much that we are not able to merge it back to RocksDB easily (This project started at 2016 as an close-source project) 2. We have different road path with RocksDB (e.g. We will remove a lot of un-used code to make TerarkDB much more light-weight than current version in the future) 3. We have lots of third-party partners (e.g. Intel, on Opatane SSD…
3) is not in line with an open source philosophy. EDIT: Detrimental to the original. Eg. Amazon forking and selling MongoDB.
Earlier quoted context omitted.
Generally I agree, but if you don't know exactly what RocksDB is and why you'd want to fork it, this just isn't for you. There's probably a mutually beneficial filter being applied here by not letting beginners stumble in.
But what if RocksDB or TerakDB would solve a specific problem I'm facing and I just don't know of this solution? Lots of us have problems but don't know the exact tech stack to solve our problems; this is true at nearly every tech company I've worked for. My favourite anecdote for this was a guy basically reinvented map/reduce in the form of hacky scripts from Hadoop round about the time Hadoop and map/reduce was sta…
I'm saying that unless you've used and hit the limits of RocksDB - and it's already absurdly fast - there's zero reason to utilize this project.
Maybe it'll mature one day, have multiplatform support and a wide array of client libraries, and be to RocksDB what RocksDB was to LevelDB. But today is not that day.
For now, developers that don't immediately understand what this project is for would best be served with a simple link to RocksDB.
Earlier quoted context omitted.
Generally I agree, but if you don't know exactly what RocksDB is and why you'd want to fork it, this just isn't for you. There's probably a mutually beneficial filter being applied here by not letting beginners stumble in.
"but if you don't know exactly what RocksDB" So things I don't know exactly about are not for me? That seriosly hinders my personal development. As a two decade CTO I think I should be interested in things I don't know about.
Earlier quoted context omitted.
There are mainly three reasons here: 1. We changed the source code too much that we are not able to merge it back to RocksDB easily (This project started at 2016 as an close-source project) 2. We have different road path with RocksDB (e.g. We will remove a lot of un-used code to make TerarkDB much more light-weight than current version in the future) 3. We have lots of third-party partners (e.g. Intel, on Opatane SSD…
3) is not in line with an open source philosophy. EDIT: Detrimental to the original. Eg. Amazon forking and selling MongoDB.
By separating out large values there's less write amplification and things get faster because more of the SSTs fit in RAM cache. RocksDB wasn't historically a great choice to hold things like file uploads - you'd use the traditional filesystem for that. But that's quite constraining. When large values work better, it not only is a performance increase, but it enables new software designs too.
[1] https://www.usenix.org/system/files/conference/fast16/fast16...
TerarkDB was acquired by Bytedance two years ago and is now using widely in Bytedance's database services. I am one of the maintainers of this project you can ask any question here.
Earlier quoted context omitted.
But what if RocksDB or TerakDB would solve a specific problem I'm facing and I just don't know of this solution? Lots of us have problems but don't know the exact tech stack to solve our problems; this is true at nearly every tech company I've worked for. My favourite anecdote for this was a guy basically reinvented map/reduce in the form of hacky scripts from Hadoop round about the time Hadoop and map/reduce was sta…
I'm not saying don't learn RocksDB - quite the opposite. It's a great tool to have in your toolbelt. I'm saying that unless you've used and hit the limits of RocksDB - and it's already absurdly fast - there's zero reason to utilize this project. Maybe it'll mature one day, have multiplatform support and a wide array of client libraries, and be to RocksDB what RocksDB was to LevelDB. But today is not that day. For now…
Earlier quoted context omitted.
Your all-in-one docs[1] refuse to render at all in firefox? Seems like a strange restriction, and disappointing that it doesn't even let you read the document in non-webkit browsers. Feels like the IE days all over again. "An error occurred. This browser is not supported, click here to learn more." [1] https://bytedance.feishu.cn/docs/doccnZmYFqHBm06BbvYgjsHHcKc
It renders on ubuntu 18.04 Firefox but also displays "This browser not supported with https://www.feishu.cn/hc/en-us/articles/360038713913 ". Probably doesn't support linux.