For a forum, should I use MyISAM or InnoDB for the table that stores the text?
I know that MyISAM supports full text searching, which sounds like it's what I should go for, but while reading, I've come across this very confusing sentence.
You should use InnoDB when
transactions are important, such as
for situations in which INSERTs and
SELECTs are being interleaved, such as
online message boards or forums.
Well, but for an "online message boards or forums" I would need good search to search through the text of each post, so doesn't it make more sense to use MyISAM? Can someone clarify what's most commonly used?
Apart from MySQL's native full text searching solution, which as you already identified requires the MyISAM storage engine, you may also want to consider the popular third-party search engines Sphinx and Apache Lucene, with which you can use InnoDB tables.
You could also stick to MySQL's solution, and use InnoDB storage for all tables except for one table which will simply hold the post_id and text_body. This is assuming that you only require full text searching for the content of forum posts.
In addition note that while the major deficiency of MyISAM is the lack of transaction support, there are other important issues as well for a production system. You may want to check the following article for further reading:
MySQL Performance Blog: Using MyISAM in production
Generally speaking, for non-critical data, I'd use InnoDB tuned for speed. (E.g., I wouldn't flush binary logs on every commit.) I'd only use MyISAM for things like logging tables.
As others have mentioned, you can use external search indexes if you need to do full text searches. They are more powerful and faster than MySQL's.
Regarding the part about transactions, it's a bit of a lie. You could do the same thing with MyISAM by locking tables for WRITE. If you are inserting into, say, three tables when posting a message, you could lock all three tables for WRITE, and the data would look consistent (assuming all three INSERTS succeeded).
But the problem with that is you are locking the entire table, which can slow down concurrent usage. In fact, that is one of InnoDB's major advantages over MyISAM: it has row-level locking.
In short: if you are unable to set up an external indexer, and your site does not experience too much traffic, then MyISAM will work fine despite it being less robust. You can emulate the consistency of transactions with table locks. (I do not mean to make it sound like the table locking is somehow equivalent to transactions.)
Otherwise, I'd use InnoDB with an external indexing service.
For any large volume of text I'd use InnoDB to store it and Sphinx to index it. It provides a lot more search features than what's built into mysql.
Related
I want to use MySQL to store session variables. From what I understand this means that on every page request there will be one read and one write to the table.
Which MySQL storage engine is best suited for this task? MyISAM, InnoDB , MariaDB (which I don't see in PHPMyAdmin), Memory, or something else entirely?
"Best" means nothing. You need to express your constraints: do you need consistency? Durability? High-availability? Performance? A combination of all these properties? Can you afford to loose your sessions? Can they fit in memory? Do you need to support concurrent accesses to the same data?
Without more context, I would choose InnoDB which is the most balanced storage engine. It provides correct performance for OLTP applications, ACID transactions, good reliability, and sensible concurrency management. Session variables access will likely be done using primary keys, and this operation is very efficient with InnoDB.
Now if performance is really a constraint, I would rather use a NoSQL engine (i.e. not MySQL). To store session data, Redis usually does a very good job, and is easy enough to integrate and deploy.
Memory storage engine sounds to be the best option. Keep in mind that this is good for temporary sessions.
http://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html
It depends on how you evaluate "betterness":
MyISAM is the most common (many shared hosting packages only let you use MyISAM). plus it is rather limited in the relationship control aspect, so you set it up really fast and easy. if you want portability and fast implementation across multiple hosting scenarios, MYISAM IS BEST.
InnoDB allows you to create relationships and saveguard data integrity by linking keys in different tables, which means more work but much more professional db design. many shared hosting packages do not implement InnoDB, therefore when exporting table structure from one environment to another, you might have some extra work to do. if you want realationship management and control, INNODB IS BEST.
As far as data portability is concerned, an InnoDB database will be completely accepted by MyISAM (because MyISAM does not check data integrity: "is there a user number 4 in the user database when i insert a new record in user_car, for example"). If you start out with MyISAM, exporting to a full-fledged InnoDB database will be a nightmare, even if your data has all keys, table data must be imported in the correct order (user and car, before user_car).
MariaDB? never, simply because less people use it, therefore you will have less support, as compared to MyISAM and InnoDB.
Bottom line clincher: INNODB.
If you do not wan't the overhead from a SQL connection consider using MemCached session sorage. See http://php.net/manual/en/memcached.sessions.php
As I have no more knowledge then usual about MyISAM, InnoDB engines, So I'm in confusion what engine to use for my large project, where
1) minimum 3000 users will log their account at a time (within hour)
2) and do some work like Update, delete data from their Account etc.
I'm on shared host. May anyone give me specific answer that what engine should I use for faster processing for above condition.
which database engine will speed up above works ? any help plz ?
Does your application use Foreign keys? If so, then you'll need to use the InnoDB engine. If it doesn't you can go ahead with MyISAM engine.
If there are many modifications of the data, it's said that InnoDB works faster because it uses row locking instead of table locking, like MyISAM. However, if there are mainly SELECT statements, a MyISAM table might be faster.
However, it's always important what the needs of a specific table are - so I would choose the storage engine that best fits the requirements for the given table. If you need foreign key constraints or transactions, you can only use InnoDB, wheras if you need fulltext indexes, you can only use MyISAM tables at the moment.
With replication it's even possible to take advantage of both storage engines on one table. For example, the master could store a table as InnoDB which makes it fast for INSERTs, UPDATEs and DELETEs while the slave(s) could store the same table as MyISAM and offer the best performance for SELECTs.
Source
both engines have advantages and disadvantages
MYISAM
myisam is very simple to use, thus it is easy to write third-party tools to interact with it.
myisam have been around for a while so it's highly optimized
myisam uses less memory than InnoDb and the actual data files are often quite a bit larger for Innodb
InnoDb
performance : u can read this blog about innodb's performance against myisam and falcon http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/
InnoDB is a largely ACID (Atomicity, Consistency, Isolation, Durability) engine, it supports transactions
InnoDB can run a backup job in a single transaction and pull consistent, database-wide backups with only a short lock at the beginning of the job. on the other hand myisam consistent back up requires database locks and this is totally unacceptable for a large websites.
I am developing a game in PHP and of course there are about 1000 different tables I will need to create to store various types of data. I heard, correct me if I am wrong, that InnoDB is better for tables that will be updated a lot because of row locking opposed to MyISAM's table locking. However MyISAM is faster with selections.
My question is, should I just stick with one table type, or is it good to mix and match based on the needs of the table?
My question is, should I just stick with one table type, or is it good to mix and match based on the needs of the table?
It's OK to mix.
MyISAM is faster for certain queries and supports FULLTEXT and SPATIAL indexes, while InnoDB is transactional and more concurrent.
In a database project I'm currently consulting there is a mix of tables for these very purposes.
It depends on your requirements. If you need row-level locking, foreign key constrains, etc you should go for InnoDB, but if you don't need it, you can go for MyISAM. Generally, InnoDB is way to go in most cases but nothing stops you from choosing multiple types of engines for your tables, that is beauty of MySQL.
Yes you can mix MyISAM and InnoDB in same database if required without any problem
While you can mix tables, I'd stick entirely with InnoDB. While MyISAM can be faster for some queries, InnoDB is usually quicker if properly tuned. If querying by primary key, InnoDB will pants MyISAM for speed, since InnoDB stores data in primary key order. MyISAM may be faster for secondary indexes.
MyISAM doesn't support transactions, and if you have 1000 tables, chances are you'll be updating several tables as part of one operation, and all those updates should be done inside a transaction (or be prepared for major headaches when concurrency becomes an issue when your game gets busy or your database lags!).
Sticking with one table type also makes memory management easier on the database machine. InnoDB gets dedicated RAM for caching, while MyISAM relies on the OS file-system cache.
Using MyISAM for fulltext search on any kind of busy site will cause you grief. Instead, use Sphinx Search.
I have heard about this problem and now I am looking for more specific information?
How does it happens, what are the reasons for that, detailed explanation of the mechanism of the deadlock to try to avoid it. How to detect the deadlock, solve it and protect the data from being corrupted because of it. The case is when using MySQL with PHP.
And can I mix the InnoDB and MyISAM? I intend to use innoDB for some majo rtables with many relationships and not that much data, as users, roles, privileges, companies, etc. and use MyISAM for tables that hold more data: customers data, actions data, etc. I would like to use only InnoDB, but the move from MyISAM scares me a bit in terms of speed and stability. And now this deadlocks :(
Deadlocks can occur if you've got two or more independent queries accessing the same resources (tables/rows) at the same time. A real world example:
Two mechanics are working on two cars. At some point during the repair, they both need a screwdriver and a hammer to loosen some badly stuck part. Mechanic A grabs the screwdriver, Mechanic B grabs the hammer, and now neither can continue, as the second tool they need is not available: they're deadlocked.
Now, humans are smart and one of the mechanics will be gracious and hand over their tool to the other: both can continue working. Databases are somewhat stupid, and neither query will be gracious and unlock whatever resource is causing the deadlock. At this point, the DBMS will turn Rambo and force a roll back (or just kill) one or more of the mutually locked queries. That will let one lucky query continue and proceed to get the locks/transactions it needs, and hopefully the aborted ones have smart enough applications handling them which will restart the transactions again later. On older/simpler DBMSs, the whole system would grind to a halt until the DBA went in and did some manual cleanup.
There's plenty of methods for coping with deadlocks, and avoiding them in the first place. One big one is to never lock resources in "random" orders. In our mechanics' case, both should reach for the screwdriver first, before reaching for the hammer. That way one can successfully working immediately, while the other one will know he has to wait.
As for mixing InnodB/MyISAM - MySQL fully supports mixing/matching table types in queries. You can select/join/update/insert/delete/alter in any order you want, just remember that doing anything to a MyISAM table within an InnoDB transaction will NOT make MyISAM magically transaction aware. The MyISAM portions will execute/commit immediately, and if you roll back the InnoDB side of things, MyISAM will not roll back as well.
The only major reason to stick with MyISAM these days is its support for fulltext indexing. Other than that, InnoDB will generally be the better choice, as it's got full transaction support and row-level locking.
I have innoDB table using numerous foreign keys, but we just want to look up some basic info out of it.
I've done some research but still lost.
How can I tell if my host has Sphinx
installed already? I don't see it
as an option for table storage
method (i.e. innodb, myisam).
Zend_Search_Lucene, responsive
enough for AJAX functionality of
millions of records?
Mirror my
innoDB with a myisam? Make every
innodb transaction end with a write
to the myisam, then use 1:1 lookups?
How would I do this automagically?
This should make MyISAM
ACID-compliant and free(er) from
corruption no?
PostgreSQL fulltext
queries don't even look like SQL to
me wtf, I don't have time to learn a
new SQL syntax I need noob options
????????????????????
This is high volume site on a decently-equipped VPS
Thanks very much for any ideas.
Sphinx is very good choice. Very scalable, built-in clustering and sharding.
Your question is very vague on what you're actually wanting to accomplish here but I can tell you to stay away from Zend_Search_Lucene with record counts that high. In my experience (and many others, including Zend Certified Engineers) ZSL's performance on large record-sets is poor at best. Use a tool like Apache Lucene instead if you go that route.