Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I have a simple yet tricky question - as far as I know Facebook, Google, etc have more than one server for obvious reasons - maintain 100% uptime, load distribution and some more.
My question is how do they synchronize the data on the sql/nosql tables behind each and every server. In other words, what do I need to look for in order to understand how they do that data synchronization?
For smaller applications data is replicated (a built in feature of several database systems) between nodes so that identical copies exist in more than one place.
Larger systems are either sharded out so different data exists in different places or clustered.
http://www.highscalability.com is a good resource for understanding the problems of running and scaling large web applications
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 5 years ago.
Improve this question
I am curios why some prefer MYSQL over SQLITE, i am interested on learning MYSQL
SQLite is an embedded library, it requires no server process, and everything it saves is contained within a single, portable file. MySQL is an RDBMS server that's a lot more work to set up, but is multi-user, more scalable, and far more featured.
For example, SQLite is used for mobile applications as well as "development" instances of code where it's only lightly loaded. It can be used at scale but generally isn't, its simple design has limitations.
If you're writing a mobile application and need a local database, SQLite is not a bad call. Spinning up a huge, cumbersome MySQL process to do the same thing on a mobile device is a bad plan.
Although they're both "SQL databases" and have a lot of functional overlap, they're engineered to solve some very different problems. In some trivial use cases it might be an arbitrary choice as to which is best, but in most cases it's pretty obvious which of the two you need.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
Morning, we have 8 databases on our live server. I have created a new one on our test/development server. In MySQL Administrator I've backed up this new database to an SQL file, this file is on the new server. If I use "restore" in MySQL Administrator to create this database, will it affect the other databases that are there or will they carry on working as normal?
Is there a better way to do this?
The new DB is only a few k in size, the others contain many years of info and data and are huge. Any help appreciated
No, it won't. As you said that your DB is small it will not affect at all the other DB. It would if it was bigger, most probably it would slow dow your server a bit during the import (if it was bigger, huge to be precise), after the import the database will work normally. Of course it will share resource to keep one more instance working. And with time, it will make some difference in performance (depending on how big this DB grow). But you will have to be more concerned with hardware capabilities then the database itself.
Of course, I assume that when you say database you are saying about a new instance on your database.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Is it possible/reasonable to have a voting system on NoSQL database ?
For example how would be possible to store StackOverflow question into the NoSQL database.
I can easily imagine almost everything except how the relation will work between question/vote/user. Everything else can be stored in one document, like tags, comments(assuming there are relatively small amount of comments on posts, in my case I will not have comments anyway), user information, etc... but can't imagine how to store user votes as document will become huge. One of the options is that I can have votes stored in separate collection/document, but it will mean that while loading a question there will be a need to send another request to check if the user have voted for a question or not.
A good reference is the MongoDB documentation on Embedded documents vs Referenced documents, since those are what you seem to be referring into your question. There's no perfect solution, as both have their trade offs. You just have to make the best decision based on the type of operations/queries and their frequencies that you're expecting to be run on your database.
Honestly, until your database starts getting some serious traffic, the difference between SQL and NoSQL won't matter. Pre optimization can end up doing more harm than good, so I would just go with the one that is easiest to get deployed and you're more comfortable with to begin with.
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 two problems with MySQL and started wondering if I should switch to Postgres
1 - Incremental backups are only available on the paid version of MySQL.
2 - It seems that mySQL has performance issues in some cases
So, are these two problems solved with Postgres?
I guess that PostgreSQL's continuous archiving can be considered a valid alternative
for every dbms you can find plenty anecdotal evidence of situations they cannot handle properly/quickly, or only with massive help in the form of cunning query rewrites, data remodelling and whatnot. Just look around here on SO or on any of the thousands of db-centered sites all over the net to see what I mean.
In short, where 1 can be a solid argument to justify a switch (and especially from a business point of view), I wouldn't be overly concerned about 2. And if your db is slow because your datamodel is not performance friendly, you'll just carry over slowness.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I have experience with databases, but not specifically with storing/querying images with databases.
I have no idea where to start. Could you please recommend me books that concentrate ONLY on databases for media content, that is images. Storing videos would be cool too but not essential.
Thank you
Most of the time you'll just want to store a pointer to the media on a file system in the database. Then, you use the path in this field to actually retrieve the image and/or video.
Most databases have a size limit on the amount of data that can be stored in a column (I know SQL Server is 2GB, but I forget the rest off the top of my head).