I am coding a web portal which stores a lot user data and later on maybe documents. In the meantime I use MySQL with many relations. I have read much about NoSQL and find that it is an interesting topic.
Is MongoDB or CouchDB ready to fully replace MySQL? Would something change in the usage of Doctrine in my application?
Is MongoDB or CouchDB ready to fully replace MySQL?
Sure, lots of people are storing their entire data set in MongoDB instead of MySQL and they are doing fine.
But I do not think that is the correct question. The key questions are really the following:
Does implementing MongoDB improve your system? Less queries, more flexibility, better performance?
Are you capable of implementing MongoDB at the appropriate scale?
MongoDB is a tool like many others and it does not solve all problems. In my experience, most systems are best implemented with some mix of databases. That would means something like MongoDB for some data and SQL for other data.
Related
I am building a social network (connections and their connections, messages and locations) and I am a little confused in deciding whether to go with a relational database (MySQL) or a no-sql system (MongoDB) when designing our backend APIs. Does anyone have any views on what to use when?
PS: I am building developer APIs for developers to tap into our system with oAuth. So scalability and performance is also key factor. Rails 3 + Devise (most likely).
This depends largely on which technology you are comfortable with, what exactly do you want to get out of this etc. etc.
Coming back to your question, not all data is relational. So For those situations, NoSQL can be helpful. With that said, NoSQL stands for "Not Only SQL". It's not intended to knock MySQL or supplant it.
SQL or MySQL has several very big advantages:
MySQL is Strong mathematical basis.
Declarative syntax.
A well-known language in Structured Query Language (SQL).
Highly proven and extremely reliable technology. MySQL has been around far more than the oldest noSQL. It's a mature piece of technology. Google Adsense runs on MySQL, Facebook persistent store is MySQL. The examples suggest its reliability.
As a result of being mature technology, people have optimised the shit out of it.
Enormous online and open source community both for support and providing features as opposed to noSQL technologies (look what happened to Cassandra)
In my opinion, all the above questions matter to me when I choose a piece of technology. Hey well, if it's a Sunday evening project that you want to whip up with little real world consequences then do what whims you but if it's slightly more serious then please consider these questions.
SQL hasn't gone away (even in noSQL). It's a mistake to think about this as an either/or argument. NoSQL is an alternative that people need to consider when it fits, that's all.
Documents can be stored in non-relational databases, like CouchDB or even in MySQL (it borders on abuse but still). A Relational database in principle could make a very good NOSQL solution
Check out this hilarious video. This gives a different perspective on this topic :)
I chose MongoDB for my "Social" application because of the flexibility of the schema and scalability/performance. MongoDB has allowed me to adjust my schema without having to make drastic code changes and makes reading/finding data very easy.
I also chose MongoDB as a learning experience. I wanted to know what all the fuss was about with these "noSQL" databases...and now I know why. MongoDB is awesome in my opinion and definitely worth looking at for a Social network that requires scalability and performance. Node.js would also be an excellent choice for the API ;)
neither.
Go with a network/graph database, you will not regret. My current favorite is Neo4j.
http://neo4j.org/
note: Not related to Neo4J
I think the latest version of Neo4J has a sql interface, just in case you would need SQL compatibility. Otherwise, do your crud using their native library. It is very fast.
If you would need to visualize the Graph data, which would be very impressive to show to your boss, use yEd package. To export neo4J to a graphml format, use this:
Convert Neo4j DB to XML?
You could front end your relationships in Neo4J and backend it with a relational db or mongodb. I have seen those hybrid architectures as well.
If you project requires actual relationships between certain objects then MySql will be fine. If you are storing things that typically just have inherent data to them, such as a user with messages to other users, then a document style database, such as MongoDB, makes more sense.
You can do relationships in mongo, but they make a lot more sense in a relational database. But, if most of your data is more inherent of a user then mongo makes more sense.
In your case a document type of scheme makes more sense where each user has a list of connected users and their own personal atributes, ect...
I'm using a php framework with a mongodb adapter that doesn't currently comprehend embedded documents as a Model/association relationship. After reading about mongodb for a few days it seems that you should use embedded documents for objects that are most often displayed together. This makes a lot of sense to me. It was said during one mongo schema talk that a collection of many small documents can negate some of the advantages of mongo over an RDBMS.
In searching stackoverflow and beyond, I can't seem to see what advantages exist, if any, when deploying mongodb into an environment where it is implemented with a reasonably normalized schema like you'd find in a traditional RDBMS.
Are there still advantages to using MongoDB when used in this way? Scaling? Performance?
If by "reasonably normalized" you mean that you need information from one table to filter the information from another table (i.e. a join), then mongo is going to work against you. In a SQL database you can easily get the info from multiple tables with a single query. In mongo you'll need multiple queries to get data from multiple collections. Any speed advantage mongo gives you in pulling from a single collection will quickly be negated by making multiple round trips to the database.
Here are some advantages that MongoDb might give you (depending on your usecase):
Schemaless: More flexible if document structure is modified later.
Performance: MongoDB utilizes the RAM available very well making it very performant
Easy replication: Replication is easy to setup
Sharding/Clustering: MongoDB is designed with sharding in mind. It is easy to setup and doesn't require experts.
Map/Reduce: If you happen to need this, there is built-in support.
Javascript: Intuitive to use if you already know Javascript (and who doesn't nowadays :) )
MongoDB website has a good list of casestudies of production deployments.
MongoDB has replication and sharding built in.
These are things that can be done with MySQL.
The downside is the learning curve and lack of programmers that know it.
If it's just for you, it would be fun as a learning project.
If this is for a larger project, you'll need to weigh the lack of MongoDB programmers and learning curve against popularity of MySQL.
I have been developing my University dissertation project with MySQL first then thought to give a shot to MongoDB to improve performance. Rewriting code was really easy and straightforward with Jongo. Production has been really smooth.
Unfortunately performance were terrible. I am not particularly skilled with MongoDB queries, but I believe I did quite a lot of research: I have used map reduce, I have used the aggregation framework, $limit and all that stuff... when at same stage I got the message: "request heap use exceeded 10% of physical RAM" I really gave up and delivered the MySQL version.
For me it's really a shame because I was working so hard to make it work the best way possible with MongoDB (as a University project stands out if you do something different). However I think I will continue study MongoDB in future, but for the moment I stick to performance (or better what I can make perform).
I hope my comment will not offend MongoDB fans, but this is my experience.
i am writing code for friend list and messaging system for my college website.I need to store interconnected data.. need to search them ...It has about 3500 records..So which way I proceed MYSQL or XML ..which is fastest..which is best ?why?
I'm going to use one of my professor's favorite answers here: "it depends."
XML and MySQL have very different applications. If you need to be doing lots of simultaneous queries for all sorts of sophisticated things, MySQL is your clear winner. Sometimes MySQL can be hard to use in some applications because you must first create a database schema in which to fit your data. It sounds like though, that you have many records with the same structure, and it would be easy enough to throw them into a database. With a SQL based database engine like MySQL, you can also construct queries using the standard SQL language. Database optimizations can also help to increase the performance of these types of queries, for example, you can used indexes and keys. If your data needs to be updated regularly, than MySQL will likely provide better performance as it will not have to rewrite the XML file. If you need your application to scale to many simultaneous connections of sophisticated queries, you are definitely going to want to go with some sort of SQL solution.
Depending upon your application though, sometimes there are other ways to store and access your data. I for one once needed to create a persistent data structure on the disk which could be accessed very quickly, but never updated. For that, I used cdb. There are also other database systems out there like the Berkeley database, and some No-SQL solutions such as couchdb and mongodb. I posed a somewhat interesting question here on stackoverflow on the use of No-SQL solutions a little while back which you may find interesting as well.
This is really just a sampling of different considerations you may want to make when you are choosing how you want to store your data. Think about questions like: How frequently will things be queried? or updated? What will your queries look like? What kinds of applications do you need to access your information from? etc.
I am thinking about using one of two databases - MySQL and MongoDB. I am planning to storing text and numeric data and I will building my app in RoR.
So I don't know, which database system could be better for this purpose - can you help me, please, under which criterium I will decide?
Let me cast this question within more general setting and into some historical perspective.
In the 60s they were asking whether to use hierarchical or network database
In the 70s the debate was relational against network
In the 80s Relational turned into SQL databases, so question mutated to SQL vs. network
In the 90s it was SQL against object databases
In 00s it was SQL against XML databases
Today we have SQL vs. NoSQL
Do you see a pattern here? Would you still bet some money onto SQL competitor, especially if it's nothing more than glorified hash table?
I have used also MySQL and MongoDB with Mongoid in my projects, and I can say that if you want to keep binary data like images, mp3s and other stuff in your database so try Mongo, for other reasons you can use SQL databases. MongoDB has no structure - you processing the hash, so you can dynamicly add and remove keys/columns.
In your case I would use MySQL.
In my opinion you should base your decision on the purpose of your application. Do you want to search through your text data, how will you define keys. There is little use in going for MySQL if you have to request each record and scan it. Even if there is functionality to do text scans in MySQL (does it have that?) MongoDB will probably do the job more efficiently. The other way around, if you are not going to use MongoDB's strong points then you might as well go for MySQL.
Another factor might be the deadline for implementing something. If you need it fast, don't waste time on learning something new. If you have time to experiment, figure out the key features you will most likely rely upon in your application.
I think, if you need a hard structure you should use MySQL because it't its nature, but if you need something more dynamic, whith no structure at all (schema-less) you should use MongoDB, I've never use MongoDB but I know it's more object/document oriented.
It would be helpful if you could provide some more detail. Would your data easily fit into a schema, or do you need the flexibility that a document store offers? What about auto-sharding, etc? Without more information, no one can give you advice that fits your needs. Lacking that, you can't hope for feedback any better than people's personal preferences, which is little more than a flamewar waiting to happen.
Whilst testing a Solr install for a future MySQL -> Solr migration, it's immediately apparent that the "rules" for what constitutes a good data stucture, and by extension an efficient search, are very different in Solr when compared to an RDBMS like MySQL. The most obvious thing being that data isn't (or doesn't seem to be) normalised to the same degree.
Does anyone have any advice regarding the best way to go about making the transition from MySQL to Solr? Are there any established patterns for structuring data in a non-RDBMS (Solr specifically) that I should be learning about? Any common pitfalls to avoid? Is it simply a case of de-normalising related tables into objects?
First of all, you have to ask yourself if you want to:
migrate the whole thing to Solr or
just use Solr as a complement used for searching.
For anything other than non-trivial relational schemas, I'd recommend #2. The more heterogeneous data you have in one index, the less useful it is.
The Solr Enterprise Search Server? If it were me doing it, I would migrate only your documents over, not the entire database. Is that feasible?