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 am looking for a tool that will allow me to compare schemas of MySQL databases.
Which is the best tool to do that?
Navicat is able to do that for you. It will also synchronize schema and/or data between two mysql database instances. I've used it with success in the past.
Link
There is a screenshot of the data and structure synchronization tool here:
http://www.navicat.com/en/products/navicat_mysql/mysql_detail_mac.html#7
Perhaps a bit late to the party, but I've just written a simple tool in PHP to compare MySQL database schemas:
PHP script to compare MySQL database schemas
How to use the script
It exports the schema and serialises it before doing the comparison. This is so that databases can be compared that reside on different hosts (where both hosts may not be accessible by the PHP script).
Edit:
Python Script
I use SQLyog:
http://www.webyog.com/en/
It isn't free but is a very good tool and has saved the cost of it's license many many times over. I'm in no way affiliated with the company, just someone who has used a number of MySQL tools.
Free trial(30-day) available from here.
The best thing to do is to try out some performance benchmarks that are already out there. It's always better to use tried-and-tested benchmarks, unless you're thoroughly convinced that your data and database loading is going to be significantly different to the traditional usage patterns (but, then, what are you using a database for?). I'm going to steal my own answer from ServerFault:
There are a good number of benchmarks
out there for different MySQL database
engines. There's a decent one
comparing MyISAM, InnoDB and Falcon on
the Percona MySQL Performance
Blog, see here.
Another thing to consider between the
two aforementioned engines (MyISAM and
InnoDB) are their approaches to
locking. MyISAM performs
table-locking, whilst InnoDB performs
row-locking. There are a variety of
things to consider, not only downright
performance figures.
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
First of all, I'm not a very experienced developer, I'm making mid-size apps in PHP, MySQL and Javascript.
There is something though which is making it hard for me to design a MySQL InnoDB database before each project. And that is the performance. I'm always quite worried about if I'm creating a normalized database scheme that when I'll have to join a couple of tables (like 5-6) together (there are usually a few many-to-many, many-to-one relationships between them) it will affect the performance a LOT (in negative) when each of these 5-6 tables has around 100k rows.
These projects that I usually have is creating analytics platforms. Therefore I'm expecting around 100M of clicks in total and I usually have to join this table to many others (each around 100k of rows) to get some data displayed. I'm usually making summarized tables of the clicks but cannot do the same for the other tables.
I'm not quite sure if I have to worry about future performance in this stage. Currently, I am actively managing a few of these applications with 30M+ clicks and tables that I join to this Clicks table with 40k+ rows. The performance is pretty bad - a select operation usually takes more than 10-20s to complete while I believe I have proper indexing, innodb_buffer_pool_size also.
I've read a lot about the key to having an optimized database is the design. That's why I'm usually thinking about the DB scheme a LOT before creating it.
Do I really have to worry about creating DB schemes where I'll have to Join 5-6 many-to-many/many-to-one/one-to-many tables or it's quite usual and MySQL should be able to easily handle this load?
Is there anything else that I should consider before creating a DB scheme?
My usual server setup is having a MySQL Server with 4GB RAM + 2 vCPUs, to serve the DB and a WebServer with 4GB RAM + 2 vCPUs. Both of them are using Ubuntu's 16.04 release and using the latest MySQL (5.7.21) and PHP7-fpm.
Gordon is right. RDBMSs are made to handle your kind of workload.
If you're using virtual machines (cloud, etc) to host your stuff, you can generally increase your RAM, vCPU count, and IO capacity simply by spending more money. But, usually, throwing money at DBMS peformance problems is less helpful than throwing better indexes at them.
At the scale of 100M rows, query performance is a legitimate concern. You will, as your project develops, need to revisit your DBMS indexing to optimize the queries you're actually using. So plan on that. The thing is, you cannot and will not know until you get lots of data what your actual performance issues will be.
Read this for a preview of what's coming: https://use-the-index-luke.com/ .
One piece of advice: partitioning of tables generally doesn't solve performance problems except under very specific circumstances.
Look up this acronym: YAGNI.
And go do your project. Spend your present effort getting it working.
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 7 years ago.
Improve this question
We are running an application that uses MySql with Engine InnoDB and we are planning to revamp the application (source code), so I was looking at postgres as it seems to be very popular and suggested by many people around the world. But there is something which really has put me on hold:
Taken from this thread.
When Not To Use PostgreSQL
Speed: If all you require is fast read operations, PostgreSQL is not
the tool to go for.
Simple set ups: Unless you require absolute data integrity, ACID
compliance or complex designs, PostgreSQL can be an over-kill for
simple set-ups.
Replication: Unless you are willing to spend the time, energy and
resources, achieving replication with MySQL might be simpler for those
who lack the database and system administration experience.
So, about speed, I am not sure what exactly it means by fast read operations. Does it mean simple read operations or complex? Because I also have read that postgres optimizes the query before executing it, so not sure if I truly understand the point or missing something?
In the end, I am not sure, which factors exactly should I look for choosing Postgres or Mysql for the application?
Note: I have read and tried to understand the differences between postgres and mysql but couldn't conclude anything, that is why I am posting question here. Also, I am not a DBA.
PostgreSQL can compress and decompress its data on the fly with a fast compression scheme to fit more data in an allotted disk space. The advantage of compressed data, besides saving disk space, is that reading data takes less IO, resulting in faster data reads.
Mysql: MyISAM tables suffer from table-level locking, and do not support ACID features such as data durability, crash recovery, transactions or foreign keys. Previously it has been claimed to perform better in read-only or read-heavy operations, but this is no longer necessarily the case.
Also see Benchmarking PostgreSQL vs. MySQL performance
It is highly depends on how your table structure maintained and how you are organising data.
Pinterest though using mysql have managed huge data with faster read.
All depends upon your application. If you are creating web application and that can be more complex, many tables with joins you are using, real time data. In that case you can prefer Postgresql.
PostgreSql Features : ORDBMS, MVCC, It can also be accessed by Routines from the platform native C library as well as Streaming API for large objects, Table inheritance, it is unified database server with a single storage engine, more reliable and fast in complex operation where many joins you are using, Locking to avoid race condition, having a lot of functions like --> To text search to_tsvecter() and to_tsquery(), get data in json format, having shared buffer cache, indexing, triggers, backup, master-slave replication and many more.
If your application is small, mobile platform, similar types of queries you are using, not many users for this application. In that case you can prefer Mysql.
Mysql Features : RDBMS, used JDBC ODBC, fast for similar types of queries, master-master replication.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I am planning on eventually switching my website's database system from MySQL to NoSQL (in this case Cassandra).
From what I have understood so far about Cassandra, is that there is no such thing as a join, but rather just larger records that work more efficiently. I am by no standard an expert in NoSQL atm, i actually understand very very little about it and am very confused on how a lot of it works...
One of my goals for my web project is to switch to Python and Cassandra for a more advanced and speedier solution as my website is beginning to grow and I want to be able to scale it easily with additional servers.
Right now i am in the process of designing a new feature for my website, the ability to take files and create folders out of them. So far this is what I was originally using: How to join/subquery a second table (A question I just asked)
Then the people were suggesting to normalize the data and make it a 3 table system including one for folders, one for folders/files, and one for files. #egrunin answered my question and even gave me the info for the NoSQL, but i really wanted to check it with a second source just to make sure that this is the right approach.
Also are there any conversion tools for SQL to NoSQL?
So my ultimate goal is to design this folder/file system in the database (along with other features that I am adding) so that when I switch from SQL to NoSQL I will be ready and the conversion of all of my data will be a lot easier.
Any tutorials, guides, and information on converting SQL to NoSQL, Cassandra, or how NoSQL works is much appreciated, so far the Cassandra documentation has left me very confused.
At Couchbase we've recently done a webinar series about the transition from RDBMS to NoSQL. It's obviously through the lens of JSON documents, but a lot of the lessons will apply to any distributed database.
http://www.couchbase.com/webinars
MasterGberry:
One of my goals for my web project is to switch to Python and Cassandra for a more advanced and speedier solution as my website is beginning to grow and I want to be able to scale it easily with additional servers.
This is something that you need to clearly quantify before switching to Cassandra.
MySQL can do amazing things and so can Cassandra, but switch to Cassandra usually cannot be driven just by wanting to do things faster, because they might not be faster - at least not in the areas where you are used for MySQL to do great (column level numerical aggregates on well defined, tabular data).
I am by no means discouraging the transition, but I am warning about the expectations.
This might be a good reading:
http://itsecrets.wordpress.com/2012/01/12/jumping-from-mysql-to-cassandra-a-success-story/
Actually, you can use a tool like playOrm to support joins BUT on partitions only NOT entire tables. So if you partition by month or account, you can grab the account 4536 partition and query into that joining it with something else (either another smaller table or another partition from another table).
This is very useful if you have a system with lots of clients and each client is really independent of another client as you can self contain all the client information into that client's partitions of all tables.
later,
Dean
Cassandra isn't really meant to be the main storage for an application. One of its main purposes is storing sequential data and pulling all that back with a key lookup. One example is logging. Interestingly, the row keys are not sorted, but the column names are. So logging would have a key for every minute and then create a new column for each log entry with a sequential time stamp as the name of the column. That is just one example of course, chat history is another.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I would like to create a database with the goal of populating this database with comprehensive inventory information obtained via a shell script from each client machine. My shell script currently writes this information to a single csv file located on a server through an ssh connection. Of course, if this script were to be run on multiple machines at once it would likely cause issues as each client potentially would try to write to the csv at the same time.
In the beginning, the inventory was all I was after; however after more thought I began to ponder wether or not much much more could be possible after I gathered this information. If I were to have this information contained within a database I might be able to utilize the information to initialize other processes based on the information of a specific machine or group of "like" machines. It is important to note that I am already currently managing a multitude of processes by identifying specific machine information. However pulling that information from a database after matching a unique identifier (in my mind) could greatly improve the efficiency. Also allowing for more of server side approach cutting down on the majority of client side scripting. (Instead of gathering this information from the client machine on the startup of each client I would have it already in a central database allowing a server to utilize the information and kick off specific events)
I am completely foreign to SQL and am not certain if it is 100% necessary. Is it necessary? For now I have decided to download and install both PostgreSQL and MySQL on separate Macs for testing. I am also fairly new to stackoverflow and apologize upfront if this is an inappropriate question or style of question. Any help including a redirection would be appreciated greatly.
I do not expect a step by step answer by any means, rather am just hoping for a generic "proceed..." "this indeed can be done..." or "don't bother there is a much easier solution."
As I come from the PostgreSQL world, I highly recommend using it for it's strong enterprise-level features and high standard compliance.
I always prefer to have a database for each project that I'm doing for the following benefits:
Normalized data is easier to process and build reports on;
Performance of database queries will be much better due to the caching done by the DB engine, indexes on your data, optimized query paths;
You can greatly improve machine data processing by using SQL/MED, which allows querying external data sources from the database directly. You can have a look on the Multicorn project and examples they provide.
Should it be required to deliver any kinds of reports to your management, DB will be your friend, while doing this outside the DB will be overly complicated.
Shortly — go for the database!
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
Now that MySQL is in Oracle's hands, do you think it's a good idea to switch to using PostgreSQL for new applications instead? (Also what do you think about converting existing applications?)
I've used both DB systems before and while PostgreSQL is great for it's licensing terms and standards compliance, MySQL is definitely easier to get up and running quickly. (I make this as a personal observation, I know you might disagree...)
Edit:
I should clarify... I don't want this to be a MySQL/PostgreSQL is better than PostgreSQL/MySQL debate. I like both DB systems and am happy using both (and really for the complexity of most of the applications I'm working on, it's much of a muchness). I'm just in a position where I'm trying to look forward and consider the stability of my technology base before committing myself to a particular course. If you have gone through a similar process and have some kind of migration plan in mind I would like to hear from you regarding what that is and why you decided on it.
Installing is a one-time-job ... kindof. Depends ofcourse. but PostgreSQL isn't much harder to install than MySQL, if harder at all. It's the day-to-day cost of ownership that matters. As a developer I prefer PostgreSQL over MySQL, as the latter behaves different from version to version (they're still playing catchup to the sql standard and probably always will). Also MySQL is a pain to administer sometime. What does it matter if it takes ten minutes more to install if you must wait for hours when adding a column to a table or other trivial tasks. Finally I think the mysql-environment was too turbulent even before the Oracle takeover, with Oracle already owning innoDB, MariaDB. I think it is a general mess. So yes, I'd migrate, but for other reasons.
If you actually prefer MySQL over PostgreSQL I'd lay out a migration plan just to be ready if need arises, as a kind of lazy proactiveness ...
Look at it this way: regardless of what Oracle says, the fact remains that they could decide to do Something Bad with MySQL at any time. Maybe they will, and maybe they won't, but why take the risk (for new projects, at least) when you can just use PostgreSQL?
Given the choice, I'd just as soon go with Postgres myself. It seems to be a very stable project upon which to base my own work. Long history, under active development, good documentation, etc.
Since you've indicated that you're happy working with either one, I say go with Postgres for new projects and don't worry about converting existing projects unless and until Oracle does something with MySQL that gives you cause for concern.
I am no fan of Oracle, but the company has come forward with a 10 point commitment to existing MySQL customers.
So at least as of now, I don't see any cause for worry. Any database migration will require some effort and cost in terms of time and money. So if I were you, I'd hold on for a while before doing anything drastic as a database migration.
Even if MySQL does go south, there's MariaDB, which was started by the founder of MySQL. It's a drop in replacement and has some quite exciting new features.
http://askmonty.org/wiki/index.php/MariaDB
I've been giving a go on my development environment and I've been liking it so far.
See the article:
Save MySQL by letting Oracle keep it GPL
This answers your question amongst other things.
Good lord.
O.k. so let's just get it in the open. I am not a MySQL fan. I think its broken. However I am biased (http://www.commandprompt.com/). That said here are the benefits of PostgreSQL.
PostgreSQL scales farther than MySQL. MySQL does really well if you have a limited number of CPUs. If you get above 4, PostgreSQL will just go farther, longer.
PostgreSQL's license allows it to never be bought. You don't have to worry about a single entity taking it over. At present there are at least a dozen actively supporting companies including, Red Hat, PgExperts, Command Prompt, OmniTI, EnterpriseDB, Fujitsu and Oracle (yep).
PostgreSQL's feature set is remarkable. Just look at it.
However, and this is the most important. Do what your business requires. MySQL is a decent database when used for its purpose.