I hope that if my question is out of context you guys will let me pass by.I am not good at all when it comes to DBMS and all i can till in my 7+ years of IT experience is able to write some basic queries (with help from Google).
I am working on my own project and i am all done with the design phase and very will clear what all table structure i need to have for the project.I am going to use MySQL for this and since project is with the capabilities of small CMS in itself which means a lot of data to be handled at the database size.
I am using TOAD for MySQL to create schema and other things for MySQL but while doing this i have few queries which i want to address in the beginning.
What should be the storage engine type for MySQL (default is InnoDB)
Any other parameters needs to taken care of storage Engine
what Character set and Collation need to be set at table level and for column level if any (Application will have to take care of internationalization )
being not much knowledgeable about the database aspect these are the question keep popping in my mind and any help in this regard will be appreciated.
You should stick with InnoDB. It has transactions and a row-level locking. For high (writing) concurrency the row-level locking allows multiple INSERTs/UPDATEs/DELETEs at the same time. MyIsam has table-locking, meaning only one modifying query at a time. If you're read-heavy, MyISAM may perform better though. SELECT COUNT(*) FROM table; for example is a statistical thing MyISAM can answer instantly, while InnoDB actually does a COUNT(). InnoDB lets you define connections between your tables (Foreign Key Constraints) to help you with your data integrity.
If you're interested in things like the above, I recommend reading High Performance MySQL from O'Reilly Media.
Regarding the Character Set you should make sure that all tables / columns use the same character set. Preferably Unicode (UTF8). Make sure your mysql client is also set up to use UTF8, to avoid (transparent) transliteration of your data. (In fact, make sure the whole app does UTF8 from storage to display).
The Collation is something that lets you define your text being UTF8, but in a, say, German, context. With that knowledge, MySQL will properly sort "fööbar" and "foobar" according to the rules of the German language. (sorting amongst other things). I usually use "utf8_general_ci". Have a look at some examples over at mysql: http://dev.mysql.com/doc/refman/5.0/en/charset-collation-effect.html
Probably you will get better answer, but quickly from my experiences:
InnoDB is good for creating reliable data-driven web application and MyISAM is good for performance. But InnoDB supports Foreign Keys, transactions and row-level-locking which makes you honest while designing tables. It means if you don't want to create a simple and experimental database, the solution is using InnoDB.
You should look at Foreign Keys, transactions and Row-level locking (Only InnoDB supports these features)
utf8_general_ci is the most popular one I know if you want to storage different languages' data. It won't let you down.
I hope this help.
Related
I have a database program that was written a few years back using MYISAM tables in a MYSQL database. It is a pretty simple structure but I wasn't the one who set it up.
All the current releases of MYSQL are all set for INNODB and I just wondered how hard it would be to convert the current application from MYISAM to INNODB or is this something better handled by starting all over.
Considering I am not a database expert :) Whatever way is the easiest.
I have found most if not all the declaratives in the modules that state for the program to use MyIsam and it sure would be nice if I could just change the necessary parts to restate that as INNODB and get it to work
Is there a physical obstruction to using innodb that would prevent the change fro MYISAM?
As I said these are very small databases maybe 25 fields in 100 records total maximum.
Thanks for any insight
There are several differences between MyISAM and InnoDB, nicely described in this discussion:
https://dba.stackexchange.com/questions/1/what-are-the-main-differences-between-innodb-and-myisam
The only aspect which could prevent the use of InnoDB would be the full text search capabilities of MyISAM, which were introduced in InnoDB with version 5.6 of MySQL. So if your program does not make use of full text search, or if your MySQL version supports full text search with InnoDB, there is no real obstruction.
Given the small size of the database, and assuming a small traffic as well, I would not expect any substantial difference in terms of performances.
For past few days I was in a great confusion deciding whether to use MyIsam or Innodb, with both having their own pros and cons. My table will have large amount of data with heavy INSERT, UPDATE and SELECT operations.
I decided to create two tables of same structure; tbl_mytbl_innodb(innodb engine) and tbl_mytbl_myisam(myisam engine) I then created two triggers on tbl_mytbl_innodb for INSERT and UPDATE events that will insert/update tbl_mytbl_myisam. So it will always write to tbl_mytbl_innodb and read from tbl_mytbl_myisam.
Is this process correct, or do I need to do it a better way?
That's a silly way to go. The only time you should use both in parallel is if you require transactions+foreign keys AND fulltext indexes. You'd use triggers to sync up the fulltextable fields in a MyISAM table, and otherwise keep everything in InnoDB.
There's few usage cases where MyISAM is preferable over InnoDB, and the major one is the lack of fulltext support in InnoDB.
I'd say that's the opposite of a correct process. My personal recommendation is use InnoDB for almost all business activities, as it supports transactions... the only use I've found for MyISAM is full text searches (dunno why that's not available in InnoDB) but I freely admit that's a personal preference.
Using triggers to synchronize the same data across multiple tables can't be good. Define your business requirements and choose an engine. If you need to use the other engine for a specific requirement, define that and populate a subset of data as necessary.
I'm running a django system over mysql in amazon's cloud, and the database default is innodb. But now I want to put a fulltext index on a couple of tables for searching, which evidently requires myisam.
The obvious solution is to just tell mysql to ALTER TABLE to myisam, but are there going to be any issues with that?
One that comes to mind is that I'll have to remember to do that any time I build a new version of the database, which should theoretically be rare, but there doesn't seem to be a way to tell django to please set the storage engine at the table level. I guess I could write a migration (we use south).
Any other things I might be missing? What could possibly go wrong?
Will the application notice? Probably not.
Will it cause problems? Only when things go wrong. MyISAM is not a transactional storage engine. If you change the data in a MyISAM table while inside of a transaction, then have to roll back changes, the changes in that table won't be rolled back. It's been a while since I tried to break it horribly, but I'm willing to wager that MySQL won't even issue a warning when this happens. This will lead to data consistency issues.
You should seriously consider external search software instead of a fulltext index, like ElasticSearch (integrates at the application level), or Sphinx (integrates at the MySQL level, though if you're using RDS instead of MySQL directly, I don't think you'll be able to use it).
the following may be of help:
use a myisam fulltext table to index back into your innodb tables for example:
Build your system using innodb:...
Any way to achieve fulltext-like search on InnoDB
I've read various threads about which is better between InnoDB and MyISAM. It seems that the debates are to use or the other. Is it not possible to use both, depending on the table?
What would be the disadvantages in doing this? As far as I can tell, the engine can be set during the CREATE TABLE command. Therefore, certain tables which are often read can be set to MyISAM, but tables that need transaction support can use InnoDB.
You can have both MyISAM and InnoDB tables in the same database. What you'll find though, when having very large tables is, MyISAM would cause table-lock issues. What this ultimately does is, it locks the whole table for a single transaction, which is very bad if you have many users using your website. e.g If you have a user searching for something on your site and the query takes minutes to complete, no other users could use your site during that period because the whole table is locked.
InnoDB on the other hand uses row-level locking, meaning, that row is the only row locked from the table during a transaction. InnoDB can be slower at searches because it doesn't offer full text search like MyISAM, but that isn't a big problem when you compare it to table-level locking of MyISAM. If you use InnoDB, like many large sites, then you could use a server side search engine like Sphinx for full text searches. Or you could even use a MyISAM table to do the searching like f00 suggested. I'd personally recommended InnoDB mainly because of the row-level locking feature, but also because you can implement full text searching in many other ways.
Basically, if you have a message board application with lots of selects, inserts as well as updates, InnoDB is probably the generally appropriate choice.
But if you're not building something like that (or any other thing with registered users) and your working mostly with static content (or more reads than writes), then you could use MyISAM.
Yes indeed you may use both in the same database, you may choose for each table separately.
In short, InnoDB is good if you are working on something that needs a reliable database that can handles a lot of INSERT and UPDATE instructions.
and, MyISAM is good if you needs a database that will mostly be taking a lot of read (SELECT) instructions rather than write (INSERT and UPDATES), considering its drawback on the table-lock thing.
you may want to check out;
Pros and Cons of InnoDB
Pros and Cons of MyISAM
You don't choose InnoDB or MyISAM on a database level, but instead on a table level. So within the one database you could have some tables running the InnoDB engine and some running MyISAM. As you pointed out, you could choose to use InnoDB on the tables that require transactions etc, and MyISAM where you need other features such as fulltext searching.
We're running a social networking site that logs every member's action (including visiting other member's pages); this involves a lot of writes to the db. These actions are stored in a MyISAM table and since something is starting to tax the CPU, my first thought was that it's the table locking of MyISAM that is causing this stress on the CPU.
There are only reads and writes, no updates to this table. I think the balance between reads and writes is about 50/50 for this table, would InnoDB therefore be a better option?
If I want to change the table to InnoDB and we don't use foreign key constraints, transactions or fulltext indexes - do I need to worry about anything?
Notwithstanding any benefits / drawbacks of its use, which are discussed in other threads ( MyISAM versus InnoDB ), migration is a nontrivial process.
Consider
Functionally testing all components which talk to the database if possible - difference engines have different semantics
Running as much performance testing as you can - some things may improve, others may be much worse. A well-known example is SELECT COUNT(*) on a large table.
Checking that all your code will handle deadlocks gracefully - you can get them without explicit use of transactions
Estimate how much space usage you'll get by converting - test this in a non-production environment.
You will doubtless need to change things in a large software platform; this is ok, but seeing as you (hopefully) have a lot of auto-test coverage, change should be acceptable.
PS: If "Something is starting to tax the CPU", then you should a) Find out what, in a non-production environment, b) Try various options to reduce it, in a non-production environment. You should not blindly start doing major things like changing database engines when you haven't fully analysed the problem.
All performance testing should be done in a non-production environment, with production-like data and on production-grade hardware. Otherwise it is difficult to interpret results correctly.
With regards to other potential migration problems:
1) Space - InnoDB tables often require more disk space, though the Barracuda file format for new versions of InnoDB have narrowed the difference. You can get a sense for this by converting a recent backup of the tables and comparing the size. Use "show table status" to compare the data length.
2) Full text search - only on MyISAM
3) GIS/Spatial datatypes - only on MyISAM
On performance, as the other answers and the referenced answer indicate, it depends on your workload. MyISAM is much faster for full table scans. InnoDB tends to be much faster for highly concurrent access. InnoDB can also be much faster if your lookups are based on the primary key.
Another performance issue is that MyISAM can always keep a row count, since it only does table level locking. So, if you're frequently trying to get the row count for a very large table, it may be much slower with InnoDB. Search the Internet if you need a workaround for this, as I've seen several proposed.
Depending on the size of the table(s), you may also need to update your MySQL config file. At the very least, you may want to shift bytes from key_buffer to innodb_buffer_pool_size. You won't get a fair comparison if you leave the database as being optimized for MyISAM. Read up on all the innodb_* configuration properties.
I think it's quite possible that switching to InnoDB would improve performance, but In my experience, you can't really be sure until you try it. If I were you, I would set up a test environment on the same server, convert to InnoDB and run a benchmark.
From my experience, MyISAM tables are only useful for text indexing where you need good performance with searches on big text, but you still don't need a full fledged search engine like Solr or ElasticSearch.
If you want to switch to InnoDB but want to keep indexing your text in a MyISAM table, I suggest you take a look at this: http://blog.lavoie.sl/2013/05/converting-myisam-to-innodb-keeping-fulltext.html
Also: InnoDB supports live atomic backups using innobackupex from Percona. This is godsent when dealing with production servers.