In November 2008 I’ve got a nice project, that resulted in a complex search engine, that specializes in clothing. I can’t give the link now, but will do when site officially launches. Key features of such service are:

• Large number of users, which search with various parameters, rate items, leave comments, create articles etc.
• Large database, that is updated frequently

Sure, the site is running on a dedicated server, sure I use caching, but optimal DB is a key to success.

MyISAM or InnoDB?

Since we need reliability, I created different tests, search the internet etc. My main question was – what to use MyISAM or InnoDB? I found the post on the MySQL Perfomance Blog (also this and this) and came to the conclusion, that when SELECT’ing, InnoDB is definitely faster (or, at least, is not slower). In addition, it provides constraints mechanism and allows transactions. The only thing it doesn’t have is FULLTEXT search. One more disadvantage is slower inserts. However, 80% of DB usage in this project are SELECT queries without FULLTEXT. For the fulltext search I created MyISAM table with fields I need and it works fine. The project is finished, but there will be phase 2 and I’m thinking of introducing Sphinx there. Anybody has experience with it?
So I came up with InnoDB storage engine.

Optimizing structure

Next important step is DB structure. I’ll give some background info about the project so you could better understand what I’m talking about. The site collects info from different UK shops. Then users can rate them, add some tags, create articles (called “looks”) and link that articles to the products they’re writing about. And the same (tags, comments, rating) applies to the looks. Here we come across with an interesting question. We can create structure of different types for this:

• Create 2 separate cross-tables for linking Rating to Look or Product
• Create one cross-table and add additional field “type” there to differentiate between Product and Look entities

See both variants in the following images:

Normalized variant

Denormalized version

• If there are 0-2 ratings linked to entity, then normalized variant is better
• If there are 3-5 ratings linked to entity, then denormalized variant is slightly (less than 1%) better
• If there are 6-8 ratings linked to the entity, the normalized variant wins again

I did these tests for different situations similar to this one, in each test I generated random records and randomly linked them with each other. Number of record in Product, Look tables was 10000, in Rating – 20000. Number of records in cross tables varies because the linkings are random.
So I came up with normalizing everything like it should be done according to the DB theory.

The only exclusion of this rule is the following situation. In this project you can add different alternatives to the product. Each alternative is “better” or “cheaper” or “different” etc. And since the only case when these alternatives are pulled from DB is when user views the product, they are pulled altogether, so it is better to keep them in the same table.

Conclusion

• InnoDB turns out to behave better under the high load, it supports transactions and maintains constraints. All that helps to develop better and never leave orphan records.
• Using normalization techniques you usually get better performance
• Create tests and test everything if you are going to do something great

Further reading

• Database Normalization
• MySQL Performance Blog

P.S. I’m looking forward to see your comments on implementation techniques in the high-loaded websites, your thoughts about the InnoDB vs MyISAM question and anything else you can think of

Liked the post? Bookmark it

Hide Sites

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

In December I’ve got a project, that required sophisticated and quite complex DB and that DB was subject to change greatly during first development phase. Before that project I was using Sparx Enterprise Architect both for application design and DB design. But, frankly speaking, it’s not good at databases, especially MySQL. So I decided to pick up a new DB modelling tool.

Requirements

My requirements to it were:

• Convenient entering of the attributes and their types. When I have an idea, I want it to be recorded fast, I don’t want to spend time clicking different “add” and “save” buttons in order to enter table attributes
• Full MySQL features (including all types of indexes) and main storage engines support (MyISAM, InnoDB, MEMORY)
• Visual tables layout like in MS Access
• Maintaining table joins and involved indexes, visual creation of table connections
• SQL export
• Free!

On the way to perfection…

I went through this list and installed and tried around 10 different tools and I didn’t like any of them. One has no visual modelling, other has inconvenient input, third has both, but doesn’t support a number of MySQL features. So finally I ended up with MySQL Workbench. It gives me all I need and even more.

Yes! It’s really perfect

Here you may find a list of features together with versions comparison. You can read it yourself and I want to describe why I liked it:

Nice design

