3
I’m creating a mobile app and need to use a database to store user data. I’ve thought about Sqlite, but it is not recommended to use it on sites with more than 100 thousand requests per day, and if my application has this number of requests, I’m afraid the database has some error or something like.
If I choose Sqlite as a database, can I exchange it for another database later? And you can suggest me some database other than Sqlite that allows more than 100,000 requests per day?
6
Your question is part of a false premise. First this is a value thought about 10, 15 years ago and was well, very conservative, and does not consider appropriate techniques to increase this capacity. The Sqlite has improved a lot since then, the hardware has improved (SSD, NVRAM coming), thought of better techniques, and in practice could always more.
I think it’s naive to post that value, because capacity can’t even be measured that way, it has a lot of false premises in that information, and worse not have updated.
Note that the official page is talking about a web server that has concurrent access and not a mobile device that does not usually have concurrent access. Actually the page says that only 1% of websites are not suitable. So it is another false premise.
My experience is that in fact 0.1% are not suitable for Sqlite (considering all, even those that not even a DB needs), if used correctly. Do you think you will be one of the 1% most successful sites in the world? That means you will be one of the 20 or 30 largest Brazilian sites. Even if one day it happens, you will have so much money coming from this site that you can hire the best professionals and buy the best tools to solve your problem.
Even the most sophisticated databases often need auxiliary tools, suitable techniques to withstand. This site you’re using now is one of the 30 most accessed in the world. It uses SQL Server, but the ability to handle all of this is not because SQL Server is excellent, it’s because the engineers who take care of the site are excellent. There’s a much smaller site that used SQL Server, Oracle, Mysql, and other things and opened its mouth. Why? Whoever did it didn’t know what they were doing. Without understanding how things work any tool can be the wrong one.
See more about where it can be used for real.
You can always change the database, but I doubt that one day you will need to use Sqlite on the web server (I just can’t guarantee it in all scenarios). If you are going to use mobile you will never have to change, because the hardware of a mobile phone can’t handle doing so much operation, Sqlite is less of your problems. But I imagine you’re only saying this because you think you have thousands of connections on a mobile device. And it’s another false premise.
If you think people will install Mysql, Oracle, etc. on your phones, you are very much mistaken. Not that I can’t, but this is crazy that I’ve never seen anyone do it except for an experiment.
As already said Sqlite can meet millions of requests a day if used correctly. This is more than nearly every website in the world needs. But if on the server want another DB, and even there are reasons for it, but not because Sqlite is not good, the most used for web is Mysql, although many people are preferring Mariadb which is a Fork mysql.
You can also use other relational databases or not, but the decision of the correct tool goes through a deep analysis of very experienced people to get it right. If you are struggling with something so basic, it is best to go for the simplest (Sqlite) and hire specialized people when you need something sophisticated.
That’s what I always say, people need to learn how things work, check on their own, and not believe what’s written out there, most of the information available on the internet is wrong. Because there is little canonical information, and even this may be wrong, as is the case, and there are copies of distorted canonical information, such as a wireless phone.
As the AP will use locally, Sqlite is ideal for it. Now, on a website, I strongly recommend against (unless it’s like sqlite.org, which only makes use of read access - still, in this case it’s best to generate and serve static pages). The competition issue already prohibits any site with reasonable traffic and access to read/write from using it. But even low-traffic sites would be better served with other http://zenadmin.org/en/blog/post720.html solutions. I also disagree with the fanciful statement that only 20 Brazilian sites would not be well served with Sqlite.
@rodorgas I imagine that ignores the real capacity of Sqlite and the real need of most sites. His ability to read is better than many other databases. The writing capacity is limited, but as he writes much faster than the other banks he can serve well more nearly concurrent writing cases. I didn’t say that only 20 Brazilian sites wouldn’t be well served by Sqlite. I’m talking about its capacity. And I’m talking about proper use. People are surprised how this site that is among the 25 most accessed in the world run with so little resource.
What I’m talking about is that if the engineering is the right one the tool matters less. There are several, I said several benchmarks that show how Sqlite is much faster than Mysql and other databases. You really need to know how to use it right so there’s high competition, so clearly the one you’ve caught is a case of someone who doesn’t know. If you have too much writing competitor It is not suitable, but most sites have very little writing. At least they should have, if they don’t have or fall in a case that really needs something more powerful or falls in case it’s been done badly.
My point is on top of that. If you do well the Sqlite is very suitable. If you do it wrong, and a lot of people do it wrong, then the tool starts to matter more. You can believe whatever you want, that’s my experience. People underestimate the ability of Sqlite and oversize the need for a website to write. The posted benchmark is very old and does not say how it was made.
It looks like the absurdity is great. 100,000 requests are not page views. But I will consider that they are. That is just over 1 per second of the day. Of course there are moments of greater use. If you have that much access, most of the content is cached in memory. Access to it is equal or better (it has much less ceremony to access the data) than other databases. If the site has so much access, it must have other caching mechanism that make the database even be consulted with this frequency.
Even if you have to access the disk database, it can handle dozens or hundreds of requests per second. Much more than is described on the site. If you consider memory, it can serve thousands. Do you know how many Brazilian sites have thousands of hits per second? And I didn’t mention that the site can be fractionated into some servers. Is it so simple to make it all work? No. But with any database it’s not simple. Is Sqlite the most suitable for these most extreme cases? No, but can it handle it well if you do everything right? Yes.
When we talk about writing, which is rare on websites (it is common for them to be less than 1% of the readings, there are cases of being a much smaller fraction than this one), then it complicates a little more. Even so it is able to withstand tens, hundreds, and who knows how to reach the 4 digits if using a array of SSD (not counting the distribution on servers of the various parts of a site that should probably be large to have so much access). There’s nothing fanciful about it. I reaffirm that it doesn’t serve any case. It serves the vast majority of cases if you know what you’re doing. Using another DB may be premature optimization.
Many sites have occasional changes in content and do not even need a database, would be better served with a static file generation tool, such as Jekyll. But if the site is a simple blog with a comment system, Sqlite is no longer suitable. If possible? Of course, it is possible to make a system of comments with fopen (that yes a competitor of Sqlite) and write the backend in C++ CGI. Is it recommended? This is more subjective, I do not recommend because it is not the appropriate tool for this. But all this is on the project page and the question is not about use on websites
It is that the project page is very conservative and is completely out of reality. It is good that people know they can use in much more than is there. I recommend it because it is the appropriate tool for it. Tied.
1
Yes. It is possible to exchange the database. Of course, it all depends on your application architecture, database structure, database location (client or server).
There are several relational databases Mysql, Oracle, SQL Server or bd Nosql, such as Mongodb, Couchdb, etc.
In the case of using Sqlite for mobile applications, this restriction of 100,000 requests is for access to the same bank, in competition. Note that many mobile applications use Sqlite, in the application user’s own mobile phone, in other words each user would have their own database. If this is the case with your application this restriction you don’t have to worry about so much with Sqlite restrictions. If you are using Sqlite on a server that all users will use in competition, I suggest then check out these database alternatives.
Browser other questions tagged database sqlite mobile performance scalability
You are not signed in. Login or sign up in order to post.
"it is not recommended to use it on sites with more than 100 thousand requests per day" I found it kind of arbitrary. If it is essentially reading, I see no problem.
– Bacco