List:Internals« Previous MessageNext Message »
From:Mats Kindahl Date:May 12 2009 7:32pm
Subject:Re: MySQL Reengineering Project
View as plain text  

Alex Esterkin wrote:
> Let me play a devil's advocate role and throw in my grumpy 2 cents.
> 
> First, let us clarify what exactly constitutes the public handler API.   It
> is much more than the set of functions defined in the sql/handler.h header
> file.   Presently, you have to include  the entire transitive closure of all
> public methods of all classes used as arguments.   There are many storage
> engines out there, especially the transactional and the column-oriented
> ones, that use THD member variables and member functions.  Download and take
> a look at the Infobright Community Edition source code to see what I mean.

Absolutely. This is one of issues that has been brought up many times.

> 
> Second, the entire MySQL code based is glued in hundreds of different ways
> by using the same classes and structures.  In software architecture terms,
> MySQL has an absolutely monolythic domain model.   To decouple different
> processing areas, you will have to create independent domain models for
> each, so that you could consistently implement separation of concerns.
> Presently, MySQL lacks separation of concerns: the same parse tree is used
> at every stage of query processing.   On the other hand, in Postgres, a
> parse tree is represented by a Query structure (a tree of C structures), the
> query optimizer generates and considers a bunch of throwaway Path tree
> structures, then the query planner generates a tree of Plan nodes (Plan
> tree).  The query execution is a state machine; Init...(_) functions
> generate various PlannerInfo structures/nodes, which are ultimately
> responsible for runtime query execution.  In the Postgres world, only Query
> tree and Plan tree need to be copyable and serializable.   This makes sorce
> tree organization simpler and cleaner.  Without implementing such separation
> of concerns, MySQL architecture will remain monolythic.   [To be fair,
> Postgres code is monolythic as well, but in a very different way]
> 
> Third, for many storage engines, there will be extra software engineering
> cost of chasing your refactoring changes, especially if some of the changes
> go against storage engine's architectural assumptions.

You might be interested in taking a look at WL#3859
(http://forge.mysql.com/worklog/task.php?id=3859) and the associated worklogs.
We are basically moving towards a model with version-stable interfaces

> I wonder if the MySQL refactoring news may indicate a tug of war between US
> based and EU based Sun / MySQL teams?

Not from where I see it.

> We already have one MySQL refactoring project under way?  It is called Drizzle. Is
> this a "Drizzle
> Reloaded" project?

Not really; Drizzle has a very drastic approach to the re-engineering, for good
and for worse. This is a project focused at breaking the monolithic model that
you have observed to both allow internal developers to work easier with the code
as well as making it easy for external developers to extend and alter the system
to their needs. Thus, we are not planning for a "major rewrite" (and personally,
I advice against it since we would be doing our users a disservice.)

> By the way, Drizzle can be used as an illustration of
> how easy it is to go too far: views and prepared statements are no longer
> supported in Drizzle.

Which is why this is not a "Drizzle Reloaded" project. Without speaking for
them, my observation of the Drizzle project is to attempt a drastically
different approach. The same approach has been seen when building extensible
microkernels instead of monolithic operating systems. Leaping to the same
conclusions for database management systems is not far away.

Just my few cents,
Mats Kindahl
-- 
Mats Kindahl
Senior Software Engineer
Database Technology Group
Sun Microsystems
Thread
MySQL Reengineering ProjectManyi Lu - Sun Norway12 May
  • Re: MySQL Reengineering ProjectJay Pipes12 May
  • Re: MySQL Reengineering ProjectMARK CALLAGHAN12 May
    • Re: MySQL Reengineering ProjectMats Kindahl12 May
      • Re: MySQL Reengineering ProjectManyi Lu - Sun Norway12 May
        • Re: MySQL Reengineering ProjectMats Kindahl12 May
    • Re: MySQL Reengineering ProjectStewart Smith13 May
  • Re: MySQL Reengineering ProjectMikiya Okuno18 May
    • Re: MySQL Reengineering ProjectSergei Golubchik18 May
      • Re: MySQL Reengineering ProjectRoy Lyseng18 May
Re: MySQL Reengineering ProjectAlaric Snell-Pym12 May
  • Re: MySQL Reengineering ProjectMats Kindahl12 May
    • Re: MySQL Reengineering ProjectJay Pipes12 May
      • Re: MySQL Reengineering ProjectJay Pipes12 May
        • Re: MySQL Reengineering ProjectAlex Esterkin12 May
          • Re: MySQL Reengineering ProjectBrian Aker12 May
      • Re: MySQL Reengineering ProjectSergei Golubchik12 May
        • Re: MySQL Reengineering ProjectBrian Aker12 May
          • Re: MySQL Reengineering ProjectSergei Golubchik12 May
            • Re: MySQL Reengineering ProjectAlex Esterkin12 May
              • Re: MySQL Reengineering ProjectBrian Aker12 May
            • Re: MySQL Reengineering ProjectJay Pipes12 May
              • Re: MySQL Reengineering ProjectDavi Arnaut13 May
              • Re: MySQL Reengineering ProjectAlex Esterkin13 May
                • Re: MySQL Reengineering ProjectJay Pipes13 May
            • Re: MySQL Reengineering ProjectMichael Widenius14 May
          • Re: MySQL Reengineering ProjectJonas Oreland13 May
        • Re: MySQL Reengineering ProjectRoy Lyseng12 May
      • Re: MySQL Reengineering ProjectMats Kindahl12 May
    • Re: MySQL Reengineering ProjectAlaric Snell-Pym12 May
      • Re: MySQL Reengineering ProjectMats Kindahl12 May
      • Re: MySQL Reengineering ProjectMichael Widenius14 May
        • Re: MySQL Reengineering ProjectAlaric Snell-Pym15 May
          • Re: MySQL Reengineering ProjectKristian Nielsen15 May
            • Re: MySQL Reengineering ProjectBrian Aker15 May
            • Re: MySQL Reengineering ProjectAlaric Snell-Pym15 May
          • Re: MySQL Reengineering ProjectMichael Widenius6 Jun
Re: MySQL Reengineering ProjectMats Kindahl12 May
Re: MySQL Reengineering ProjectAlex Esterkin12 May
  • Re: MySQL Reengineering ProjectMasood Mortazavi13 May
    • Re: MySQL Reengineering ProjectBrian Aker13 May
    • Re: MySQL Reengineering ProjectAlex Esterkin13 May
      • Re: MySQL Reengineering ProjectBaron Schwartz13 May
        • Re: MySQL Reengineering ProjectStewart Smith13 May
          • Re: MySQL Reengineering ProjectBaron Schwartz13 May
    • Re: MySQL Reengineering ProjectAlex Esterkin13 May
    • Re: MySQL Reengineering ProjectStewart Smith13 May
  • Re: MySQL Reengineering ProjectMichael Widenius14 May