Skip to content
This repository has been archived by the owner on Oct 23, 2020. It is now read-only.

Consider ToroDB #250

Open
cmc333333 opened this issue May 25, 2016 · 1 comment
Open

Consider ToroDB #250

cmc333333 opened this issue May 25, 2016 · 1 comment

Comments

@cmc333333
Copy link
Contributor

I haven't used it myself, but ToroDB looks like it'd solve some of the pain points I remember from trying to model data via MongoDB. In particular, it'd avoid the field-name hashing scheme, reduce disk use, and give you a path towards a tabular data store (which seems appropriate for the types of queries Qu performs).

@jonathanwcrane
Copy link

I just saw something today that's relevant on reddit:

https://www.reddit.com/r/programming/comments/4l24hn/scaling_to_100m_mysql_is_a_better_nosql/

The top comment is pretty interesting.

The upshot of it is, MySQL probably outperforms MongoDB for the kinds of workloads Qu sees.

If we were going to build it on AWS and needed more performance than what MySQL does, AWS has a variant called Aurora that uses the same drivers (so exactly the same code) which is about 5 times as performant as MySQL.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants