I am really new to AWS and I want to migrate my database to AWS RDS. But I'm facing several issues. The database is entirely built using MyISAM instead of InnoDB. From what I read at AWS RDS documentation, I understand that I can enjoy the AWS RDS features if I use InnoDB for the database, e.g. the daily backup and the read replica.
The main reason I use MyISAM is to utilize the Full-Text Search and the Spatial Indexing. Until this day, I understand that the MySQL version supported by AWS RDS still doesn't support Full-Text Search (According to this, it's for 5.6.4) and the InnoDB still doesn't support Spatial Indexing too.
So here are my questions
Let's say I convert all remaining tables that don't need the FTS & Spatial to use the InnoDB engine, how optimal can I use the features provided by AWS RDS (read replica, daily backup, etc)?
Will it be any better if I break down a table into two table, one in InnoDB and one in MyISAM? This concern came because some of the columns are often be updated, so those columns will be moved to the InnoDB one to avoid table locking. On the other hand, the MyISAM one is rarely updated.
Let's say I use separate engine for the Full Text e.g. Sphinx or Solr, how can I use it along with RDS? And is there a separate engine for Spatial Indexing that can be used along with RDS?
Any better idea?
The reason for this is that MyISAM is not considered ACID compliant. This means if that something were to happen to your database in the middle of a transaction, it could be left in an inconsistent state.
Personally, I would use full text search engine designed for the purpose. The quality of results is generally much better than what mysql provides and you can offload some of the work from your mysql server.
Related
I have an PHP-based API that runs on shared hosting and uses MySQL. I've been doing reading on InnoDB vs MyISAM and wanted to paste some specific things about my API's database to make sure it makes sense to move on to InnoDB. MyISAM was set by default for these tables, so I didn't deliberately pick that database engine.
My queries are a little more writes than reads (70% writes I'd say). Reads/lookups are always by a "foreign key" (userid) (I understand MyISAM doesn't have these constraints) but might be good to know if I move since I could take advantage of that.
I don't do full text searches
My data is important to me, and I recently learned MyISAM has a risk of losing data? A few times in the past I've lost some data and just assumed it was my user's fault in how they interacted with the API. Perhaps not? I am confused about how anyone would be ok with losing data and thus choosing MyISAM so perhaps I don't understand MyISAM enough.
I'm on a shared host and they confirmed I don't have access to change settings in my.cnf, change buffers, threading, concurrency settings, etc.
I will probably switch to DigitalOcean or AWS in the future
My hosting company uses MySQL Version is 14.14 Distribution: 5.6.34
Based on these factors, my instinct is to switch all my tables to InnoDB and at least see if there are problems. If I hit an issue, I can just run the same statement but swap InnoDB with MyISAM to revert back.
Thanks so much.
Short answer: YES! MyISAM was the original format of MySQL, but many years ago InnoDB has been preferred for many reasons. On high-level picture, your app will better perform as InnoDB has a better lock management.
You can find here a longer answer to your question Should I change my DB from MyISAM to InnoDB? (AWS notification) and the following 2 articles covering migration from MyISAM to InnoDB:
https://dba.stackexchange.com/questions/167842/can-converting-myisam-to-innodb-cause-problems
https://kinsta.com/knowledgebase/convert-myisam-to-innodb/
I need to have possibility to make transactions while using one of my mySQL tables.
I could do that if I'd switch engine from MYISAM (which is set by default to all of the tables at the moment) to INNODB.
However I am not MySQL server admin and guy who is has asked me if I have read about possible dangers of doing so.
I tried to find an answer and failed, so here's my question:
INNODB is currently DISABLED (it says so when im execute SHOW ENGINES). Can I turn it ON without risk of damaging any data in existing MYISAM tables? Are there any specific dangers when doing so?
MYSQL version of server is 5.09.
No, there is no danger to making another engine available for database and object creation in MySQL. You will have to stop and restart your MySQL service for it to take effect, so you'll have a modicum of downtime, so do it after business hours.
My site runs on a VDS-server. I've just found out that my MySQL server doesn't support InnoDB engine, therefore I can't use database transactions in my application.
It makes me think, that some people might never use transactions. Is this the case? If so, how does one manage to coordinate related operations on different tables in MyISAM?
Otherwise, is there a way to install InnoDB on a MySQL server which is run on a VDS?
Thanks!
If you need transactions, then you need transactions and MyISAM isn't going to cut the mustard.
Some applications won't need transactions. For example; an application that never runs more than one related SQL statement at a time and has no need to rollback multiple SQL statements. Another example is an application that uses MySQL as a simple Key-Value Store. There are many use cases that don't require database level transaction support.
It's hard to answer the second part of your question without knowing more details about your VDS. Who is you hosting provider? Do you have shell access and permissions to change my.cnf? If not, then you probably won't be able to enable InnoDB. If you do, then here is a another SO answer that details how to enable InnoDB on MySQL: How to enable INNODB in mysql
You can often either enable the engine, install the InnoDB components manually, or simply re-install a version of MySQL that includes that engine by default. MyISAM is the crazypants database, stupidly fast but also unreliable and prone to complete destruction if your system isn't shut down properly.
Running a mission critical application on MyISAM is an extremely bad idea. Where you need MyISAM tables for performance reasons they should always be disposable, easily re-built from another more reliable source of data.
How does MYSQL Cluster (NDB) compare against MongoDB? It seems that while both NDB and Mongo supports scale out over commodity machine nodes, NDB also provides all the relational capabilities such as JOINs, transactions, etc...
Therefore, under what situations would one choose Mongo over NDB?
Even though MYSQL Cluster NDB is a shared-nothing approach that scales a relational database across commodity machines, there are limitations and impacts to performance. You can read the full details at the link below, but some of the more important features are just not supported in NDB, such a foreign keys, which may make you question why you would cluster a RDBMS in the first place if you have to give up some of the features you're expecting to leverage.
18.1.5.1 Differences Between the NDB and InnoDB Storage Engines
What are the limitations of implementing MySQL NDB Cluster?
I come from a relational background, and things like MongoDB did not initially click with me, but after tinkering with it for a few weeks, I was surprised at how much is possible while not being subject to traditional schema guidelines and transactional overhead that comes with relational databases. If you really want true, horizontal scalability and are willing to give up the luxury of joins and foreign keys, you should seriously consider using Mongo or something similar that falls under the NoSQL category.
If you want to keep your sql/ relational database structure then go with NDB.
If you want to build data that is a little more heirarchial in structure you should go with mongodb.
Is there any way to tell Hibernate use MySql Memory Storage Engine?
Thanks.
Edit: I found Memory Storage Engine does not support all features of a regular Store Engine like InnoDB, etc. So it may be seemed logical that there is no option for it.
There should be a properties file where you can put your URL to MySQL
#hibernate.dialect org.hibernate.dialect.MySQLDialect
#hibernate.dialect org.hibernate.dialect.MySQLInnoDBDialect
#hibernate.dialect org.hibernate.dialect.MySQLMyISAMDialect
#hibernate.connection.driver_class com.mysql.jdbc.Driver
#hibernate.connection.url jdbc:mysql:///mysqlURL
#hibernate.connection.username
#hibernate.connection.password
But be aware of this
When using the MyISAM storage engine, MySQL uses extremely fast table locking that allows multiple
readers or a single writer. The biggest problem with this storage engine occurs when you have a steady
stream of mixed updates and slow selects on a single table. If this is a problem for certain tables, you can
use another storage engine for them.
The storage engine used by mySQL is declared when you create your tables. Use the qualifier ENGINE=MEMORY at the end of your CREATE TABLE DDL. Then use it like any other table.
But, of course, remember that if your mySQL server bounces for any reason, all rows will be gone from that MEMORY table when it comes back.
Why do you want in-memory storage?
My personal use case scenario for such a setup is testing.
Think about using h2, hsql or derby. AFAIK they all provide in-memory storage. And if you consistently use Hibernate, it should make no difference which database runs in the background -- at least not from a development standpoint.