midom

6 ms·

1.
by midom 3y ago
rocksdb is used in many more systems, but the storage layer behind TAO (UDB) is using MyRocks for quite a few years by now - migration was done in 2016 or so - https://engineering.fb.com/2016/08/31/core-data&#
2.
by midom 3y ago
/wave
3.
by midom 3y ago
https://developers.facebook.com/videos/f8-2018/cassandra-on-... (there's not much Cassandra now, though)
4.
by midom 3y ago
something doesn't make sense here - MySQL/InnoDB does put tables into files, but partitions get separate file. MyRocks has a collection of files per each column family, and when you drop data it can quickly expunge files that don&
5.
by midom 3y ago
this misses multiple points - lots of block access happens via internal caches (hyperclock/lru/etc) and filesystem isn't in the critical path as much as you'd think. files are mapped out in relatively large chunks, espec
6.
by midom 5y ago
> Facebook has gone through many databases. Main use cases (social graph, messaging, ..) are on MySQL (and never left it). Storage engine is different, replication is improved, etc, but it is still tracking upstream MySQL tree. The thing
7.
by midom 5y ago
I'm not sure page level compression can get efficiency of LSM-Tree, and frequent page writes will be a write amplification problem if you end up doing any form of copy-on-write and try to do in-place overwrites.
8.
by midom 5y ago
¯\_(ツ)_/¯ optimizer guy says he did not do good job, shits on optimizer? There're many reasons to pick MySQL over PG at large scale deployments (economics, replication strategies, etc) - and the fact that some queries will run bet
9.
by midom 5y ago
there's also this team page, although it has been somewhat lower on volume lately - https://www.facebook.com/MySQLatFacebook/
10.
by midom 8y ago
I can see some MySQL Infrastructure people in it :-)
11.
by midom 8y ago
based on his previous submissions, he did not come here to discuss database technology or be factually correct.
12.
by midom 8y ago
doesn't really qualify much as research - just lots of engineering to cover all corners
13.
by midom 8y ago
+ app server / schema rework
14.
by midom 10y ago
technically, it is a patch set, it gets frequently rebased against the upstream
15.
by midom 10y ago
As long as you can shard (across multiple instances, or even within same instance, to avoid B-Tree latching), 1B+ rows within MySQL is piece of cake. Also, MySQL* is getting LSM-Tree support lately, which makes high performance data ingesti
16.
by midom 11y ago
LIMIT 2 is also exposed to this issue, at different data ratios (in my tests up to LIMIT 142, I went through the math).
17.
by midom 11y ago
So sad I can't see or reply to that comment anymore - I'm the author. Sorry, HN, my personal blog rarely gets that wide circulation, I should've done better job at introducing the context. This was just one of many systems t
18.
by midom 11y ago
It was conversion from standard MongoDB to RocksDB based MongoDB, so replica count calculations don't really apply. And yes, Mongo did not optimize for space efficiency, which is why there're efforts to optimize for space efficien
19.
Flashcache at Facebook: 2010 to 2013 and beyond(facebook.com)
6 points by midom 13y ago|0 comments
20.
by midom 14y ago
1, O_DIRECT, 1
21.
by midom 14y ago
No, that is not the highest praise you can get from me. It definitely is very interesting technology, and what it does well, it does really well - though I didn't get to benchmark parallel performance, as I had work to do :-) I wouldn't hav
22.
by midom 15y ago
oh well, maybe indeed I assumed more about general knowledge of new database technologies around. voltdb (Stonebraker's solution) is in-memory store, so are few other of all this new wave of solutions (e.g. you don't want active mongo datas