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 considering implementing a cluster server. I have currently used MySQL for my application for the past few years but I've read a lot of uncertainty over the past year on what is going to be happening with MySQL and also the advantages and improvements of MariaDB.
If it were a single server, based on everything I've read I would switch over to MariaDB right now so I wouldn't need to do it later, but since it's a cluster I am torn about whether I should switch to MariaDB Galera right now or wait awhile before it's more mature.
Does anyone have experience implementing both of these solutions and "pros" and "cons" of those implementations?
My other worry is that with improvements, MariaDB won't be a complete drop-in replacement after a year or 2 as it improves and adds new features, so now WOULD be a better time to switch to MariaDB.
You can also use Galera in Percona XtraDB Cluster, which is backward compatible with MySQL.
(disclaimer: I work for Percona.)
No one can truthfully guarantee backward compatibility forever -- not even Oracle.
FWIW, if you're worried about drop-in replacement technology, then you should know that MySQL Cluster is a great example of not satisfying that criterion.
Because of the way the NDB storage engine partitions data, most users need to redesign their schema to take advantage of NDB. Many users "upgrade" an existing app to MySQL Cluster but experience worse performance, because their queries tend to touch every node in the cluster anyway. MySQL Cluster is a brilliant solution for the cases it handles well, but you can't assume it's a drop-in replacement for conventional InnoDB architecture. You have to do careful functional testing, performance testing, and load testing.
First of all - I should point out that I'm part of the MySQL team within Oracle.
I'm not going to criticise MariaDB or Galera but suggest that if you switch to them then it should be because you're convinced that they provide a better solution and not because of any FUD you've heard that Oracle is planning to kill or wind down MySQL - the opposite is true. Take a look at this presentation by the VP of MySQL engineering (Oracle) from this year's Percona conference for details of the great stuff that's been happening.... http://www.youtube.com/watch?feature=player_embedded&v=OpHTV59I1gs#at=16
Regarding MySQL Cluster, we've just declared General Availability for MySQL Cluster 7.3 which contains some major enhancements such as:
Support for Foreign Keys
JavaScript/Node.js API
Performance enhnacements
Browser-based auto-installer
Take a look at http://www.clusterdb.com/mysql-cluster/mysql-cluster-7-3-is-now-ga/ for some details.
Related
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 3 years ago.
Improve this question
My client strongly desires for a highly availability access to data stored in their MySQL database. They want to be confident that a reliable solution exists to avert downtime due to a database server failure.
In the scope of MySQL database, how may I provide a resilient data storage solution to my clients?
There should be a means to ensure our app stays up and is not starved of data necessity for its operation when DB server goes down. I googled and found this:
http://galeracluster.com/documentation-webpages/configuration.html
But I think there should be an easier way to switch between different DB servers, am I right?
In any case my question is: what is the practices to handle such situations when DB server goes offline?
You are looking for a database cluster (probably with multi-master replication)
https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-replication-multi-master.html
This topic is WAY too deep for an SO post, but this is the direction you should be heading.
The solution to the challenge you described is Database Replication.
Replication in computing involves sharing information so as to ensure consistency between redundant resources, such as software or hardware components, to improve reliability, fault-tolerance, or accessibility.
Database replication can be used on many database management systems (DBMS), usually with a master-slave relationship between the original and the copies. The master logs the updates, which then ripple through to the slaves. Each slave outputs a message stating that it has received the update successfully, thus allowing the sending of subsequent updates.
MySQL supports DB replication when you configure it. So, you do not have to implement the actual replication process.
See the official MySQL documentation on ⇢ MySQL database replication.
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
Our DBA deployed a standalone TiDB and a standalone MySQL to respectively handle about one million tables but it seemed that TiDB could not perform as good as MySQL, why? If it's because the data size is too small, how much data should I put in the database to ensure a better performance in TiDB than MySQL?
TiDB is designed for scenarios where sharding is used because the capacity of a MySQL standalone is limited, and where strong consistency and complete distributed transactions are required. One of the advantages of TiDB is pushing down computing to the storage nodes to execute concurrent computing.
TiDB is not suitable for tables of small size (such as below ten million level), because its strength in concurrency cannot be shown with small size data and limited Region. A typical example is the counter table, in which records of a few lines are updated high frequently. In TiDB, these lines become several Key-Value pairs in the storage engine, and then settle into a Region located on a single node. The overhead of background replication to guarantee strong consistency and operations from TiDB to TiKV leads to a poorer performance than a MySQL standalone.
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.
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.
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 came to know about the Free DB2 Express C today. I have a few questions about it. Can someone please tell me
How does Free DB2 Express C compare with MySQL?
Is it a bad idea to switch from MySQL to Express C?
What are the restrictions on the free version? I couldn't find that information on its website.
DB2 is a real database with all the minimal components such as referential integrity, stored procedures, ACID, etc. and some interesting extras such as native XML.
MySQL begins to adopt some of these minimal requirements for one of its storage engines, however this still remains immature. MySQL could be better than DB2 for some specific cases when transactions are not really important, such as a small web site that shows simple content.
DB2 is NOT open source, and for the version express-c you can only download the latest (most recent) version of DB2. It means, that you cannot apply patches, nor fix bugs. However, when there is a new release in the DB2 family, the express-c version is also release, so you always have access to the most recent updates (not like in Oracle, that the express version is still 10G)
The restriction in the DB2 express-c version is the memory size used (for buffer pools and other elements) and its size is 4GB. It could use only 2 cores if the machine has several ones.
There is not limit for the storage or quantity of users.
http://www.ibm.com/developerworks/wikis/display/DB2/DB2+Express-C+FAQ
When you business needs grow, you can update to another version in the DB2 family easily, because your platform (applications) are already designed to work with DB2.
DB2 is good for very small database, and for very bigs database with several TBs.
MySQL is Open Source, and it was bought by Sun, which was bought by Oracle. Some days ago, several Open Sources projects maintained by Oracle were finished, and they will only work with the payed versions; such as OpenSolaris and OpenOffice. We do not know the future of MySQL with Oracle as owner.
In the other side, IBM has been working hard with the Open Source (Eclipse, Apache Derby), and in the last years, there has been a continuous effort to use DB2 express-c, so it seems that IBM will continue this way.
"DB2 is DB2 is DB2"