Yes, it matters. When you use Windows95-like program, you can’t feel as good as if you’re using excellent-designed one. Here is a screen:

Model Overview

Creating DB

I liked their “schema approach”. When you create DB, you set the schema default encoding and all the tables in DB are automatically created in this encoding. Sure, you can change it for each table, but this is very helpful. I’ve also set up mydefault storage engine – InnoDB (MyISAM is default). This setting can be found in a seconds; everything is in it’s place (Tools -> Options -> MySQL).
So now I can create my table without remembering that I should change some settings each time I create new table. That’s my first requirement.

Creating tables

I liked their template approach to the generic field names. Near every table has ID field. In my name conventions (since I’m using Yii framework, I follow their), ID field name is [tableName]ID. So I go to the Tools -> Options -> Model and set there:

• Primary key pattern – %table%ID
• Primary key default type – INT(11)
• Foreign key defaults (since I’m using InnoDB, which takes care of data integrity, I set this. I’ll tell more about this in my future posts about MySQL&InnoDB)

Three little settings, but it makes my life much more simple! Actually, you can set up the naming of the auto-generated index fields, but I don’t use it, I create all tables I need myself. However, Workbench can create cross table for Many-to-Many relation for you.
Now I create the table (collation and engine are set automatically), go to the “fields” tab (tabs are in the bottom – I had problems finding them first time) and have my ID field created. Unfortunately, I can’t say that I want first letter in lower-case, so I correct it manually. Then start adding fields. It is very simple. First you double click on the empty row where should one name of the field, enter your name, press TAB, enter the field type (I usually enter 1-3 letters and press “Down” key, it selects correct type), press TAB again and you’re on the next field! So you just keep populating your attributes really fast! Then just tick NN (not null) and AI (auto increment) checkboxes and your table scheme is done. All indexes are set up on the next tab – Indexes except PRIMARY KEY. ID field is PRIMARY KEY by default. To add more fields there, select field and tick PRIMARY KEY checkbox in the right part of the tab.

Visual layout

Consider we created tables we need, now we advance to the scheme and connections. Double click “Add Diagram” in the top of the screen and you’re there. In the centre of the right pane you have tables you created. If you drag table from that list to your diagram, you’ll see big dot near it’s name. That’s also very convenient when you have a number of tables. Sure, here you can snap to grid, show/hide it, but that’s not so impressive.

Visual grouping

And this feature is mega-great! When you have huge DB, you can group tables using coloured layers:

ER Diagram with coloured layers for grouping

Visual connections

Yes, it allows you to connect tables like you want. 1-1,1-N and N-M relations. If you prefer to create foreign keys automatically, yo can use these types of joins. I prefer to create all tables and fields and then connect it. So I click on the last icon in the left toolbar, select foreign key, then click “Pick referenced columns” and finally select the primary key I link to. I’m done. All InnoDB connections are automatically created.

Creating relationship using existing columns

SQL export

Sure, SQL export is not new or impressive feature, but MySQL Workbench allows you not only to create SQL for the scheme, but also to create ALTER DB script for the CREATE DB script already created. For example, you designed a great DB, exported to SQL query, installed on server and then your client wants changes. You open MySQL Workbench project, make necessary changes and then create ALTER script. Very convenient thing

Integration with Yii

One clever guy (unikly) created the Yii shell command, that allows to use mwb file instead of DB connection when creating Yii DB models. This command is available on the Yii extensions page. As for me, it’s a very big plus.

A fly in the ointment

I’ve noticed several bad things in this software:

• When DB becomes huge, you need a good machine to work with it comfortably. It takes too much resources
• Some interface elements are not evident (In the DB overview screen lowest part has tabs both on the top and on the bottom. Top tabs – switch between tables, bottom tabs – switch between table’s sections (properties, fields, indexes)
• When creating joins, it doesn’t maintain the uniqueness of foreign indexes names. Take a close look at the export script (and watch for constraints and auto-created foreign keys) when it fails in phpMyAdmin (or other tool)

Disclaimer: Screenshots are taken from MySQL Workbench site, I was lazy to take my own ones.

Liked the post? Bookmark it

Hide Sites

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.