14827 items (1495 unread) in 26 feeds
Database
(1495 unread)
This is a temporary post that was not deleted. Please delete this manually. (615c35b0-2189-45d9-bae4-8d3aa8d66447)
---
Related Articles at Eddie Awad's Blog:
I'm visiting customer in Zurich next week and also was invited to give a talk on MySQL Performance Wednesday November 21.
If you're in the area please feel free to drop by I'll start by talking about Query Optimization and we'll keep it interactive to see what else audience would like to know.
Entry posted by peter | One comment
I was thinking today of how people tend to use MySQL in modern applications and it stroke me in many cases MySQL is not used to process the data, at least not on the large scale - instead it is used for data storage and light duty data retrieval. Even in this case however the cache (ie memcache) is often implemented to offload MySQL.
When it comes to large scale data processing other techniques are used. Google uses some bigtable based technologies for search and Google Analytics (which is quite typical log processing application), when you look at recommendation task as well as a lot of other personalized services they may not use MySQL (and SQL at all). In many cases you would see absolutely custom solutions are implemented, in other cases you would see Hadoop or Sphinx used to crunch data in parallel or it even could be special wrapper on top of MySQL do do the work
The reason for this is not only because many tasks are not well expressed in SQL or map to relational data structure to well, but also because of lack of build in parallel processing. When you need high data processing speed you simply can't do it on single CPU especially since systems are getting wider more than CPU cores get faster, though even single node does not take you that far.
MySQL concept of Single Query=Single Thread works well when few rows needs to be analyzed which often forces us to do tricky optimizations because if query has to analyze 10.000.000 of rows you're busted - it simply will take too long for user to wait for reply (especially in modern age of AJAX applications with sub second response requirements). Note you will have to solve this problem even if it is relatively rare case and in most cases it will take much shorter time. This is why we have to do careful indexing build summary/cache tables hunt queries which traverse a lot of data and kill them.
Now think what happens if you Search Google or engage in any other processing intensive activity. If result is not served from cache you will have many CPU seconds if not minutes used processing your request, but you get reply fast because hundreds and thousands of CPUs were handling data for you in parallel.
You may argue limited number of applications needs so serious data crunches - could be, however the number of such applications would likely grow in the future. Mobile Internet is to seriously increase number of global Internet users, plus we see more and more personalized services in terms of information provisioning, advertisement, social interactions etc which will need to employ more and more complex algorithms as they mature.
Interesting enough so far MySQL does not have anything which tackles this need, even on the roadmap.
Indeed MySQL has MySQL Cluster but it is quite different. MySQL Cluster at this point is a cluster in terms of Storage - only minor aspects such as data filtering can be offloaded and performed in parallel while a lot of other jobs such as sorting, unions/instersections have to be performed on the SQL node.
May be MySQL Cluster will evolve and data storage nodes will be able to perform all kinds of operations, in which case it will become much more helpful. Of course if it also drops a lot of its other limits and will be able to scale to thousands of nodes.
Entry posted by peter | 8 comments
A user wrote in asking for clarification on polymorphic view objects. He had started by creating a base Emp entity object without a Comm attribute, having its Job attribute marked as the discriminator attribute. Then, he extended Emp to create Clerk entity object as well as a Salesman entity object, in both cases overriding the Job discriminator attribute to set the appropriate default value for that subtype. In the Salesman entity, he added the additional Comm attribute for commission. He wanted to know why his polymorphic view object was not giving him access on the client side to the additional Comm attribute in rows where the Job was equal to 'SALESMAN', the discriminator attribute value for the Saleman entity object. In this entry I try to clarify why the behavior he was seeing is correct, and how to achieve what he wanted to do.
There are two kinds of polymorphic view objects that we support. These two types are documented in Dev Guide sections:
When you use the first kind of polymorphic view object, as this reader was doing, the different entity usage subtypes are opaque to the client. As far as the client layer is concerned, every row in the view object's result set has the same set of attributes and row type, even though under the covers ADFBC ensures that the correct EO row subtype is created based on the discriminator attribute value. In other words, with a polymorphic entity usage, only the entity row parts of a view row are changing type, but the view row type is constant.
The second type of polymorphic view object involves defining a hierarchy of view objects, and then configuring the application module to allow one or more view row subtypes in the result. Only the second type of polymorphism produces different subtypes of client-visible view row types. Only this type allows the client to "see" a subtype of a client view row with an additional attributes.
You can use either type of polymorphism on its own, or combine the two, at your choice. So, to achieve that the reader wanted to accomplish, he would need to define a base EmpView having his base Emp entity object as its entity usage. Then, create ClerkView VO that extends EmpView and SalesmanView that extends Emp. Finally, in the application module editor, he would need to configure ClerkView and SalesmanView as view subtypes to allow for the EmpView view instance. Then, in the client layer, rows for salesmen would have an additional Comm attribute available.
P.S. Another thing that came up in answering his question was that he was allowing the ADF polymorphic discriminator attribute filtering to narrow down the query to only contain the expected subtypes. However, it's not best practice to rely solely on the discriminators to perform type filtering in the query as this will effectively end up querying all rows and then "throwing away" rows that don't qualify any of the disciminator values in the middle tier. See section 27.6.4.1 Your Query Must Limit Rows to Expected Entity Subtypes in the dev guide for more info.
When I watched Sunday Night Live--the Keynote with Larry Ellison from Oracle OpenWorld 2007--I thought it was interesting that they had current and former cast members of Saturday Night Live. Typical corporate event for famous people, I suppose. Kevin Nealon did a good job, considering the nature of the material. Victoria Jackson was great, too.
But now I read about the writer's strike affecting SNL, and how they just fired a large portion of their production staff. Don't know how this affects the actors, but it can't be good for them, either. Good thing some (one?) of them got a few extra Hamiltons to help them get through this season.
And don't forget: Tom Kite is a great professional golfer, but Tom Kyte is also a great professional Oracle employee.