Ask HN: Did I choose the right NoSQL database?
6 comments
What if I asked you: "Did I make a mistake using cream cheese?"
How the heck are you going to answer me? What's the context?
I think you couldn't give us less information if you tried. You need to explain the problem you are trying to solve, the solution you came up with. We need to see data model, example queries.
Also, this isn't a help forum. Ask in the CouchDB group, or on stack overflow.
For what it's worth, I'm going to guess that the problem is with how you wrote it.
How the heck are you going to answer me? What's the context?
I think you couldn't give us less information if you tried. You need to explain the problem you are trying to solve, the solution you came up with. We need to see data model, example queries.
Also, this isn't a help forum. Ask in the CouchDB group, or on stack overflow.
For what it's worth, I'm going to guess that the problem is with how you wrote it.
Thanks latch. You're right. I genuinely feel like an idiot for asking such a vague out of place question in this forum.
To save myself some embarrassment though.. I did outline that my use case was "web analytics" and "real-time". I also suggested I was looking for high level insight.
Still though, I can understand how you might be confused. Let me be clear. I based my expectations on this list:
http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
To save myself some embarrassment though.. I did outline that my use case was "web analytics" and "real-time". I also suggested I was looking for high level insight.
Still though, I can understand how you might be confused. Let me be clear. I based my expectations on this list:
http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
For starters, as evidenced by this post, your thought processes are confusing. You might want to try and bring some focus and clarity to your tasks.
In the beginning, it would be surprising if you already had so much data that it is the amount of data that is causing the performance issues instead of your code or db decision.
For what you are doing, I would give a slight edge to Mongo.
In the beginning, it would be surprising if you already had so much data that it is the amount of data that is causing the performance issues instead of your code or db decision.
For what you are doing, I would give a slight edge to Mongo.
It is really hard to tell that CouchDB was the wrong option, since (if I understand correctly) you're doubting your choice on performance issues.
Performance (or lack thereof) can come from the back-end as well, such as complex algorithms. Then there's the connection between the database and the application, caching etc.
I have tried cassandra for a while, but my knowledge of MySQL is so far superior that I stopped bothering with NoSQL and went back to SQL.
Performance (or lack thereof) can come from the back-end as well, such as complex algorithms. Then there's the connection between the database and the application, caching etc.
I have tried cassandra for a while, but my knowledge of MySQL is so far superior that I stopped bothering with NoSQL and went back to SQL.
Don't know about CouchDB well, but personally recommend to go to more popular one (cassandra, mongo, hbase, riak etc) so you may find better documentations and more data points as far as nosql is concerned.
I'm not sure, I have not used CouchDB (have played with MongoDB, and know MySQL etc very well).
Your description of the problem is not that clear.
Your description of the problem is not that clear.
[more detail]
I've had a great time working with CouchDB, and the guys behind it have been enormously patient helping me along on a case by case basis (I have refused them the right to tell me I should use something else, because I needed to understand why myself. Doubt is a cancer). I have rebuilt the entire back-end several times confidently, and concisely. On top of that, I'm primarily a front-end developer, so to have gotten this far is without a doubt something the CouchDB team can brag about (I can hardly manage the basics of MySQL without a cheat sheet).
But in my "smallest big client" tests, I haven't been impressed with what speeds I've gotten and fear launching in this state would highlight my lack of qualification to enter the market. Still though, I have pressed on. Maintaining the logic that not finishing is not an option (I have other ideas that are simpler to build).
So far, CouchDB has nailed real-time. The _changes makes something that seemed like a Trojan horse of complexity, as simple as a callback (when paired with NodeJS). The learning curve was slow, but ramped up quickly (remember I'm coming from no NoSQL experience). Additionally there was never a database problem I came across that wasn't due to my own error. The problems I'm having are with representing historical data quickly.
I completely accept that I may have botched some small detail, or missed the big picture during my implementation.. But for the number of iterations I have gone through, I feel like I should have nailed it by now. I am at least confident of that.
Knowing what I know now, I'm certain I can make use of some high level insight. What do you think? Was CouchDB a silly choice for my application?