sqlite vs mysql for Ghost Blog? [closed] - mysql

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'm currently setting up ghost on my server. I will host my own blog and probably some more for my friends.
Ghost uses sqlite per default. Sqlite is good for small applications and development environments.
I plan to run my blog for at least 1 - 2 years or longer if ghost will work out well. A blog contains a lot of images and text. The sqlite db will grow over time with more and more images and so on.
Is it ok to use sqlite for this purpose for several years? MySQL would be much more powerful but also more complex to setup.
What would be the best choice for a Ghost Blog?

Please note that database performance depends not so much on the amount of data (until you run out of local disk space) but on the amount of concurrency.
The SQLite documentation says:
SQLite usually will work great as the database engine for low to medium traffic websites (which is to say, 99.9% of all websites). The amount of web traffic that SQLite can handle depends, of course, on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.
[…]
But if your website is so busy that you are thinking of splitting the database component off onto a separate machine, then you should definitely consider using an enterprise-class client/server database engine instead of SQLite.

Related

MySQL Community - Scaling [closed]

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 4 years ago.
Improve this question
I am working in an environment that is under extreme load. It is a DB used by about a thousand users with one application. This application does thousands of queries against the DB. We have noticed significant performance degradation over time and are looking for a long-term solution to this problem. Of course, query optimization is one of the tasks we are working on, and we are also optimizing indexes; however, this will not be enough to see the performance gains we need.
I have worked in SQL Server for several years but my MySQL knowledge is limited. To start scaling MySQL, I've researched Sharding, but as we are using MySQL community edition, I'm nervous that this will cause more headaches than it's worth. The only other possibility is to re-design the application, specifically how it pulls data from the DB, but I'd rather not do that.
So my question is, is sharing worthwhile to pursue? Is it feasible without an enterprise edition of MySQL? Is there another possibility you could recommend?
Turn on the slowlog with long_query_time=1. Wait a day. Use pt-query-digest to identify the 'worst' could of queries. Then let's discuss them. Sometimes it involves the trivial addition of a 'composite' index.
That is, Slow queries is almost always the cause for scaling problems.
If we eliminate that as a problem, then we can discuss sharding and other non-trivial approaches.
We must see SHOW CREATE TABLE and other clues of what is going on.

Why do some people prefer SQLite over MySQL? I am a MSSQL user [closed]

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.

Which database engine is best for node.js apps? [closed]

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 looking for a database engine which is the best for storing thousands of records. I first wanted to use MySQL, because I know it best, but I'd like to have strong answer.
I need predefined columns, database can be as small as 10 MB or as "big" as 10 GB of data and it would be cool if that engine is fast for reads (insertions may be a bit slower). I don't need fast-fulltext-search or regexp searching. To give you an example - selecting items via slug extracted from link.
I saw this site before but I still don't know what is best option for me.
So here is my question: Which database engine is best for uses like mine?
You should look at MEAN stack. Personally, I like MongoDB - I use an ORM tool like mongooseJS - It increases your development speed rapidly. The one thing i really like about having Node JS, Express body parser, mongodb and mongoose is I deal everything on the server side in one language - Javascript and I expose REST services which can be consumed on Web (typically Angular - the A in MEAN stack or backbone) based application.
database can be as small as 10 MB or as "big" as 10 GB of data
At that size, you could use virtually any database you want. Remember, 10 GBs of data is small enough to fit into memory on a modern server.
I need predefined columns...
Sounds like SQL. Take you pick: MySQL, PostgreSQL, SQLite... at that size it will barely matter, just use what you like.
The performance difference on a "few gigs" of data will be negligible.
Look at MongoDB.
And don't forget to look at TokuMX - it's very promising!

Which one should I use: MySQL Lite or SQLite? [closed]

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 starting a simple windows forms application that requires a database to store inventory and purchasing records (less than 1000 items). What I want to ask is for your opinion which 'lite' database should I use for this small project, considering that the prerequisites I'll be installing in a client computer should have 'minimal' file size.
The client computer has a running OS of Windows 7, and I don't want him to install so many files, such as the .NET framework and the server that hosts the database, just to install the main application I'm currently developing.
What I'm really asking from you guys is to find out which of these two commonly known databases should I use, and look for the 'right recipe' to be used when building the installer. Thank you.
Of the two, SQLite is simpler to install and deploy. Fewer files, smaller distribution footprint and fewer configuration options to deal with (mostly because SQLite is a library that links into your application where as MySQL is a full client/server RDBMS).
SQLite is made for extremely simple database needs, and is probably a good fit based on your description.
I have never heard of MySQL Lite and a web search turned up nothing, so I will assume you meant MySQL. MySQL is a RDBS client/server system and probably major overkill unless you plan to store many records, or to have multiple people accessing the database at the same time.

When does a project get too big for mysql [closed]

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 3 years ago.
Improve this question
I know google uses its own Big Tables (is that right?) and Facebook and Twitter use Cassandra but when does your everyday project outgrow mysql (if ever?)
If you were starting out on a potentially massive scale web application, would you use mysql as an engine or start with an alternative from the start?
I think the only way you can know when MySQL isn't good enough is when you start to see performance issues or you feel like your fighting to keep it going. If you are aware that your application is potentially huge then you should be implementing the right tools from the start otherwise it's a huge headache transferring at a later date.
There is no simple metric which will tell you the answer - it depends not only on the amount of data, number of transactions but also the nature of the replication - number of replicated sites, required speed of replication etc.
Yes, a large scale noSQL clsuter can out-perform a a MySQL cluster built for the same budget for OLTP, however its called noSQL for a reason - when you need to start doing somethng useful with the data, the relational model and SQL language make slicing and dicing the data much easier. OTOH, at some point OLAP then overtakes the relational model in terms of performance - but I think it would be rather difficult to use a datawarehouse for transaction processing.
So its quite possible that the functional requirements of an application will outgrow the capabilities of a noSQL database much faster than the perofrmance requriements would outgrow a relational database.
I'd start with an alternative (PostgreSQL), but not because of scaling issues, but because MySQL's support for transactions and referential integrity is worthless.