Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am developing a Real Time messaging application (such as WhatsApp and co) and I am facing a big question.
The application itself is not as complicated as what exists on the market. However, I am no sure what storage system I should use. I have several ideas but I don't know which one is better that the others:
A simple mysql database with relations between messages/conversations/conversations
A mongodb with replicate of each conversations for all users in the conversations
A redis store with replicate conversations for all users in the conversations.
I don't know which one is better for what I want to do. If you have some advise so I can choose the right solution. (or if there is a solution I haven't listed which is even better :) )
Note : My API is developped in Ruby On Rails (if this can help make a decision)
Data volume and number of read/writes should be the key factor leading you to the decision. If the data volume and number of read/write is not going to be huge you can do with mysql. I believe few TB of data with few hundreds of read/writes per minute is SQL database territory. Beyond that it is NoSQL world. However, you should be ready to deal with increased complexity of non-SQL data store design, query implementation, and achieving eventual consistency if you choose NoSQL solution. All the best!
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
We're about to start developing a scheduling system and we're motivated to migrate from PHP to Node for the Backend, so it makes sense to also migrate from MySQL to MongoDB (or something similar), I'm not a very tech person, but I'm trying to help my team to make the choices here. All features of this system seem ok to be with either database, but one particular situation raised me concerns regarding performance:
Let's assume I have several doctors on my base, each one with their specialties and clinic locations and also with their time span to work on this system. They also already have some appointments scheduled for spread hours during the weeks.
One user fills the search form with:
Their geolocalization (x,y);
The search radius (ex.: 10miles);
Specialization needed (ex.: dermatologist);
Desired hour (ex.: 11am);
This search, for my old-school mindset, seems OK for a relational database, but a lot of work for non-relational, since their availability will be inside each doctor 'JSON', and not in a specific external 'table' for scheduling.
Do my concerns make any sense?
You can achieve the desired result with both SQL and NoSQL database. But the project you are talking about is more relational design. Example:- Doctor can visit multiple clinics. A patient has also related to the Clinic as well as the doctor. The best solution, in this case, is the hybrid approach where your primary database should be relational and for the reading operation, you can plug NoSQL database like MongoDB if required.
#Rafael Souza
You should go with Relational schema design.
If you use NoSQL then in our case below are the points I want to convey
NoSQL will not be utilized fully at its best.
Developers will have to learn NoSQL and its frameworks.
There is a vast forum for SQL problems compare to NOSQL.
Database storage size would not big so SQL should do good.
Here you need to manage the relationship between Doctor and Clinics which is best suitable in SQL.
I should say that don't go with the Hybrid approach as it will be overhead for your design, any database type is alone capable of handling all the features.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am thinking of storing persons contact data centrally. So there will be so many persons and each will have their contact list. There will be more number of updates and selects on database as user will be searching their contacts or searching for a person not in his/her contact list. Person may be updating their contact details. But inserts in database will be limited because only one time enrollment will be there. I am confused in using databases MySQL or Neo4j. Because when I think of searching person from database neo4j seems better. But when I think of handling millions of records MySQL seems better. So can anyone suggest which database suits best? MySQL/Neo4j/ both MySQL and Neo4j or some other database?
Neo4j allows you to store the connections between the people via their contacts, so if you want to leverage the network effect in your application it makes sense to look into that.
It all depends on how you want people to search and interact with your app. If treat people as individual records with no connections then MySQL is good enough. Otherwise Neo4j would probably work better.
IF you have the time to a tiny PoC with some realistic data with both and then decide for yourself.
you can use MySQL latest version it is quite simple and relevant to your need , you need to just use locking system on your database or you can lock your table when inserting or updating.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a project which is using NodeJS and I have different entities for example, people and places.
I need the ability to find both types of entities by location together so what I was thinking of doing is having an index on a field called, type, for example, which would be either person or place and make use geospatial indexes, does this sound a good way to do this or is there a better way?
I will probably need a lot of joins too, so should I use MySQL alongside MongoDB and use MongoDB just for delivering the location based queries?
Thanks
This question is a poor fit for stackoverflow, but here's some radom bullet points:
PostgreSQL supports both joins and geospatial. I'd pick that first personally lacking other details warranting a different data store.
A totally valid option would be to keep people and places separate and query multiple collections as necessary. However, if you need to sort the results, then yes best to throw them in the same collection.
You could also keep people and places in separate mongodb collections but have a mapreduce job translate them into a locations collection for search purposes.
Generally, there are lots of ways to do this and the best one depends very much on the specific aspects of you application. Reads vs writes, data stability, data size, query load, etc, etc.
My broad word of advice is start with the most logical, easiest-to-follow, straightforward data organization (separate collections), and deviate from that when you understand the specific pain you have and how doing something more complicated or unusual will be an overall win.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I need to create a database for dealing with click stream (from ~240 subdomains). I use a Java Script for grabbing information like (Host, Page, Date, userID, Referer, HostName, RefererPath, uniqueUserID) for each click and than insert the data to the database through a java web dynamic application. There are about 9 milion new records each day and I have to insert new records every minute. Another application needs to be able to retrieve information about pageviews/unique visitors/ect for a certain article/subdomain in the last (10min, 20min, 30min, 1hour...24 hours). I only need to keep records for the last 3 months.
Initially I thought about using MySQL as I'm only interested in open-source. But I'm thinking about NoSQL solutions. The problem is that I've had experience only with relational databases and am not really able to tell if NoSQL would be a better solution here or not. Also which database should I use if I choose to go wiht NoSQL? and would Key-value store be the best way to go?
I'm guessing this data consistency isn't critical (statistics ?) so you could indeed spare a bit of consistency. NoSQL seems a good choice and a key value store would also be my pick. Now the real question is : what is the most suited one ?
I'd give a consideration to Redis and Riak (which are basically the most well-known ones) :
Riak (AP system) :
Fault-tolerant (masterless with partitioning and replication)
Map reduce
Full text search
BASE
Redis (CP system) :
Really fast
In-memory : You need RAM ! That also means you want replication so you don't lose everything on a crash. Redis also uses disk snapshot I believe.
Master/Slave with reelection
BASE
Both have a lot more features, you should go read the documentation for gotchas. Redis is primarly used as a cache since it's fast, whereas Riak focuses on fault-tolerance. Given your scalability requirements, both can satisfy your need. Therefore you must chose according to what's above.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What are the pros and cons of using a NoSQL database (like MongoDb, etc) entirely for a web application which is intended to be a social networking site. I mean, for the User accounts and other credentials to be stored in a NoSQL database, instead of using SQL like MySQL with Hibernate and totally relying on NoSQL, is it a good approach? If not, what are the trends in designing MySQL entities or domain objects (usually User accounts, etc) "bind" to a NoSQL database (which are usually posts, messages, etc.)?
Here are the issues you should consider:
Latency
NoSQL solutions are designed to do well here. They generally write data to memory which is flushed to the disk in batches. If the server crashes before it is written, the data might be lost. MongoDB has Journaling, which will help recovery from crashes. So no issues here
Reliability
NoSQL solutions offer in-built solutions for replicating data. With MySQL, you'll have to do this yourself
For a social network scenario, document stores like MongoDB are a good idea for activity, comments related information. The user data can be stored in a MySQL database