If anyone is interested in my previous blog posts, you can find them at
http://www.unyoug.com/forums/viewforum.php?f=1
http://www.unyoug.com/forums/viewforum.php?f=1
Wednesday, October 27, 2010
Monday, October 18, 2010
Infiniband coming to a town near you
As the Exadata takes off (I've heard it is REALLY taking off), more and more vendors are opening their eyes to the bottleneck of I/O.
You are going to see some other solutions come to the market that are infiniband based. You are also going to see more solutions like the Storage Cell's.. Just look at the IBM XIV ! they have storage cells just like the exadata with large caches. The concept is catching on..
But what does the Exadata have besides the obvious ? It has the ability to parallelize the I/O at the storage level.. I'm sure you going yea. I knew that.. but think about it.
a) Exadata.. run a non-parallel query that does a FTS on a 5tb table. You will marshall all the resources of the I/O from a single query on a single NODE
b) XXXXXX.. Run a non-parallel query, and you only will be able to marshall all the I/O that the single CPU can handle.
Sure you can build an Exadata like solution, but in order to utilze the power of the storage/infiniband subsystem you need to parallelize across multiple CPU's.. This uses a lot of CPU's, and parallization might not be the best plan for all queries.
In my mind, this is big bonus of the exadata.. Parallize or not, you can do FTS's at 20.8g/s
You are going to see some other solutions come to the market that are infiniband based. You are also going to see more solutions like the Storage Cell's.. Just look at the IBM XIV ! they have storage cells just like the exadata with large caches. The concept is catching on..
But what does the Exadata have besides the obvious ? It has the ability to parallelize the I/O at the storage level.. I'm sure you going yea. I knew that.. but think about it.
a) Exadata.. run a non-parallel query that does a FTS on a 5tb table. You will marshall all the resources of the I/O from a single query on a single NODE
b) XXXXXX.. Run a non-parallel query, and you only will be able to marshall all the I/O that the single CPU can handle.
Sure you can build an Exadata like solution, but in order to utilze the power of the storage/infiniband subsystem you need to parallelize across multiple CPU's.. This uses a lot of CPU's, and parallization might not be the best plan for all queries.
In my mind, this is big bonus of the exadata.. Parallize or not, you can do FTS's at 20.8g/s
Wednesday, October 6, 2010
Exadata and indexes
This has been a very interesting topic around my shop.. Some people say that you can get rid of all you indexes, some people say no..
Well first lets look at why you have indexes and rule out those as removal candidates.
1) Indexes that support Primary keys. Gotta keep those right ?
2) Indexes that support RI to avoid locking. OLTP ? Gotta keep those.
For a lot of OLTP applications, just the 2 above criteria is enough to keep most of your indexes in play. But what about everything else.
Here is what I've been seeing. The exadata can scan like crazy, but there is a limit (20.8 on a full rack, do the math for your configuration). If you have a FTS on a table containing 50G, you can see that you utilizing ALL I/O for almost 3 seconds. if you have any concurrency, you can imagin what happens.
So in my mind the answer is to keep indexes where they can significantly limit the data access.
Well first lets look at why you have indexes and rule out those as removal candidates.
1) Indexes that support Primary keys. Gotta keep those right ?
2) Indexes that support RI to avoid locking. OLTP ? Gotta keep those.
For a lot of OLTP applications, just the 2 above criteria is enough to keep most of your indexes in play. But what about everything else.
Here is what I've been seeing. The exadata can scan like crazy, but there is a limit (20.8 on a full rack, do the math for your configuration). If you have a FTS on a table containing 50G, you can see that you utilizing ALL I/O for almost 3 seconds. if you have any concurrency, you can imagin what happens.
So in my mind the answer is to keep indexes where they can significantly limit the data access.
Subscribe to:
Comments (Atom)