SQL and NoSQL in the same project

0 like 0 dislike
42 views
I would like to know opinion of knowledgeable people about crossing in a single project SQL solution (MySQL) and NoSQL (MongoDB). On the one hand, somehow not on Feng Shui to use both at once. But on the other hand, separately each decision is not fully satisfy the needs.

On the one hand the project it is necessary to use a very large number of documents with variable structure (different number of fields (which is mandatory)) and different size (from 200 bytes up to 200 kilobytes on average) and this requires a lot of speed work with them. On this MongoDB is very well suited for this. It is also quite easy cluster to increase speed and failover (Replica Sets + Sharding)

On the other hand in the project you want to use a lot of clearly structured data that are very closely related to each other. And store them in a nonrelational database is simply not feasible and quite uncomfortable to extract information(restore relations may require hundreds of subqueries). And all that is connected with removal, will generally cause a lot of inconvenience. At the same time, these data — minimum quantity (in comparison with the number of "documents"). So the whole work can be organized through a single MySQL server.

If you only use Mongo, it will cause a lot of problems when working with related data.
If you only use MySQL, you will have problems with scalability, speed and data storage

Who believes if you want to use both approaches at once, or to come up with anything else? And has anyone used these in practice?

PS the Project is a normal web service but it must withstand a heavy load and should have a good horizontal scalability.
by | 42 views

6 Answers

0 like 0 dislike
>> On the one hand, somehow not on Feng Shui to use both at once
\r
Here, just have to decide what is more important — Feng Shui or timeline.
by
0 like 0 dislike
Your project, say — would be done now would only MongoDB. The main problem is search. At the same time to do a search on one database and another, and how to find the intersection of data? That is, we need to find the users profiles (SQL with constraints) with red noses and green ears (Mongo). In the end, we need to do or a request to the RDBMS, and then the obtained id to search for Mongo with settings or Vice versa were found in Mongo parameters to look in MySQL (or other database).
\r
If the data bit, then no problem, but when the number of similar data increases, and increases the number of records that need to carry from one base to another.
\r
Now the search will move to more ideologically kosher Sphinx, but the project will be to rewrite the full MongoDB.
by
0 like 0 dislike
Perhaps you're missing another factor — the killer feature of many relational databases (although this is irrelevant to the classification of sql/nosql, but in practice it is) is to support ACID. Using transactional and not transactional storage together you eventually have a common repository is not transactional... It is the only BUT if you use your approach. Generally advise quite difficult as there are such variants:
\r
1) Use only MongoDB. Kaki any queries he has. And maybe in practice it will not be as scary as you think. For example "hundred-subqueries" can be faster heavy sql nick joyname.
\r
2) Use only the RDBMS. Storage of documents can be implemented for example in XML. Many databases do not know about MySQL, but Postgresql allows you to do queries using XPath. Scaling to make the handles on the client with the storage of meta-information, "where a set is" in some Riak.
by
0 like 0 dislike
> somehow not on Feng Shui to use both
\r
Why do you think so? If because there are two warring camps of fans, some like to break a lance and to Troll, others to work.
\r
This, by the way, it says on the website Mongi www.mongodb.org/display/DOCS/Use+Cases
by
0 like 0 dislike
Use memcache (also because key-value storage), together with the RDBMS just stores each responsible for their own, for something better than that.
by
0 like 0 dislike
On the one hand, somehow not on Feng Shui to use both at once
And immediately we read what does NOSQL. Then take your brain, put him in his place and understands that for each task you have to use your tools.
\r
\rOn the other hand in the project you want to use a lot of clearly structured data that are very closely related to each other. And store them in a nonrelational database is simply not feasible and quite uncomfortable to extract information(restore relations may require hundreds of subqueries).
\r
You just trying to model of working with RDBMS to migrate to Document Oriented Databases?
by

Related questions

0 like 0 dislike
3 answers
0 like 0 dislike
7 answers
asked Mar 28, 2019 by ZhukV
0 like 0 dislike
1 answer
0 like 0 dislike
3 answers
0 like 0 dislike
1 answer
110,608 questions
257,186 answers
0 comments
28,662 users